I spend about half my time working on large, commercial website build projects. Ostensibly I’m there to lead on technical SEO, but in practice I often find myself involved in everything up to and including debates about subtly different connotations of apparently similar words in languages I don’t understand.

And that encapsulates SEO pretty well: you need to know a bit about a lot, be prepared to learn about anything that becomes important to the job in hand, and know how to connect and apply those disparate bits of knowledge.

Web design wireframe
A basic website wireframe cobbled together at General Assembly’s rather excellent UX Bootcamp

The technologies involved in all of this – websites, search engines, mobile devices – are all developing at an incredible pace, and since most organisations are heavily dependent on organic search traffic, it’s critical not only that web development projects have SEO input, but that it’s fundamental to the whole process and happens from day one.

Of course, the reality of actually making this happen – especially for really big projects – is an art in itself, and it took me the best part of a year to get to a point where I felt I had a good idea of how it should work. Your mileage may vary, but here’s what I’ve learned.

Get in early

The sooner the better. Unless someone with SEO expertise is being consulted when statements of work and contract agreements are being drawn up, you’re almost certainly going to find out that something important got missed well past the point you can do anything about it.

Not only that, you need to meet all the key players, understand how the project will work (milestones, deadlines, client involvement) early enough to be able to concoct a plan – even a temporary one – for what you’re going to deliver, when, and to whom.

Finally, if you’re not familiar with all of the various disciplines involved – user experience design, content strategy, whatever project management methods are being applied – having the time to understand them will pay off later.

Set up working practices you can stick to

Each build is a unique combination of requirements, deadlines, budgets, personalities, client priorities and so on, and consequently there is no perfect SEO process that can be applied to all builds. So be all zen about it: rather than trying to impose a pre-determined process to a project, let the project inform your process.

Gradually feeding in SEO consultancy throughout the design and build processes is more efficient because it avoids the (hopefully) obvious problems associated with dropping huge amounts of information in batches. That is, small but frequent course corrections are preferable to sudden handbrake turns, and the latter probably won’t be possible anyway due to deadlines.

Some starting points:

  • Decide which regular meetings you need to attend to keep SEO on track. Choose carefully – you don’t want to burn all your time on interminable meetings about font sizes and what colour the footer should be.
  • If you have to, set up your own SEO-focussed meetings, but keep them short and to the point.
  • Learn how the issue tracking and ticketing system will work. At DigitasLBi we use Jira, but there are lots of alternatives including many that are free and open-source, and even an Excel spreadsheet will do in a pinch.
  • Decide how you’re going to use your ticketing system to support your SEO objectives. For example, I don’t like having SEO requirements on their own tickets as it complicates workflows, makes it easy for things to get missed, and reinforces the idea of SEO as separate from the build. Far better to contribute to writing the specification and requirements for each task.

Talk to everyone often

You can solve a lot of SEO problems before they happen by being there when designs are still little more than sketches on paper. It’s surprising how much detailed functionality is conceived well before any developers get involved, especially if you’re skipping the sketches and wireframes and moving straight to prototypes. Don’t make the mistake of thinking you only need to talk to the people doing the build and content.

Likewise, project managers aren’t there just to knock out Gantt charts and drag you into meetings. They’re usually the only people who always know what everyone’s doing, especially on really big projects; taking the time to chat with them about what you’re up to can often lead to finding out about things you might otherwise miss.

Offer concise, easy to use documentation

Avoid the temptation to provide the team with large, detailed documents specifying every conceivable SEO requirement, alternate approaches, rationale, etc. Nobody has the time to read it even if they have the inclination.

Moreover, the nature of a build is such that you need to deliver small, task-specific bits of information to different people at different times: don’t rely on the interface developer remembering to consult your manual when he re-builds the navigation for the umpteenth time.

So weaving your requirements into each task is most efficient, but you do want to be able to refer to something more detailed and explanatory when the situation demands it. For that, have a regularly updated and thorough set of guidelines available in a place everyone can access it, and refer back to those fuller explanations in your annotations, work tickets, what have you.

Whatever you do, keep rationale to a minimum. A few sentences at most will usually do. If anyone needs more than that, go and have a conversation with them or deal with it in a meeting, but do make sure you’ve very prepared to rationalise your requirements in detail if need be.

Agree a sign-off process and stick to it

One of the benefits of getting in early is that you should be able to plan sensible times for you to sign-off on designs, modules and so on before things progress. Be careful to define exactly what you expect giving your approval for something to look like and how it should be recorded.