Test the final rendered page with two validators. Use Google's Rich Results Test to check eligibility for Google-supported rich result types. Use the Schema.org validator to inspect the broader vocabulary and graph. After deployment, use Search Console to monitor detected structured data and search performance.

A passing test means the markup passed that tool's checks at that moment. It does not guarantee a rich result, higher ranking, AI citation, or traffic gain.

Why One Test Is Not Enough

The schema testing query cluster produced 125 Google Search impressions across 37 variants in the complete 28-day window ending September 12, 2026. Every impression occurred in the second half of the window. The demand is fragmented across practical questions about validators, rich results, JSON-LD, and errors.

The central confusion is that the available tools answer different questions.

Google Rich Results Test

The Google Rich Results Test checks whether Google can read the page and whether its markup is eligible for the rich result types Google supports. It can test a public URL or a code snippet.

Use it when you are implementing an Article, Product, Breadcrumb, Organization, or another feature covered by Google's search gallery. Review errors first. Warnings may describe recommended properties that improve completeness without making the item invalid.

A valid result is eligibility evidence. Google's structured data guidelines state that correct markup does not guarantee display as a rich result.

Schema.org Validator

The Schema.org validator checks structured data against the Schema.org vocabulary. It is useful for properties and types beyond Google's supported search features, and for inspecting how connected JSON-LD nodes resolve.

Use it to find misspelled properties, unexpected types, broken references, and graph-shape problems. A clean Schema.org result does not mean Google offers a search feature for the type.

A Reliable Testing Sequence

  1. Render the real page. Test the HTML a crawler receives, not only the template or source JSON used to build it.
  2. Confirm the canonical response. The target URL should return the expected status, canonical tag, visible content, and structured data.
  3. Run the Rich Results Test. Resolve parsing errors and required-property errors for the intended Google feature.
  4. Run the Schema.org validator. Inspect every node, property, identifier, and relationship in the broader graph.
  5. Compare markup with the page. Names, dates, ratings, questions, answers, authors, prices, and availability should match visible content.
  6. Deploy and retest the public URL. A local snippet cannot expose caching, routing, canonical, or server-response mistakes.
  7. Monitor Search Console. Review structured data enhancement reports when available, URL inspection, page indexing, impressions, clicks, and the actual landing page.

Test What the Crawler Receives

Many markup bugs come from testing a source file instead of the rendered response. A PHP template may omit a field, encode JSON twice, inject an invalid character, or generate a different canonical URL in production. JavaScript can also change what is available at render time.

Fetch the public URL and inspect the application/ld+json blocks in the returned HTML. Confirm that each block parses as JSON. Then compare the values with the page title, content, breadcrumbs, author, and dates.

Common Errors and What They Mean

  • Invalid JSON: A comma, quote, control character, or encoding problem prevents parsing.
  • Unknown property: The property is misspelled or does not belong on the declared type.
  • Wrong type: The page uses a schema type that does not describe the visible content.
  • Missing required property: A Google feature cannot evaluate the item without a required value.
  • Missing recommended property: The item may remain valid but provides less complete information.
  • Conflicting identifiers: The same @id describes different entities, or one entity receives multiple inconsistent identifiers.
  • Hidden marked-up content: The graph contains reviews, FAQs, prices, or claims that visitors cannot find on the page.
  • Relative or wrong canonical URL: The graph points to a staging host, noncanonical hostname, or outdated route.

Validate FAQ and Article Markup Carefully

If a page emits FAQPage markup, the questions and answers should be visible to visitors. If it emits Article markup, the headline, author, publication date, modification date, image, publisher, and main entity relationship should describe that article.

Do not add a content type only because a testing tool recognizes it. The schema should follow the page, not the feature you hope to receive.

What to Record

For repeatable quality control, record the tested URL, test date, deployed version or update timestamp, detected items, error count, warning count, and any Search Console enhancement status. Keep screenshots only when they help diagnose a changing interface. The structured results and page source are the stronger record.

What to Watch After Deployment

Watch validator errors, indexed-page status, structured data enhancement reports, impressions, clicks, average position, and the queries that reach the page. A rich result can appear or disappear even when markup remains valid because eligibility and display are separate decisions.

The success condition is accurate, maintainable structured data that search systems can parse. A visual enhancement is a possible outcome, not proof that the markup was worth publishing.