SEO for Web Developers

I’m due to give a talk at one of those surprisingly fun crowdsourced unconferences – BarCamp Belfast. My talk will be about what web developers can do to ensure the websites they build are search engine friendly. Too often I’ve had to work with websites that seemed built to thwart search engines instead of welcome them, so it’s a topic dear to my heart.

I’ve had some great input from the members at the SEO Training Dojo and have a clear idea of what I want to discuss in this 30-minute talk I’ll be giving, but I figure it never hurts to get some extra input. I’m sure the the State of Search audience has their own horror stories about SEO-unfriendly websites to share.
Anyway, here are my key points for web developers to keep in mind when developing SEO friendly websites:

Parameters in the URL – resist the urge

I know it’s easy. I know it makes perfect sense for coders. I know it helps keep things transparent. But please, for the sake all SEOs around the world, don’t put parameters in your URLs!

There are countless things that can go wrong with URLs containing parameters, from duplicate content issues to indexation-loops. But worst of all, search engine spiders really don’t like parameters. Yes, with Webmaster Tools you can tell Google what parameters you are using, but really, that’s like using a band-aid to fix a severed limb.

Your URLs should be static, straightforward, and human-readable. No parameters. If you can’t build a website that serves only static URLs, you shouldn’t be a web developer. There’s no excuse to use query values, session IDs, viewstates, or any other type of parameter in your URLs.

Just to make sure you really get it, here are two examples:

This is a bad, bad URL: http://www.example.com/default.aspx?p=20&num=100&id=AE987BC1220CXH&x=…

This is a good URL: http://www.example.com/category/product/

The URL doesn’t have to end in .html, it doesn’t even need a hierarchical structure (though for site management purposes I do recommend it), but please for the sake of all that is right, don’t use parameters!

[Note: there are always exceptions, but if you give web developers a finger they’ll take your whole bloody arm, so I won’t mention any of them here.]

Structure your code as if your in-laws are visiting

You know that sudden feeling of dread you experience when your partner kindly informs you your in-laws are coming to visit, and you look around the house and it’s as if a clusterbomb went off? Yes?

Now I want you to experience that same dread every time you look at your own code and you can’t immediately tell when your navigation ends and your content begins.

Code structure is one of the hardest things to do, but clean code pays itself back in so many different ways that it’s worth every bit of the effort you’ll be putting in to it. From faster load-times to cross-browser compatibility, from manageability to (of course) SEO, clean code helps!

Here are some tips to keep in mind when coding up a website to make sure your code doesn’t get you in trouble with your in-laws.. eh, I mean your SEO:

Use unsorted lists for the navigation

Put the body content high up in the code

Use h1-h2-h3 tags for headlines

Keep the body content in an unbroken segment

Use standard code for bold & emphasized text

Try to minimise CSS and JavaScript in the page code but keep it in separate files

Concentrate your CSS and JavaScript in as few files as possible

Put the code for trackers & analytics at the bottom

Try to limit browser repaint events

W3C compliance is not a must, but it doesn’t hurt to aim for it

Know your HTTP status codes

You know when you call someone on their mobile, and it rings a couple of times, and then you hear them say “hello” and you say hello back and start talking only to suddenly realise it’s the voicemail you’re talking to? It sucks, doesn’t it. It just isn’t funny. You think you’re talking to a real person but instead you’re jabbering to some dumb machine.

Sending the wrong HTTP status codes is exactly like that. When a page doesn’t exist, don’t send a 200 code and redirect to the homepage. Send a 404! When a page has been permanently moved or has expired, don’t send a 302, send a 301! Gone is gone, and using a 302 temporary redirect is like moving homes and sending your mates a card saying that you’ll only be moved for a short while instead of forever. There’s a big chance they’ll show up at the wrong place for your house-warming party.

Understand your HTTP status codes, know which one to use when, and don’t try to be clever with them – it’s not gonna work.

Sharing the pain
Even though I have plenty more to say about SEO for web developers (be nice and put GA tracking in by default, mind your link structure and internal anchors, don’t use Flash/JS for nav purposes, etc) but this blog post is turning out to be quite long enough already. And I want to save some goodies for my presentation at BarCamp Belfast.

So what are your web developer horror stories? Share them in the comments and we can all laugh at your pain. Schadenfreude and all that.