Structured Data Testing for AI

#01Which tool answers which question?

Our view: the Schema Markup Validator matters for GEO because many useful types, such as sameAs on Organization or DefinedTerm, aren't Google rich results, so the Rich Results Test won't evaluate them.

#02How do you test a page step by step?

1. Fetch the raw HTML and confirm the JSON-LD is there:

curl -s https://www.example.com/page | grep -c 'application/ld+json'

1. Run the Schema Markup Validator on the URL. Fix syntax errors and unknown properties.
2. Run the Rich Results Test if the type is a Google feature (Product, Article, Organization and so on). Fix errors, then review warnings.
3. Use URL Inspection on live pages to check the rendered HTML and detected structured data.
4. Compare to visible text: names, prices, ratings, dates and authors must match what users see.

#03Why check raw HTML as well as rendered?

Vercel and MERJ found that major AI crawlers they studied didn't execute JavaScript (Vercel). Our view: if your JSON-LD is injected by a tag manager or client-side script, Google may see it after rendering while AI crawlers don't. Put markup in server-rendered HTML.

#04What do Google's policies require?

From Google's structured data guidelines (Google) and AI features guidance (Google):

• Markup must represent the main content of the page.
• Don't mark up content that's hidden from users.
• Structured data should match visible text.
• Violations can make a page ineligible for rich results.

#05How do you test before a page is live?

Both the Rich Results Test and the Schema Markup Validator accept a code snippet as well as a URL (Google, Schema.org). Our view: paste the rendered template output from staging into the code input, so errors are caught before release. Don't rely on the URL option for staging sites behind authentication, because the tools can't reach them. After launch, re-test with the live URL, since CDN caching, plugins and consent scripts can change the final HTML.

#06What should a QA routine look like?

Our view:

Test per template, not per page: if the product template is right, all products usually are, but check edge cases such as out-of-stock items or missing ratings.

#07What errors are most common?

#08Can you test how AI uses your markup?

Not directly. Our view: the best proxy is to check whether AI answers state facts that live in your markup correctly, such as price, founder or release date. Keep a fixed prompt set, run it monthly, and log errors. If an assistant gets a fact wrong, check that the visible text and markup agree, then look at third-party sources it may be citing instead.

#09How do you link entities across markup?

Our view: give your Organization a stable @id (for example https://www.example.com/#org) and reference it from Article publisher and Product brand instead of repeating the details. The Schema Markup Validator shows the resolved graph, which makes inconsistencies easy to spot. See Organization schema.

#10Exercise

#11Checklist

• JSON-LD in raw HTML
• Validator clean
• Rich Results Test clean for Google types
• URL Inspection confirms rendered markup
• Markup matches visible text
• Weekly Search Console check

#12From MentionX data: which pages engines citeOriginal data

Method. Read-only aggregate queries over MentionX scans from 22 August to 29 October 2026 (UTC): 2,217 engine runs (2,154 completed) across 18 anonymised projects and six engines.

Structured data testing protects the pages engines cite. In the MentionX sample, those pages span several types:

Engines also differ in how often they cite anything:

Our view: no public test shows how an AI engine uses your markup. What you can test is whether the markup is valid, matches the page and is visible to crawlers that don't run JavaScript.

Limits. A convenience sample of mostly B2B software projects, run through engine APIs, which can behave differently from the consumer apps. Perplexity, Copilot and DeepSeek figures come from a single day (26 October 2026), so treat them as a snapshot, not a trend.

#13Worked example: Ledgerline adds markup testing to its release checklist

Ledgerline is a fictional accounts-payable tool. Figures are illustrative.

After a redesign, Ledgerline's article pages lose their Article markup without anyone noticing for weeks. The team adds structured data checks to its release process.

Before each release, a developer tests one page per template in the Rich Results Test and the Schema Markup Validator, and compares the raw HTML with the rendered HTML to confirm the JSON-LD is present in both. After release, the SEO lead checks Search Console's enhancement reports weekly for new errors.

The team also keeps a sheet of each template, the markup types it should carry and the properties it uses, so any change to a template triggers a re-test.

#14How do you choose which pages to test?

List each template on your site, such as articles, product pages, pricing and author pages. Pick one representative URL for each, plus any pages with unusual content. Test those after every template change. Our view: a short list tested often beats a full crawl tested rarely.

#15How do you read test results?

Errors usually mean a required property is missing or invalid, and they can make a page ineligible for a rich result. Warnings usually mean a recommended property is missing. Fix errors first. Check that the detected items are the ones you expected, because a page may carry markup you didn't know about from a plugin or tag manager.

#16How do you handle markup from plugins?

Content management plugins often add markup automatically. Check what they output, and remove duplicates when two plugins mark up the same item. Keep one source for each markup type so changes are predictable.

#17How do you monitor markup after launch?

Search Console's enhancement reports show errors by type over time. Set a regular review and investigate any sudden change. Crawl the site periodically with a tool that extracts structured data, so you can spot pages that lost their markup.

#18How do you compare raw and rendered HTML?

View the page source to see the raw HTML the server sends, and use the URL Inspection tool in Search Console or the Rich Results Test to see the rendered HTML. Check that the JSON-LD block appears in both. If it only appears after rendering, crawlers that don't run JavaScript won't see it. Our view: serve markup in the raw HTML wherever you can.

#19How do you check markup matches the page?

Compare each marked-up value with what readers see, such as the headline, author, dates, prices and ratings. Values that don't appear on the page, or that differ, break Google's guidelines. Automate this check where possible by generating markup from the same data as the visible content.

#20How do you handle staging sites?

Test markup on staging with code snippets before release. Make sure staging is blocked from indexing, but don't copy that block to production. Check robots.txt and noindex tags after each release.

#21What should a markup inventory include?

List each template, the markup types it uses, the properties and where the values come from. Note the owner of each template. Update the inventory when templates change, and use it to plan tests.

#22How do you prioritise fixes?

Fix errors on templates that cover the most pages first, then errors on high-value pages such as pricing and product pages. Leave warnings for optional properties until errors are fixed.

#23How do you test entity links?

Where markup references other items, such as an author or an organisation, check that the ids and urls are consistent across pages. The same organisation should use the same name, url and logo everywhere. Our view: consistent entity references make it easier for engines to connect your pages to the right brand.

#24Who should own structured data?

Give one person responsibility for the markup inventory and the QA routine, usually an SEO lead or developer. Make sure template changes go through them, or at least trigger a test.

#25How do you document fixes?

Record each error found, the cause, the fix and the date. Over time, the log shows which templates cause the most problems and where testing should focus.

#26How do you test markup in bulk?

Use a site crawler that extracts JSON-LD to check every page of a template, not just one sample. Export the results and look for missing properties, empty values and pages without markup. Compare the counts with the number of pages in each section. Our view: a monthly bulk check catches problems that single-page tests miss, such as markup dropped from older pages.

#27How do you report on markup health?

Share a short monthly summary with the number of errors by template, what was fixed and what's outstanding. Keep it simple so developers and content teams can act on it.

#28Common questions

Which tool should we use first? The Rich Results Test for Google features, then the Schema Markup Validator for general validity.

Does valid markup guarantee a rich result? No. Google decides whether to show rich results, even for valid markup.

Can we test pages before they're live? Yes. Both tools accept code snippets, so you can test staging HTML.

#29Related

• Technical GEO audit checklist
• Wikidata for brands