Schema Tags: What They Are and How to Use Them

Schema tags are structured data added to a web page to identify what its content describes: an article, product, business, recipe, or another item. They use the Schema.org vocabulary. Google uses structured data to understand page content and enable supported rich results, such as search listings with additional product information.

schema tags: a large illuminated web-page model centered among a product box, storefront model, person figurine, offer token, validation screen, desk lamp, potted plant

What are schema tags?

“Schema tags” is a common name for schema markup. Schema.org’s introductory guide explains the vocabulary in terms of types and properties:

  • A type identifies the kind of thing being described, such as Product, Person, or LocalBusiness.
  • A property describes that thing, such as its name, image, or url.
  • A format determines how the data is written into the page: JSON-LD, Microdata, or RDFa.

Product is a vocabulary term, rather than an HTML element. An HTML heading identifies a heading; schema markup can identify the thing named in that heading. JSON-LD is a way to write that description, rather than a separate set of schema types.

JSON-LD, Microdata, and RDFa

Google supports three structured-data formats and generally recommends JSON-LD when the site’s setup allows it.

FormatHow it is added to a page
JSON-LDA JSON block inside a script element, separate from the visible text.
MicrodataAttributes on HTML elements; itemscope, itemtype, and itemprop identify items and properties.
RDFaHTML attributes that associate structured statements with page content.

The Schema.org Microdata guide documents the attributes used in Microdata.

Which schema type should a page use?

Choose a type that describes the content on the page. Google’s general structured-data guidelines call for the most specific applicable type and a true representation of the page’s main content.

These types cover several frequently encountered page contents:

Content being describedSchema typeWhat the markup describes
A news, blog, or editorial articleArticle, NewsArticle, or BlogPostingThe headline, author, images, and dates covered by Google’s Article guide.
A productProductProduct information, including price, availability, and ratings in Google’s product features.
A business locationLocalBusiness or a specific subtypeThe location’s name, address, and opening hours in Google’s Local Business guide.
A navigation trailBreadcrumbListThe page’s position in the site hierarchy, represented with ordered items in Google’s Breadcrumb guide.
A cooking recipeRecipeRecipe content that can qualify for a feature in Google’s search gallery.
An organized eventEventEvent information covered by Google’s supported search features.
An organizationOrganizationOrganization details, including its name, logo, and contact information, listed in Google’s search gallery.

For local businesses, Google’s type definitions explicitly recommend a specific subtype, such as Restaurant, when applicable.

A page can contain several relevant items. Google’s multiple-item guidance allows related items to be nested or described individually. Article information and breadcrumb navigation can therefore be represented together when both apply to the page.

Schema.org defines the vocabulary; Google’s search gallery identifies documented search features and links to their implementation rules. Check the feature guide before deciding which properties to include.

A simple JSON-LD schema example

JSON-LD uses a script element with type="application/ld+json". Google’s format documentation permits the block in either the HTML head or body.

This compact example describes this article using its title and the headline property documented in Google’s Article guide:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Tags: What They Are and How to Use Them"
}
</script>

The W3C JSON-LD specification explains the roles of @context and @type: the context supplies rules for interpreting terms, and the type identifies the kind of item. Here, the context is Schema.org, the item is an article, and headline supplies its title.

Expand article markup with accurate author, image, datePublished, and dateModified values when applicable. Google’s Article property definitions list these as recommended properties and specify no required properties for this feature. The headline-only example is a starting point for understanding the syntax.

Other features have different requirements. Google’s LocalBusiness definitions, for example, require name and address. Google’s product documentation distinguishes product snippets from merchant listings, with requirements depending on how the page presents the product.

How to add schema tags to a website

In a CMS, structured data may be provided through search settings or a plugin, as Google’s implementation guidance explains. For a custom site, place the markup in the page template that renders the relevant content.

Use this implementation sequence:

  1. Inspect existing markup. Check the rendered page before adding another generator. Identify which template, CMS setting, or plugin supplies each item.
  2. Choose the type and feature. Match the page’s subject to a type, then open the applicable Google feature guide.
  3. Map properties to content fields. Use the same maintained fields for visible content and structured data, including names, dates, and business information.
  4. Generate the markup. Start with the required properties for the intended feature and add applicable recommended details.
  5. Validate a rendered page. Check both the extracted markup and its agreement with visible content before expanding the implementation.
  6. Recheck after changes. Review the output when templates or the underlying content fields change.

Treat the example code as a pattern. Generate the headline from each article’s actual title instead of pasting this article’s title into every page.

How to test schema tags

Google’s structured-data testing page distinguishes two tools with different purposes:

ToolWhat it checks
Schema Markup ValidatorSchema.org markup generally, without Google feature-specific validation.
Rich Results TestStructured data for Google-supported rich results, with previews for supported features.

Start with code testing, then test the rendered URL. During a manual comparison, check that the extracted title, author, images, dates, and other values agree with the page. Google’s Article troubleshooting guide notes that policy issues may go undetected by the Rich Results Test.

After publication, use Search Console’s rich result reports to monitor detected valid and invalid items for supported report types. Critical issues prevent an item from qualifying for the corresponding rich result; non-critical issues identify possible improvements. These reports show samples, so use URL Inspection to investigate a specific page absent from a report.

A JSON-LD block must also be valid JSON, according to the W3C specification. Check JSON syntax when the data cannot be parsed, then check type and property requirements when it can be parsed but fails feature validation.

Keep markup accurate as content changes

Google’s content and image rules require current, relevant information and prohibit hidden, misleading, or fabricated content. Apply those rules to each field:

  • Update structured values when visible information changes.
  • Include genuine reviews and ratings only when the relevant feature permits them.
  • Use relevant images whose URLs Google can crawl and index.
  • Remove statements about content that has been removed from the page.

A valid test result establishes only what that test checks. Google’s rich-result policy expressly says that correctly marked-up pages are not guaranteed a rich result.

The page also needs to meet Google’s minimum technical requirements: Googlebot access, a successful HTTP 200 response, and indexable content. Meeting these requirements still does not guarantee indexing. Add schema tags to describe the page accurately, then verify the markup, the feature requirements, and the accessible page together.

One person. A whole marketing team.

Invite only