Structured data in 2026: what it does, what Google still shows and how to implement it

What structured data is and what it does

Google's definition: “Structured data is a standardized format for providing information about a page and classifying the page content; for example, on a recipe page, what are the ingredients, the cooking time and temperature, the calories, and so on.” A visitor reads the recipe; structured data hands the same facts to a machine as labelled fields.

What it can do for you is described just as plainly: “Adding structured data can enable search results that are more engaging to users and might encourage them to interact more with your website, which are called rich results.” A rich result is a search listing with something extra: price and availability, a rating, cooking time, event dates, a video thumbnail. Google also uses markup more broadly: it “uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general, such as information about the people, books, or companies that are included in the markup.”

Just as important is what structured data does not do:

• It does not guarantee a rich result. “Using structured data enables a feature to be present, it does not guarantee that it will be present.”
• It is not a ranking lever. Google's documentation frames markup as eligibility for enhanced display, not as a way to rank higher. Even when Google penalises spammy markup, the manual action “doesn't affect how the page ranks in Google web search”; the page just loses rich results.
• It is not required for AI features. “Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add.” Google still advises using it for rich results.
• It does not replace content. Markup describes what is on the page. It cannot add facts the page does not show.

What Google officially says

Three more statements from the same documentation that settle common arguments:

• “Most Search structured data uses schema.org vocabulary, but you should rely on the Google Search Central documentation as definitive for Google Search behavior, rather than the schema.org documentation.”
• “You must include all the required properties for an object to be eligible for appearance in Google Search with enhanced display.”
• “However, it is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.”

Formats: JSON-LD, Microdata and RDFa

Google reads three syntaxes, and on validity it treats them equally: “all 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature's documentation.”

• JSON-LD (recommended). A <script type="application/ld+json"> block in the <head> or <body>. It is separate from the visible HTML, so a redesign does not break it and nested data is easy to express.
• Microdata. Attributes such as itemscope, itemtype and itemprop added to the visible HTML elements.
• RDFa. Attributes such as vocab, typeof and property, also attached to visible HTML.

Microdata and RDFa tie the data to your markup, so a template change can silently break them. That is why most sites use JSON-LD. One more point matters for implementation: “Also, Google can read JSON-LD data when it is dynamically injected into the page's contents, such as by JavaScript code or embedded widgets in your content management system.” Old data-vocabulary.org markup is dead: “Data-vocabulary.org markup is no longer eligible for Google rich result features.”

Anatomy of a JSON-LD block

Every block has the same building blocks. @context names the vocabulary (https://schema.org). @type says what the thing is. The other keys are properties, and a property can hold a nested object with its own @type. @id gives the thing a stable identifier other blocks can point to.

<script type="application/ld+json">
{
  "@context": "https://schema.org",                       // 1 vocabulary
  "@type": "Product",                                  // 2 most specific type
  "@id": "https://example.com/kettles/blue-kettle/#product", // 3 stable ID
  "name": "Blue Steel Kettle 1.7 L",                   // 4 required
  "image": "https://example.com/img/blue-kettle.jpg",     // 5 recommended
  "description": "Stainless steel kettle, 1.7 litres.",
  "brand": { "@type": "Brand", "name": "Example Home" },
  "offers": {                                          // 6 nested object
    "@type": "Offer",
    "price": "39.00",                                  // 7 must match the page
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "seller": { "@id": "https://example.com/#organization" } // 8 reference
  }
}
</script>

Required, recommended and optional properties

Each Google feature guide lists properties in two groups. Required properties are the minimum: “Items that are missing required properties are not eligible for rich results.” In Search Console a missing required property is a critical issue and the item is invalid. Recommended properties add detail; when they are missing you get a non-critical warning and the item can still be eligible. Everything else schema.org allows is optional from Google's point of view: harmless, sometimes useful to other consumers, but not used for the feature.

Do not chase zero warnings at any cost. Google's own advice is that fewer, complete and accurate recommended properties beat a long list of half-filled ones. Leave out aggregateRating if you have no real reviews.

Rich results Google supports in 2026

The authoritative list is the Search Gallery page, Structured data markup that Google Search supports. On 30 October 2026 it lists 25 features. The Gallery filter column shows the site categories Google tags each feature with; the schema.org types column is the usual starting type, and the feature guide always has the final word.

Google adds a caveat to the whole list: “Note: The actual appearance in search results might be different.” Product markup has two Search Console reports (product snippets and merchant listings), and several features have their own lessons: see the Navigation and breadcrumbs lesson for BreadcrumbList, the Video SEO lesson for VideoObject, and Authors, About and editorial policy for author and Organization details on article pages.

Retired and restricted features

Since 2023 Google has been removing rich result types it considers little used. If an older guide tells you to add one of these, it is out of date.

What to do with markup that no longer produces anything: nothing urgent. Google's FAQ and How-to announcement put it this way: “Structured data that's not being used does not cause problems for Search, but also has no visible effects in Google Search.” And for the 2025 removals: “The use of these structured data types outside of Google Search (and dependent features) is not affected.” In practice, remove dead types when you next touch the template if they cost maintenance, keep the visible FAQ section if it helps readers, and never invent questions just to keep markup alive.

Google's general guidelines

The general guidelines apply to every type. Some can be checked by tools; the quality rules cannot, and Google warns that “Violating a quality guideline can prevent syntactically correct structured data from being displayed as a rich result in Google Search, or possibly cause it to be marked as spam.”

Technical: format and access

Use JSON-LD, Microdata or RDFa, and let Google fetch the page: “Don't block your structured data pages to Googlebot using robots.txt, noindex, or any other access control methods.” A noindex page cannot earn a rich result.

Content

• “Don't mark up content that is not visible to readers of the page.”
• “Provide up-to-date information. We won't show a rich result for time-sensitive content that is no longer relevant.” Past events, expired jobs and old prices should be updated or removed.
• “Don't mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page.”
• “Don't use structured data to deceive or mislead users. Don't impersonate any person or organization, or misrepresent your ownership, affiliation, or primary purpose.”

Relevance

“Your structured data must be a true representation of the page content.” Google's example of irrelevant markup: “A woodworking site labeling instructions as recipes.”

Completeness

Fill every required property. If you mark up reviews, mark up all of the visible ones: “If a page didn't mark up all of the reviews on a page, this would be misleading for people who expect to see all of those reviews, based on the appearance of the page in Search results.”

Location

“Put the structured data on the page that it describes, unless specified otherwise by the documentation.” A sitewide Product block in the footer is wrong. For duplicates, Google is explicit: “If you have duplicate pages for the same content, we recommend placing the same structured data on all page duplicates, not just on the canonical page.”

Specificity and images

“Try to use the most specific applicable type and property names defined by schema.org for your markup.” Images must be relevant to the page, and “All image URLs specified in structured data must be crawlable and indexable.” An image folder blocked in robots.txt breaks the image in the result.

Manual actions

Spammy markup, such as fake or self-written ratings, can lead to a structured data manual action, visible in the Manual Actions report in Search Console. The consequence is narrow but real: “A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search.” A related, well-known restriction: Google does not show review stars for reviews a business publishes about itself in LocalBusiness or Organization markup.

Several items on one page: nesting and @id

A page often describes more than one thing: a recipe, a video of it and a breadcrumb trail. Google handles both styles: “Google Search understands multiple items on a page, whether you nest the items or specify each item individually”.

• Nesting puts related items inside the main item: the video and aggregateRating inside the Recipe, the Offer inside the Product.
• Individual items are separate blocks, or one JSON array, for things that are not part of each other, such as a Recipe and a BreadcrumbList.

When separate items belong together, link them with @id. Google's example is a recipe and its video: “If you didn't link the items together, Google Search may not know that it can show the video as a Recipe rich result.” Also make sure the page's main type is present: “If the page only contained Video structured data, Google Search wouldn't know enough about the page to also display it as a recipe rich result.”

A practical @id pattern on example.com:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization",
      "name": "Example Home", "url": "https://example.com/",
      "logo": "https://example.com/logo.png" },
    { "@type": "Article", "@id": "https://example.com/guides/descale-kettle/#article",
      "headline": "How to descale a kettle",
      "author": { "@type": "Person", "name": "Anna Berg",
                  "url": "https://example.com/authors/anna-berg/" },
      "publisher": { "@id": "https://example.com/#organization" } }
  ]
}

Keep each @id stable across the site and over time. Many SEO plugins already output a linked @graph like this; your job is to check that the values in it are right.

How to implement: CMS, plugins, tag manager or code

Google acknowledges that many site owners cannot touch the HTML: “If you use a CMS, such as Wix, WordPress, or Shopify, you might not be able to edit your HTML directly. Instead, your CMS may have a search engine settings page, or you may be able to install a plugin that allows you to specify structured data.” Each route has trade-offs.

Built-in CMS and theme markup

Shop platforms and many themes output Product, Organization or Article markup by default. It is free and consistent, but often generic and sometimes outdated. Check what your theme prints before adding anything, because theme plus plugin is the most common source of duplicate, conflicting blocks.

SEO plugins and apps

Plugins such as Yoast SEO or Rank Math on WordPress, or schema apps on Shopify, generate a connected graph for every template and let editors fill fields per page. They are the fastest route for most sites. The risks: generic types where a specific one fits, fields left empty, values that drift from the page (a review widget's rating versus the plugin's), and changes after plugin updates.

Google Tag Manager or other JavaScript

Injecting JSON-LD with a tag manager works, because Google reads dynamically injected JSON-LD. In practice it is the most fragile route: it depends on rendering, the data is scraped from the page or typed by hand and falls out of sync, and fast-changing values like price and stock are risky. Use it as a stopgap, not as the long-term setup.

Hand-coded templates

Developers generate JSON-LD on the server from the same database fields that fill the visible page. This is the most reliable option: one source of truth, markup present in the raw HTML, no mismatch between page and markup. It costs development time and needs tests in the release process.

Testing and monitoring

Google's routine is short: “Be sure to check your structured data using the Rich Results Test during development, and the Rich result status reports after deployment, to monitor the validity of your pages, which might break after deployment due to templating or serving issues.” In practice the workflow has seven steps.

Rich Results Test

Google calls it “an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search.” Paste a URL or a code snippet; it shows which Google features the page is eligible for, with errors (missing required properties) and warnings (missing recommended ones). It only knows Google-supported features, so retired types simply stop appearing in it.

Schema Markup Validator

The validator at validator.schema.org checks schema.org syntax for every type, including ones Google ignores. Use it to catch broken JSON, misspelled properties and wrong value types, especially for markup aimed at other consumers.

URL Inspection

After release, the live test in URL Inspection shows the structured data Google detects on the rendered page. It is the quickest way to confirm that markup injected by JavaScript is actually seen.

Rich result reports in Search Console

Reports appear under Enhancements, and under Shopping for product snippets and merchant listings, only for types Google found on your property. Each shows valid and invalid items over time; “An invalid item has at least one critical issue preventing it from appearing as a rich result.” Remember that “The reports aren’t a comprehensive list of all detected items.” They show a sample, so use URL Inspection for pages you do not see listed. After fixing an issue, use Validate fix.

Measuring the effect

The Performance report's Search appearance filter shows clicks and impressions for rich result types. To judge whether markup paid off, Google suggests “The best way to do that is to run a before and after test on a few pages on your site.” Pick stable, popular pages without markup, add it, confirm it is detected, and compare a few months of data.

Schema.org beyond Google

Schema.org is a shared vocabulary, not a Google product. Its own description: “Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.” Google also notes that schema.org properties it does not require “may be useful for other search engines, services, tools, and platforms.”

In practice that means Bing reads schema.org markup, and social platforms, shopping services, email clients and assistants may use parts of it. AI search tools and chat assistants may parse it when they fetch a page, but none of them publish a guarantee that it changes what they show. Treat clean, accurate markup as cheap insurance for other consumers, and judge its value for Google by the features in the gallery.

Common mistakes

• ✕Markup for invisible contentReviews, FAQs or prices that exist only in the JSON-LD.
• ✕Price or stock out of syncThe page says €39 and out of stock, the markup says €35 and in stock. Usually a caching or tag manager issue.
• ✕Duplicate, conflicting blocksTheme, plugin and review app each print a Product with different values.
• ✕Missing required propertiesThe item is invalid and cannot become a rich result.
• ✕Sitewide markup in the wrong placeProduct, Recipe or Review blocks in a global header or footer.
• ✕Self-serving or invented ratingsStars your business gave itself, or ratings not collected from real users.
• ✕Chasing retired featuresAdding FAQPage or HowTo in 2026 and waiting for a rich result.
• ✕Testing onceMarkup breaks after template releases and plugin updates; nobody notices without the Search Console reports.

FAQ

Sources

• Google Search Central — Introduction to structured data markup in Google Search
• Google Search Central — General structured data guidelines
• Google Search Central — Structured data markup that Google Search supports
• Google Search Central Blog — Simplifying the search results page (June 2025)
• Google Search Central Blog — Changes to HowTo and FAQ rich results (August 2023)
• Google Search Central — Documentation updates (changelog)
• Google Search Central — Optimizing for generative AI features
• Google Search Console Help — Rich result report overview
• Schema.org — Home

Quotes checked against the official pages on 30 October 2026.