Came across a Google oddity while testing out a few search terms from my website (we all do it, right?)
The article in question is about WordPress search, which I wrote on September 1st 2010. This is how it appears in Google search listings:
Google search result excerpt; publication date is wrong
Which is strange, considering the date I wrote it. Here’s how it appears on my blog:
01/09/10 means 1 September 2010 in the UK
Of course, 01/09/10 means different things to different people; if you’re in the US it does indeed mean 9th January 2010, while in the UK it means 1st September 2010.
Fair enough, you might think—you can’t expect Google to guess the author’s intention (after all, the document’s declared language is en-us). However, there’s a little bit more going on here than meets the eye. Here’s the relevant HTML:
<time datetime="2010-09-01T20:03:05+00:00" pubdate>01/09/10</time>Note the datetime. This value isn’t open to intepretation, and it’s ‘machine readable’. It’s telling the machine (in this case the Google search robot) that the article was published on the September 1st 2010 at 3 minutes and 5 seconds past 8 in the evening (see the wonderful Dive Into HTML5 for an explanation on how time works).
So what’s happening? As far as I can work out, it’s one (or a combination) of:
- Google doesn’t recognise
time - Google doesn’t read
datetime - Google reads human dates but not machine dates
- Google respects the document’s language setting and interprets a human date accordingly
- Google ignores the document’s language setting and interprets dates as American dates
Obviously this is unimportant in the scheme of things, but it’s interesting to see what would happen if I marked up the publication date using hatom. Would Google read the time in the title?
It’s also worth taking a look at Florent’s time and HTML 5 article and his test page.
Google do claim to support Microdata, and specifically mention time with the datetime-attribute (as used on your site) as an example in their documentation: http://www.google.com/support/webmasters/bin/answer.py?answer=176035
Could be a bug..
On a related note, “01/09/10″ is not only a problem for Google, it’s also a problem for humans. The order differs from country to country, and website to website (even websites from the same country mix this up), and there’s no way to tell which is which until you find a date between 13-31.
I usually tend to go for spelling out the month name in abbreviated form: “Sep 1, 10″. It’s unambiguous and virtually the same length (only a couple of extra characters).
PS. the new design is great.
Thanks for the comment, Jamie.
Yes, thought it was odd. Google isn’t actually at the stage of making firm statements about how it’ll use microdata, so it’s all a bit shot in the dark. I’m guessing that it reads microformats more readily, though, as they’ve been established a while.
Agree about the confusing ‘human’ date. I went with a numeric format when I had post titles and dates on the same line as it saved space; I’m British, so dd/mm/yy makes more sense. I’ll change it to text.
I’m quite happy with this design (I change about once a month), especially with the fact that it works on a normal mobile phone with no javascript or separate website.
I got to admit I find this quite annoying!
I have a website with news post which display the post date – in UK date format. This is interpreted by Google as US date format which makes my news look about a year old.
eg. 01/12/2010 is changed to 12/01/2010
I’m surprised Google haven’t put something into their webmaster tool to allow you to tell Google what timezone your site is in. Or maybe even the robot.txt file could do this.
Would be great to get this solved – Google?
Thanks for your comment, Mark. I think it’s fair enough to assume a US date if there’s no supporting information within the document; perhaps the declared
langor ametatag would be enough. Butdatetimereally should be supported.One day Google will recognise the HTML5 time element and act accordingly. But it has to be said that they often seem incapable of even writing valid code for their own pages. I just ran their Advanced Search page (UK version) through W3C, and discovered with a mixture of horror and hilarity that it doesn’t even have a doctype declaration (and it’s still HTML4, to boot) – LOL!!!