Start with the actual page, not a schema type#
Structured data is standardized markup that provides explicit clues about page meaning. Google says it uses markup it finds on the web to understand page content and the wider web. Begin with the page’s real purpose—article, product, organization, event, or FAQ—and the information a reader can verify there. Then choose vocabulary that describes it. Do not start with a hoped-for search feature and retrofit claims into JSON-LD.
Google’s structured-data guide recommends JSON-LD as the format that is often easiest to implement and maintain, while noting that supported valid formats can work. The operational preference is maintainability: generate values from the same source used for visible titles, prices, authors, dates, and answers so two representations do not drift.
Make every entity complete and page-specific#
A useful implementation identifies the entity, its type, and the properties users need to understand it. Use stable URLs for @id and canonical references where appropriate. Give Article an accurate headline and author; give Product an actual offer only when the price and availability are visible; give FAQPage questions and answers that exist for users. Schema.org offers broad vocabulary, but Schema.org is not a catalogue of Google feature promises.
| Review point | Good evidence | Failure to avoid |
|---|---|---|
| Identity | canonical URL and stable entity ID | a generic entity copied to every page |
| Completeness | required and meaningful properties | empty strings or invented values |
| Visibility | matching HTML text | data visible only in JSON-LD |
| Freshness | same release updates both views | stale price, author, or answer |
| Scope | type matches the page | marking a category as a single product |
Do not mistake markup for an AI access control#
Structured data does not grant crawling permission, force a renderer to execute JavaScript, put a URL into an index, or require a model to cite the page. Google’s AI features guidance says there are no special machine-readable files, AI text files, or special markup required for its AI features. That makes ordinary page quality, crawlability, and accurate content the first job.
Treat raw and rendered results as separate observations. If JSON-LD is injected client-side, capture the rendered artifact and confirm the deployment delivers it. If key page facts exist only in a script, make the user-facing HTML clear on its own. This is resilience for readers and varied automated clients, not a claim about a particular bot’s rendering contract.
Validate, deploy, and retest#
Validate the source JSON, test the live canonical URL, inspect a rendered capture, and monitor production after template releases. Google advises developers to validate markup during development and monitor live pages because serving or templating failures can break it. Record the validator, timestamp, URL, output, and release version.
Use CrawlReady’s schema checker to find candidate markup issues and the score methodology to see how broader crawlability evidence is reported. Prioritize factual correctness before coverage. A smaller set of complete entities is more defensible than a large, inconsistent graph.
Scope and limits. This procedure creates an audit trail, not a promise of crawler access, inclusion, indexing, citations, referral traffic, rankings, or conversions. User-agent text is easy to spoof. Treat the records as observed request artifacts unless the requester is verified by the relevant operator method. Keep the raw event, the verification result, and the interpretation separate so a later reviewer can reproduce the conclusion.
Evidence checklist#
Keep a small record for every schema release: the source content identifier, JSON-LD generated from it, canonical URL, validator result, and a capture showing the corresponding visible facts. Check that dates use the intended timezone, currency and availability match the offer presented to users, and organization identities do not conflict between templates. If multiple JSON-LD scripts describe the same entity, inspect the merged graph for contradictory values.
This is especially important after migrations and CMS changes. A page can look normal to a reviewer while its structured data is omitted, escaped, duplicated, or copied from a previous route. Diagnose that as a delivery defect, not as an AI-crawler behavior claim.
Choosing a safe implementation path#
Prefer a single server-generated JSON-LD graph per canonical page when the application architecture allows it. If client injection is unavoidable, test a no-JavaScript response and a rendered response, then document which one contains the graph. Avoid copying a global organization, offer, or FAQ node into every route unless it genuinely describes each route.
Build a content-model contract: which fields are mandatory, who owns them, how a missing value is represented, and which release test rejects invalid output. The contract is a better investment than adding many types because it keeps information aligned as the site changes.
FAQ#
Is structured data required for Google AI features?#
No. Google says its AI features do not require special machine-readable files, AI text formats, or special markup.
Can schema markup make an AI crawler access a blocked page?#
No. Structured data does not override robots rules, authentication, network controls, or an engine’s own crawl and indexing decisions.
Should structured data repeat visible content?#
It should describe the same page content accurately. Keep important facts understandable in visible HTML and keep markup synchronized with it.