Information Architecture - A Site Review is Nothing Without It

Will and I have a recurring argument about what should and shouldn't be in a site review. My argument has been (and remains) that before you can do a proper site review, you need to do keyword research in order to validate that the site architecture is correct. Whereas Will says his argument is that you can separate a "site review" into two separate parts: technical review and keyword targeting review - which could be separate deliverables, and for which only the second one do you need keyword research.

I have been doing a fair few site reviews recently and one thing has stuck out. Yes, almost every site I've ever looked at has technical issues that should be fixed. Yes, people are still using font tags in a deliberate attempt not to pass semantic information to the search engines, and yes, some people still insist on creating a hideous flash monstrosity. However, the biggest issue (ignoring the hideous flash monstrosity, which deserves everything it gets) is not something that can be fixed by tweaking a template here or adding a mod re-write rule there.

I'd love to stir this up into a big issue, but unfortunately it really isn't. You see, Will knows I'm right but never likes to admit he's wrong. Will wants us to first send the client a technical site review. After that, he argues we can look at the keyphrase research and information architecture. I'm a firm believer that step one should be keyphrase research, which can then feed into a site review which not only looks at if there is a h1 tag on the page, but whether the keywords in the h1 tag are the right keywords.

I see a correlation between big sites and fairly few or fairly small technical issues. However, the opposite is true of site architecture, where the bigger the site, the more site architecture problems there tend to be.

Site/information architecture issues fall into a number of camps: duplicate content, keyword cannibalisation, and a distinct lack of keyword targeting. All of which, in my opinion, are a bigger hurdle to ranking than most of the issues that are picked up in a technical site review.

As an example, I was looking at a site the other day that is one of a number of trusted Cisco partners providing Cisco training. Technically the site was ok (ish), but whoever wrote the content of the site certainly didn't have the search engines in mind; come to think of it, I'm not sure they had anyone in mind.

They had a page linked from the homepage of the site talking about the training they offered. The title tag of the page was Company Name | Training. The header of the page was Training with Company Name, and the page didn't mention Cisco once.

<not very subtle jibe>Obviously Will understands, just as well as you all do, that updating a header (coded in a font tag) to an h1 tag won't make the slightest bit of difference if the keyword isn't in the header.</not very subtle jibe>

With this issue in mind, I'd like to propose the following methodology for a full site review, and see what you guys think.

Step 1 - Keyphrase research. I think it's vital to get this done as early as possible in any process. Keywords drive SEO, so you want to know these as early in the process as possible. I'm as guilty as anyone for thinking I can get by without keyword research. Keywords are obvious right up until the point that someone points out you are wrong.

At this stage, if you can end up with more than just a list with search volumes you are on to a winner. Try to spot patterns in the way people search. You want to start with short tail keywords and find a hierarchy leading you to your pages.

Step 2 - Site Architecture. This step is, in my opinion, where the big bucks are earnt. Coming up with a site architecture can be very tricky. At this stage you need to look at your keyword research and the existing site (in order to make as few changes as possible). You can think of this in terms of your site map. You need a hierarchy that leads you to each of your "money pages" (i.e., those pages where conversions are most likely to occur). Obviously, a good site hierarchy allows the parents of your money pages to rank for relevant keywords (which are likely to be shorter tail).

Most products have an obvious hierarchy they fit into, but when you start talking in terms of anything that naturally has multiple hierarchies it gets incredibly tricky. The trickiest hierarchies, in my opinion, occur when there is a location involved. In London alone there are London boroughs, metropoliton boroughs, tube stations, and postcodes. For you fact junkies out there, London even has a city ("The City of London") within it.

In an ideal world you will end up with a single hierarchy that is natural to your users and gives the closest mapping to your keywords. Whenever there are multiple ways that people search for the same product, it makes coming up with a hierarchy that much harder. Rand touched on this (relating to blogs) when he was talking about solving indexation problems.

Step 3 - Keyword mapping. Once you have both a list of keywords and a list of pages, spending the time mapping one to another is well worth it. It suddenly becomes a very easy job to spot pages that aren't targeting a keyword, and arguably more importantly keywords that don't have a page.

It's worth pointing out that between step 2 and step 3 you will remove any wasted pages. Rand covers exactly this problem in his 2nd Headsmaking tip, how to come up with top level navigation naming conventions.

If this stage is causing you issues, I suggest you revisit step 2. Your site architecture should lead naturally to a mapping that is both easy to use but, importantly for the search engines, includes your keyphrases.

Step 4 - Site review. Once you are armed with your keyword mapping, a site review becomes a lot easier. Take a look at Tom in Whiteboard Studios, who talks you through a site review process. Now when you are looking at title tags and headings you can refer back to your keyword mapping and not only see if the heading is in an h1 tag, but also if it includes the right keywords..

So, to help finish my debate with Will, I'd love to hear your thoughts on how you go about a site review. Do you prefer to send through one document with everything included, or would you rather send multiple documents over time, but with the first technical site review being delivered earlier?