In light of Google’s recent announcement to support the Schema.org semantic framework, I wrote a rant about how the big G is getting webmasters to do the hard work:

State of Search: We’re doing Google’s job for them

Google, as a search engine, exists to find all the information on the web (crawling), make sense of what it finds (indexing), and serve us with the most relevant content for any given query (ranking). This, in a very simplified nutshell, is Information Retrieval, and it’s what search engines do. However, it seems search engines are actually quite poor at this. Or at least poor enough that they think they need us – the masses – to do the hard work for them.

Also for State of Search I described how SEO as an internet marketing activity can fit in to the SOSTAC® strategy framework:

State of Search: SEO within the SOSTAC® strategy framework

To summarize it very briefly, SOSTAC® stands for Situation Analysis, Objectives, Strategy, Tactics, Actions, and Control. Developed by PR Smith, SOSTAC ®is a powerful yet simple strategy framework that captures all aspects of creating and executing an IM strategy, yet it has enough flexibility to fit around the varying requirements of our wide range of clients.

Google’s Job / SEO and SOSTAC® is a blog post from Barry Adams.

For State of Search I wrote a blog post in which I explore the different ways in which SEOs can quantify and report on what they do. This is becoming increasingly difficult for our profession and we need to find solid, widely accepted methods for measuring the success of an SEO project.

State of Search: The Business of SEO

What we as SEOs do is very quantifiable: we generate lists of relevant keywords, we perform on-site optimisation that we can easily show to clients, and we generate new links that (generally speaking) we’re also able to report. However, none of those things are easily attributable to a return on investment. Between what an SEO does and what SEO delivers are intermediate steps over which we have very little, if any, control.

Google has introduced two new meta tags for use on news sites that allow news publishers to indicate what the original source of a news story is, and whether a story that is published on their site is original content or syndicated from a feed. I explain these new tags in a post for Search News Central:

Search News Central: Source Attribution meta tags

Previously Google made deals with the likes of AP to host AP’s news stories and link to those instead of the same stories on other news sites. But that is a bit of a patchy solution, depending too much on what kind of deals it is able to make with content syndicators. Last Tuesday, November 16th, Google announced what might be a proper and definitive solution to this issue: source attribution meta tags. These meta tags should enable Google to see which is original content and which is duplicated content from syndication feeds. There are two types of meta tags: original-source and syndication-source.

The Business of SEO / Source Attribution is a blog post from Barry Adams.

(This article was originally published on the Visual Script blog.)

Sitemaps are a crucial aspect of a successful website. First, let’s make it clear what we mean with a sitemap. There are two types of sitemaps: one meant for visitors of your website, and one for search engine spiders.

Sitemaps for Visitors
The first type of sitemap is probably very familiar to you. It’s a webpage that shows an overview of all the content on a website. You can see an example here of our own Visual Script sitemap.

This type of sitemap is very useful as it allows your visitors to quickly find what they’re looking for without having to go through your website’s navigation. Especially for large websites it’s recommended to have a well-structured sitemap that is linked from every page on your site, for example in your website’s footer.

Sitemaps for Search Engines
The second type of sitemap is a so-called XML sitemap. This type of sitemap is specifically intended for search engines, and it does roughly the same: allowing search engines to find all the content on your website quickly and easily.

Why bother with an XML sitemap then, if it’s the same as a normal sitemap? Because an XML sitemap allows you to include extra information about the content on your site, such as:

• when a webpage was last updated
• how often a webpage is usually updated
• what the priority of a webpage is relative to other pages on your site
• what type of content a webage contains (text, video, etc)

An XML sitemap allows a search engine to quickly and efficiently index all the content on your website, making sure your site is fully spidered and all your content is part of a search engine’s index.

Google recommends every site includes an XML sitemap. You can create an XML sitemap yourself manually, or you could have one generated automatically – ask your site’s web developer about it, or look at Google’s sitemap help pages here.

For larger websites it’s recommended to have a sitemap created automatically, so that whenever you create a new page or update an existing page your sitemap is automatically updated as well.

You can tell Google you have a sitemap by submitting it manually in Google’s Webmaster Tools, or you can include a sitemap reference in your robots.txt file. The second option is always recommended as this way other search engines such as Bing can also find your sitemap.

Need help with sitemaps or other aspects of your website? Get in touch with us at Visual Script, an experienced Northern Ireland Web Design company that can help you with all aspects of your online adventure.

The Importance Of Sitemaps is a blog post from Barry Adams.

On the most recent edition of the Barcamp Belfast conference I did a 20-minute talk about the mistakes some web developers make when building search engine friendly websites. Much of the content in that talk came from a blog post I did for State of Search about the same topic – SEO for Web Developers. Below are the slides:

Presentation: SEO for Web Developers is a blog post from Barry Adams.

Earlier this week Google’s Webmaster Central blog wrote about how to effectively geotarget your website. In that article they promised to discuss multilingual websites as well.

And now they have. In a new Webmaster Central blog post published today they discussed the best practices for multilingual websites. Some key take-aways are:

One page, one language
Don’t put two different languages side by side on a single page. Make sure the content on a page is in only one language.

Language-specific URLs
There’s no special need for language-specific URLs from a purely SEO point of view, as Google apparently detects the language straight from the content itself. Though having language-specific URLs is a good usability practice and helps make management of your site a lot less complicated.

Language indicators in the code
Interestingly enough Google says it ignores all language indicators in the code, including the ‘lang’-attribute and doctype declarations.

Character encoding
When using non-English characters in URLs, make sure your document encoding is set to UTF-8. That way URLs containing special non-English characters (such as á, é, ö, etc) are properly escaped to use the encoding of that character.

Full crawling & indexation
Make sure your properly translated content can be fully crawled and indexed by Google. Cross-link your pages in different languages – so for example on your English language page you should link to the German and French versions.

Automated translations
If you can’t afford proper translations and publish content that’s machine-translated, don’t let Google index it. Apparently Google can see automatically translated content as spam due to its low quality.

There’s a couple of other tips in Google’s blog post, so I recommend you read it in detail: Working with multilingual websites.

SEO Factors for Multilingual Websites is a blog post from Barry Adams.

One of the most important issues European SEOs struggle with is optimising websites that target different countries.

There are all sorts of challenges when dealing with international SEO, such as what domain extension to use, how to structure multiple target countries on a single domain, dealing with country selection without losing link value, how to build incoming links across all countries, and so on.

There have never been any hard rules on how search engines deal with international SEO, leaving optimisers with trial and error exercises to discover the right approach for their sites.

Now Google is lending a helping hand with an extensive post on their Webmaster Central blog, which explains how they attempt to handle different geotargeting factors such as domains & subdomains, directory structure, and Webmaster Tools settings.

For experienced SEOs there aren’t many surprises: Country-level domains are important and probably the best way to target different countries if you can spare the expense. Subdomains are a good alternative, as are country-specific directories on your website.

Duplicate content issues have plagued international SEOs since the dawn of the web. Often it’s extremely hard to avoid duplicate content when your business operates internationally in Europe. Many countries use the same language, so if you want to effectively target all your operating markets you will eventually end up duplicating content in the same language for different countries.

Google doesn’t recommend hiding this duplicate content with robots.txt or noindex tags – I’ve never been a fan of hiding content in this way either, as every page on your website may convey some ranking benefit and I feel you should let search engines crawl the full length and breadth of your content.

What you should do is pick one ‘preferred’ version (ideally the version with the largest target market) and ensure all duplicate versions of that content use the canonical tag to point to the preferred version.

Google does have one interesting revelation though in their geotargeting recommendations:

“Note that we do not use locational meta tags (like “geo.position” or “distribution”) or HTML attributes for geotargeting. While these may be useful in other regards, we’ve found that they are generally not reliable enough to use for geotargeting.”
(Emphasis added)

This might mean that the ‘lang’ HTML attribute conveys no geotargeting benefit, though it’s undoubtedly a useful attribute for browsers and other UAs and helps with multilingual websites.

In upcoming blog posts Google will take a look at multilingual websites and special situations with global websites, so I recommend keeping a sharp eye on the Webmaster Central blog, and I’ll be discussing things here as well.

SEO Factors for Geotargeting Your Website is a blog post from Barry Adams.

A term often busied by web developers and also SEO agencies is W3C compliance. I’ve written about the benefits of W3C compliant code before, but my perspective has changed a bit over time and I feel it’s important to point out that full W3C compliance is not a definitive requirement for an effective website.

W3C compliance basically means that the HTML and CSS code that a website is built with is fully compliant with the standards set by the World Wide Web Consortium (W3C for short).

The W3C is an international standards organization, founded by the inventor of the web. They develop the standards on which the world wide web is run.

You’d think that making sure your website’s code complies fully with these standards is pretty important. And it is, up to a certain point.

You can easily find out if your website’s code is W3C compliant – simply submit your website URL to the W3C Validator tool and you’ll get an overview of all the ‘errors’ in your code. And you’ll almost certainly get a lot of ‘errors’. It’s very unlikely your website’s code complies to all of the W3C’s standards.

I say ‘errors’ because often they’re not really errors. The W3C standards are extremely strict, with no room for interpretation. So every little niggle in your code, every small deviation from the W3C’s strict standards, will generate an error in this validation tool.

W3C compliance for browsers

But most web browsers are flexible pieces of software that are built to deal with a wide range of different sorts of HTML and CSS code, and will probably render your website perfectly regardless of how many errors the validation tool shows.

Often web developers have to use shortcuts and non-compliant code to make something work in a particular way on a website, and while this results in validation errors it doesn’t hinder a website’s functionality at all. Quite the contrary, sometimes you have to break the rules of the W3C to get something to work exactly how you want it in every web browser.

W3C compliance for SEO

There is also the misconception that search engine crawlers require a website’s code to be 100% W3C compliant, or else they will rank your site lower in the SERPs. A lot of SEO agencies recommend you make every webpage on your site fully W3C compliant.

This is often a costly endeavour, and quite unnecessary. Search engine crawlers, like browsers, are sturdy and flexible pieces of software that can index almost any type of code, regardless of the errors it contains.

For proper crawling and indexation a search engine will need to be able to distinguish the different elements of a webpage – style, navigation, and content – and will need to be able to interpret the meaning of the content, which it does through analysing the content itself and the mark-up code that is used to style the content.

Clean, compliant HTML and CSS code help in this process. Compliant code makes it easier for search engine crawlers to identify what the content on a webpage is, and what that content means.

But 100% compliance, meaning zero errors in the W3C validation tool, is not only often hard to achieve (especially if your website has advanced functionality) but is unnecessary as well. The code just needs to be sufficiently well-structured and tidy enough for search engines to be able to distinguish style, navigation, and content.

So bad code is OK?

No, bad code is not OK. It’s still a good idea to strive towards compliant code. A website with hundreds of W3C validation errors is not a good thing. It’s likely that these errors cause the site to display differently in some web browsers (or worse, not work at all) and can cause all sorts of trouble for both users and search engines.

But if your website’s code only shows a couple of handfuls of non-critical errors, especially if they’re only small warnings, there really is little need to fix them.

For on-site optimisation your time and resources are better spent on making sure your website’s title tags, content, and other factors are fully optimised.

W3C compliance – is it a requirement? is a blog post from Barry Adams.

Recently I’ve been doing a lot of research on microformats and other approaches to structured data. This inspired a post for State of Search where I wonder if the time has come for web developers and search engine optimisers to embrace structured data, or whether we’re better off waiting for a firmer standard to emerge.

State of Search: Microformats and RDF, is this the right time?

A low-level buzz in SEO that’s steadily becoming louder is the use of microformats. This article explores the problems that exist with microformats and RDF and asks if this is the right time to implement these particular approaches to structured data.

Google’s recent legal setbacks in the form of a ruling against it in Italy and strong signals that the European Commission is launching an anti-trust investigation, sparked a passionate defence of Google’s practices from one its highest profile employees, Matt Cutts.

Searchcowboys: Google: “We’re the good guys, remember?”

As Google is coming under ever increasing scrutiny and pressure, it goes ever more on the defensive. Google seems to possess an almost childish naivety about its position as a global corporate giant, and it needs to come to terms with its role as the new Microsoft.

Microformats and RDF / Google’s Self-Image is a blog post from Barry Adams.

Often when you do a site-wide update of your design, your content and/or your site structure, it can affect your website’s rankings in search engines negatively. Facing a huge site update project myself, I recently spent some time doing research on how to prepare for a big site update and ensure your high rankings stay high. I wanted to share my findings with you here.

My research soon lead me to an article on the popular Dutch blog Marketingfacts.nl, providing a site migration checklist. The key takeaways from this article are:

• Try to keep your URL’s the same. Use 301 redirects for URL’s that have to change and ensure you redirect all changed URL’s to the content’s new location.
• Don’t change too much too quickly. If you do a redesign, content update and rebrand all in one, too many changes are happening and you’re likely to lose rankings on many keywords.
• Don’t change your domain’s WhoIs information. A changed WhoIs can give search engines the impression your website has changed owners, and they could reset all your rankings across the board.

An article from Jennifer Osborne on SearchEnginePeople.com added several considerations:

• Do a phased change-over: start with a small section of your site and evaluate, then proceed with the rest.
• Keep your internal link structure in mind when doing a redesign. Internal link juice is important as it tells search engine spiders which pages on your site are important. Don’t divert attention from your key pages with a poor structure.
• Track your web analytics and pay extra attention to 404 errors after the migration. This may indicate broken links, both internal and external, pointing to moved or deleted content.

Denver SEO adds the following point:

• Expect to see your rankings drop regardless of your preparations. A 25 to 30 day drop in search engine rankings is normal before levels return to normal or better.

Of course we can’t skip Google’s own recommendations:

• Add and verify your site on Google’s Webmaster Tools.
• Update your submitted Sitemap XML file to reflect the updated site.
• Keep track of crawling errors to detect 301 redirect problems and 404 errors.

And here are a few other tips I came across on various sites and blogs:

• Create a custom 404 error page to try and minimize the impact of broken links.
• If your site update is significant enough, publish a press release.
• Use search engine marketing to supplement your (temporary) drop in rankings.
• Update your robots.txt file to reflect any changes in off-limits content.

After this research I feel well-equipped to handle the SEO aspect of my own site migration project. If you have any further tips or ideas, please leave them in the comments.

SEO Concerns When Migrating Your Website is a blog post from Barry Adams.

Web widgets – little pieces of code, often JavaScipt – can add a lot of fun features to your website. Widgets come in all sizes and shapes; sports widgets showing the latest scores and standings, weather widgets with accurate forecasts, widgets that connect to social networks like Facebook, the list goes on. You can find them all over the web. Nearly every major content provider offers widgets that allow you to show their content on your website automatically.

Sometimes a widget can really add useful information and functionality to your website. For example of you have a physical store, a routeplanner widget will help website visitors find your store’s location. If you organize travel trips around sports events, a widget showing the upcoming fixtures will save you the trouble of maintaining this information yourself.

But often widgets are detrimental to the quality of your website. Widgets, especially when used in abundance, tend to make your site look amateurish and cobbled-together. Be wary of this when you see a cool widget and decide it would look awesome on your own website.

Widgets should be used sparingly and only when they add genuine value to your website experience. Don’t just put widgets on your website for the sake of it. For every widget ask yourself if it’s just something you think is cool, or if a user can really benefit from its functionality.

And most importantly a widget need to be relevant to your website. Showing weather forecasts is pretty useless if your website is about providing interim management. However for a website about day trips, a local weather forecast in the day trip area could be handy – though if the weather there is consistently bad, it might actually hurt your business.

In short, if you want to use widgets on your website, do so with caution and awareness.

Using Widgets on Your Website is a blog post from Barry Adams.