I've inherited a site where I noticed that

  1. there is an excessive use of Schema.org in all navigation elements
  2. pages describing products are marked as itemtype="http://schema.org/CreativeWork"

So I'm wondering if these tags are sending the wrong message and not truly optimized. I realize that the nav (1) is done in some themes, but I'm more worried about (2). Can it be a hit SEO-wise to mislabel pages instead of products?

  • I will rewrite the answer when I can. It was not my best work. I apologize that it was not up to my usual standard.
    – closetnoc
    Feb 29, 2016 at 2:03

6 Answers 6


Hurt SEO? No.

Not be as helpful? Yes.

Let's focus on (2).

If you look at the spec for https://schema.org/CreativeWork you can see that it includes the important elements for Offer which can allow it to behave much like a product, as well the mainEntity property which has the expected type of Thing - which is the parent of Product (and, just about everything else).

What that means you can have a simple structure much like this to serve your product pages:

<body class="page-wrap" itemtype="https://schema.org/CreativeWork">
<div class="main" itemprop="mainEntity" itemscope itemtype="Product">
<!-- The main entity property is actually another item called Product, which is the primary focus of the page -->

So this is a simple way to include the product in the page.

In fact, wrapping the entire HTML or Body for a Schema.org ItemType should be, by default, schema.org/WebPage or its various children - which are all children of the CreativeWork item type.

There isn't anything inherently wrong with labeling a WebPage as a CreativeWork, because it is one.

The way its Schema.org should be optimised for a product page is as follows:

  • Body or HTML tag marked as an ItemPage - this is semantically the correct page for a product or item. This extends WebPage, which extends CreativeWork.
  • In the relevant area where your product is listed (i.e. your main content), mark it as the mainEntity property of your ItemPage and set its itemType as Product.
    • Ensure that your Offer is optimised properly. From a SERP appearance, this enitire area is the most important and relevant part of the product page. In fact, as long as Offer is configured correctly in a parent type such as CreativeWork, you may have rich snippets for properties like price or availability. The property offers with an expected type of Offer and its child AggregateOffer are the important elements there.

So don't be too fretted about that - a product page is preferred because it is a higher-level of fidelity, but CreativeWork is still semantically correct, just a lower level of fidelity.

Also to note: It is bad practice to label an entire page as a Product. A webpage cannot be a product, it can be about a product. This is why we have children, inheritance of properties etc in Microdata - it helps break up the page.

It the above example, I used ItemPage because it was appropriate. This allows flexibility for things like BreadCrumbs* which are appropriate for a page, not a product.

Regarding (1):

I have seen zero evidence that appropriate markup of navigational elements to have a negative effect, though the net-gains from this are still unknown.

The only negative effects from Schema.org related Microdata are bugs (i.e. putting the wrong data on the wrong properties) and cloaking - using the <meta> tag in excess puts your website at risk in that regard for trying to game relevance.

*Though there is a bug with the way Microdata of that property is handled, and it is best handled with the JSON-LD notation.


Google has quality guidelines for using structured data:

At Google, our first priority is to help our users find relevant, engaging answers for their search queries. High-quality structured data must not create a misleading or deceptive experience for search users. It should be an up-to-date and accurate reflection of the topic and content already found on the page, such as text, images, and videos. For example:

  • A page about a dinner recipe may use recipe structured data to list the ingredients and describe the cooking steps.
  • A page that lists a local business may use structured data to describe the business, its location, contact information, and opening hours.

We perform algorithmic and manual quality checks to ensure that structured data meets relevancy standards. In cases where we see structured data that does not comply with these standards, we reserve the right to take manual action (e.g., disable rich snippets for a site) in order to maintain a high-quality search experience for our users.

Structured data spam has become a problem for Google. The search results have numerous examples of sites that have inappropriate markup: one, two. Users have confirmed that Google has started doling out manual penalties for misusing schema and getting inappropriate rich snippets. Here is the text that a webmaster received upon getting this manual penalty:

Spammy structured markup

Markup on some pages on this site appears to use techniques such as marking up content that is invisible to users, marking up irrelevant or misleading content, and/or other manipulative behavior that violates Google's Rich Snippet Quality guidelines.

I'm not sure that the examples of misused schema given in this question are spammy enough to get a site penalized, but sites that go too far certainly can get hit with penalties.


2018 Update: Just to be clear, spammy or incorrect structured data CAN hurt your SEO.

Why? It's a manual action that Google will alert you with in your search console. If not addressed and fixed, your rankings WILL decline. We had a client who used structured data to markup 3 reviews plastered on a footer on every page. The result: a quick manual action which, after time, caused a noticeable hit in rankings.

Also think of Schema as a way to categorize your site. Say you're a restaurant but you mark yourself up as an Ice Cream Shop. Well suddenly, you're limiting yourself to a small niche audience when you could be reaching out to more people.

When using structured data always try to be as precise as possible without cutting out any of your potential audience.

  • 1
    Please reference answers where possible, e.g., in this instance links to Google's guidance on spammy structured markup would be helpful.
    – GDVS
    Mar 2, 2018 at 15:48

I don't know if there's an exact way to answer this for a general case, but I would reason that any misinformation on your site is automatically bad for SEO. Search engines can only do one of the following with bad information:

  • Ignore it, in which case, you're just adding to your load times for no benefit.
  • Use it, in which case you're getting hits for categories that you don't actually want, which is bad for conversion.
  • Penalize you for it, which is the worst case scenario.

So, I'd say yes, it is bad to have inaccurate markup. As for too much markup, I don't know if there is such a thing, as long as it doesn't impact usability or emphasize irrelevant portions of your site. Use it as a lens to focus a web-crawler's attention on what you care about, such as product info, contact info, and location. More detail lets the engine send more, and better, customers to your site.


Actually misused schema.org had hurt SEO.

Do you remember search results with rating stars and more information about articles or products? They are gone!

Because too many websites misused them and now you have to get a verified rating 3rd party.

  • I am the one who offered bounty for this question. Can you please add some details about what are the ways to "Rise up" from such messy situation and how is it most safe, for anyone, to construct schemas from your experience?
    – user58733
    Mar 6, 2016 at 7:48

No, Google has clearly said that misused of schema will not hurt your website ranking but yes clean HTML markups will help your site to take a edge in search results.

  • 1
    Do you have a reference? I thought that Google handed out webspam penalties for sites that abused schema markup. Mar 6, 2016 at 9:50

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.