Begin with the page and a supported feature
Do not begin by adding every schema.org type that sounds related to your business. Schema.org is a broad shared vocabulary, while Google’s Search Gallery documents the rich-result features it supports and the properties they need. A product, event, or article page should first be useful without markup.
For each template, name its main subject and visible supporting facts. Then read Google’s current guide for the matching feature. Product, Recipe, Article, Breadcrumb, Event, Organization, Local business, and Video are examples. A vocabulary type alone does not create a Google feature; that feature’s required properties determine eligibility.
Make the primary visible item the primary markup.
Use Google’s guide for feature behavior and schema.org for vocabulary.
Make the visible page the source of truth
Markup must represent the main page content, not hidden, irrelevant, or misleading material. If it says a performer appears, the page needs to describe that performer. If it marks up an aggregate rating, visitors need to see that rating. This prevents a template from drifting into a misleading summary.
Build page copy and markup from the same approved records. A product feed, event system, or CMS can supply both, but values need review before publication. Do not copy a price, stock state, date, or review total into a markup-only field that can be forgotten. Update or remove markup when the visible information changes.
Keep names, dates, prices, availability, and ratings aligned with the page.
Never fill properties with guessed or stale values.
Use JSON-LD as a maintainable data layer
JSON-LD is a JSON-based linked-data format placed in an HTML document. Google supports JSON-LD, Microdata, and RDFa, and says JSON-LD is generally easiest to implement and maintain at scale. Its separation from visible markup can make nested information easier to model.
Use one clear data object for each real item, with an appropriate schema.org type and accurate supported properties. For every template, document the feature guide, source field, required-field behavior, and owner. Inspect rendered output too: a plug-in or component can add duplicate or conflicting markup.
Choose the format your team can maintain consistently.
Do not invent a required value when source data is absent.
Validate the code and the accessible page
Validation answers two questions. First, is markup complete enough for a supported feature? The Rich Results Test accepts pasted code or a publicly accessible URL and reports rich results that can be generated from the structured data. Test representative examples for every template, not one unusually complete page.
Second, can Google access the released page and resources? Do not block marked-up pages with robots.txt, noindex, or access controls. Check relevant image URLs. The test is not a quality guarantee: visible-content or policy problems can still prevent display.
Test code first, then test a live public URL.
Compare rendered page, source, and test result when tooling adds markup.
Potential display is not a promise of eventual display.
Release it like a user-facing template change
Structured data often depends on templates, feeds, and publication rules. A redesign, inventory integration change, localization update, or removed component can break many items. Add representative markup checks to the pre-release review used for canonical tags, titles, and images. Record the template, page examples, source fields, and release date.
When a template emits wrong markup, correct the shared source or template, validate a small sample, deploy the narrowest safe change, and retest affected URLs. If the fix behaves unexpectedly, use your normal rollback process. The aim is evidence-based remediation of a degraded web capability, not an outage alert.
Check representative page sets, not a single URL.
Record the change and markup component before a follow-up fix.
Maintain, measure, and accept the display limit
After deployment, use the relevant Search Console rich-result report to investigate issues and confirm fixes. Reports are samples rather than a complete inventory, and counts refer to items, not pages. Inspect a specific URL when needed.
Measure cautiously. Google suggests a before-and-after comparison on stable, sufficiently read pages over months in Search Console. Record the release date and other page changes. Correct markup enables eligibility only; Google determines the search presentation.
Recheck after CMS, template, feed, policy, or content-model changes.
Avoid comparisons where other major page changes differ.