1. Choose a type that fits the page
Inspect the page's main purpose before choosing markup. An article, a product, and a navigation trail describe different things. Google's structured-data gallery lists supported search features and links to their individual requirements; the broader Schema.org vocabulary is not a promise that every type creates a Google enhancement. Make a short decision record naming the page type, the source of each value, and the person responsible. If the content does not support a feature, improve the page or choose another appropriate description instead of stretching the meaning.
2. Match the visible facts
Treat structured data as another representation of your content, not as a hidden advertising space. Names, authors, prices, availability, and other relevant facts should agree with what visitors can see. Never invent ratings, reviews, or business details to fill a template. For example, if your team changes a product's availability in the interface, the corresponding structured value needs to change too. Prefer a shared content source over manually maintaining two versions. That reduces the risk of a correct page carrying stale machine-readable information.
3. Implement a small, maintainable first version
Google generally recommends JSON-LD when your setup supports it. Before adding a new block, inspect what the CMS and existing plugins already generate. Multiple independent generators can describe the same entity inconsistently. Start with one representative template and a clearly assigned owner. Write down which fields are mandatory for your chosen Google feature and which are recommended. Do not fill unknown values with placeholders simply to silence a validator. A narrower, accurate implementation is easier to review than a large block nobody can explain.
4. Validate syntax, requirements, and meaning
Use Google's Rich Results Test for supported features, then read the specific warnings and errors rather than stopping at a headline. A parsing problem, a missing required property, and an optional recommendation are different findings. Also compare the values with the rendered page manually. Automated testing cannot establish that every statement is truthful or that all policy requirements are met. Test a normal example and at least one awkward case, such as a page with a missing optional image or an unusually long title.
5. Interpret a scan without overclaiming
Finding JSON-LD in public HTML does not establish that it is valid, appropriate, or eligible for a rich result. Equally, not detecting JSON-LD does not prove there is no structured data: other formats or implementation details may require another check. Use Suprara's public HTML review to prioritize an investigation and carry it into your personalized PDF or action plan. After implementation, rescan and validate the relevant feature with Google's tools. Even compliant markup does not guarantee that Google will display an enhanced result for a particular search.
Your practical checklist
- Choose markup that matches the page and its visible content.
- Check existing CMS output before adding another generator.
- Use real values from a maintained content source.
- Separate required-property errors from optional recommendations.
- Validate representative pages again after template changes.
Frequently asked questions
Apply what you learned
Practice this topic in Academy, then use the worksheet to document the evidence and the change you plan to make.
Sources and further reading
A clearer website starts with evidence.
Get a real public-page scan and a personalized PDF, then use the free worksheet to prioritize your next changes.