In my last article, Developing your Descriptions (Part 1, The Problem), I discuss the importance of meta-data descriptions for all websites depending on any organic traffic through search engines.

I also briefly discussed some of the obstacles in getting this data implemented correctly on larger websites.

These obstacles include:

Not understanding the negative impact of not including description meta-data on each page.

Populating this data can be tedious, causing many people to avoid it like the SEO plague.

If not included in the project plan, this information often just falls through the cracks and sometimes will never be complete.

Not learning from the last job… this mistake often just repeats itself over and over on each new website that is launched.

So what to do? How do we make meta-data population just another part of launching a website? Essentially it should just be one more checkbox to tick off before going live. Much like validating your HTML, browser testing on different platforms and even ensuring your content is actually all there ready to go and formatted correctly.

Have a list, check it twice

This is not specific to SEO or meta-data, but a list of pre-launch activities to assess and confirm that everything is correct before launching a live product is essential. People change projects, staff turnover from time to time and people just plain forget some small details when working on larger projects.

I worked in a large company for many years. Each time we launched a large project we left this step up to each professional (whether that is back-end, front-end or if the producer is co-coordinating the show) to take care of their own area. Depending on who this was per project, the criteria before launching a product could vary greatly and so would the results.

A checklist of pre-determined criteria for basic quality control could really make everyone’s life easier in these stages of manic development and testing. Not only does this establish a set of common expectations within a project team, but it also delivers a more consistent product across a large company.

This shouldn’t be complex and this shouldn’t create unnecessary obstacles. It should start simple and just get people involved in thinking about what needs to be on a website when it goes live.

Define roles, share responsibility

The SEO is too busy with strategy, the back-end guy wants nothing to do with populating meta-data and the Information Architects don’t really even give it a second thought. Well, somebody has to be dobbed in to do the work and it must be understood throughout the organisation.

Let’s just first define what is not SEO work. To get meta-data going you have to make sure there is some sort of automation of the process, meaning the back-end guys need to ensure that there is a way of harvesting this data (be it a database of description data or a tricky way of scraping this data eg. title tag + headline of story + stock phrases). So there you go, back-end guys you are in on this… but not alone, you need help.

Which leaves us with the creating and sorting this data. What do we do to ensure that the data being created for each of these pages is unique and describes each page accurately? There can be a few ways to make this happen, but I have an idea I would like to share with you from my past experiences with this exact situation.

Spread the <meta-love>

Nobody wants to get stuck with the boring, tedious part of a job but there is some aspect of each role that will no doubt have you inwardly cringing. Browser testing for developers, vague functional specs for back-end developers… these are no different when it comes to certain aspects of usable and finable websites.

What I am about to suggest isn’t going to work for everybody but if you have a large team that involves information architects and SEO professionals under one roof, then you are indeed a) lucky and also b) well-equipped for the following process.

Let’s break down a few loose definitions of some key roles in this process:

Information Architect = meaning “organising content into a structure” and “intuitive navigation”

SEO = meaning “more traffic through targeted keywords” and “increasing (or fine tune) relevance of search terms”

Back-end Developer = meaning “integrating technical solutions” and “defining architecture”

So if you look at that list again we can break the meta-data problem into three separate components or stages to deal with seperately. Structure, copy writing and integration.

Structure

Now as far as I am concerned, description meta-data is content that needs to be structured logically and intuitively. It may be hidden inside the <head> element of your documents but when it is revealed on the search engine results pages it can expose numerous usability issues for a potential visitor looking for your webpage.

This content needs the eyes of those who understand these navigational pitfalls, the Information Architect (IA). Below is an example of a basic wireframe an IA might put together for a website, this is a crude example but it will convey my idea sufficiently.

Regular wireframe

Most charting software allows you to work in layers, much like Photoshop. This is where I suggest the IA start thinking about another output layer in their wireframing process, the meta-data layer.

Regular wireframe with meta-data layer

As mentioned before when breaking down the definitions of each role, this meta-data layer would be looked at from a usability and navigational perspective. When a user sees a description on a search engine result page, does the description make sense to the user? Does it require much cognitive effort to associate what the user is searching for vs. what the description meaning is conveying?

Does the description make the user want to click on the link and aid them in ending their search? This is the required information and structure from what the SEO must now base his further work from.

Of course, much this data will be available in the page view wireframes in more detail but what we are looking for here is a snapshot of the important information to provide the SEO with a basic, descriptive meta-data foundation.

Copy writing

Now that we have a basic structure and layout for our descriptions the SEO can concentrate on what they are experts at, fine-tuning phrases and content into SEO-friendly material.

From this basic wireframe layer the SEO will have direction and can start to analyse current trends in search, discover common search terms that may conflict or support the IA’s labeling and finally they can enhance this bare-bones wireframe with a more SEO-friendly flavour.

This is what an SEO should be concentrating on, not the IA work such as labeling, or influencing basic usability or getting their hands dirty and constructing confusing navigational elements.

This is not to say the SEO does not have insight into providing a better solution to the problem at hand. This is a suggestion that this should be an iterative conversion between the SEO and IA during the project, and not all of this responsibility should be automatically dished onto the SEO’s plate.

From this stage the SEO can now build a database (or most likely a spreadsheet) of description and title data that is a finely-tuned, SEO enhanced version of the content the IA had originally created earlier in the this process.

Integration

Finally, it’s time for the back-end guy to get involved. This should be early and should be well-documented by now. The SEO can also liase with the programmer to discuss optimal output of the data he has structured, what is acceptable for output across a large website and also what to watch out for while putting it all together.

The back-end guys don’t want to be bothered with vague specs on how to populate meta-data. It needs to be documented well or else it’s bound to fail or have to be dealt with manually for the rest of that website’s life.

A couple of extra tips

NOODP attribute

<meta name=”robots” content=”noodp” />
This code will prevent Google from pulling description data from the Open Directory Project abstracts and forces them to use your provided descriptions.

NOYDIR attribute

<meta name="slurp" content="noydir" />
This code will prevent Yahoo from pulling description data from their own Yahoo Directory abstracts and forces them to use your provided descriptions.

Empty <description> elements

<meta name="description" content=" " />
Don’t do it, this will just result in some random copy on your website being pulled into your description on the search engine result pages. This could be the copyright text, testimonials or HTML code.

Throw us a bone

This is an idea I have had brewing that is probably more specific to larger organisations that have these larger teams, larger projects and often lack many logical checkpoints or role definition causing many of the problems I discuss in both articles.

Smaller companies still need quality control and methodologies that guarantee they do not make these same mistakes, but it’s easier for smaller companies to adapt to such issues and for one person to take on more of the responsibilities whether it is actually theirs or not.

I would love to hear what people think of this concept, what works for you or simply why it won’t work and should be shelved. I think it’s hard to cross a lot of these disciplines and get more teams to work together seamlessly personally, but it’s not impossible.