Using Head Content as Microdata for Google+

by Aaron Bradley on January 6, 2012

in Semantic Web, SEO

Using Meta Data as Microdata for Google Plus

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.

  1. microdata
  2. Open Graph protocol
  3. Meta "title" and "description" tags
  4. Best guess from page content

The examples given for 1 ( microdata) and 3 (meta tags) – and the fact they are listed separately – imply that they are mutually exclusive.  The 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…

Customize +Snippet Tool on Google

… this is the code it generated for me:

<!-- Update your html tag to include the itemscope
and itemtype attributes -->
<html itemscope itemtype="">

<!-- 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.

{ 11 comments… read them below or add one }

1 AJ Kohn January 6, 2012 at 2:01 pm

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.


2 Aaron Bradley January 6, 2012 at 2:30 pm

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 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.


3 Phoenix SEO February 3, 2012 at 8:41 am

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!!


4 Slobodan June 12, 2012 at 11:48 am

Hi Aaron,

Not quite related to your question at the end of the post, but is it possible to tell +1 button to ignore Schema data? I added markup to author box WordPress plugin, but now +1 buttons from posts with author box use some of the data related to author:

Adding another Schema dataset () is not an option in this case.


5 Slobodan June 12, 2012 at 11:49 am

That Schema dataset was supposed to be:

html itemscope itemtype=””

But I included HTML tabs, sorry about that.


6 Dragan Nikolic June 12, 2012 at 11:52 am

This looks like a logical order –

1. microdata
2. Open Graph protocol
3. Meta “title” and “description” tags
4. Best guess from page content

, but it would be nice if we had the opportunity to choose which microdata gets to be picked up by Google or Google+ button if there are several of those (schemas) on a single page.


7 Aaron Bradley June 13, 2012 at 8:34 am

@Slobodan – As far as I know there’s no way of overriding the generated snippet.

As per the list from @Dragon Nikolic, Google populates the snippet by pulling from microdata, Open Graph tag, standard meta tags or Google’s best guess:

However, there’s a semi-workaround if you can manipulate the order of the page’s microdata. The source above says:

I have multiple itemscopes on my page. Which one will the +Snippet use?

If you have multiple itemscopes defined on your page, the +Snippet will be created from the itemscope which is nearest the top of your page’s source code. For example if you have itemscopes defined on both the body element and a div element defined below the start body tag in your page, the +Snippet will be created from the itemscope associated with the body element.

So if you could markup your code so that the name, description and image itemprop values are referenced by declaring them in the itemscope of , you might be able to supersede the author information declared in the .


8 Slobodan June 13, 2012 at 8:46 am


I was afraid that was the case. Unfortunately, since WordPress plugin I’m working on can’t manipulate anything outside HTML for author box it’s adding it might be best to just drop markup. Ideally it would be with nested, but not possible here.

Thanks for your response.


9 Pure Tentation May 9, 2013 at 6:49 am

Thanks for this tip, but the second itemscope becomes useless doesn’t it?
I’ve now a problem i’d like to include Microdata about my LocalBusiness and OpenGraph data about a product in the page describing the product.
First do you think it’s smart ? if Yes, how would you do ?
Indeed, if i describe LocalBusiness first, it hides everything behind it..
Best regards


10 Aaron Bradley May 9, 2013 at 12:09 pm

You’re absolutely right PT – and in fact I keep meaning to update this post, or create another post that augments this one. Declaring an itemscope on too broad a block is problematic if you need to markup properties that don’t apply to that type.

To your question, you need to define your LocalBusiness and Product blocks separately – as you say, you’re not going to be able to describe your Product if it is within the defined itemscope of LocalBusiness (none of this matters for OpenGraph, which is described in the <head>).


11 BiNA Office Furniture November 27, 2012 at 8:28 am

The schema spec indicates that meta tags are used when you wish to include properties from other schema that are not intrinsic to the one you are using. Thus it is not arbitrary, and follows a definite convention.


Leave a Comment

Previous post:

Next post: