Template-level audit
What each template emits, whether it validates, and whether it matches rendered content. Reported by template rather than by page, so the numbers are actionable.
Why markup decays on large sites
Markup decays because it is written once and the site keeps moving. A field gets renamed, a component is refactored, a content type gains an optional field nobody populates — and schema that validated last quarter now describes something the page no longer says, across every page using that template.
The scale of the failure is what makes this different from ordinary schema work. On a ten-page site, invalid markup is a ten-page problem someone notices. On a fifty-thousand-page catalogue, one template change produces fifty thousand invalid pages, and Search Console reports it as a number nobody has time to investigate.
The second failure mode is silent inaccuracy, which is worse than invalidity. Markup that validates perfectly while describing the wrong thing — stale availability, a rating aggregated from reviews that were removed, a product attribute no longer shown — passes every automated check and steadily teaches engines that your declarations are unreliable.
Both problems have the same root cause: markup treated as content rather than as code. Schema written by hand into a CMS field, or added per page by an editor, has no mechanism to stay true. Markup generated from the same data the page renders cannot drift, because there is only one source.
Governance is therefore mostly an engineering question. Where is markup generated, what validates it, what fails the build, and who is alerted when production diverges from expectation. Those four answers determine whether structured data is an asset or a slowly accumulating liability.
What the engagement covers
The engagement covers an audit of what every template currently emits, migration of markup from hand-written fields to template generation, validation wired into your build, production monitoring for drift, and documented ownership so schema changes are reviewed rather than improvised.
Generation migration
Markup moved from hand-written CMS fields to generation from the same data the page renders, which removes the mechanism by which drift happens at all.
Build-time validation
Schema validation in CI, failing the build on invalid output. Cheaper than discovering it in Search Console six weeks later across forty thousand pages.
Production drift monitoring
Scheduled checks against live pages, because staging validation cannot catch markup that goes wrong due to real content in production.
Type coverage decisions
Which schema types each template should emit, decided deliberately rather than accumulated. Removing markup that serves nothing is part of the work.
Ownership and review
Documented ownership of the schema layer, so a template change that affects markup is reviewed by someone who knows what it declares.
How the engagement runs
The engagement runs in two phases: an implementation that audits every template, migrates markup to generation and wires validation into your build pipeline, followed by ongoing monitoring that checks production for drift and alerts whenever live output diverges from what was expected.
- 01
Audit by template
Every template's output validated and compared against what the page renders. Aggregating by template rather than by page turns an unmanageable error count into a short list.
→ A per-template validity and accuracy report
- 02
Decide type coverage
Which types each template should emit, and which existing markup should be removed. Schema accumulated over years frequently includes types nobody can justify.
→ An agreed schema specification per template
- 03
Migrate to generation
Markup generated from the same data the page renders, so the two cannot disagree. This is the change that stops drift rather than merely correcting it.
→ Generated markup deployed per template
- 04
Wire validation into CI
Invalid schema fails the build. The cost of catching it here is minutes; the cost of catching it in Search Console is a quarter of degraded trust.
→ Validation running in your pipeline
- 05
Monitor production
Scheduled checks against live URLs, alerting when real content produces markup that staging never did. This is where the remaining failures actually live.
→ Production monitoring and drift alerts
Where markup goes wrong at scale
Failures cluster into four distinct patterns, and only one of them is caught by validation alone. The other three pass every automated check while describing something untrue, which is why governance has to cover accuracy against rendered content rather than validity in isolation.
| Failure | Detected by | Typical cause |
|---|---|---|
| Invalid syntax or missing required fields | Validators and Search Console | A template change or a renamed field |
| Valid but inaccurate | Comparison against rendered content | Stale data, or markup written by hand |
| Valid on staging, broken in production | Live monitoring only | Real content hitting untested edge cases |
| Types nobody decided to emit | A coverage audit | Schema accumulated over years without review |
Signals you need this now
You need this when Search Console reports structured data errors in the thousands, when markup is written by hand into CMS fields, when nobody owns the schema layer, or when a template change has previously broken markup across a large part of the site.
- Search Console reports structured data errors in the thousands
- Markup is written by hand into CMS fields
- A past template change silently invalidated markup at scale
- Nobody owns the schema layer or reviews changes to it
- Your site emits schema types nobody can justify
- Validation happens manually, if at all
- You run thousands of templated pages across several content types
What changes afterwards
Error counts fall quickly once markup is generated rather than hand-written, because the drift mechanism is removed rather than corrected. The durable change is that a template refactor can no longer silently invalidate markup, since the build fails before it ships.
Where this fits
Related AEO services
Common in these sectors
The adjacent disciplines
Deciding between options
Questions about structured data at scale
Each answer is written to stand alone in 40 to 60 words — the shape an AI Overview or Perplexity citation lifts. Ships with FAQPage schema.
How is this different from your FAQ and HowTo schema service?
That service implements markup on a defined set of pages. This one is about keeping markup valid and accurate across thousands of templated pages as the site changes, which is an engineering and ownership problem rather than a content one.
Why does our markup keep breaking?
Almost always because it is written by hand and the site keeps moving. A renamed field or a refactored component invalidates every page using that template. Markup generated from the same data the page renders cannot drift, because there is one source.
Is valid markup enough?
No. Markup can validate perfectly while describing something the page no longer says — stale availability, a rating from removed reviews. That passes every automated check and steadily teaches engines that your structured declarations are unreliable.
Should validation fail our build?
We recommend it for the templates that matter. Catching invalid schema in CI costs minutes; catching it in Search Console costs a quarter of degraded trust across however many pages the template generates.
Do we need production monitoring if we validate in CI?
Yes. CI validates the output of test data. Real content hits edge cases staging never sees — unusual characters, missing optional fields, content types nobody anticipated. Most surviving failures are found only against live pages.
Can we just remove markup we are unsure about?
Frequently the right call, and part of the engagement. Schema accumulated over years often includes types nobody can justify. Removing markup that serves nothing reduces surface area for drift and costs you nothing in visibility.
Find out whether this is your constraint.
Thirty minutes with a senior strategist. We pull your live visibility while we talk and tell you plainly whether a structured data at scale is what you need — or whether your problem sits somewhere else.