Markup dies at the rebuild because it lives in the template.

Why the markup goes first

Structured data is the least visible thing on a page and the first casualty of any rebuild. Nothing in the rendered design depends on it, no stakeholder reviews it, and no acceptance test covers it — so it disappears unnoticed for about nine months, which is roughly when someone asks why the organization stopped appearing as a recognized entity.

It fails in four recognizable ways, and none of them is a mistake about the vocabulary.

• It was pasted into a page template, so replacing the template deletes it. Design review looks at the rendered page, where nothing changed.
• It was produced by a plugin or a tag manager that the new stack does not have, so it leaves with the platform.
• It restates facts that also appear in the visible page — a legal name, an address, a service description — so the two drift apart the first time either is edited, and the markup starts asserting something the page contradicts.
• It was written by hand once per page, which means the twelfth page got a slightly different version, the thirty-first got none, and nobody can say which is which without opening all of them.

Every one of these is a maintenance problem wearing a markup problem’s clothes. The vocabulary is stable and well documented; what is unstable is where the values come from and who is responsible for them when the templates change hands.

Declare the organization once, and point at it

The single highest-value structural decision is to stop repeating the organization on every page. Declare it once — legal name, the name customers use, logo, contact points, the profiles you genuinely control — and give that declaration a stable identifier. Every other node on every other page then references the identifier rather than restating the facts.

An identifier here is an absolute URL, conventionally the site origin with a fragment naming the node on the end. It does not have to resolve to anything a person can visit; it has to be unique, stable and used consistently. Treat it as a permanent key. Changing it later is equivalent to declaring a new organization, and a site that changes it at every redesign is producing a new entity every two years rather than accumulating one.

With that in place, the pattern for the rest is mechanical. The site node states which organization publishes it. An article names its publisher by identifier. A service names its provider by identifier. A page states which site it is part of. Nothing repeats a fact that the organization node already carries, so there is exactly one place where the legal name is wrong if it is wrong.

The failure mode of this pattern is the one worth naming in advance, because it is the defect we find most often: a node referencing an identifier that nothing on the site emits. It is syntactically perfect, it passes every validator, and it carries no meaning at all. It usually arrives when markup is copied from the page it was written for onto four others, where the node it pointed at never existed.

Be conservative about the profile links. They assert that these accounts are the same entity, and an abandoned account or a directory listing somebody else controls weakens that claim. Three you maintain beat eleven you once created.

Generate it from what the page already knows

The rule that makes markup durable is that it must be a projection of the page’s data rather than a second copy of it. If the page renders a service name from a content file, the service node reads that same value from that same file. If the page renders a publication date, the article node reads that date. Nothing is typed twice, so nothing can disagree.

In practice this is one module that takes a page’s own content and returns the graph. Templates do not contain markup; they call a function. An editor changing a service name changes the markup as a side effect and never learns that structured data exists, which is the correct outcome — the alternative is a process step that depends on somebody remembering.

This is also what makes the next redesign cheap. New templates call the same function, and the markup arrives with them. What a rebuild has to port is one module and the data it reads, rather than an audit of forty page types by someone who was not there when they were written. Budget that module explicitly in the rebuild, or it will be discovered in the final week and dropped.

The honest caveat: this does not make markup immortal. A platform migration still moves it, and a content model that changes shape still breaks the projection. What it changes is the size of the failure. A generated graph breaks all at once, loudly, in a way a single check catches; hand-authored markup breaks one page at a time, silently, and is only ever discovered by accident.

The checks that catch the break

Validators test whether the syntax parses and whether a type has the properties a platform wants. They do not test whether what you said is true, whether the identifiers connect, or whether page twelve is missing entirely. Those are the failures that actually happen, and they need checks of their own.

• Every identifier referenced by one node resolves to a node the site actually emits, checked across the whole built output rather than page by page.
• No page declares two organizations, and no page declares one that differs from the canonical declaration.
• Every value that appears both in the markup and in the visible page came from the same source, which is provable by construction if the markup is generated.
• The crawl runs over every built URL. A spot check of the homepage is how a site ends up with correct markup on one page and nothing on the other two hundred.

Run all of that against the built output, not against the source, and run it on the way out of the build rather than as an occasional audit. A check that runs when somebody remembers to run it has the same reliability as the convention it replaced.

At a cutover, do one more thing: capture the set of nodes and identifiers the current site emits before the new one goes live, and diff it against the new set. Every node that disappeared is either a deliberate removal or the thing this piece is about, and the diff is a ten-minute artifact that tells you which. It is the single most useful item to add to a redesign’s launch list, and almost nobody has it.