Plan structured data page by page, then keep it accurate

Start with the page and the facts people can see

Begin with a real page, not a list of schema types. Write down what the page is about, what a visitor can verify there, and which system or person owns each fact. A business name might come from an approved brand record; an address from the location owner; an article date from the publishing workflow. If nobody can identify the source, leave the field out until it is confirmed.

Structured data gives machines explicit labels for information in a page. Google describes it as a way to provide clues about page meaning and says it can make pages eligible for richer search appearances. The main answer still belongs in readable page content. Markup should describe that answer, not add a second version containing hidden claims or details that visitors cannot find.

Separate Schema.org vocabulary from Google search features

Schema.org defines a shared vocabulary of types and properties. Google Search uses that vocabulary, but its documentation is the authority for which properties and types Google recognizes for a particular search feature. Its current gallery is the practical shortlist when the goal is a Google Search appearance. Schema.org also includes types and properties Google does not currently use for a documented Search feature; other services may still use them. Record the intended consumer instead of assuming that every valid type produces a Google result.

A type that passes a syntax check may still be irrelevant to the page, unsupported for a Google feature, incomplete for that feature or inconsistent with the visible content. Even correctly implemented data only makes a page eligible where the feature rules are met; Google says it does not guarantee that the feature will appear. Treat a rich result as a possible presentation, not a promised ranking or traffic outcome.

Copy this fact-to-markup planning register

Use one row for each page and candidate entity. Keep the register beside the content inventory, not only inside a developer ticket. The completed sheet should let another person explain why each type exists, where every property came from and who will correct it when the source changes.

• Page and purpose: canonical URL, page owner, the visitor task and the page’s main subject.
• Visible fact and source: exact visitor-visible name, date, address, image or other fact; the authoritative record; and the person who can verify it.
• Candidate type and properties: the narrowest applicable Schema.org type and only the properties that match the content. Link the vocabulary definition and any Google feature-specific documentation.
• Intended consumer: Google Search feature, another named platform or internal use. Record “no current Google rich-result feature” when that is the honest answer.
• Eligibility and disclosure: required fields, public availability, visible-content match, permission to publish, and any fields deliberately omitted because they are private, unknown or irrelevant.
• Implementation owner: the CMS, plugin, template or application code that emits the markup. Record how duplicate output is detected and which source wins.
• Test evidence: the rendered URL or source inspected, tool and date, detected item, errors fixed and the result after deployment.
• Maintenance: fact owner, update trigger, review date and the person who can correct or remove stale markup.
• Decision: publish, revise, defer or remove, with the reason and approver.

Hypothetical example: one service business, three page jobs

Consider a hypothetical repair business with one real business location, three nearby towns it serves, and a practical maintenance guide. The names, place and page details in this example are invented. Its draft register could make these decisions:

• Home page — consider Organization details for the identity that the site visibly presents. Verify the official name, website, logo and any contact or address facts against the business’s own approved records. Google says this information belongs on the home page or one page that describes the organization; it does not need to be copied onto every page.
• Location information — describe the actual local business location when LocalBusiness markup fits the business and its visible details. The three towns served do not become three extra office locations merely because the site names them. Use the existing service-area page screen to decide whether each town deserves useful content; that is a separate website-content decision.
• Maintenance guide — Article markup should reflect the real headline and publishing history, with truthful authorship. BreadcrumbList markup should reflect the page’s actual site position and labels. Keep each consistent with the visible page. Do not label the guide as a product, review or event to seek a different search treatment.

Choose one publishing path and look for duplicate output

A site can emit structured data through a CMS, a theme, an extension, a tag manager or custom application code. Inventory these sources before adding another. Two components may output separate Organization objects with conflicting names or addresses, or a plugin may add markup after a developer has already added the same item to a template. A passing validator will not decide which version the business intended.

Google supports JSON-LD, Microdata and RDFa, and recommends JSON-LD when the site setup allows it because it is generally easier to implement and maintain. Pick the format and owner the team can review reliably. For each page type, keep a small sample in the release checklist and inspect the final rendered page after template or plugin changes.

Validate the rendered page before and after release

For a Google-supported feature, run the Rich Results Test on the public URL or a representative code sample. Fix syntax and required-property errors, then compare each value with the visible page and its source record. The test can report what it detects; it cannot establish that the business facts are true, that a type is suitable, or that Google will show a rich result.

After release, use the Search Console report for a supported feature and inspect individual URLs when needed. Reports show samples, not necessarily every item. Check that the page is crawlable and that its structured data still appears in the served version. When a template feeds many pages, inspect one normal case and the exceptions: missing optional facts, long names, changed addresses, retired offers and old content.

Keep markup aligned when the business changes

Review the register when the underlying fact changes, when a page is repurposed, when the CMS or markup generator changes, or when the linked feature documentation changes. Correct the page and the structured data together. Remove properties that are no longer supported by a real source or visible content. If a feature disappears from the current gallery, reassess its maintenance cost and any separate downstream use before keeping the markup.

For a website project, put the register, implementation owner and post-release check in the handover. The website brief defines the overall audience and project scope; the service content map decides which service pages answer distinct questions; the handover guide assigns access and ongoing ownership. This guide covers the narrower job of mapping facts on those pages to structured descriptions that remain accurate.