Structured Content: Fields That Survive the Next Redesign

A team redesigns its website every four or five years. Ask what the redesign costs and you get a design fee, a build fee and a timeline. Ask what it actually costs and the answer is different: somebody spends weeks copying words out of one system and pasting them into another, because the old system stored pages as layout and the new one wants meaning.

That is the test a content model has to pass. A field survives a redesign if it describes what something is, and dies with the design if it describes where something goes. Every other rule in structured content modelling is a consequence of that one distinction.

Modelling is not really a technical exercise, although it is usually handed to engineers because it arrives in a schema file. It is an editorial decision about what your organisation claims to know about a page. Which is why we start content work with the model rather than a calendar, and why the model outlives whoever drew the first wireframe.

Modelling is separating meaning from presentation

A content model is the list of things you publish and, for each one, the list of facts you store about it. That is the whole definition. All the discipline sits in what counts as a fact.

Presentation answers "how should this look here". Meaning answers what is this. "Hero heading" is presentation: it names a slot in one design. "Service name" is meaning: it stays true when the slot moves, shrinks, or disappears in the next design entirely. The first is a rented field. The second is one you own.

The reason this matters commercially is that presentation changes on a cycle you do not control, and meaning almost never changes at all. What a service produces, who it is for, what it asks of a client: those facts survive three visual identities. The size of the heading does not survive one.

A page type modelled badly

Take a service detail page, because nearly every site has one and nearly every site gets it wrong the same way. Here is the field list a builder-driven build tends to produce, and it is worth reading slowly, because none of it looks unreasonable.

• Page title. Doing four jobs at once: the H1, the navigation label, the card label, and the browser tab.
• Hero image. Cropped for one layout, at one aspect ratio, with alternative text treated as optional.
• Hero text. A rich-text field, because somebody wanted a bold word in it once.
• Body content. One rich-text field holding headings, paragraphs, a table, three pull quotes, a bulleted list of deliverables, six questions with answers, and an embedded form.
• Sidebar content. A second rich-text field, holding everything that did not fit above it.
• Button label and button link. Because the approved design had exactly one button on it.
• Title tag and meta description. Added last, by whoever remembered.

Why it looks fine on launch day

It renders. Editors can publish without asking anyone. The result matches the mockup pixel for pixel, and the build came in on time. Nothing in that list is visibly wrong until the second thing happens to it, and the second thing is always a request that sounds small.

What breaks the moment anything changes

Marketing wants the questions and answers from every service page pulled onto one hub. Nobody can do it, because those are sentences inside a blob and the system has no idea they are questions. Search wants FAQPage markup emitted only where a visitor can actually see the answers, which is impossible for the same reason. A new design wants the opening paragraph rendered as a standfirst, and nobody can extract "the opening paragraph" reliably, because a third of the pages open with a heading and one opens with an image.

Then the site moves. The export is a wall of HTML with inline styles baked into it, class names from a theme that no longer exists, and three different ways of writing a list. That is the moment the migration budget stops being a number and becomes a negotiation. Anyone who has tried to move ten years of pages without losing the archive recognises this as the expensive part, and it was decided years earlier.

The same page type, modelled well

Now model it by meaning. The question for each field stops being "where does this appear" and becomes "would somebody describing this service out loud say this thing". Facts a person would say become fields. Everything else becomes template.

Name the field after the fact, not the slot

"Promise" survives a redesign. "Hero subtitle" does not, because the next design may have no hero and certainly has no subtitle. A quick test: read the field name to somebody who has never seen the website. If they can guess what belongs in it without being shown a page, the name is about meaning. If they ask to see the design first, you have named a slot.

The same discipline is what makes structured data honest rather than decorative. Fields that map cleanly onto Article properties can be emitted with confidence, because the model knows which text is a headline and which is a published date. A model that stores everything as one blob has to guess, and guessed markup is worse than none at all.

Blocks are not the same thing as a page builder

Structured body content is an ordered list of typed blocks: a paragraph, a heading with a level and an anchor, a list with an ordered flag, a table with a head and rows, a quote, a callout. Each block carries its own fields and no styling whatsoever. WordPress made this shape mainstream, and the block editor handbook is worth reading even if you never ship WordPress, because it separates block data from block rendering in exactly the way a model should.

The difference between blocks and a page builder is where the styling lives. In a block model, a callout knows it is a callout and nothing else. In a builder, it also knows its padding, its background colour and how it behaves at 768 pixels, and all three of those are now content you have to migrate. Which is why the model belongs in the same conversation as the build, rather than in a ticket raised after the templates are finished.

Required, optional, and the category nobody names

Every field is one of three things, and most teams recognise only two. Required means the page cannot exist without it and the system refuses to save. Optional means the page renders correctly whether the field is there or not, and the design has a defined state for absent. The third category is conditionally required: a field the design silently depends on but the model does not enforce. That is where the damage lives.

A missing optional field is a design state. A missing conditionally-required field is a broken page, discovered by a visitor, on a Sunday.

So the rule we apply is blunt: required means the design breaks without it, and if the design does not break, the field is optional and the template must handle its absence. Write that absent state into the design review, not into a ticket after launch. The second rule is harsher and saves more time. A required field with a default value is not a required field. It is an optional field with a lie attached, and defaults are how empty pages get published looking full.

Which turns the model into a workflow question, answered by whoever holds the publish gate. A model with no real draft state forces editors to publish work in progress or keep it somewhere nobody can review, and the three states most systems get wrong are preview, draft and publish. Those belong in the model as fields, not in a folder naming convention.

A publish date is a good example of where the line sits. The date is a fact about the content and belongs in the model. Whether a future date actually causes the page to appear is a property of the system, and what each scheduling mechanism guarantees varies enough that it should be settled during modelling rather than discovered in launch week.

Refusing the free-text catch-all

Every model gets the same request, usually in week three, and it always sounds reasonable: can we add a general content field, just for anything that does not fit? Say no. Say it politely, and say it every single time.

The catch-all is where a model goes to die. It starts as an exception for one page and becomes the place everything difficult gets put, because putting something there is faster than making a decision about it. Six months later the field holds a pasted table, an embedded video, a block of text shaped like an address and somebody’s inline CSS. None of it can be queried, validated, translated or re-rendered.

What makes it worse is that the field always looks used. Nobody deletes it, because nobody can establish what depends on it.

The correct response to "this does not fit" is a question: what is it? If the answer names a recognisable thing, add a block type for it and you have improved the model. If it happens exactly once, it belongs in a one-off page rather than in the shape of thirty pages. And if nobody can name it at all, that is the strongest available signal that it should not be published.

The concession, and it is a real one: this is not free. A stricter model means more work for the person who has to say no, and it will occasionally hold a launch for a day while somebody decides whether a thing is a callout or a quote. Teams under genuine deadline pressure find that irritating, and they are not wrong to. The alternative is paying the same cost later, with interest, during a migration.

Five tests a field has to pass

Run each proposed field through these in order. Most bad fields fail on the second question, and the ones that survive to the fifth are usually a catch-all wearing a respectable name.

1. Can you name it without pointing at the design? If the only available name is "the bit under the hero", it is a slot rather than a field, and it will not outlive the layout that created it.
2. Would you still store it if the page looked completely different? This is the redesign test, and it removes more fields than any other question you can ask.
3. Can anything else use it? A field only one template reads is not necessarily wrong, but it has to earn its place. A field that three surfaces read is obviously right.
4. Is its absence designed? If nobody has decided what the page looks like without it, the field is not optional yet, whatever the schema currently says.
5. Can it be validated? Length, format, allowed values, required relationships. A field with no possible validation rule is usually free text in disguise.

Content that knows what it is can be shown anywhere. Content that only knows where it went can be shown once.

Who owns the model, and where it is written down

The model is the most-referenced document nobody writes down. It lives partly in a schema file, partly in the editing interface, and mostly in the heads of two people who attended the original workshop. When those two move on, the site develops mystery fields that everybody is afraid to remove.

Write it as a document that states, for each type: what it represents, who publishes it, which fields are required and why, and what each optional field does when it is absent. That document is also the single most useful artefact you can give to a new developer or a new agency, which is a subject of its own, because handing over a codebase is mostly handing over decisions rather than files.

Where the fields physically live is a separate decision and a consequential one. Typed fields in a repository give you a diff for every content change and a schema that moves with the code. Records behind an API give you an interface non-technical editors take to immediately. Our parent company has set out that trade in Git-backed or API-backed. A workspace like Acrosite takes the first route while hiding it: editors work in structured fields, and the workspace generates the files, commits them to GitHub and triggers the configured deployment.

Where we would start

Model the page type you have the most of, not the one you argue about most. The homepage is bespoke and rare and everybody has an opinion about it. The service page, the article, the location page: those repeat, and repetition is where a model pays for itself.

Print one of those pages. Draw a box around everything a person would still call a fact if the design vanished overnight. Name each box out loud. Then look at what is left over, because the leftovers are the interesting part: some of it is decoration and should not be stored at all, and one or two items turn out to be claims nobody realised the site was making.

Then write the absent state for every optional field before a single template is built. That one habit removes most of the launch-week emergencies we see, and it costs an afternoon.

The condition where this advice softens: if the site is genuinely small, genuinely short-lived, and edited by the same person who builds it, a looser model is a rational trade. Nobody should model a landing page for a conference that ends in March as though it will be re-rendered in 2031. The discipline is for content that has to outlive the design wrapped around it. If you are looking at an export full of pasted HTML and trying to work out what is recoverable, tell us what you are running and how many page types are hiding inside it.