What should structured data clarify first?
Start by matching structured data to the page’s main subject, not by adding every schema type available. A product page should clarify a product, a service page should clarify a service, and an article should clarify its article details. The markup should help a search system connect the page with the entities, properties, and relationships already stated visibly on the page.
Write down the question the page answers and the facts a buyer must understand to use that answer. Those facts become the source for choosing relevant schema.org properties. For example, a software comparison may need clear names, features, limitations, and audience information, while a local service page may need business identity, area served, and contact details. Structured data is not a place to add claims that the page does not show.
The first check is alignment. Compare every proposed property with the visible wording, page purpose, and current business information. Remove properties that are vague, unsupported, or copied from another template. This prevents a common failure: valid markup that describes a richer or different page than the visitor can actually read.
For more context, read AI Search Technical SEO Checklist: What to Fix First.
Which schema format and types fit the page?
Use JSON-LD when the team needs a maintainable way to add structured data without weaving attributes through the page’s visible HTML. JSON-LD is usually easier to manage across templates, but the format matters less than whether the chosen type accurately describes the page and follows the relevant search documentation.
Choose the most specific legitimate type that fits the content. Do not mark a general buying guide as a product, or a company opinion as a review, simply because those types appear to offer more search features. A page can use several connected entities when the relationships are real, such as an article about a software product written by an identifiable organisation.
Check the type against three questions. Does the type describe the page’s primary purpose? Are the required or recommended properties genuinely available? Would a reader recognise the same entity and relationship from the visible page? If any answer is no, simplify the markup. Search enhancements are eligibility features, not a guarantee that ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews, or Google AI Mode will cite the page.
For more context, read Ai Visibility Audit Checklist 12 Checks Before Publishing.
How do I make markup agree with visible content?
Make structured data repeat and organise important facts that visitors can already verify on the page. Names, descriptions, prices, dates, authorship, product identifiers, and availability should match the visible content wherever those properties apply. A search system can treat conflicting versions as a reason to distrust or ignore the markup.
Check the rendered page rather than only the source template. Client-side rendering, consent tools, localisation, or conditional components can cause the visible page and the JSON-LD output to diverge. Compare the page title, main heading, canonical URL, entity name, and key claims with the structured data generated for that URL.
The most important check is not whether the code contains a property, but whether the property is understandable in context. A description that implies a guarantee, a date that is no longer visible, or a rating without an identifiable basis can make the markup less useful. Keep the page and its markup under the same content owner, and create a review trigger whenever a product, service, policy, or company fact changes.
What should I validate before publishing?
Validate both the code and the page experience before releasing structured data across a site. A syntax validator can identify malformed JSON, invalid values, and missing punctuation, while Google’s testing and reporting tools can show whether a supported rich result is eligible. Eligibility is narrower than general usefulness, so passing a test does not mean that every search system will use the markup.
Check a representative URL from each template, including a page with optional fields absent. Test empty values, special characters, multiple languages, redirects, and pages with noindex or canonical signals. Confirm that the generated markup uses the final URL and that dates, identifiers, images, and organisation details are current.
Review warnings as well as errors. A warning may not block display, but it can reveal missing information that matters to people or creates inconsistent records across templates. Record the validation result, template version, and publishing date. That evidence makes later diagnosis easier when a page changes, a search feature disappears, or a team claims that markup was added when only the template was updated.
Can search systems access the marked-up page?
Structured data cannot help a page that search systems cannot reliably retrieve, render, or associate with the correct canonical URL. Check robots.txt rules, noindex directives, authentication, server responses, redirects, canonical tags, and JavaScript dependencies before treating markup as the solution.
Use a small sample of important URLs to confirm that the public version contains the intended content and JSON-LD. Check whether a crawler receives an error, a soft redirect, an empty application shell, or a different language and region version. Also confirm that internal links and XML sitemaps lead to the preferred URLs rather than duplicate or parameterised copies.
Do not assume that access by Google guarantees identical access or interpretation by ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews, and Google AI Mode. Their retrieval and answer systems can change, and some may use different sources or access paths. The practical decision is to fix broad accessibility problems first, then add markup where it accurately clarifies a page. A blocked or contradictory page needs technical and editorial work, not more schema properties.
How should I choose between manual checks and monitoring?
Use manual inspection for a small set of high-value pages, and use ongoing monitoring when the business needs to know whether buyer questions produce mentions or citations. Manual checks are useful for reviewing rendered markup, comparing page text with properties, and investigating a specific answer. They are weak at revealing repeat patterns across engines, prompts, competitors, and time.
Google Search Console can connect search performance with the pages and queries that receive Google exposure, but it does not provide a complete view of answers from every named engine. Structured-data reports and validation tools show implementation issues, not whether a buyer’s question leads to a citation in ChatGPT or another assistant.
Cituna tracks whether seven AI answer engines, ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews, and Google AI Mode, mention and cite a brand for the questions its buyers ask every day. It also shows which competitors and pages they cite instead, joins those answers to Google Search Console data, and gives SEO, AEO, and GEO fixes. That makes it useful after implementation, when the decision is which page or content issue to address first.
What should I change when markup passes but citations do not?
When structured data passes validation but citations remain absent, inspect the page’s answer quality and source signals before adding more markup. Valid markup proves that a machine-readable description exists. It does not prove that the page is the best answer for a buyer’s question or that a particular engine will retrieve it.
Compare the page with the pages cited for the same question. Check whether the cited pages answer the question directly, explain important distinctions, show evidence, use terminology buyers recognise, and remain current. Then check whether your page has a clear answer that can be quoted without requiring several clicks or interpretation. Structured data may clarify the subject, but visible text usually carries the explanation and the evidence.
Use a decision rule: fix access or contradiction first, improve the page’s answer and supporting evidence second, and add or refine markup when it removes a genuine ambiguity. Avoid changing all three at once. A controlled change gives the team a better chance of connecting a later visibility change with its cause, although rules and retrieval behaviour can change independently.
How do I roll out structured data without creating sitewide errors?
Roll out structured data by template and risk level, beginning with pages where the business can clearly define the subject and maintain the underlying facts. A staged release is safer than placing one broad schema block across every URL, because different templates often have different entities, optional fields, and content owners.
Before deployment, document the source for each property, the owner responsible for updates, the validation method, and the condition that removes stale markup. Release a small sample, inspect the rendered output, check Search Console after the pages are crawled, and compare the results with the previous implementation. Expand only after the sample behaves as expected.
Set a rollback path for malformed JSON, incorrect entity relationships, or a template that labels pages inaccurately. Keep structured-data changes separate from major copy, URL, and internal-link changes where possible. If several changes are unavoidable, record them together so later analysis does not mistake a schema deployment for the cause of a change in Google visibility or citations from ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews, or Google AI Mode.
Related reading
Sources consulted
- Google Search Central (developers.google.com)
- Google Search Console Help (support.google.com)
- OpenAI Platform (platform.openai.com)
- Perplexity API Documentation (docs.perplexity.ai)
Drafted with AI assistance from our own research and Search Console data, and reviewed by Rahul A before publishing. Rules and prices change; check the linked official source before you act.