Modelling content so it survives the next redesign
A content model survives a redesign when its fields describe meaning instead of position. Meaningful field names, references for reused entities, structured rich text and locale decisions taken early.
Contents
- Key takeaways
- What a content model is, and what it is not
- Why presentational fields are the ones that break
- Reference or embed: a decision rule
- Rich text is a data structure, not a string
- Localization is a modelling decision, not a plugin
- Migrating a model without a rewrite
- What changed in this update
- FAQ
Updated 30 September 2025 — visual editing tools now cover the preview problem that used to justify presentational fields.
A content model survives a redesign when its fields describe what the content is, not where it sits on screen. Name fields for meaning, store rich text as structured data, use references for anything reused, and settle locales before the second language arrives. Presentational fields are what force a rewrite.
Key takeaways
- Rachel Lovinger argued in A List Apart on 24 April 2012 that every element needing separate display deserves its own field. Her example was a subtitle bolded inside body text.
- WordPress has serialized blocks into
post_contentas HTML with comment delimiters since version 5.0 shipped on 6 December 2018. Block content carries the markup of the editor that produced it. - The Jamstack Community Survey 2022 gathered nearly 7,000 responses. WordPress was in use on some or many projects by 37% of respondents, headless WordPress by 22% and Contentful by 19%.
- RFC 5646, published by the IETF in September 2009, makes
es,es-ESandes-419three distinct language tags rather than three spellings of one. - Carrie Hane and Mike Atherton put content architecture before visual design in Designing Connected Content (New Riders, December 2017), which is the same order this article argues for.
What a content model is, and what it is not
A content model is the set of content types in a system, the fields inside each type, and the relationships between them. It is a schema written in the vocabulary of the business rather than the vocabulary of the page. That is why it starts with the questions a brief should ask, not with a sitemap.
The test takes ten seconds. Read a field name to someone who has never seen the site. If they can say what belongs in it without a mockup, the field describes content; if they need the mockup, it describes a layout. Layouts are the part that changes.
This is also why the CMS argument is smaller than it looks. A clean model moves between WordPress, Sanity and Contentful with a migration script. A model built from layout slots dies in all three, so choosing a platform by constraint settles less than teams expect.
Why presentational fields are the ones that break
Presentational fields encode a decision that belongs to the front end. heroImageLeft, bannerVariantThree, introTextGreen: each names a position, a variant or a color. Redesigns exist to change positions, variants and colors.
Rachel Lovinger wrote in A List Apart on 24 April 2012 that “each element that needs to be displayed differently should be in its own field.” She asked how a subtitle bolded inside body text would behave in an RSS feed. (Content Modelling: A Master Skill)
The cost never lands on launch day. It lands two years later, when several thousand entries hold a field whose meaning only the retired template understood. Migrating that field means reading it, guessing intent, and rewriting it entry by entry.
Karen McGrane framed the same problem in a talk A List Apart published on 14 January 2013, asking why authors still plan for where content will live on a page. Ten years on, the question still separates a model from a page builder.
Reference or embed: a decision rule
Two questions settle almost every case. Does this thing have a life outside the page it appears on, and does anything else need to point at it? An author, a product, a location and a policy document all answer yes, so each becomes its own document type with references pointing to it.
The same conclusion arrives from the other direction. A separate document type is preferable whenever the client will need to add more items later. An inline object suits a fixed grouping of fields that only makes sense together.
Embedding by default is the common failure. Copy an author's name and photo into every article and the author becomes unfixable. A new headshot means a bulk edit, and a typo lives forever in the entries nobody reopens.
Referencing everything is the opposite failure. When a call-to-action that appears on one page becomes its own document, editors navigate four screens to change one sentence, and they stop using the system as designed.
Rich text is a data structure, not a string
The body field is where models quietly die. If it stores HTML, it stores the markup decisions of whichever editor produced it, and every future channel inherits them.
WordPress 5.0 shipped the block editor on 6 December 2018. The Block Editor Handbook documents that blocks are serialized intopost_contentas HTML with comment delimiters such as<!-- wp:image -->, carrying block attributes as JSON inside the comment. (WordPress Developer Resources)
That format is a reasonable engineering answer to backward compatibility, and it is a poor answer to reuse. The markup and the content travel together, so a second channel gets the first channel's decisions.
Structured rich text stores the same body as a tree. It holds blocks, inline spans, marks kept apart from the text they annotate, and typed embeds that reference real documents. Rendering to a page, an email or a voice response becomes a rendering choice. The front end also stops shipping markup nobody asked for, which is one of the things that actually move LCP.
The workable rule is a closed set. Allow a documented list of block types inside rich text and give each one a schema. An “arbitrary HTML” block is an escape hatch, and escape hatches end up holding a third of the site. The argument is the same one that makes design tokens the contract between design and code, one layer further down.
Localization is a modelling decision, not a plugin
There are two shapes, and the choice is structural. Field-level localization keeps one document per piece of content and stores a value per locale on each field. Entry-level localization keeps one document per locale and links the versions together.
Field-level keeps translations beside the original and makes fallbacks trivial, but every editor sees every language. Entry-level lets a market team own its document and diverge from the source, but answering “is this translated yet?” becomes a query instead of a glance.
RFC 5646, published by the IETF on 4 September 2009 as part of BCP 47, defines language tags assembled from language, script and region subtags. It is the reasones,es-ESandes-419are three different values rather than three spellings. (RFC Editor)
Fix the granularity before the second language exists. Splitting es into es-ES and es-419 afterwards means deciding, entry by entry, which market each existing value belonged to.
Migrating a model without a rewrite
Schema changes are code, so they get the treatment code gets. Write the change as a migration script, run it against a copy of the dataset, and diff the result before it touches production. A migration you can re-run is a migration someone can review.
Three habits make every later change cheaper. Version the schema and record which version each document was written under. Keep a field's meaning stable even when its editing widget changes. Never repurpose a field: deprecate it, add the replacement, migrate, then delete.
The Jamstack Community Survey 2022, published by Netlify, drew nearly 7,000 responses. WordPress was in use on some or many projects by 37% of respondents, headless WordPress by 22%, Contentful by 19% and Sanity by 16%. (Jamstack.org)
Most organizations run more than one system, which makes migration a routine operation rather than a crisis. That is an argument for treating content architecture as an operations problem with an owner, not as a one-off project deliverable.
What changed in this update
Contentful announced Contentful Studio on 28 March 2024, letting teams assemble pages visually on top of existing content types. Sanity's Presentation tool does something comparable by encoding source references into the rendered front end. Both address the reason presentational fields kept reappearing: editors could not see what they were writing. The modelling advice is unchanged. It is easier to follow, because the composition layer finally lives in a tool rather than inside the content type.
FAQ
What is a content model?
A content model is the list of content types in a system, the fields each type contains, and the relationships between them. It describes meaning rather than layout, so an article has an author reference and a publication date, not a hero position and a banner variant.
How do I know if a field is presentational?
Read the field name to someone who has never seen the design. If they can explain what belongs in it without a mockup, the field describes content. If the name refers to a position, a color, a column or a variant number, the front end owns that decision.
Should I use a reference or an embedded object?
Use a reference when the thing exists outside the page and something else may point at it: authors, products, locations, documents. Use an embedded object when the fields only make sense together in that one place, such as a quantity attached to a selected product.
Is field-level or entry-level localization better?
Field-level keeps every language in one document and makes fallbacks simple, which suits synchronized translation. Entry-level gives each market its own document and room to diverge, which suits autonomous regional teams. Decide the language tag granularity first, because splitting locales later is the expensive part.
Does a headless CMS guarantee a clean model?
No. Headless removes the template from the storage layer, but nothing stops a team from recreating layout slots as fields. The failure modes described here appear in every platform. The discipline lives in the schema review, not in the product choice.
Model the nouns first, then the relationships, then the schema for rich text, and leave layout to the front end. Locale tags come before the second language, not after the first translation request. Six months from now the honest measure is a count of the fields the next redesign forced you to migrate. Under five means the model described content; over twenty means it described a page.
