A valid build can still ship broken schema
A component refactor passes its unit tests. The page looks right in preview. Its JSON-LD still parses. After release, every article points to a new author ID, a service loses its provider relationship or a client-side error prevents the structured data from reaching the rendered DOM.
Those are schema regressions even when the JSON is valid. Parsing proves that software can read the block. It doesn't prove that the intended nodes, relationships and facts survived the release.
Google says JavaScript-generated structured data can be processed when it appears in the rendered page, and its guidance directs teams to test URLs. That makes browser output an essential layer. A source file or build artefact can't establish what a deployed browser route ultimately contains.
A useful test contract follows the output through several states. Parse the JSON-LD, assert the approved graph, inspect representative rendered routes, apply a clear release gate, then sample production and Google's indexed view. Each layer answers a different question.
Decide which schema behaviour deserves protection
Start with decisions the team has already approved. Tests can preserve a poor implementation, so people still need to agree which facts are true, which relationships matter and which platform rules apply.
Use the schema prioritisation framework to choose the output valuable enough to protect. A high-value provider identity used across service pages deserves stronger coverage than an optional property nobody owns. The connected schema graph contract then supplies stable IDs, intended node relationships and sources of truth.
For each important template, write a small contract in language an editor and developer can both review. Name the expected types, IDs, canonical URL, critical references and visible facts. Separate durable business rules from feature-specific requirements that may change.
For example, an Article contract might require one Article node, its canonical @id, an author reference to an approved Person ID, and accurate datePublished and dateModified values. Whether that page currently meets every requirement for a particular Google presentation belongs in a separately maintained eligibility check.
Google's general structured data guidelines require structured data to represent the page and visible content accurately. They also say correct markup doesn't guarantee display as a rich result. Your contract should protect truthful output without turning a passed test into a search-performance promise.
Build fixtures around real content states
A single ideal record won't expose the conditions most likely to break. Build fixtures from real states that exercise conditional template logic. A useful set can include a normal record, an updated record, a legacy record and one with an allowed optional field missing.
Turn evidence from a structured data audit into regression fixtures. The audit identifies representative templates and known edge cases. The test suite preserves the approved result after the defect is understood.
Article output gives a bounded example. Create one fixture with a named author and matching published and modified dates. Add an updated article where dateModified is later while the original datePublished remains stable. If legacy articles legitimately use a different author source, include one and assert its approved Person reference. The Article authorship and dates guide defines the domain decisions those fixtures should express.
Breadcrumbs provide a second example. Include a shallow page and a deeper service or insight route. Assert consecutive positions, canonical item URLs and agreement with the visible trail. The breadcrumb schema guide explains why both outputs should come from the maintained hierarchy.
Connect every fixture to governed inputs. If an author relationship fails, the useful diagnostic points toward the Person record, article field or template mapping. The guide to structured content models shows how fields, validation and outputs can share one contract.
Fixture choice is Off Piste implementation judgement. Choose records that expose meaningful variation. Near-identical samples slow the suite without increasing confidence.
Turn the graph contract into deterministic assertions
JSON-LD 1.1 defines JSON-based graph syntax, including node identifiers and references between objects. That gives ordinary test tools a stable structure to parse and query.
Begin with the cheapest checks. Find every application/ld+json block, parse each one and fail on malformed JSON. Normalise arrays, top-level objects and @graph collections into a node set. Then assert the rules that express your approved contract.
A platform-neutral Article test can read like this:
given an updated article fixture
find the Article node by its canonical @id
require its author reference to equal the fixture's approved Person @id
require datePublished to equal the original publication date
require dateModified to equal the approved update date
require the visible byline and dates to agree with those valuesFor a breadcrumb fixture, require one BreadcrumbList, positions beginning at one with no gaps, canonical item URLs and the same order as the visible trail. For shared entities, verify that a reference points to the registered ID. A copied provider object with a new identifier should fail even if its name happens to match.
Keep structural checks and current platform eligibility rules distinguishable in code and ownership. Google's structured data feature guide documents the defined features Google currently supports. Feature assertions should cite the relevant current documentation and carry a review trigger. Your stable IDs and truthful visible facts usually change for different reasons.
Test the rendered page
Build tests catch malformed JSON and incorrect graph data early. They can't catch everything a browser, component lifecycle or deployed route can change.
Load representative routes with the same rendering behaviour users receive. Wait for the application's meaningful ready state, then extract JSON-LD from the DOM and run the same graph assertions. This layer can expose duplicate blocks added by two systems, JSON-LD removed during hydration, stale component props, malformed script injection and nodes that arrive too late or never arrive.
Compare important values with visible elements in the same test. The article byline should identify the person referenced by the Article node. The visible breadcrumb order should agree with BreadcrumbList. A service name and provider claim should match the content a visitor can inspect.
Be precise about timing. A fixed delay can hide intermittent failures and make the suite fragile. Wait for an application state you control, such as the page's content-ready signal or the element that owns the data. Then retain the rendered JSON-LD and route with a failed build so the owner can reproduce the evidence.
Make failures produce clear release decisions
A test suite only protects a release when the team has agreed what failure means. Off Piste recommends assigning each assertion a blocking failure, a review-required warning or an accepted exception with an owner and review date. That severity model is implementation judgement, not a rule from Google or Schema.org.
The record below keeps the gate actionable because a missing provider relationship and an optional recommendation need different responses.
Put fast parse and graph assertions early in continuous integration. Run representative browser tests before merge or deployment when their risk justifies the time. A failure report should identify the route, fixture, assertion, expected value and actual value. “Schema test failed” isn't enough for a developer or content owner to act on.
The same checks can support a larger launch gate during a redesign, while the schema migration checklist owns baselines, URL mapping, cutover and handover. Routine regression testing should remain useful between migrations.
Use validators for the jobs they actually perform
Local assertions test your contract. External tools assess different parts of the output.
The Schema.org Markup Validator documentation describes extraction and checks for general Schema.org markup. Use it to inspect vocabulary and graph output. A clean result doesn't establish eligibility for a Google feature, agreement with visible business facts or preservation of your intended identifiers.
Google's supported-feature documentation supplies current requirements for eligible search presentations. URL-based tools can help inspect deployed behaviour. As of the 30 September 2026 documentation review, we found no documented general Rich Results Test API intended as a CI dependency. That's a scoped current-documentation finding. Don't build a release design around an API that hasn't been documented for that purpose.
An automated suite can retain links to validator evidence or trigger supported third-party tooling where the business accepts that dependency. Keep the core contract executable in your own test environment so a tool interface change doesn't erase the release gate.
Sample production and indexed state after deployment
Continuous integration ends before real infrastructure, caching and production configuration have had their say. After deployment, run a small sample across high-value templates and meaningful variants. Fetch the production route, inspect its rendered DOM and apply the same assertions. Investigate differences from the build evidence.
Google's URL Inspection API reference describes inspection results for Google's indexed view, including rich-results analysis. It isn't a live pre-merge test. Indexed evidence arrives after deployment and depends on Google's crawl and indexing state. The API reference also documents rich-results item states, including that items with errors can't appear with rich-result features.
Use indexed-state inspection as a later sample with realistic quota and timing expectations. It can reveal that Google holds an older version or reports a feature issue. It can't prove the current build will pass before release, and one inspected URL can't prove parity across a template set.
Feed recurring production or indexed differences into the schema change-management workflow. Platform requirements, CMS models and rendering strategies evolve. Their approved assertions and accepted warnings need named maintenance triggers too.
A useful schema test suite protects decisions
Start with one commercially important template. Approve its facts and graph contract, choose fixtures that represent genuine content states, automate the deterministic assertions and add a rendered-route check. Decide who can block, review or accept each failure before the first red build arrives.
The suite won't guarantee indexing, rich results, rankings or AI citations. It will tell you whether the website still publishes the structured decisions your team approved.
Website design and implementation support can build these controls into components, CMS templates and continuous integration. SEO strategy and governance can define the graph contract, acceptance criteria and monitoring evidence.