Where SEO Belongs In The Web Site Development Cycle

Many in-house SEOs are actually marketers with minimal technical background or insight into the web site development process. Often, these people either have an interest in SEO or were already managing other marketing functions. Because they are new to SEO (and often times new to web site development), they often struggle with getting their requirements noticed and live on the site. The key to getting your requirements out there is by injecting yourself into the primary portions of the project that are used for developing the site—which basically means that you need be involved in the key deliverables that go to management and the programmers.

To give you some guidance for your upcoming projects, I have outlined the areas of a project where I inject myself for each web site release:

Project charter document. Most companies develop an initial charter document. It’s been done differently in every company I have worked with, and each had its own name for this document. In a nutshell, it’s an overview of what the product is (or what the major enhancement is) and how it will function, along with business goals. The reason you want to get your SEO goals and strategy ideas into this document is so that the project team is held accountable for the inclusion of search engine friendliness, and so that key stakeholders are aware that SEO is a strategy for this release.

Here’s a tip: There is often a time span required to create these documents, so be sure to comment in the beginning about your strategic ideas, potential search engine obstacles, and anything that upper management and development needs to be aware of so that they know your thoughts very early in the process. Also, be sure to comment at the end of the time span so that you can provide SEO feedback on anything that was added since you reviewed the document.

Every change request. As the person responsible for SEO, you should know everything your development team puts on the site, even if it is back-end changes. The reason is that you need to know if the change will impact what is sent back to the user’s computer. If it will, then it has potential SEO complications or may offer new SEO opportunities. No one else on the development team can make this type assessment. When I’m assigned a website, I look at every single change request description to see if it has an SEO impact, and if I don’t understand it, I ask. If there are SEO points to consider, I put a notation in the change request that includes SEO requirements and/or says that they need to pull me in for the requirements discussion.

Here’s a tip: Include your comments not only in the description, but also in the historical comments because in many change management systems the historical comments made on the change request cannot be deleted; whereas I’ve had many notes in the description mysteriously removed more than once.

Wireframe reviews. Get involved in wireframe development, preferably reviewing wireframes with the user experience designer (UED) before it is presented to the project team. When I’m on a project, the UED and I iterate on wireframes about 2-3 times before they are presented to the project team.

Here’s a tip: Add SEO notes to your wireframes. Most wireframes contain notes on functionality, how content is to be displayed, etc. Work with the user experience designer to incorporate SEO notes into the wireframe document for each page. This is important because programmers code from wireframes and use cases/tech specs that are written based on what appears in the wireframe document.

Visual design reviews. Work closely with your visual designer so that headlines are not images, key content elements are not images, etc. Review all visual designs and talk about each element to ensure that the design is SEO friendly. As with the wireframes, I often iterate with the visual designer a couple of times before anything is presented to the project team.

Here’s a tip: Train your visual designers on SEO limitations. Once they understand the searchbot’s limitations, they can create visual designs that meet the SEO goals.

Code reviews. You need to be looking at the code that renders in the browser to make sure it’s done properly for SEO. It’s the only way to notice problems like multiple H1 tags, extensive JavaScript that’s not in external files, etc.

Here’s a tip: This is one of the easiest things to outsource and the portion I have outsourced the most. When your plate is full, it’s great to just copy the code and delegate its review to someone else, because they typically do not need to be brought up to speed on project details to complete this task.

Use cases and tech specs. This one is the most painful things to get involved in, but it is vital that you sit down with the person writing your use cases and tech specs (typically a business analyst) and walk through all of the documentation. This is your chance to ask questions about how things are being done and to expand on directions so that things are developed and launched—because this is what the programmers use for development. As uninteresting as this portion of the project is, I do this for every project and typically all at once (for new sites the printouts are often at least 2 inches high).

Here’s a tip: To make it a bit easier, hold these meetings at a local coffee shop and expense it.

QA testing.Unfortunately, just because you spec it and everyone knows about it, that doesn’t mean your requirements will make it into the final product. What you need to do is participate in QA testing before every release goes live. Spot check for things that may have gone amiss during development, such as: are page title tags unique, header tags still there, etc. Then, every single request you made for the release needs to be QA’d.

Here’s a Tip: Train your QA team on SEO elements and get your items on their radar (and in their QA test scripts). While I still encourage you to do your own QA testing, they may catch things before you get to your round of testing, thus it can save you time overall. Also, if you have 301 redirects being launched, be sure to check these both before and after the release—in my experience they go live correctly 60% of the time, even if they’ve looked correct pre-launch.

The biggest tip of all: If you are not currently involved in these activities, you need to take action to get there. These are areas where key decisions are made regarding the site and where programmers are given specific details on how to code—this is where an SEO needs to provide their input and guidance. Talk to the program manager about reeling you in to participate in these deliverables. And if you only do one thing to inject yourself in these areas, befriend the project manager, because the project manager controls the “completed” status of all activities and they can ensure that you are involved every step of the way.

If you don’t have the technical expertise to do these activities, then you need to sign up for SEO training and/or outsource to a consultant to fill in your gaps of knowledge. Bear in mind that one or two training courses probably won’t be enough for you to start doing code reviews if you have never programmed, or to review tech specs if you aren’t technical. Fortunately, decent SEOs can be found at $300-$700/hour. It is rare to find a great one at the lower price point, but they are out there, and many of these activities won’t take more than a couple of hours for a seasoned expert.

Jessica Bowman is an in-house SEO Evangelist at Yahoo! Inc. relishing in the human side of SEO, and author of the SEM / SEO In-house Blog. The In House column appears on Wednesdays at Search Engine Land.