Why You Should Stop Storing Content as a Wall of HTML

Open the content store behind most managed websites and you will find the same shape. One field per page, holding a few thousand characters of HTML: headings, paragraphs, a table pasted out of a spreadsheet, two inline colour declarations, and a wrapper element whose class name stopped existing two redesigns ago. That field is the page. Everything around it is chrome.

That field is also the most expensive shortcut in publishing. It costs nothing to adopt, it looks fine for a year or so, and then it starts charging. Never in one large bill. Always in small ones: a restyle that has to be done page by page, an app that cannot reuse a single sentence, a screen reader that meets a level-four heading immediately after a level-two.

The alternative has a dull name and a long payoff. Content as data means every meaningful part of a page is stored as its own typed field or block, and presentation is decided when the page renders rather than baked in by whoever was editing that afternoon. It is a modelling decision rather than a platform one, which is why it sits underneath the more visible argument about where content should live. You can model badly on any system, and most teams do.

The shortcut that bills later

Nobody sits in a planning meeting and decides to store pages as opaque markup. It arrives by default. The editor offers a rich-text field, the field accepts anything, and the shortest route from a document to a live page is paste. Every individual decision along the way is reasonable. The aggregate is a content store that nothing can read except a browser.

The second driver is the calendar. Modelling content properly costs an afternoon of argument about what a page actually contains, and that afternoon looks expensive when launch is three weeks away. So the field stays generic, the launch happens, and the bill is handed to a team that has not been hired yet. It is the cheapest possible way to buy a problem.

The sentence worth holding on to is this: a rich-text field is a rendering format pretending to be a storage format. It records how something looked in one editor, on one day, inside one design. Storage should record what the thing is, so that how it looks can change without anybody reopening the page.

What a wall of HTML actually is

A wall of HTML is any content field whose value is markup you did not generate. The distinction matters, because plenty of good systems store markup somewhere. A static site generator turns Markdown into HTML at build time and that is fine, because the Markdown is still the record. The problem is markup as the record itself, with no structure behind it and no way to recover the structure except by parsing and guessing.

How to tell you have one

• Styles inside the prose. Colours, font sizes and margins appear in the content, so a brand change becomes a search across every page rather than an edit to a stylesheet.
• Layout inside the prose. Two-column arrangements, floated images and spacer elements live in the field, which is why some pages break on a phone in ways no CSS can reach.
• Headings chosen by size. Somebody picked a level because it looked right on screen, so the document outline is decorative rather than structural, and it varies page to page.
• Components rebuilt by hand. The same callout box exists many times over, each version slightly different, each one now a separate thing to maintain and nobody sure which is current.
• Data trapped in tables. Specifications, pricing tiers and comparison rows are markup rather than records, so nothing can sort them, filter them or show them anywhere else.

Why it looks fine right up until it does not

A wall of HTML renders perfectly. That is the trap. Every problem it causes is a problem with doing something other than rendering that exact page in that exact design, and for a long while nobody asks for anything else. The failure never arrives as a bug report. It arrives as a quote for a piece of work that comes back several times higher than anyone expected, and nobody connects that number to a decision made about a database column years earlier.

The first bill: a redesign

Here is what a redesign consists of when content is modelled: new templates, new components, a build, a review. The words move across untouched, because the words were never entangled with the design. Here is what it consists of when content is a wall of markup: all of the above, plus one person opening every page and repairing it by hand.

That second job is invisible in the proposal and enormous in the delivery. It also degrades quality, because the person doing the repair is rarely the person who wrote the copy, and by the last third of the list they are matching patterns rather than reading. We have written separately about the fields that survive the next redesign, and the short version is that a field survives when it describes meaning rather than appearance. Everything else gets rebuilt, whether or not anyone planned for it.

This is also why a website design and development engagement should begin at the content model rather than the homepage. The model decides how much of the project is mechanical and how much is manual, and that ratio is the largest single variable in what the work costs.

The second bill: everything that is not your website

The moment a second surface appears, a wall of HTML stops being merely awkward and becomes unusable. This is the bill teams are least prepared for, because the second surface is usually somebody else’s idea and it arrives with a date already attached.

The second surface

A mobile app cannot render your markup, because your markup carries your web design. A newsletter cannot use it, because mail clients discard half of it and mangle the rest. A partner feed cannot accept it, because the partner wants a title, a summary and a category, not a rendered page. Each of these ends the same way: somebody writes the content again, by hand, in a second place, and now there are two versions that will disagree within a month.

What machines read

Search engines and AI assistants both work on structure. Structured data describes what a page is: an article with a headline, an author, a date, a set of questions and answers. If your content is one opaque field, that description has to be reverse-engineered by pattern matching, and pattern matching over hand-edited markup fails quietly rather than loudly. Which types actually earn something back is a separate question, and we have answered it in which schema types earn something.

Modelled content makes this ordinary. The headline field is the headline. The FAQ entries are entries. There is nothing to infer, so nothing to infer wrongly, and the markup you emit stays consistent across every page of the same type without anybody checking it page by page.

The third bill: accessibility

This is the bill that is easiest to ignore and hardest to defend. WCAG 2.2 asks for several things a wall of HTML routinely breaks: a heading order that reflects document structure, tables with real header cells, images with meaningful alternative text, and link text that means something when read out of context. Inside a rich-text field, all four are the editor’s responsibility, on every page, forever.

That is not a training problem. It is a design problem. If a field allows a heading level to be picked by eye, someone will pick it by eye, and the outline will be wrong on some pages and right on others with no reliable way to tell which. Generate the structure instead and the outline is either correct everywhere or incorrect everywhere. Incorrect everywhere is a bug you fix once.

The same argument holds for alternative text. As a field on an image record it is a thing somebody can audit, report on and require before publishing. As an attribute buried inside pasted markup it is a thing nobody can see. This is one of the quiet reasons product and interface design work keeps returning to the content model. Accessibility that depends on individual discipline is accessibility that decays, and it decays fastest on the pages nobody looks at.

What content as data looks like in practice

None of this is an argument for stripping formatting out of writing. Editors need emphasis, links, lists, quotes and headings, and removing those produces worse content rather than better structure. The line to draw is between formatting that describes meaning and formatting that describes appearance.

Fields, not a field

A page type is a list of the things that page always has. A service page has a name, a promise, a set of outcomes, a process with ordered steps, an FAQ set, and a set of related pages. Those are fields. They are dull to define and they make everything downstream simple, because a field can be validated, required, translated, reordered, reused on another page and queried by something that is not a browser.

Blocks for the body

For the long-form middle of a page, the pattern that works is a list of typed blocks: paragraph, heading with a level, list with an ordered flag, table with a head and rows, callout with a title, quote with optional attribution. Rich text lives inside a block as a small set of named segments rather than as arbitrary markup. That is enough expressiveness for almost any editorial page, and it produces a format that a template, an app, a translator and a crawler can all read without negotiation.

Both halves need an interface, or editors will quietly route around them. The gap is real: structured fields are harder to author than a free-form box, and nobody should be hand-writing JSON to publish a paragraph. A structured content workspace such as Acrosite takes that job, giving editors a form-shaped interface, then generating the required files, committing them to GitHub and triggering the configured deployment. The tool is not the point. The point is that the structured path has to be the easiest one, not the disciplined one.

Getting out, without stopping publishing

The reason teams stay inside a wall of HTML is that the exit looks like a wall too. It does not have to be done in one movement, and it should not be. The sequence below is the one we would run, and the order matters considerably more than the speed.

1. Model before you touch anything. Write down your page types and the fields each one needs, using the pages you already have as evidence rather than a wishlist. An afternoon here sets the size of everything after it.
2. Extract the outer fields first. Title, summary, hero copy, calls to action, related links. These are usually already separate or trivially separable, and moving them buys real reuse straight away.
3. Convert the body mechanically. A script can turn well-formed markup into typed blocks at a high hit rate and flag whatever it cannot classify. Do not start this by hand; hand work is for the residue.
4. Repair the flagged pages in priority order. Pages with traffic, pages with legal weight and pages linked from navigation go first. The long tail can wait, and some of it should simply be retired instead.
5. Freeze the old field. Make it read-only the day the new model goes live, or you will migrate the same page twice while somebody edits it behind you.
6. Keep the addresses. A content migration that also changes URLs is two projects wearing one name. If addresses must change, the redirect map decides whether the migration holds.

That last step is where content work and website migrations meet, and it is also the moment teams discover exactly what their current system will hand back. That is a question worth asking long before you need the answer, which is why we have written about what happens to your content when you leave a CMS, and why our parent company covered the workflow half in where drafts live and what stops them.

Where a rich-text field still earns its place

Here is the honest limit of the argument. If a page is genuinely one-off, will not be redesigned, is not syndicated anywhere and nobody needs to query it, a rich-text field is the correct tool and structuring it is waste. Long-tail documentation, an occasional announcement, an archive kept for reference: model those and you have spent a day building a cage for a document that will never move.

The same applies below a certain size. A structured model carries a fixed cost that only pays back through repetition, so where there is no repetition there is no payback. We would not model a twelve-page site run by one editor with no second surface and no redesign in view. We would still separate the title, the summary and the calls to action, because those cost almost nothing and they are the fields you always end up wanting.

A rich-text field remembers how a page looked. A content model remembers what the page said. Only one of those survives the next redesign.

The decision rule we use

One test, applied per field rather than per site: if the same kind of information appears on more than one page, it is a field. If it appears once, it is prose. That rule is crude and it is right most of the time, and it settles in minutes the arguments that otherwise run for weeks.

The second rule is about sequencing. Model the content before choosing the system, never after. A model is portable and a system is not, and every vendor demonstration becomes shorter and more honest when you arrive holding a list of the fields you actually need. Vendors who cannot represent your model tend to say so quickly, which is exactly what you want an evaluation to produce.

And if you are sitting on a few hundred pages of pasted markup wondering whether the disruption is worth it, the question is not how bad the current state is. It is what you intend to do in the next two years. A site that will be redesigned, translated, syndicated or handed to a different team should be modelled now, while nobody is under pressure and nothing is on fire. If you want a second read on a specific content store before committing to anything, tell us what you are running and what you are planning to do to it.