How to Use Structured Data for Rich Results in 2026

Rich result eligibility starts with a supported search feature and accurate structured data, but valid markup never guarantees display. Google decides whether to show a rich result for a particular query and page.

The first check is semantic accuracy. Every marked-up property should describe content that exists on the page and should follow the applicable structured data guidelines. Do not add properties simply because a generator offers them.

The second check is page quality and usefulness. If your markup describes a 300-word instructional page, searchers have very little to act on. The same markup on a 1,800-word guide with clear step delineation, supporting images, and internal links to related content describes a page that deserves a premium SERP placement. Google sets no word-count rule, so judge completeness by what the searcher needs.

The third check is technical eligibility. The page must be crawlable and indexable, the markup must be parsable, required properties must be present, and the implementation must comply with the feature's policies.

The fourth check is intent fit. Use a schema type because it accurately describes the content, not because a richer search appearance would be attractive. A product page, event page, article, video, recipe, or other eligible content type should satisfy the requirements specific to that feature.

Even a 1,000-word page can fail if the structured data contradicts the visible content or omits required information. Conversely, concise content can qualify when it genuinely satisfies the documented requirements.

Use this sequence before deployment: confirm feature support, verify page-content alignment, implement required properties, test syntax and eligibility, then monitor Search Console for detected issues where a relevant enhancement report exists.

Keep the distinction between page usefulness and structured data eligibility clear in reporting. If a page is useful but no relevant rich result exists, adding unrelated markup does not create one. If a relevant feature exists but the page lacks required information, fix the visible content first rather than hiding data only in JSON-LD.

This eligibility-first thinking reorders the entire implementation process. Schema becomes the last step, not the first.

The Schema Signal Stack is the core framework we use when approaching structured data for any site. It organizes markup into three layers - entity-level, page-level, and interaction-level - each building on the previous, so that every piece of markup contributes to a coherent description rather than existing in isolation.

Structured data also becomes easier to maintain when the site uses stable identifiers and models relationships consistently.

Layer One is Entity-Level Markup. Start with organization and person entities only where the site has accurate information to support them. Use consistent names, URLs, logos, and SameAs references that genuinely point to profiles for the same entity. Avoid adding directories or profiles simply to increase the number of references.

Layer Two is Page-Level Markup. On individual pages, choose the primary schema type that matches the visible content. An article can reference its author, publisher, image, and breadcrumb relationships. A product can reference an offer or review data only when those details exist and satisfy the relevant guidelines.

Multiple types on the same URL can be correct. The important question is whether they describe distinct, real aspects of the page without contradiction. BreadcrumbList plus Article is common. Product plus an unrelated Review that does not reflect visible review content is not.

Use @id values to connect repeated entities when that makes the graph easier to maintain. Consistent identifiers can prevent accidental duplication across separate JSON-LD blocks.

Layer Three is Interaction-Level Markup, the layer most SEOs skip. VideoObject markup on embedded videos makes them eligible for video results in Search, and Speakable markup, a beta feature for news publishers, identifies the sections best suited to being read aloud by Google Assistant.

Implementing the Stack in order matters. Entity first. Page-level second. Interaction signals third. Skipping Layer One and jumping to Layer Two is the most common structural error we see. At every layer, a smaller, accurate graph is preferable to a large collection of speculative properties, and feature support and schema guidance deserve a fresh review in 2026 rather than an assumption that old implementations remain current.

Prioritize structured data according to the page types your site actually publishes and the rich result features Google currently supports. A schema type can be valid Schema.org vocabulary without producing a Google rich result, and the opportunity landscape shifts meaningfully every twelve to eighteen months.

Currently overplayed: FAQ schema and HowTo schema. Feature availability has changed, and implementations that were useful in 2022 may no longer justify development time in the same way. FAQ rich results now appear only for well-known government and health websites, and HowTo rich results have been retired. A site spending implementation time on these two types above all others is unlikely to see strong returns.

Currently underutilized: Product schema with Review aggregation. If your site sells or reviews products, properly implemented Product schema combined with AggregateRating and Review properties creates eligibility for star ratings in organic results when the required product information is visible.

This is one of the few rich result types where the visual upgrade directly and measurably influences click-through intent. The technical implementation is more complex than FAQ schema, which is precisely why most sites skip it - and why it represents a genuine competitive gap.

Review and rating properties must comply with the applicable review and merchant guidelines; do not mark up self-written testimonials.

High opportunity: Article and BlogPosting with Author entity markup. Implementing Person schema for your authors with credentials, social profiles, and SameAs properties, and connecting that Person entity to Article markup through the author property, helps Google understand who wrote the content and makes the expertise behind it explicit.

Event schema remains consistently valuable for any site with time-bound content - webinars, conferences, product launches - and earns visually distinct search features with minimal competition in most niches.

VideoObject markup is equally valuable when the page contains an eligible video. Use the documentation for each type rather than assuming the same property set applies everywhere.

Speakable markup is a beta feature for news publishers, used to identify sections suited to audio playback by Google Assistant; it is not a general route into Google AI Overviews.

The best prioritization rule is simple: implement supported markup first on pages where the corresponding visible content is complete, accurate, and strategically important.

Before adding any new schema, the most impactful action most sites can take is auditing the structured data that already exists. We call this the Dead Schema Audit, and it consistently surfaces implementation problems that hold back eligibility across entire domains.

It should answer what markup exists, who generates it, whether it matches the page, and whether it is still relevant to a supported feature.

Start by crawling representative templates and inspecting the rendered HTML for JSON-LD, Microdata, and RDFa. Identify whether the CMS, theme, tag manager, plugin, application code, or another system outputs each block.

Then test important URLs with the Rich Results Test when the markup targets a supported Google rich result. Use Schema.org validation or equivalent checks for vocabulary that is valid but not tied to a Google rich result.

Look for contradictions rather than assuming multiple blocks are automatically harmful. Duplicate Organization or WebPage nodes may be harmless when they agree, but conflicting names, URLs, canonicals, offers, ratings, dates, or entity identifiers create ambiguity, and that often happens when multiple plugins or developers have touched the same site's schema layer.

Flag deprecated properties too: Schema.org evolves continuously, and properties that were valid two or three years ago may now be deprecated or ignored.

Remove obsolete markup when the page no longer contains the described content. If an event page becomes an evergreen article, the old event markup should not remain unless an event is still visible and relevant.

Review template-wide output carefully because one inaccurate field can propagate across many URLs. Sitewide LocalBusiness, Organization, or breadcrumb markup is only useful when the values are accurate for every page where it appears.

Document which system generates each structured data block before editing. Otherwise a manual fix can be overwritten by the CMS or duplicated by another generator. When several systems output overlapping data, fix the generator that owns the field rather than patching individual pages.

Template-level corrections reduce the chance that the same contradiction will return on the next release. In our experience, this audit phase alone can improve rich result eligibility for pages that previously had 'correct' markup but were silently held back by conflicting or stale signals.

AI Overviews - Google's generative search experience - represent a new consumption layer for your content. They aggregate and synthesize information from multiple sources, and Google documents no special structured data requirement for them or for other Google AI features: pages are eligible on the same terms as in Search.

Structured data helps machines understand explicit entities and page content. The same rule applies to AI features as to traditional search: markup must reflect visible content and should be implemented for a documented purpose.

On content structure: use clear HTML headings, self-contained paragraphs that answer discrete questions, accurate dates where dates matter, and consistent entity information. Content with a clear hierarchy is easier to extract and attribute correctly. Apply Article schema with accurate datePublished and dateModified properties when the page qualifies.

On entity clarity: establish your Organization entity thoroughly, with accurate SameAs references, so it is clear who stands behind the content.

Speakable is a beta feature for news content read aloud by Google Assistant, not an AI Overviews signal, and HowTo, FAQPage, or Article markup belongs on a page because it describes that page.

When a page is cited or surfaced by a Google AI feature, record it as an observed search outcome alongside the content and markup changes that preceded it.

The correct operating practice is to maintain accurate markup, high-quality visible content, crawlability, and clear entity references, then measure search outcomes separately.

JSON-LD is the implementation format Google recommends for structured data, and for good reason. Unlike Microdata or RDFa, JSON-LD is injected into the page without modifying the visible HTML structure. This makes it easier to maintain, easier to debug, and easier to update without risking content changes.

Placement: put JSON-LD where your rendering stack reliably outputs it in the final HTML or rendered DOM. The document head is the usual place, and immediately before the closing body tag works just as well; the important requirement is that Google can access the markup when it processes the page.

Structure: each JSON-LD block should begin with the @context and @type declarations, followed by required properties for that schema type, then recommended properties, then any additional nested types.

Nesting is where most implementations either gain or lose significant value. An Article block should nest a Person block for the author rather than simply providing a string name, and a Product block should nest an AggregateRating or Offer block rather than declaring them as flat properties.

Always implement all required properties first, then add recommended properties to maximize the richness of the resulting search feature.

Use @graph when it makes a multi-entity page easier to model and maintain. Separate script blocks can also be valid. Choose the architecture that prevents contradictions and is easiest for the development team to test.

Before deployment, test representative URLs. Use the Rich Results Test for supported Google rich result types, inspect the rendered page when JavaScript generates markup, and compare every important property with visible page content.

Errors in the Rich Results Test block eligibility; address all of them before deployment. After deployment, request indexing through URL Inspection so Google recrawls the updated page, then monitor the relevant Search Console enhancement report over the following two to four weeks to confirm the items are detected, and keep watching for template regressions.

Document the implementation path so future theme, CMS, or application changes do not break the structured data silently. Include test cases in deployment QA for the templates that carry structured data.

A representative article, product, event, and other key template can reveal rendering regressions before they affect a larger set of URLs.

The most underrated concept in structured data strategy is content-schema alignment: structured data should describe what a user can reasonably identify on the page. Start with the page's dominant purpose and choose markup that fits that content.

An editorial guide can use Article or BlogPosting when appropriate. A genuine product page can use Product and Offer data when the visible page contains the required information. A real event page can use Event. A breadcrumb trail can use BreadcrumbList.

Problems arise when templates assign a type to pages that do not match it. Category archives, tag pages, author pages, and editorial articles should not inherit Product or other commercial markup merely because the CMS uses a shared component.

Repurposed URLs deserve special review. If a page changes from one content type to another, remove structured data that describes the former purpose.

Secondary types can add useful context when they are accurate. BreadcrumbList with Article or Product can be appropriate. The presence of several types is not inherently good or bad.

Build a page-type map for the site, define the allowed structured data for each template, and let exceptions be explicit rather than accidental. This process typically reveals that a meaningful proportion of a site's schema is misaligned in ways that generate no visible errors.

The page-type map should be shared with content and engineering. Editors can flag when a page changes purpose, and developers can keep template output aligned with the publishing model instead of guessing from URL patterns.

Structured data measurement should separate eligibility, actual search appearance, click performance, and downstream business outcomes.

Start with eligibility. The Rich Results Test can show whether markup meets supported feature requirements at test time, while Search Console enhancement reports can surface detected items and issues for certain rich result types.

Check them weekly during the first three months after implementation: a drop in eligible pages after a site update is an early warning signal that deserves immediate investigation.

Next, confirm actual search appearance where possible. Search Console search appearance filters may help for supported result types, and manual SERP review can provide additional observation for important queries.

Be careful with third-party feature trackers because they observe search results rather than Google's internal eligibility state.

Then compare performance. In Search Console, compare the click-through rates of pages with confirmed rich results against similarly positioned pages without them, and check position, query mix, title, competition, seasonality, and content changes over the same period so each comparison stays interpretable.

What most sites miss: rich results change the type of clicks you receive, not just the volume. A product listing with star ratings attracts visitors who are further along in purchase intent. That intent shift affects conversion rates downstream and is worth tracking through goal completions in your analytics platform alongside raw traffic volume.

Record implementation dates, template releases, content updates, and SERP changes so later analysis can distinguish correlated events.

The decision question is whether the markup remains accurate, eligible, useful to users, and worth maintaining. That is more robust than treating rich result presence as the only success criterion. When a feature disappears, check whether the markup changed, the page changed, eligibility changed, or the search result presentation changed. That sequence prevents teams from rewriting valid markup in response to a presentation decision they do not control.