Schema-graph integrity · Cross-block validation · Franchise + multi-unit

Every schema block passes the validator. The rich result still disappeared. Catch it at PR time.

You run multi-location SEO across hundreds or thousands of franchise location pages. Each JSON-LD block on the page passes Schema.org Validator individually. Two of them declare mainEntity. Google sees ambiguous page- canonical-entity and drops the rich result. Engineering spends two days finding the conflict. The fix is one line. Cross-schema integrity detection runs in CI at PR time and catches mainEntity collisions, aggregateRating duplications, orphan-graph nodes, identifier collisions, circular references, and per-page-type completeness gaps before they ship.

Audit your cross-schema integrity (Tier 1)Explore Fractional CMO operation

Published May 30, 2026

Why per-block validation is not enough at multi-location scale

Schema App, Yext, Merkle, Google Rich Results Test, SchemaPro, RankRanger — each is excellent at the per-block validation primitive. The block compiles, the required properties are present, the enumerations are valid Schema.org. Every block passes.

The combined per-page @graph is a different surface. Two blocks declaring mainEntity each pass individually. Combined they tell Google that two entities are the page canonical, and Google drops both rich results. Same shape for aggregateRating duplication: each block valid individually, combined values contradict, Google drops the rating snippet.

The conflict is invisible to per-block validation. It shows up in production when the rich result disappears and engineering opens a ticket. The fix is one line. The debugging is two days. Cross-schema detection at PR time eliminates the two-day debugging cycle.

We’ve built cross-schema detection for franchise + multi-location operators. Here’s what we know.

You probably already use Schema App, Yext, Merkle, or SchemaPro for per-block validation. Each is good at that primitive. The gap is the cross-block graph-integrity detection that runs at PR time on the combined @graph rather than per-block. We bring the per-conflict-class detection runbook, the CI integration playbook, and the per-template confidence threshold starter.

We have built this for franchise networks across verticals. We know which conflict class dominates per template type (mainEntity collision in location pages that mix LocalBusiness + FAQPage + Service; orphan-graph in Product pages that reference Offer by @id but emit Offer conditionally; per-page-type completeness in Blog pages that have FAQ sections but no FAQPage block). We bring the per-class starter so the first 30 days of detection produces signal, not just noise.

How we get from post-deploy debugging to PR-time detection

Step 1 — Tier 1 AI Readiness Assessment (2-3 weeks). We audit your structured-data emission surface (template tree, per-page-type coverage, current cross-schema conflict baseline). We sample 30-60 days of deploys and identify which rich-result disappearances were caused by cross-schema conflicts. Output: the detection specification, the per-class detection priority list, the CI integration plan, and a per-template confidence threshold starter.

Step 2 — Tier 2 AI Swarm Setup Sprint (4-8 weeks). We build the detection layer end-to-end: per-PR trigger integration, page-sample rendering, JSON-LD extraction, @graph building, per-class conflict-detection logic, CI integration, PR-comment formatting, per-template confidence threshold tuning. Your engineering team receives the running system, all source code, all credentials.

Step 3 — Tier 3 Fractional CMO with AI Swarm ( 6-month minimum, 1-2 days/wk). We operate the detection layer in production. Extend per-class detection as new Schema.org features ship. Tune per-template confidence thresholds against false-positive feedback. Coordinate the layer with the schema-auto-remediation layer (auto-remediation PRs flow through the same detection). Roll up monthly per-template fix-queue progress reports.

What changes for you

You stop spending engineering days debugging why a rich result disappeared after a template change. The cross-schema conflict surfaces in PR review, not in post-deploy investigation.

You stop guessing whether the schema auto-remediation PR introduced a cross-block conflict. Detection runs on every PR including auto-remediation PRs; the two layers compose.

You can answer the question your VP of Engineering asks at sprint planning: which cross-schema conflict classes are showing up most often in PR review, and which template families are causing them. The per-class detection rollup is the answer.

You can onboard a new template type with the per-class detection coverage extended rather than waiting for the first production rich-result disappearance to learn what could go wrong.

Frequently asked

How can every schema block pass the validator and the rich result still disappear?

Schema.org Validator checks each block individually for compliance with the Schema.org spec. The combined per-page @graph is a different surface. Two blocks can each pass — a Product block declaring mainEntity, an FAQPage block also declaring mainEntity. Each is valid Schema.org in isolation. Together they tell Google that two different entities are the canonical page entity, and Google drops both rich results because the page canonical is ambiguous. Same shape for aggregateRating duplication: a Product block declares aggregateRating with one value, a Review block declares aggregateRating with a different value. Each is valid individually; combined they contradict. Per-block validation catches Schema.org compliance. Cross-schema graph integrity catches the combined-graph conflicts.

What are the canonical conflict classes that need PR-time detection?

Six recur across multi-location operators. mainEntity collision (two or more schemas on the same page declare mainEntity, producing ambiguous page-canonical-entity). aggregateRating duplication (two or more schemas declare different aggregateRating values; Google sees contradiction and drops the rating snippet). Orphan-graph nodes (entity referenced by @id but the referenced node is missing from the @graph). Identifier collision (two distinct entities share the same @id, causing graph merging that produces wrong type assignments). Circular reference (entity A references entity B via @id, entity B references entity A — cycle that breaks downstream consumers). Per-page-type completeness gap (Product pages without BreadcrumbList; LocalBusiness pages without FAQPage when a FAQ section is present; Article pages without datePublished even though the article has a publish date elsewhere on the page).

How does PR-time detection integrate with the existing CI pipeline?

The detection layer runs as a CI check on every PR that modifies a page-emitting template or a per-page-data file. The check renders the affected page-sample (one representative page per affected template), extracts the JSON-LD blocks, builds the combined @graph, applies the conflict-class detection logic, and posts a PR comment naming the page URL, the conflict class, the involved schema blocks, and the proposed fix. Failures block merge. Engineers see the conflict during code review rather than after deploy. The schema-conflict detection layer composes with the schema-auto-remediation layer: auto-remediation generates the per-error-class fix PR, conflict detection validates that the fix does not introduce a cross-schema conflict before merge.

What does Completions commit to on Tier 3 if we run the detection layer in production?

Tier 3 process commitments include: detection runs on every PR touching templates or per-page data files; per-class conflict detection coverage maintained as new Schema.org features ship (Google rolls out new Rich Result types quarterly); per-template confidence threshold reviewed monthly with your engineering leadership; weekly false-positive review of detections that fired without producing rich-result risk; per-template fix-queue progress trended monthly. We commit to the operating discipline. Per-class precision is tuned per stack and recorded as engagement KPIs.

Who owns the template tree, the CI pipeline, and the conflict-class definitions post-engagement?

Your team owns the template tree, the CI pipeline, the page-sample selection criteria, the per-template confidence thresholds, the conflict-class extension catalog, and the engineering credentials. Completions owns the orchestration knowledge: the per-class detection runbook, the false-positive triage playbook, the per-template confidence-threshold tuning history. At engagement end we transition operational ownership back to your team over 30-60 days with documented handover.

How does the detection layer connect to the rest of the SEO + engineering stack?

The detection layer subscribes upstream to your CI pipeline (per-PR triggers), to the template tree (which templates the PR modifies), and to a representative page-sample for each affected template. It publishes downstream: PR comments to GitHub, merge gating signals to the CI pipeline, and per-conflict-class trend data to the multi-location SEO architecture layer. The schema-auto-remediation layer feeds detection (every auto-remediation PR runs through the same detection) so cross-block integrity holds even on machine-generated fix PRs.

Start with the audit

Tier 1 AI Readiness Assessment (2-3 weeks): we audit your structured-data emission surface, sample 30-60 days of deploys against rich-result outcomes, and produce the detection specification + per-class priority list + CI integration plan + per-template confidence threshold starter. If you decide to build, Tier 2 ships the detection layer. If you decide to operate it with us, Tier 3 runs the per-PR cycle in production. You choose the next step at each gate.