When one shares a resource using the +1 button, Google attempts to extract a page title, a description of the page and a thumbnail image from that resource. This preview is then used on the Google+ post page (and one would think that the same extraction logic is used when linking to a page directly from Google+, but I have yet to verify this with testing).
According to Google’s technical documentation for the +1 button, the data is extracted from the target URL in one of four ways, listed in order of precedence.
- Schema.org microdata
- Open Graph protocol
- Meta “title” and “description” tags
- Best guess from page content
The examples given for 1 (schema.org microdata) and 3 (meta tags) – and the fact they are listed separately – imply that they are mutually exclusive. The schema.org example (like any “official” examples I’ve encountered) show the description and name properties (itemprop) employed in the <body>. This is consistent with Google’s discussion of “non-visible content” on their microdata page.
In general, Google won’t display content that is not visible to the user. In other words, don’t show content to users in one way, and use hidden text to mark up information separately for search engines and web applications. You should mark up the text that actually appears to your users when they visit your web pages.
In their discussion of exceptions they talk chiefly of using non-visible content “to provide search engines with more detailed information, even if you don’t want that information to be seen by visitors to your page” (emphasis mine).
It always struck me as problematic that, according to these examples and Google’s guidelines, I seemingly shouldn’t be using the <meta> description as the description itemprop for a page, despite the fact they serve the same function. And as often as not it would be disingenuous to put a description of the page a visitor is already viewing on the page itself. Such a description is most useful in off-site environments, such as a search result or a Google+ post snippet.
The same is conceptually true of a page’s <title> tag, where one would think that the <title> tag is acceptable to use as the name itemprop for an Article or WebPage type, although unlike a <meta> description the content of a <title> tag usually appears on the page as a human-viewable heading, so at least is accessible for one to markup as a human-viewable element.
However, when I went to Google’s +1 Button page that contains a snippet customization tool, it provides you with the utility to set the markup location as <head>. When I entered the following…
… this is the code it generated for me:
<!-- Update your html tag to include the itemscope and itemtype attributes --> <html itemscope itemtype="http://schema.org/Article"> <!-- Add the following three tags inside head --> <meta itemprop="name" content="Aaron's Article Title"> <meta itemprop="description" content="A riveting description of the article.">
As one can clearly see, one can encode the description itemprop in a <meta> tag that appears in the <head>. So why not double up on the <meta> description tag? (By the way that’s the verbatim output: yes, it says to add three tags but gives you only two.)
<meta name="description" itemprop="description" content="A riveting description of the article.">
For that matter, why not go the full distance and double up on the <title> tag as well?
<title itemprop="name">Aaron's Article Title</title> <meta name="description" itemprop="description" content="A riveting description of the article.">
I don’t see anything wrong with this either from a microdata syntax perspective, or from a Google+ usage perspective. I’d love to hear from any readers that see this as problematic.
{ 3 comments… read them below or add one }
When I worked on this a few months ago I gave up on the Schema structure because it seemed to break the testing tools at best and actually create conflicts at worst.
In particular, the Facebook snippet got mangled when you tried to have meta, micro and OG tags all at once.
Now, I was at the end of my rope at that point so perhaps I just didn’t push on through to figure out how to make it all work in harmony but … that’s sort of the problem.
Both platforms use meta and OG tags to cobble together their snippets so while the Schema stuff is interesting it’s sort of like extra credit in summer school.
Interestingly enough, when I posted the link to this article the Like button plugin mangled my description, at once proving Google does take the +Snippet (did they really have to coin that?) from OG tags and validating your point about conflicts.
I like your analogy about extra credit. Whether employing microdata in addition to Open Graph (and, for that matter, in addition to the standard HTML meta tags) is base or extra credit really depends on who consumes the data and how the data is used.
Certainly for +Snippets it’s an either/or situation, since Google will consume and regurgitate either. On a broader scale … who knows? (Unsurprisingly, perhaps, Google Custom Search allows you to use microformats, RDFa, microdata and tags to customize Site Search results, but not Open Graph tags.) Widespread microdata adoption would settle the issue, but we won’t be calling microdata adoption “widespread” anytime soon. On the flip side, although OG adoption in the form of the ubiquitous like button is broad, most webmasters don’t pay much attention to data encoded in the underlying Open Graph tags (if they’re even aware of their existence).
So – just looking at a typical resource title – we’ve got <title>, itemprop=”name” and property=”og:title” all referencing exactly the same data. While one could see why using, say, the schema.org CivicStructure property might have a particular benefit, using different types of structured markup for the same standard data types is indeed a pain. Less like extra credit than just flat out extra work.
Certainly for +Snippets it’s an either/or situation, since Google will consume and regurgitate either.. so many great points in this blog, thank you!!