Google rich results test for developers: staging, code mode and scripts

The Google rich results test at search.google.com/test/rich-results checks a URL or a pasted code snippet and lists the rich result types its structured data qualifies for, with errors and warnings per item. Developers get the most out of it by testing in code mode before deploy, reading the rendered HTML when markup goes missing, and pairing it with seogeoaeo.ai's Schema Markup Checker for a JSON-LD check that a script or a coding agent can run.

URL mode or code mode

The test has two inputs, and they fail in different ways.

URL mode fetches the page as Google-InspectionTool, the way an anonymous visitor would. A robots.txt rule or a noindex directive stops the test outright, and anything behind a login or firewall is unavailable to it. The default crawler is a smartphone; switch to desktop only if your desktop template ships different markup.

Code mode takes whatever you paste, from a full HTML document to a single JSON-LD block. You can edit the code in place and run it again as often as you like, which makes it the fastest loop while you are still writing the markup.

Testing staging and localhost

Google's own help page covers the local case: a page behind a firewall or on your machine can be tested through a tunnel that exposes it publicly. Two catches apply. A staging robots.txt that disallows everything still blocks the test, and a tunnel lets anyone with the address reach your machine, so close it when you are done.

The other route is code mode. Load the page in Chrome, open DevTools, copy the outerHTML of the html element, and paste it in. That copy includes JSON-LD your framework injected on the client, which a plain view-source would miss.

Reading the errors

• Syntax errors in items of unknown type. The parser stopped before it learned what the item was. Google lists the causes: an invalid JSON document, a missing colon, comma, brace or bracket. Trailing commas and unescaped quotes inside strings are the usual suspects.
• Incorrect value type. A field got a string where Google expects a number or an array.
• Comments. The test ignores comments inside JSON-LD, but the JSON-LD standard does not allow them, so strip them before you ship.
• Results that change between runs. Google says unloadable resources can make results differ from run to run. Check the page loading warning before you blame the markup.

Clicking an error opens the code explorer at that spot. It shows the rendered source, so it reflects what JavaScript produced, not what is in your repository.

Scripting the JSON-LD side

The rich results test is a page you use in a browser. For a check that runs from a terminal, a CI job or an agent, our pick is the seogeoaeo.ai Schema Markup Checker API. Send a public URL or a raw JSON-LD string:

curl -X POST https://seogeoaeo.ai/api/v1/tools/schema-checker/runs \
  -H "Authorization: Bearer $SEOGEOAEO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input":{"jsonld":"{\"@context\":\"https://schema.org\",\"@type\":\"SoftwareApplication\",\"name\":\"Acme\"}"}}'

It reports blocks that fail to parse, missing required and recommended properties under Google's documented rules, and for a URL the schema.org types the page should add. Each finished run includes tips in priority order and a status, so an agent can fix the template and call it again until the status reads clean. The same tool is exposed over MCP for Claude Code, Cursor and Codex. A run costs 8 credits, and a run that fails costs nothing.

Know its limits before you wire it in: it reads JSON-LD only and does not execute JavaScript, so client-rendered markup still needs Google's test.

Where each check fits

Google's test stays the final word on eligibility, and Google says even correct markup does not guarantee a rich result in search.