Through our handy Ask The Doctor service, we get a lot of e-mails asking us about HTML5’s effect on Search Engine Optimisation (SEO). While we can’t answer in great detail (Messrs Google, Yahoo, Bing, and their friends haven’t sent us in-depth details of their algorithms), we’ve rounded up some useful facts from Google, the world’s most dominant search engine.
At the moment, Google indexes HTML5 microdata (more about microdata) but does not reward you for using the new HTML5 structural elements, but neither does it penalise you:
As HTML5 gains in popularity and as we recognize specific markup elements that provide value to our indexing system, this is likely to change, but at the moment I would not assume that you would have an advantage by using HTML5 instead of older variants….
Personally, I would recommend using HTML5 where you think that it already makes sense, perhaps reverting to HTML4 if you can determine that the browser won’t support the elements of HTML5 that you use properly. While this will not result in an advantage for your content in our search results, it generally wouldn’t be disadvantageous either.
But they will take account of HTML5 once it becomes widespread, and they seem to be encouraging experimentation:
Our general strategy is to wait to see how content is marked up on the web in practice and to adapt to that. If we find that more and more content uses HTML5 markup, that this markup can give us additional information, and that it doesn’t cause problems if webmasters incorrectly use it (which is always a problem in the beginning), then over time we’ll attempt to work that into our algorithms….
HTML5 is still very much a work in progress, so it’s great to see bleeding-edge sites making use of the new possibilities :)
The Doctors’ advice on SEO is to follow Google’s time-honoured guidelines: write valid, cross-browser, accessible HTML, don’t misuse markup or “cloak” with CSS, make a site with a clear hierarchy and text links, and write good content:
Create a useful, information-rich site, and write pages that clearly and accurately describe your content.
Happy New Year. May your hat remain white.
HTML5 microdata and schema.org
Added October 2011:
Schema.org is a consortium of Bing, Google and Yahoo!. On its website it says
[schema.org] provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results
schema.org uses HTML5 microdata with new elements like
<time>. So, yes: in this special case (using these markup patterns) will ensure that this HTML5 will assist search engines to categorise your content (which is not the same as guaranteeing a higher ranking, of course).
Multiple <h1>s on a page
The new HTML5 outlining algorithm allows multiple <h1>s in a page. We get lots of questions about whether developers will be penalised by Google which, according to myth, disallowed this.
I say “myth” because Google has always allowed multiple <h1>s on a page, provided that it’s organic rather than trying to game the system, as this video shows:
However, don’t go too crazy with the <h1>-only approach as it removes any hierarchy from your pages in browsers that don’t implement the outline algorithm and screenreaders that sit on top of them.
29 Responses on the article “HTML5 and Search Engine Optimisation (SEO)”
Early doors. I found Google struggles with
datetime. Anecdotally: I’ve been getting loads of search engine traffic on my blog since moving to HTML5, but that maybe because I’ve been using microformats better (or a million other reasons).
Any thoughts on how Google might deal with finding a large number of
s on each page?
I fear that it might be considered spammy.
(Note to self: read the effin manual)
Ahem… any thoughts on how Google might deal with finding a large number of *h1*s on each page?
GoogleWebmasterHelp’s video More than one H1 on a page: good or bad? says it’s fine for natural headers. If your entire page is an h1, CSS’d to look like body text, it’s spammy.
@Stuart Charlton, @ Bruce Lawson
At the moment, I’m going with the traditional one h1 per page model. I knew Google could cope with more than one, my concern is screen readers so I’ll wait a bit before using the html5 model of h1-6 tags.
Like Stuart, I could read the fn manuals but that would require work :)
I think what Stuart meant is that he uses h1s inside each new section, article, nav, etc. (everything that alters the document outline) with just a few h2s or h3s.
(This is one thing I’ve been thinking a lot about; will we end up using just h1 with a few exceptions? It would make sense since then I could use the same markup (code snippet) for a login form inside a sidebar (and wrap it with an aside, section or whtever makes sense) and for a separate login page. But then styling that stuff becomes a mess.. I would love to have a universal “outline element selector”! If any of that makes sense.)
The Matt Cutts video addresses that case you mention, and says it’s fine as long as it;’s natural. Remember, multiple h1s has always been legal.
I expect we will end up using all h1s. In fact, the spec says “authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level” http://dev.w3.org/html5/spec/sections.html#headings-and-sections
Using only h1s fits the use-case and allows content to be syndicated around.
Thanks very much for your reply.
I know this is highly OT, but what about styling my h1s then? I could start off with an h1 rule, an article h1 rule and an article article h1 rule. But what if one of those article tags becomes a section or nav tag? You see the point I’m trying to make here?
Do you have any resources on that problem? Or am I the only one having trouble with that? Am I missing somethimg something very obvious here?
If not, I’d suggest some solution with which I can say, for example, “give every h1 that is buried n levels deep inside the document’s outlime a font-size of x“.
Rudolph – you’re not missing anything obvious at all. Your question gets to the heart of it.
CSS to style all possible permutations of article h1, section h1, aside h1, nav h1 etc quickly becomes cumbersome.
Anyway, at the moment using only h1 harms accessibility, so I advise people to follow the spec’s advice “use elements of the appropriate rank for the section’s nesting level”
I just hope this stand point from Google doesn’t slow down the adoption of HTML5.
I know I’m late to the party but I’ve been working out a plan for my use of HTML5 for new templates that can be summed up as “Who’s your daddy!”
Therefore, as @Bruce Lawson stated above with the headers, as well as how I interpret the spec, is that it’s all down to how you “relate everything to its parent”.
Saying that, it’s not another “box-model” so to speak, but still reminds me of those wooden Russian dolls!
I’d like to have my article titles be the main heading in the outline because it seems that’d be best for SEO, (maybe I’m wrong about that?)
To twist around my markup to make that happen though seems pretty tough.
In HTML4 if I was on the home page of my site I’d use an h1 for the logo and site title but if it were a subpage I’d put the h1 around the article name, easy… done.
This is not so easy to accomplish in html5 though since a typical site would be marked up with a header and nav element in for the site’s banner area and these would make it in as being above the page title in the outline right…
Maybe answering my own question but maybe not, would it make sense (for almost any site) to add section around the main <header> element so that the H1s in there for the nav element and the site title get treated at the same level as the h1 for the title of the article?
nevermind mental lapse there, I can just echo the title of the main post for the page into the root level header tag as the H1 there and it’ll show up at the top of the outline. Not sure why you guys don’t do that here, wouldn’t this be better for SEO and maybe even the most logical main heading for the page as well:
1. html5 seo search engine optimisation – HTML5 Doctor
1. Untitled Section
2.HTML5 and Search Engine Optimisation (SEO)
1. HTML5 Doctor
2.HTML5 and Search Engine Optimisation (SEO)
It does repeat the name of the article but the page itself is more about that article than anything else so it seems like that’d be the way to do it no?
Will using HTML5 mark up result in lower rankings ?
I wonder how current this still is. It has been a year, and html5 has taken off, to a large part probably due to the html5boilerplate.com techniques, and it remains guesswork to do seo on nav elements, header elements, footers, main content etc in html4. For seo (though not compatibility) the benefits are clear, and it’s hard to imagine that the search engines haven’t taken advantage of that.
My site is developed in Asp.net how much it will be beneficial to me if I convert it in to HTML 5? Your suggestion is highly appreciated.
I don’t know about HTML5 but I cannot see the point of two H1 tags from an SEO point of view (or any other) if your heading is correct. Surely the second less precise one would only dilute the effect of the first. Am I wrong?
If you want to have a second bite of the cherry, assuming that it is secondary then why not H2? If it’s more important then swap them.
All this is based on my philosophy of doing what makes sense in the real world first with only half an eye on SEO. The more genuine your content, the better in the long run…
I think google now checks on HTML 5 elements? Can you update your post please?
There is still no correlation between using HTML5 tags and SEO advantage.
See the response from John Mu (Google representative).
Their POV is that since the end user can’t tell the difference between an HTML5 element or HTML4 element, it shouldn’t affect the rankings.
Awesome article. So basically we continue to do our normal onpage and off page stuff and let the bots just enjoy easier content readability
so, do I get this right: Your recommendation is not to use multiple s on one page until it all (or most) browsers can interpret it correctly/accessibly?
How does google now, if an h1 that is semantically an h2 (because it is a standalone section that is a child of the h1 section) has less seo value than the actual (meaning semantically more important) h1?
andrej my advice is not to make every heading an h1.
Sadly, Google haven’t given me a copy of their algorithm.
bummer. If they do, could you send me a copy? ;)
thx for the feedback
I wouldn’t recommend using multuple H1’s on a page unless you have content to back it up on that same page.
You have a carousel on a page which slides through various product pitches. Each of these has it’s own H1 tag. However, the H1’s are disembodied from any content on the page.
In this case I would probably ditch the carousel. If not I would think about promoting only 1 H1 Tag and demoting the others.
Sometimes I feel like when Cutts says “XYZ” people kinda hear what they want to hear. Instead of what is he is actually saying
I would also counter the posted 2009 Matt Cutts video with this one from 2011 http://www.youtube.com/watch?v=Hgy3Oc9zfOw where he states his preference is that there be 1 H1 Tag
In reply to Shankar:
Visual Studio 2012 supports the HTML5 DOCTYPE natively, but even if you are still developing with VS2010, the only aspect of ASP.NET that you have to concern yourself with, as it relates to HTML5 is how server controls will render their markup to the client. Since most controls render with semanticly neutral markup (span’s and div’s), there is no reason you should be concerned. ASP.NET was never really sending Hx elements to the client anyway.
I’ve been using this for years as a formatting tool never considering there could be a penalty. Good to know there isn’t one.
Leave a Reply to Jon R. Humphrey