Nascondi

Structured Data Policies

The following guidelines describe our general policies on creating high-quality structured data. Additionally, each structured data type may have specific policies that apply to it.

Technical guidelines

Structured data should be expressed using the most specific applicable type and property names defined by schema.org. The data may be embedded in your webpage using any of three supported formats: JSON-LD, RDFa, and microdata.

It is important to mark up mobile-specific pages on your site in addition to their desktop equivalents to provide the best experience across devices.

Quality guidelines

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.

Multiple entities on the same page

When you have multiple entity types on a page, we recommend you mark up all entities on that page to help Google algorithms better understand and index your content. For example:

  • A recipe page might have text describing the recipe along with an accompanying video. Each of these types should be marked separately with schema.org/Recipe and schema.org/VideoObject respectively.
  • A category page listing several different products (or recipes, videos, or any other type). Each entity should be marked up using the relevant schema.org type, such as schema.org/Product for product category pages. Marking up just one category entity from all listed on the page is against our guidelines.
  • A video play page might have related videos embedded in a separate section on the page. In this case, mark up the main video as well as the related videos.

Guidelines for marking up images

When marking up an image URL as a property of a type, make sure that the image actually belongs to the instance of that type. For example, if you mark up the schema.org/image property of schema.org/NewsArticle, the marked-up image must directly belong to that news article.

All image URLs should be crawlable and indexable. Otherwise, we will not be able to display them on the search results page.

Non-visible content and machine-readable alternative

Typically Google will not display content that isn't visible to the end user. In other words, you generally shouldn't mark up content that is not visible to users. However, in some situations it can be valuable to provide search engines with additional data, as seen in examples below.

The values of many schema.org properties can be ambiguous when supplied with human-readable text. For example, the date 11/12/2014 can be the 11th of December in the UK or the 12th of November in the USA.

For this reason, schema.org markup employs machine-readable alternatives to remove ambiguity in these cases. This syntax is typically invisible to users, but visible in the page's source code. For example, you would use machine-readable syntax for Dates, prices, currency, and stock availability.

Here is an example of currency markup:

    <span itemprop="priceCurrency" content="USD">$</span><span itemprop="price">119.99</span>

Alternatively, you may use the meta tag to provide content that is not visible on the page, like this:

    <meta itemprop="datePublished" content="1991-05-01">May 1, 1991

The meta tag should not be used to hide content that is not visible to users in any form, since it might create misleading or deceptive search experience.

Policies specific to each type of structured data

In addition to the guidelines above, each type of structured data can have specific technical and quality guidelines. Check the relevant article for each type you're using.