Structured data implemented from the content model, not per page
Structured data is a set of claims about what is on a page. Implemented per page it drifts immediately; implemented from the content model it is generated, consistent, and correctable in one place.
Markup added page by page is markup that will be wrong
The usual approach is to add structured data to the templates that matter, or to install a plugin that emits a generic graph. Both produce something. Neither survives a site that changes: templates get replaced, page types get added, and the markup someone wrote for the pages they were thinking about does not extend to the ones they were not. And because structured data is a claim rather than a description, being wrong about it is not neutral.
- Structured data exists on some page types and not others with no reason
- Markup was added by hand and nobody knows what it now says
- A plugin emits a generic graph that does not reflect what the pages are
- Search Console reports structured data errors or warnings nobody has addressed
- The site has entities — organisations, people, products, locations — with no consistent representation
- The same thing is described differently on different pages
- A page is marked up as one type and behaves as another
- Markup exists for a page type that has since been redesigned
The people who usually bring us this problem
A site with structured data nobody maintains
It exists, it is inconsistent, and it no longer describes what the pages are.
A site where entity descriptions disagree
The organisation, its people, its locations or its products are described differently across the site.
A site adding page types and needing the markup to follow
The templates need to generate structured data from the content model rather than have it written into them.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Structured data is an assertion, and a wrong one is a problem
It says a page contains a product with a price, an article with a publication date, an organisation in a particular place. If the page does not support the claim, the markup is not merely useless — it is misinformation that has been deliberately encoded for machines to read. Marking up content that is not on the page is the specific practice to avoid.
Per-page markup drifts from the moment it is written
Templates change, page types are added, content models are extended. Markup written into a template is invisible to everyone except the next person to edit that template, and there is no list of what exists. This is how a site ends up asserting something about itself that stopped being true two redesigns ago.
Rich results are not an outcome anyone can promise
Valid structured data does not produce an enhanced result. Whether a result is enhanced is decided by the search engine against criteria it does not publish, on a subject-by-subject basis, and it changes without notice. Structured data is a prerequisite in some cases and never a guarantee, and treating it as the deliverable leads to the work being judged on something it does not control.
Entities are the part that matters and the part that is skipped
Beyond the well-known types, the durable value is describing entities consistently: one organisation with one identity, the people who belong to it, the products it makes, the places it operates. That is a modelling decision made once and generated everywhere, and it is much more useful to the systems reading the site than a per-page type annotation.
Capabilities
Each of these is work we carry out, not an area we advise on.
Entity and vocabulary modelling
What the site actually describes — organisations, people, products, services, articles, places, events — and how those relate. This is the design work, and it determines what every later implementation can say.
Type selection against what the page actually is
Choosing the vocabulary type that matches the content rather than the type that looks most valuable. A page marked up as something it is not is worse than an unmarked page, and the temptation to reach for a commercial type is where that mistake gets made.
Generation from the content model
Producing the markup from the same data that renders the page, per template and per page type, so it cannot drift and so a change is made once. This is the structural difference between markup that survives and markup that does not.
Identifier and reference consistency
One stable identifier per entity, referenced identically wherever the entity appears, so that a search engine or another consumer can tell that two mentions are the same thing. Inconsistent identifiers are the reason a correctly-typed graph still reads as several unrelated fragments.
Relation between the page and its place in the estate
Breadcrumbs, section membership, parent and related content, and canonical URLs — expressed so the structure the site has is legible, not only what each page contains in isolation.
Time-critical and eligibility-sensitive types
Where a type has eligibility requirements — articles, news, products with prices and availability, review and rating markup — implementing them against the actual requirements and verifying the page genuinely satisfies them. Those are exactly the types where a claim the page cannot support is most consequential.
Validation across every page type
Every type generated by the model, validated, with the required properties present and the values agreeing with the page. Validation is run against the rendered output rather than the intended output, because rendering and generation are different steps and only one of them is what a consumer reads.
Correction and maintenance
Where a claim stops being true — a price format changes, a page type is retired, an eligibility requirement is revised — the change is made in the generator rather than in the pages it produced. That is what makes this maintainable rather than a project that decays.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Model the entities before choosing the types
Establish what the site describes and how those things relate, then select types that express it. Choosing types first and bending the content to fit produces a graph that is valid and does not describe the site.
Prefer what the page can support
Every property emitted is a claim the page's own content substantiates. Where a property would require data the page does not carry, it is left out — an absent property costs nothing and a false one is a deliberate misstatement.
Generate, do not author
Markup comes from the content model per template, so the set of page types with structured data is the set of page types that exist. Authoring it per page guarantees eventual drift, and there is no list of what was written to check it against.
Use one identifier per entity everywhere
A stable, absolute identifier, referenced identically from every page that mentions the entity. This is what allows separate pages to be understood as describing the same thing, and it is what most per-page implementations lack.
Validate the rendered output, every type
Not the template and not the intention — the HTML that is served. Generation and rendering are separate steps, and a value that exists in the model can still be absent from the page if a template omits it.
Say what structured data does and does not do
It makes claims legible to systems that read them, including search engines and AI answer systems. It does not produce an enhanced search result, and no implementation can promise one. The report says what was implemented, what was validated and what is now assertible, and does not present an outcome it does not control.
Keep the generator as the place to change it
Every later correction happens in one place, and the documentation says so. A structured data implementation that is understood as a set of files rather than a generator is one that gets edited in the wrong place and drifts again.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Modelling
- The entities the site describes, and how they relate
- Vocabulary types selected against what each page actually is
- One stable identifier per entity, and where it is referenced from
- Properties emitted per type, and those deliberately omitted because the page cannot support them
- Eligibility-sensitive types checked against their actual requirements
Implementation
- Generation from the content model, per template and page type
- Entity references consistent across the estate
- Breadcrumb, section and canonical structure expressed
- Rendered output validated for every page type
- A documented place to change each part of it
Verification and handover
- Validation of the served HTML across every page type, not a sample
- Search Console structured data review, with the warnings that remain
- An inventory of what the site now asserts, by type
- What is emitted and why, for whoever edits the templates next
- An explicit statement that no enhanced-result outcome is promised
Architecture and technology
What structured data is for
- Stating what a page contains, in a form machines can read without inferring
- Identifying entities so mentions across pages resolve to the same thing
- Expressing relationships: what belongs to what, what relates to what
- Making time-critical and eligibility-sensitive content assertible
- Feeding systems beyond search, including AI answer engines
What it does not do
- Produce a rich or enhanced search result — that is decided elsewhere against unpublished criteria
- Compensate for content that is not on the page
- Override a canonical or an indexation decision
- Substitute for crawlable, server-rendered content
- Compensate for inconsistent entities elsewhere on the site
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The markup needs to arrive with the HTML
Rendering, hydration and what a crawler actually receives.
JavaScript SEOThe markup is emitted but pages are not indexed
Indexation constraints, which structured data cannot resolve.
Crawl and indexationThe front end is decoupled
Where structured data and sitemaps have to be generated once the CMS stops rendering.
Headless website developmentThe whole technical position needs establishing
An audit delivered as a prioritised engineering backlog.
Technical SEO auditFrequently asked
Will this get us rich results?
We will not claim that, and the reason is not caution. Whether a result is enhanced is decided by the search engine against criteria it does not publish, applied per subject and changed without notice. Valid structured data is a prerequisite for some of those treatments and never a guarantee of any of them. What this work delivers is that the site's claims are correct, consistent, generated from its content model and legible to the systems that read them — which is the part that is within anyone's control.
Why not just use a plugin?
A plugin emits a graph based on what it can infer from the platform, which works reasonably for standard article and organisation markup and poorly for anything specific to your site. It also tends to emit the same set of claims on page types that are not alike, and to include properties the page does not support. Where a site is standard and the requirement is modest, a plugin is a reasonable answer and we will say so. Where the site has its own entities, its own page types or eligibility-sensitive content, the markup needs to come from the content model — which is what generation means here.
What is the risk of getting it wrong?
Structured data is deliberately encoded information for machines, so a wrong claim is not a neutral mistake — it is misinformation with a machine-readable guarantee attached. Marking up a product with a price and availability the page does not show, or an article with a publication date it does not have, is the specific practice the guidelines prohibit. Separately, inconsistent entity identifiers make a correct-looking graph read as several unrelated fragments, so the implementation is valid and does not achieve what it was for.
Do AI answer engines use structured data?
It is read, and how much weight it carries is not published and plausibly varies. The honest position is that structured data is one input among several, alongside the page's actual content, its crawlability and the consistency of the site's entity descriptions. It is worth implementing correctly for that reason and it is not worth treating as the mechanism that earns a citation. If it is part of why you want this, that is a reasonable motivation and it is not a measurable outcome we can commit to.
How much work is it on a large site?
It scales with the number of page types, not the number of pages — which is the point of generating it. A site with two million pages across twelve templates is broadly the same implementation as one with two thousand pages across twelve templates, because the work is per type. The cost is in the modelling, which is where the page types are decided and where the entity relationships are established, and it does not grow with volume. That is the difference between generating from the content model and writing markup per page.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.