Start with the information the page actually provides
Structured data describes entities, attributes and relationships in a machine-readable form. It works best when it makes an existing page more explicit: who wrote an article, which organisation publishes it or where the page sits in a navigational hierarchy. It cannot replace missing information or make an unsupported claim trustworthy.
Define the intended use before choosing a type. Distinguish a vocabulary decision from a Google feature decision. Schema.org covers many concepts that have no dedicated Google rich-result presentation. Conversely, a supported Google feature has its own requirements beyond the existence of a matching Schema.org type. Record both decisions in the implementation brief.
For a professional website, begin with identity, authorship and navigation. Add specialised markup only where the relevant content and business model justify it. A consultancy service page does not become a product listing merely because a plugin offers Product markup. The appropriate model follows the published subject and relationships, rather than whichever result treatment looks most attractive.
Create an evidence checklist and ownership map
Inventory the templates that emit structured data and the systems that generate it. Check server templates, CMS extensions, tag managers and client components. Save the response and rendered output for representative pages. Record each block’s type, identifier, source component and relationship to the visible content. Multiple blocks are not inherently a defect, but unexplained ownership is a maintenance risk.
For each proposed property, identify an authoritative content field or approved business record. Names, profile links and contact information need a clear owner. Time-sensitive facts need an update mechanism. Mark optional unknown values as omitted rather than substituting a placeholder or borrowing information from another entity.
Retain a short evidence checklist: canonical page address, visible supporting passage, selected vocabulary definition, applicable Google guide, generated output and review date. This is more useful than a screenshot of a green validator result. It lets the next reviewer determine whether the implementation remains accurate after an editorial change.
Model separate entities and stable relationships
A page, a person and an organisation are different things even when they share a name. Give each a coherent role. A profile page can describe a person; an article can reference that person as its author; the publisher can be a separate organisation. Do not merge those entities merely to reduce the number of objects.
Stable absolute identifiers make intended relationships easier to inspect. An identifier ending in a fragment can label an entity without creating a new page. Choose a documented convention and reuse it consistently. Avoid deriving identifiers from a mutable display name or producing a different person identifier for every article.
The Person modelling guide examines identity and authorship, while organisation structured data covers the publishing business. References should express facts supported by the website. Linking two nodes with the same identifier is an implementation choice, not evidence that an external system has recognised or merged that identity.
Choose a delivery method with predictable dependencies
Google supports JSON-LD, Microdata and RDFa, and recommends JSON-LD. For a static PHP site, generating a JSON-LD block from the same approved record as the visible page is usually a straightforward engineering choice. It reduces the need to maintain attributes throughout a changing HTML layout. That preference does not make other supported formats invalid.
Use an actual JSON encoder rather than assembling strings with punctuation and user-entered values. Handle the HTML embedding context as well as JSON syntax. A correctly encoded object can still need safe treatment when inserted into a script data block. Keep display examples escaped so documentation does not accidentally become executable page markup.
Client-generated structured data can be processed by Google, but it introduces execution and resource dependencies. Choose it when the application requires it, then verify the public rendered output. The JSON-LD implementation guide explains serialisation, identifiers and safe integration in more detail.
Validate syntax, meaning and feature requirements separately
First check that each data block parses. Then inspect whether the vocabulary types and properties describe the intended objects. Next apply the current requirements of any Google feature you deliberately target. Finally review the claims against the page and supporting records. These layers answer different questions and should have separate outcomes.
Use the Schema Markup Validator for broad Schema.org extraction and vocabulary review. Use Google’s Rich Results Test for the Google-supported features it recognises. A type not reported by that tool may still be legitimate Schema.org data. Equally, a detected item does not prove that its claims are accurate or that it will appear in search.
The validation workflow turns these checks into a repeatable sequence. Preserve the URL, testing mode, capture date and detected items with every result. Testing a pasted code fragment isolates generation problems, while testing the deployed URL examines a different boundary: what the public delivery path actually exposes.
Investigate missing search treatments without assuming a defect
When a search treatment is absent, keep competing hypotheses open. The feature may no longer be supported, the page may not meet content requirements, the deployed output may differ from the sample or Google may simply choose another presentation. A missing enhancement report can also reflect reporting coverage rather than broken syntax.
Check the current feature documentation before changing the model. Google retired FAQ rich results in May 2026. Useful questions and answers can remain on the page, but maintaining FAQPage markup cannot restore that retired treatment. Avoid replacing an unsupported promise with an equally unsupported claim about guaranteed AI citations.
If a supported feature is relevant, inspect a live representative page, its access conditions and any applicable Search Console evidence. Compare the detected item with the expected entity and release version. Do not respond to uncertainty by adding more unrelated types. Additional unsupported claims make diagnosis harder and can create a quality problem where none previously existed.
Illustrative worked example: a professional guide library
Consider an illustrative independent practice publishing technical guides. The site has an about page, a business homepage and topic guides with visible breadcrumbs. This is a proposed model, not a report of client results. The team first records whether the publisher is an individual or a distinct business before creating any organisational claims.
A verified author record supplies the person’s public name and profile URL. The guide references that author, while a BreadcrumbList describes its navigational path. The organisation node is included only if the business exists and its published details support the chosen properties. No awards, reviews or membership claims are invented to make the graph appear richer.
A release sample includes a normal guide, an old guide without optional author biography text and the about page. The reviewer checks visible attribution, stable references and valid breadcrumb destinations. Success means those intended facts survive generation and deployment. It does not establish a ranking improvement, knowledge panel appearance, indexing outcome or citation by an AI system.
Define implementation acceptance and useful priorities
Acceptance starts with the agreed model, not a requirement to emit the greatest possible number of properties. Every block must parse; every asserted entity must have the correct role; every factual claim must have supporting evidence. Required properties for an intended supported feature must be present, while recommended properties are assessed for relevance and truthfulness.
Test representative templates, incomplete optional records and translated or migrated URLs where those exist. Confirm that the original response and rendered output contain no contradictory duplicate definitions. Differences need explanation, not automatic deletion: two blocks may validly describe separate entities. Prioritise false identity, broken serialisation and shared template defects before cosmetic warning reduction.
Assign one owner to each generator and one content owner to mutable facts. Link production deployment to the approved data revision so a stale cache can be distinguished from bad source data. Define the release evidence and unresolved limitations explicitly. These requirements create a maintainable information layer rather than a collection of isolated validator screenshots.
Plan rollback, review dates and realistic limitations
Keep a known accurate model and an inventory of affected templates before deployment. If the change publishes false claims or breaks serialisation across pages, disable or restore the responsible generator. Recheck the public response and caches after rollback. Removing a shared component without examining its responsibilities can also remove valid breadcrumbs or authorship elsewhere.
Make the rollback scope proportional to the fault. A wrong contact field may need a data correction, while a malformed shared encoder needs a code repair. The deployment and QA guide covers release evidence and monitoring. Keep useful visible content intact when a machine-readable enhancement is withdrawn.
Review documentation and business facts periodically and after significant changes. Structured data does not guarantee rich results, rankings, indexing or AI citations. It also does not correct an inaccessible page or substitute for coherent navigation. Its practical value is an accurate, explicit representation that can be tested and maintained alongside the content it describes.
Frequently asked questions
Is Schema.org the same as Google’s structured data requirements?
No. Schema.org defines a broad vocabulary. Google documents a subset of features and the conditions for using them in Search. Review both when targeting a supported feature, and do not label a legitimate vocabulary type invalid solely because Google’s test does not recognise a rich result for it.
Does every page need structured data?
No. Choose markup where it accurately describes useful entities or supports a relevant documented feature. A simple page can remain useful without a large graph. Maintenance cost and factual reliability should guide the decision, especially when the same information is generated by several systems.
Can structured data contain information absent from the page?
It should represent the page and its relevant entities accurately, with visible support for substantive claims. Do not hide qualifications, ratings or services exclusively in markup. Review feature-specific guidance as well, because some properties have more detailed requirements than a general matching-content check.
Should FAQ sections be removed after the 2026 change?
No. Keep questions and answers that help readers. Google retired FAQ rich results in May 2026, so remove promises tied to that appearance and reassess any markup maintained solely for it. The editorial usefulness of an answer does not depend on a search enhancement.
What should trigger a structured data review?
Review after template changes, identity changes, migrations and edits to important business facts. Also revisit assumptions when Google updates or retires a feature. Keep the review tied to affected records and generators so that a narrow correction does not become an unnecessary site-wide rewrite.