13

Please consider the following code marked up with attributes to provide microdata:

<!DOCTYPE html>
<html>
    <head>
        <title>Micro data test - Normal version</title>
    </head>
    <body>
        <div itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Product name</h1>
            <img alt="" itemprop="image" src="http://placehold.it/200x200" />
            <div itemprop="description">This is the product description.</div>
            <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
                <meta content="in_stock" itemprop="availability" />
                <span content="GBP" itemprop="priceCurrency">£</span><span itemprop="price">100.00</span>
            </div>
        </div>
    </body>
</html>

Using Google's Structured Data Testing Tool gives positive results.

This is fine in the test example, however, we want to implement microdata on a variety of sites whose HTML structure vary greatly. To implement the attributes in this way will require someone to manually edit the HTML markup on each of the sites individually.

Preferably, we would like to be able to call a single function that packages all the microdata in one place; technically this is possible by using meta tags in the following way:

<!DOCTYPE html>
<html>
    <head>
        <title>Micro data test - Meta tag version</title>
    </head>
    <body>
        <meta itemscope itemtype="http://schema.org/Product" itemref="microName microImage microDescription microOffer" />
        <meta id="microName" itemprop="name" content="Product name" />
        <link id="microImage" itemprop="image" href="http://placehold.it/200x200" />
        <meta id="microDescription" itemprop="description" content="This is the product description." />
        <meta id="microOffer" itemprop="offers" itemscope itemtype="http://schema.org/Offer" itemref="microCurrency microPrice microAvail" />
        <meta id="microAvail" itemprop="availability" content="in_stock" />
        <meta id="microCurrency" itemprop="priceCurrency" content="GBP" />
        <meta id="microPrice" itemprop="price" content="100.00" />
        <div>
            <h1>Product name</h1>
            <img alt="" src="http://placehold.it/200x200" />
            <div>This is the product description.</div>
            <div>£100.00</div>
        </div>
    </body>
</html>

Using Google's Structured Data Testing Tool gives the same positive results as the first test.

For reference (we would never do this on an actual site) Google's Structured Data Testing Tool returns an error if you try to pass microdata hidden by CSS.

So, both the normal and meta tag markup produce the same results, however, I have some concerns due to the following statements from Google and Schema.org:

https://support.google.com/webmasters/answer/146750 states:

In general, Google will use only marked-up data that is visible to the user. Hidden data will be ignored. However, in a few circumstances, it can be useful to provide both a machine-readable and a human-readable version of your content. For example, while the text string "Elvis's birthday" is significant to a great many human readers, it's not as meaningful to search engines as 1935-01-08. Similarly, human readers can infer the meaning of the $ symbol, but it can be useful to specifically tell search engines whether your prices are in pesos or dollars.

http://schema.org/docs/gs.html states (in relation to using meta tags):

This technique should be used sparingly. Only use meta with content for information that cannot otherwise be marked up.

http://schema.org/docs/faq.html#13 states:

As a general rule, you should mark up only the content that is visible to people who visit the web page and not content in hidden div's or other hidden page elements.

My questions are:

  1. While no errors are returned, would we be penalized by search engines for using meta tags in this way (i.e. duplicate content, hiding information etc)?
  2. If this isn't suitable can you suggest any way of splitting the microdata from the actual data or will we have to bite the bullet and implement this in HTML on a case by case basis?
2
  • 2
    This kind of stuff represents quite a tricky a balancing act for Google. Even if there is no problem today, Google could easily change their policy. Google makes its money by having a search engine that leads its users to the most suitable content better than its competitors. Hidden content by any means can undermine that, so it's always going to be safer to mark up visible content.
    – Alohci
    Oct 25, 2014 at 1:39
  • @Alohci Yeah, this is what I'm fearful of and there is no way to tell until it's too late! Thanks for the comments, I think we may just have to bite the bullet on this one and do it the normal way.
    – user45839
    Oct 25, 2014 at 9:06

3 Answers 3

6
+50

Your plan of using meta data for microdata is not viable. Here is Google's FAQ about why it isn't showing your data in the search results:

Is your marked-up content hidden from users?

In general, Google won't display any content in rich snippets that is not visible to human user. Don't hide the content that you have marked up for rich snippets using techniques like display:none, value-title, or css. Google will ignore content that isn't visible to human users, so you should mark up the text that visitors will see on your web pages.

The only way to get Google to use the microdata that you supply is to mark it up where it lays in the page, visible to the user.

At this point, Google is not penalizing for trying to abuse rich snippets other than just turning off rich snippets for that site. It wouldn't surprise me if Google were to start excluding sites from the search results entirely when Google finds the site trying to use microdata in a way that doesn't corform to the guidelines.

As long as your meta data that you are marking up is also visible somewhere on the page, Google is unlikely to penalize your site as malicious. However, their automatic tools detect when you are marking the data up in a non-visible location and they won't show it in the search results.

1
  • Thanks for the answer. You raise some interesting points; it seems a bit pointless implementing microdata in meta tags if the data won't get used!
    – user45839
    Nov 4, 2014 at 9:25
4

Using meta (and link) elements for Microdata is fine. Sometimes there is even no sensible alternative to it, e.g., if specific codes have to be provided where it would make no sense to show them to your users.

Google even uses meta in some of their Rich Snippets examples:

  • Products and Software Apps:

    <meta itemprop="priceCurrency" content="USD" />
    
  • Reviews:

    <meta itemprop="datePublished" content="2006-05-04">
    <meta itemprop="bestRating" content="10"/>
    <meta itemprop="worstRating" content="1"/>
    
  • Videos:

    <meta itemprop="uploadDate" content="2015-02-05T08:00:00+08:00"/>
    <meta itemprop="duration" content="PT1M33S" />
    <meta itemprop="interactionCount" content="2347" />
    
  • Articles:

    <meta itemprop="datePublished" content="2015-02-05T08:00:00+08:00"/>
    

So the question is, how much is too much (if there is a limit at all)? And I think it’s safe to assume that there is no hard limit, it most likely depends on various additional factors.

However, it would make sense for Google not to dismiss Microdata markup if only meta/link is used. Why? Because they also support (and sometimes even recommend) JSON-LD for providing Schema.org data, and this consists only of "hidden" content (namely, a hidden script element used as data block).

And this would be what I’d suggest in your case: If you don’t want to add the structured data by marking up your existing elements, use JSON-LD.

1
  • Thanks for the suggestions. I'll take a look at JSON-LD.
    – user45839
    Jun 10, 2015 at 20:17
1

I cant comment on whether this would work for all situations, but we use Schema.org in the manner you describe -- as meta "content" on the product pages. Why? It's just so much more portable and doesn't wreck up themes. It also allows more granular control on formatting the data, and it gets relevant data just after <body> (far above the fold). Platforms that are hook based (or even F&R based like vQmod) come to mind: there is no way to fluidly F&R all the directives into structure without hard-coding it all into view.

We have not noticed any penalties, Google still uses the data, still puts it into SERP widgets. We do still have most of the data on the page somewhere, but as far as most of the markup goes, it's in 1 single hierarchical meta container using content="" like your bottom example only its wrapped withing organization as "making an offer". Now don't take this too far -- structural things like reviews loop, breadcrumbs, main description, or specs are best left out of this meta container. Try to hard code them into view.

Most people will say "don't use content="" metas" but then again, most of those people have never tried it. Same goes for things like rich markup on product lists in categories...yeah we break that rule too :) Just remember that Google isn't the only fish in the RDF pond. What G says is not "make or break" in this circumstance of using standard-issue data formats in a manner that is perfectly acceptable to the rest of the pond. Perhaps even because G itself changes its' mind in the future. It wants data above/above all, yet it makes you code in the data below/below, whereas meta attribs put it front and center, in machine-accessible language.

2
  • Flaggellum note, OpenGraph (OG) and more work in a similar method: as metas with content in the <head> or <body>. Pinterest likes the data-first from Schema. Twitter cards work similar. And don't be afraid to use data-vocabulary for breadcrumbs and parts of reviews loop, it's valid.
    – dhaupin
    Nov 3, 2014 at 23:40
  • Thanks for the answer, it's interesting to know that the meta tag method has been implemented successfully without any obvious penalties.
    – user45839
    Nov 4, 2014 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.