It is no secret that a vocal minority of developers distrust or dislike SEO. Located in the largely-abandoned hinterland between marketing and technology, it incorporates elements of both. This makes both traditional marketers and developers suspicious, and sometimes rightly so.
There are good reasons for developers to harbour some degree of antipathy towards SEO. Sometimes we will look over a build that was supposed to be final and pick at the edges, finding what seem to be pedantic discrepancies with the standards. We are sometimes more closely aligned with marketing than development, so our requests might make life difficult for you in order to achieve goals that the marketing department then takes credit for. Finally, there are bad actors within the industry that are more than capable of putting a developer off SEO for life.
That’s why it might seem counter-intuitive that I’m suggesting that SEO is not just a useful tool in the web developer’s toolkit, SEO is a developer’s most powerful secret weapon.
Using SEO To Get What You Want
We’re not going to make you a sales pitch here, we’re just going to explain how and why our goals and your goals align – and how you can use that alignment to get what you want.
The short phrase “Because SEO” is your key to getting your way, improving the experience of the users on the site, and making your company more money. How so? Well, think of a development best practice, or a web standard that has gone sadly neglected in favour of getting things live, or just a fancy new toy. It is close to certain that you can either draw a direct or indirect line between what you want and generally-improved SEO.
It’s easy to say that, it’s harder to explain – so let’s avoid explanations and go straight to concrete examples!
“That isn’t what that’s for!”
Whether it’s <table>s being used as footers, 302 redirects being used in place of 301s, or URLs being anything but ‘U’, there are all kinds of accumulated hacks and work-arounds that plague modern websites.
Using strange, meaningless HTML was essential, of course, back in the days when IE6 still had too much market share (that is to say, it had market share). Maybe these practices even eased the transition from still-older practices, like putting everything in frames.
The important thing is that they’re just not being used right! What’s more, with the HTML Living Standard as it currently exists, it has never been easier to use clear, semantic HTML that actually reflects and conveys your intentions.
Now, though, it’s time for a rework, to clean up all the loose ends. Except no-one else really sees the problem – the website looks fine, just like it always did, and when you try to explain about keeping a distinction between presentation and semantic HTML, and quirks mode, and the difference between a ‘temporary’ and ‘permanent’ redirect, and why a 303 or 307 might be preferable to a 302…
“Because SEO”
This is the perfect time to play the SEO card.
Before the boss’s eyes glaze over, before they make a resolution to give you time for the overhaul next year, before they just dismiss it as a bunch of technicalities, make sure they understand that a website doesn’t just have to ‘work’ to rank well.
An HTML document is not a program; it is a form of communication. To rank well, you must communicate clearly to all interested parties what each part of your website is for – and a search engine is a very, very interested party.
Misleading practices like returning a 200 header code when a page isn’t found, using semantic elements (like <table>) for display purposes or using an image alt tag to store data about the image might be ignored by users, or they might find a way around them. Search engines are not as clever as your users, and your site’s overall SEO will suffer if you use the wrong tool, header or markup for the wrong purpose, even if it ‘works’.
Bring up the potential impact on organic traffic, and suddenly your relatively dry technical recommendations become glaring errors that need urgent action.
“We just don’t need so many libraries!”
JavaScript libraries, in particular, can spiral out of control. When everything is humming along, a single heavy JavaScript library may be essential to your site’s continued functionality. It is likely to automatically include polyfills to support older browsers, be as performant as possible in the most common situations (once it actually loads), and generally stop you from having to reinvent the wheel.
Over time, though, other developers add another library to deal with presentation, and another to deal with JSON-LD, and a framework because they are just more familiar with working in that framework than in vanilla JavaScript. Eventually, one of the newer developers adds the latest version of jQuery, and finds that some of the older code now breaks when you remove the older version. So you keep the old version of jQuery running alongside the new, because no-one has time to deal with it right this second, and eventually you have up to ten libraries, two or three frameworks (one of which may be a near-duplicate in terms of functionality), and an additional library to ensure smooth interoperation between them all.
This is not hyperbole. Development can be chaotic, and it is not uncommon to find jQuery.min.js live on the same page as a complete jQuery.js. A mournful Mustache.js lingers, ungroomed and forgotten, long after the developer who was trying it out has left the company – and no-one who is left is brave enough to try to find out if anything depends on it. Angular.js lurks in a corner, after yet another former developer wedged it forcibly into the site to build up their C.V. and land a job building web apps.
Often, the time required to rebuild a site to be less dependent on libraries seems excessive to non-technical management compared to the benefit, but it is often worth it to make the site more performant, more modifiable, and faster to load.
“Because SEO”
There is a direct link between SEO and page load speed, especially for mobile. You can often achieve greatly reduced page load speeds just by trimming the fat on the frontend and implementing some kind of cacheing on the server side.
Theoretically, we should all be aiming for load times of under a second on desktop, leaving room to allow for slower load times on most mobile networks. This is a noble goal, even if it is not achievable for many websites, but to put it in context that is roughly equivalent to a complete copy of jQuery and two large background images using a standard, cheap hosting provider.
Reaching that goal may be difficult, but the closer you get the more benefits you will reap. You have the added advantage that, while Google considers your page load speed when it is considering your Search Engine Ranking, it also considers how users treat your pages. Reducing page load speed and complexity goes a long way towards reducing bounce rates and generally improving user experience, especially on mobile. These improved user engagement metrics are taken into account by Google in addition to the impact of raw page load speed improvement, which leads us neatly on to the next item on the wishlist.
“We need to overhaul the design!”
The world of design moves inexorably onwards, and for purely practical purposes you need to stay close to modern design. Maybe your site is, like Amazon’s, a little on the utilitarian side, or maybe it is, like Le Coq Sportif or Hard Graft, more focussed on image and flashy design. Either way, you’re aware that it is especially important for client-facing design to use the principle of least surprise, which means that keeping pace with broad User Experience trends, at the very least, is important.
Dropdown menus, for example, were great for desktop (or, at the very least, the best we could do), but now we have to cater for mobile as well and we need an entirely different way of navigating a website. It’s becoming more and more common to see websites do away with dropdown menus altogether, preferring to use a mobile solution that also works on desktop. Consequently, your users might have lost the habit of expecting to see further details on mousing over a particular menu. Dropdown use decreases, and as a result if you have something important hidden in a dropdown you might see fewer conversions.
Away from the much more sharply graded shifts in user experience design, the current major design trend seems to be overwhelmingly in favour of simpler, flatter, more seamless designs. Features that may date a website such as gradients, border-radiuses, and a lack of easing-in for thumbnails and other images could give users the impression that the website is rarely updated or maintained, and decrease trust.
The amenability of your peers to design overhauls will vary greatly from business to business. If they are dead set against updating the site, then you will probably still need to wait until it is observably leaking huge amounts of money before they will even consider making a change. If, on the other hand, they are keen to get started tomorrow, they will probably be quite happy to go along with your suggestion
“Because SEO”
We have already touched on how user experience can affect SEO by decreasing bounce rate and increasing user engagement metrics such as time on site. Less tangible design changes still have an effect, and having an attractive site is a strong signal to users that your site is reputable, respectable and reliable. Anything that can increase user trust and time on site will improve your key user engagement metrics, which (as well as boosting your conversion rates) should significantly affect your site’s SEO.
“We need to use the new thing!”
Web development is going through something of a glut of tools, libraries, frameworks and various other pieces of software at present. Whether it’s an essential part of the deployment process, a program to help your non-technical staff to use version control programs, or a fresh CSS framework developers are constantly offered new, exciting ways to streamline their workflow, accomplish difficult tasks with ease, incorporate backwards compatibility automatically and generally just make life easier.
It’s often hard to explain why this new thing is so different from the last new thing, how it will actually help the bottom line, and whether or not it’s worth the investment to make the developer’s life easier (or the product better) if it’s a paid tool.
If you really want to make your pitch even more convincing, add in a “Think of the SEO!” for good measure.
“Because SEO”
This is absolutely not a direct link, but it is still an important one. A well-populated, respectable developer blog is a powerful SEO asset for technical and media companies, attracting very high quality traffic and superb links.
One of the best ways to populate a developer blog, in turn, is to talk about exactly what you’re doing with the new tools. As much as it is important that you have access to the tools you need, it’s important that you can have confidence in your tools. Developers everywhere are trying to find out if the new shiny tools are any good, and nothing is more reliable than a first-hand account from hands-on experience.
It isn’t just tech giants that have dedicated developer blogs any more. eCommerce, media and startups in all sorts of sectors have some kind of space that explains what their stack is, why they picked it, and how well it works. There’s no need to be coy about your tech, either. No-one will berate for using PHP when Facebook uses it (or at least, only the few residual trolls that lurk on every internet discussion – and if you’d used something cool like Haskell instead, they’d still have some complaint or other).
In the mean-time, being responsible for a good chunk of recognition, trust and traffic should raise your own profile, too!
Talk To Us!
If you’re a website manager, web developer or CTO who’s on the fence about SEO, we’d love to talk to you about what you need and how we can work with you. Or, if you’re a marketing manager, business development manager, CMO or CEO, we’d love to discuss the technical changes that could help your site attract more buying customers.
