Schema Markup:
What It Is and How to Use It

Schema markup is code that uses the shared Schema.org vocabulary to describe a web page’s content, including articles, products, people, and organizations. Search engines can use those explicit descriptions to understand the page and enable richer search listings, as Google’s structured-data guide explains.

Schema markup, structured data, and rich results#

Schema markup adds meaning to information already on a page. HTML headings identify the structure of a document; schema properties identify what its content represents. A headline can be labeled as an article’s headline, and an author can be described as a person or organization. The distinction between presentation and meaning is explained in Schema.org’s introductory guide.

These related terms describe different parts of the process:

Schema.org organizes its vocabulary into a hierarchy of types. A type identifies the kind of thing being described; properties supply its details. Article is a type, while headline and author are properties. A property’s value can itself describe another entity, such as an author with a name, as Schema.org’s guide to embedded items shows.

For SEO, the practical benefit is eligibility for supported search features. Google’s structured-data gallery documents the available features and their implementation guides. Schema.org defines the vocabulary; Google’s feature documentation defines what a particular Google search experience accepts.

Common types of schema markup#

The following categories appear in Google’s supported-feature gallery. Choose a type based on the information the page actually provides.

Type selection follows the page’s main content. Google’s general guidelines require relevant markup and recommend the most specific applicable type. A type’s existence in Schema.org does not by itself establish eligibility for a Google feature; check that feature’s documentation.

Schema markup formats and a JSON-LD example#

Google supports JSON-LD, Microdata, and RDFa, and its format guidance recommends JSON-LD in most cases because it is easier to implement and maintain.

All three formats can work for Google when implemented correctly for the feature, according to the same format guidance.

This minimal example describes the article you are reading, using its headline and recorded publication and modification dates. The content properties come from the Schema.org Article definition.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup: What It Is and How to Use It",
  "datePublished": "2026-09-06",
  "dateModified": "2026-10-04"
}
</script>

The fields have specific meanings:

The W3C JSON-LD specification defines the roles of @context and @type, and the Schema.org Article reference defines the headline and date properties.

For a fuller implementation, Google’s Article guide recommends applicable information about the author, representative images, headline, and dates. It currently lists no required Article properties. The short example above demonstrates the syntax; it omits author and image details rather than supplying unverified values.

How to add schema markup to a page#

1. Identify the content and select its type. Start with the article, product, event, or other subject the page describes. Consult the Schema.org type hierarchy to find the relevant vocabulary, then the Google feature guide for the intended search appearance.

2. Check the feature’s property requirements. Requirements differ by feature. Google’s Product snippet documentation, for instance, requires a product name and at least one of review, aggregateRating, or offers. Article’s property requirements are different. Include the relevant required and recommended fields supported by the page.

3. Add the markup through the publishing system. Google’s implementation guidance notes that a CMS plugin can provide an integrated way to add structured data. For direct HTML implementations, the W3C specification describes embedding JSON-LD in a script element with its type set to application/ld+json.

4. Match the markup to the published content. Google’s content and location rules require relevant, current information on the page it describes. Compare the fields with the displayed headline, byline, dates, prices, or other applicable details. Update the structured data when those details change.

How to test and monitor schema markup#

Google’s testing guide distinguishes two tools:

Use a code test during development, then test the published URL. The Rich Results Test instructions support both inputs and explain that a URL test needs publicly accessible page resources. Inspect detected items, errors, warnings, and the rendered source to see what the tool actually received.

Check indexing separately with Search Console’s URL Inspection tool. Its indexed report describes Google’s stored version of a page; its live test examines the current page. A successful live test can establish that the page is accessible for indexing, but does not guarantee that Google will index it.

After changes, Google’s recrawling guidance says crawling can take days to weeks. Requesting a crawl does not guarantee inclusion in search results. The published markup and Google’s indexed copy may therefore differ while a change awaits processing.

For performance measurement, Google’s structured-data guide recommends a before-and-after comparison of selected pages in Search Console. Account for seasonality and content changes when interpreting traffic. Record whether Google found the markup before attributing a performance change to its implementation.

Common schema markup errors#

• Malformed JSON. Missing punctuation or incorrect value types can stop parsing. The Rich Results Test error reference lists these failures. Correct the reported syntax or type error and retest.

• Missing feature requirements. A valid Product object may still lack the properties needed for a product snippet. Check the Product feature requirements, rather than treating a recognized type as sufficient.

• Outdated or hidden information. Google’s content rules exclude misleading, invisible, or stale claims. Compare the data with the current rendered page, including time-sensitive information.

• Confusing general validation with Google support. Google’s testing documentation separates vocabulary validation from feature validation. A Schema.org-valid type can fall outside the Google features being tested; check the feature guide before diagnosing missing results as a syntax problem.

Frequently asked questions#