Understanding Structured Data

Structured data provides machine-readable information that describes the meaning and relationships of content on a webpage.

Search engines can use structured data to better understand information such as products, organizations, articles, recipes, events, videos, and breadcrumbs. Correct markup can also make supported content eligible for enhanced search appearances known as rich results, although displaying a rich result is never guaranteed.

What Is Structured Data?

Structured data is information written in a standardized format that allows software to identify what webpage content represents rather than relying only on the visible words and layout.

For example, a visitor may easily recognize that a page describes an article, but structured data can explicitly identify information such as the article's headline, author, publication date, and image.

Structured data supplements the visible HTML content. It does not replace descriptive page titles, headings, text, links, images, or other well-organized webpage content.

Schema.org Vocabulary

Schema.org provides a shared vocabulary for describing many kinds of things and the properties associated with them.

Examples of Schema.org types include Article, Organization, Person, Product, Recipe, Event, VideoObject, and BreadcrumbList.

Each type can have properties that provide additional information. For example, an Article can include properties such as headline, author, datePublished, and image.

JSON-LD

JSON-LD, or JavaScript Object Notation for Linked Data, is a common format for adding structured data to webpages. Google recommends JSON-LD when it is practical to use. :contentReference[oaicite:0]{index=0}

JSON-LD is placed inside a <script> element with the type application/ld+json.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Growing Tomatoes"
}
</script>

The JSON-LD block describes the page content without adding visible information to the rendered webpage.

Context and Type

Two properties commonly found near the beginning of Schema.org JSON-LD are @context and @type.

{
  "@context": "https://schema.org",
  "@type": "Article"
}

The @context identifies the vocabulary being used. In this example, the terms come from Schema.org.

The @type identifies the type of item being described. Here, the structured data describes an Article.

Properties and Values

After identifying the type, properties provide information about the item.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Growing Tomatoes",
  "datePublished": "2026-04-15"
}

In this example, headline and datePublished are properties, while Growing Tomatoes and 2026-04-15 are their values.

Some properties can contain another structured object rather than a simple text value. For example, an article's author can be identified as a Person.

"author": {
  "@type": "Person",
  "name": "Jane Smith"
}

Structured Data Types

Different types of content require different structured data. The markup should accurately represent what the page actually contains.

Type Common Use
Article Articles, news stories, and blog posts
Organization Businesses and organizations
Person Information about a person
Product Products and product information
Recipe Recipes and cooking information
Event Events with dates and locations
VideoObject Video content and information
BreadcrumbList A page's position within a website hierarchy

Schema.org contains many additional types. Google supports specific types and properties for particular Search features, so its current documentation should be checked before implementing markup for a Google rich-result feature.

Structured Data and Rich Results

Google can use supported structured data to make eligible pages available for enhanced search presentations known as rich results. Depending on the content type, these may include additional information such as images, ratings, prices, availability, event details, or other features. :contentReference[oaicite:1]{index=1}

Adding valid structured data does not guarantee that a rich result will appear. The page must meet the requirements and policies for the particular search feature, and Google ultimately determines whether and how a result is displayed.

Structured data is therefore best viewed as a way to accurately describe content and establish eligibility for supported features rather than as a method for forcing a particular search-result appearance.

Match the Visible Content

Structured data should accurately describe the content that visitors can find on the page. Do not use markup to claim information that the webpage does not actually provide.

For example, if a recipe page does not display a preparation time, do not invent one solely to add a structured data property.

The same principle applies to reviews, ratings, prices, authors, events, products, and other information. Structured data should represent the page rather than create a different version of it for search engines.

Required and Recommended Properties

Google's requirements vary according to the structured data feature. Some types require particular properties for rich-result eligibility, while other properties are recommended because they can provide additional useful information.

For example, Google's Recipe documentation defines properties that must be supplied for particular recipe features and additional recommended properties that can enhance the information available to Google. :contentReference[oaicite:2]{index=2}

Do not assume that every Schema.org property is required or that every Schema.org type produces a Google rich result. Check the documentation for the search feature you intend to support.

Validate Structured Data

Structured data should be tested before and after it is published. Google's Rich Results Test can check whether a page contains structured data eligible for supported Google rich-result features.

Google recommends correcting critical errors and considering non-critical issues reported by the test. After publishing, the URL Inspection tool in Google Search Console can be used to check how Google sees the page. :contentReference[oaicite:3]{index=3}

Schema.org markup that is not associated with a Google rich-result feature can also be checked with a general Schema.org validator.

Common Structured Data Mistakes

Mistake Better Approach
Using a type that does not match the page Select structured data that accurately represents the visible content.
Adding information that visitors cannot find on the page Keep structured data consistent with the actual page content.
Inventing ratings, reviews, prices, or other values Mark up only genuine information represented by the page.
Missing properties required for a particular feature Follow the current documentation for the structured data feature.
Assuming all Schema.org types create rich results Check which structured data features the search engine currently supports.
Assuming valid markup guarantees a rich result Treat structured data as establishing eligibility rather than guaranteeing appearance.
Publishing markup without testing it Validate structured data and correct errors before relying on it.

Structured Data Example

The following example uses JSON-LD to describe an article about growing tomatoes.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Growing Tomatoes - Beginner Gardening Guide</title>
  <meta name="description" content="Learn how to plant, care for, and harvest healthy tomato plants.">
  <link rel="canonical" href="https://www.example-web.site/gardening/growing-tomatoes.html">

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Growing Tomatoes",
    "description": "Learn how to plant, care for, and harvest healthy tomato plants.",
    "datePublished": "2026-04-15",
    "author": {
      "@type": "Person",
      "name": "Jane Smith"
    }
  }
  </script>
</head>
<body>
  <main>
    <article>
      <h1>Growing Tomatoes</h1>
      <p>Learn how to plant, care for, and harvest healthy tomato plants.</p>
    </article>
  </main>
</body>
</html>

The visible page identifies the article and its subject, while the JSON-LD provides machine-readable information describing that same content. Additional properties can be added when they accurately apply to the page and are useful for the structured data being implemented.

Best Practices

  • Use structured data that accurately represents the page's actual content.
  • Use Schema.org types and properties appropriate to the information being described.
  • Use JSON-LD when it is practical and appropriate for the implementation.
  • Include properties that accurately apply to the content.
  • Follow current search engine requirements for specific rich-result features.
  • Do not invent information solely to complete structured data properties.
  • Keep structured data consistent with information available to visitors.
  • Do not assume every Schema.org type is supported as a search feature.
  • Do not assume valid structured data guarantees a rich result.
  • Validate markup before publishing it.
  • Test published pages to verify that search engines can access and process the markup.
  • Update structured data when important information on the page changes.

Summary

Structured data describes webpage information in a standardized, machine-readable form. Schema.org provides the vocabulary, while formats such as JSON-LD provide a way to include that information in a webpage.

Accurate structured data can help search engines understand content and make eligible pages available for supported rich-result features, but it should always reflect the real page and does not guarantee a particular search appearance. Next, we will look at social media metadata and how Open Graph tags describe pages when they are shared.