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.

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.

12 Nick van de Veerdonk August 29, 2015 at 2:09 am

Hi Aaron thanks for a very useful article!

Not too long ago I have added Microdata markup to my website and found it strange that 99% of the websites out there hardly use any markup, and/or often (including the Genesis theme) full of errors. In fact it was VERY hard to find websites that had extensive implementation.

Do you have an explanation for this? Is the learning curve to big, not worth the effort, or -please no!- has the initiative failed?

Love to hear your opinion,

Kind regards,

13 Aaron Bradley September 9, 2015 at 11:11 am

Hi Nick. Thanks for your comment.

Actually the number of sites that have adopted is quite high (I take it when you say you “have added Microdata” you specifically mean in microdata – it’s the vocabulary here that’s of importance, not the markup syntax per se). If you look at the usage counts for different types you’ll see many that clock in at over 1,000,000 domains: Product, Article and Person, for example.

Furthermore, the raw number of domains that have adopted belies the fact that has been adopted by many large websites (i.e. one domain, millions of pages), especially in ecommerce. I just did a spot check of major ecommerce sites for use. Best Buy? Check. Walmart? Check. Overstock? Check. eBay? Check. (Amazon is notable for being almost alone among major ecommerce sites in not having adopted

The same is true of large niche sites. IMDb has long employed A while Amazon doesn’t use it purchased Goodreads, which uses And, like virtually all major recipe sites, employs (If you want to quickly check whether a page for a specific product, book review, movie or recipe contains structured data markup, install the Google Structured Data Testing Tool Bookmarklet.)

I’ll note that in regard to microdata specifically, more and more sites are opting to use JSON-LD when Google supports it for the type in question. And yes, an error-free implementation of structured data markup is hard to find, but I think that’s less a question of the difficulty of using the vocabulary (although JSON-LD is making it easier to produce valid code) than specific implementation errors in specific situations (try running any given page on any given site using the W3C HTML validator and see how many are error-free:).

TL;DR? has exceeded the sponsors’ wildest expectations in regard to adoption, and the initiative is better described as a rip-roaring success than a failure.

14 Nick van de Veerdonk September 9, 2015 at 2:02 pm

Aaron thanks for your reply! It’s good to hear that the sponsors find it a success in adaption, who are these sponsors? Do you mean the participating search engines?

I just did a check on Wallmart, Bestbuy and overstock myself:

– Wallmart homepage: one viewpoint and one product (with error)
– Bestbuy homepage: NO microdata added
– Overstock homepage: Organization (error), WebSite, BusinessEntity (maybe to make up for the error in ‘Organization’?)

Not so much as a proper markup for Body class, and these are the giants!

You mention the numbers counts for the use of certain markup, doesn’t a number of 1,000.000 strike you as not so much? Mind you we are even talking about site that use microdata at all, we’re not counting the use of different schema’s so a site that let’s say uses ‘Product’ and ‘BreadCrumbs’ still counts as 1.

Let’s be generous and add a full zero to that number and call that the total amount of websites that use the markup even once, there’s close to a billion websites: that would make it 1%!

And of that 1% I garantee you 50% does not exceed the markup of a lost Hatom and a stray review.

Sure there is more use of microdata that produces rich snippets and I totally get why that works, hence more use of it. But a more complete (but still far from complete) markup like this:

is it worth the effort? How can I find value in this when it is so rare that I can count the websites that I’ve found on one hand?

Please don’t get me wrong: I’m not here to troll, I’m a developer myself who just 4 weeks learning the basics and I’m looking for some context.

Love to hear your opinion Aaron!

15 Aaron Bradley September 10, 2015 at 9:53 am

… who are these sponsors? Do you mean the participating search engines


I just did a check on Wallmart, Bestbuy and overstock myself…

Of the home pages, which in each case aren’t sources of product information. Walmart, for example, has one home page and 6,840,000 product pages; it’s the later that are important to the search engines. Similarly, the IMDb home page doesn’t provide information about movie titles, but is 37,800,000 pages do.

doesn’t a number of 1,000.000 strike you as not so much

That’s the upper limit that outputs on their sites. As to the proportion of domains that use or don’t use a particular type of markup, again scale is important (i.e. these tend to be enterprise sites).

is it worth the effort?

Depends on what you want to accomplish with your code. If you want to have better control over you Knowledge Graph presence, make yourself eligible for rich snippets, or just be sure that Google et al. have the clearest possible understanding of the entities present in your pages by making it available in machine readable format then yes, it’s worth it. If there’s no Knowledge Graph or rich snippet components associated with your site, and you’re satisfied that the search engines have a clear enough understanding of your content without the extra effort of marking up your content, then you may not see much benefit in doing so.

16 Lori January 13, 2016 at 1:49 pm

Hi – I’m about to implement schema to my ecommerce site and I want to make sure I don’t upset Google. In my product schema code, should I use the “description” property in ADDITION to the “meta descrption” on the page? If I do use both, should they be the same content or should I change it?


17 Aaron Bradley January 13, 2016 at 2:11 pm

Thanks for your question Lori. There’s no problem at all using description in addition to <meta name="description">. While they’re conceptually similar, they’re different data points (as are conceptually similar data points used by social media networks, like og:description and twitter:description), something that Google and other search engines understand well.

And no, the value (i.e. the text string that constitutes the actual description you’re declaring) for these two types of descriptions does not need to be identical. Having said this, I typically use the same description value for both the description property and the <meta name="description"> for the sake of consistency, and because there’s no compelling reason at present I can see for varying the two. However, I wouldn’t hesitate to encode different descriptions if a use case materialized that made this desirable. For example, let’s say Google released a feature that used the value for description to display up to 500 characters of a product’s description in a new “product knowledge panel.” In this hypothetical I case I would definitely create a description longer than the <meta name="description">, as the latter is typically truncated in the SERPs after 156 characters. So different if necessary, but not necessarily different. 🙂

18 Lori January 13, 2016 at 2:17 pm

Thank you, Aaron! I appreciate the response and for replying so quickly!

19 Lori January 20, 2016 at 9:02 am

One more question – for the organization and local business code: Google just says “markup should be embedded on your official web site” and I’ve read it should be added to either the HEAD or BODY of a page that’s indexed by Google. Does that mean it only goes on ONE page or should I put it in the header of all pages? Also, do you know any reason why the code can’t go in the footer? My developer wants to put it there but I haven’t found anything that confirms that’s ok. Thanks again for your help, Aaron!

20 Aaron Bradley January 20, 2016 at 9:34 am

Hi Lori. The organization and business code data need only be declared once, preferably on your home page. See my answer to this Quora question.

Regarding placement, as per Google’s guidelines JSON-LD may be added “anywhere in the HTML.” If you’re using RDFa or microdata the markup should (more-or-less) be inline with your content – but if you’re using <meta> tags these, too, can be used in the <head> or <body> (as long as that markup falls within the scope of the type you’re marking up).

21 Lori January 20, 2016 at 9:42 am

Awesome! Thanks for the info! I’ll have my developer put the Organization and Local Business code in the and we’ll put the product code in the or of those pages.

22 paul July 19, 2016 at 8:52 pm

schema markup annoys me!

23 Aaron Bradley July 20, 2016 at 10:22 am

Well, bad metadata annoys me, so I guess all of us have something to complain about. 🙂

Previous post:

Next post: