What is structured content, and why your clients need it
What is structured content? Content stored as named fields instead of formatted pages, and why it's the thing that keeps a client site tidy for years.
A client sends over their events for the new site. It's a Word document. Each event is a bold line, a paragraph with the date somewhere in the middle, the venue in italics and the price at the end, sometimes. Two of them have the date in a different format. One is in a table.
That document is unstructured content. Turning it into something a website can use well is what this post is about.
A definition, with one example
Structured content is content stored as named fields rather than as formatted text.
An event, stored as structured content, is a title, a date, a venue, a price and a description. Each one is a separate field with a type: the date is a real date, the price is a number, the venue is a link to a venue record. The same event, stored as unstructured content, is a paragraph someone formatted to look right.
Both can produce an identical-looking page. The difference shows up the moment you want to do anything else with it.
What it buys the client
Filtering and sorting. With real dates, the site can show only upcoming events, in order, and hide them automatically once they've passed. With a paragraph, someone has to remember to delete last month's events.
The same content in more than one place. The next three events can appear on the home page, the full list on the events page and each event on its own page, all from one record. Edit the price once and it changes everywhere. Why our content model is a graph explains how that reuse works when one thing links to another.
A correct sitemap. When each event is a real record with its own address, the site can list every page search engines should know about, automatically, and keep that list current.
Machines that can read it. Search engines, AI assistants answering questions about the business, and whatever comes next all do better with content that says "this is a date, this is a price" than with formatting they have to guess at.
What it buys the agency
Consistency by construction. If every event has the same fields, every event page looks the same, because the template decides how it looks rather than whoever typed it. There are no forty slightly different heading sizes after two years of edits.
Redesigns that don't move content. When the content is fields, a redesign is a new template for the same fields. Nobody reformats four hundred entries.
A smaller handover. The client fills in fields. They can't break a layout they never touch. Why we don't have a drag-and-drop editor is the long argument for that.
Rich text is structured too, if it's stored properly
A fair question: what about the long-form parts, the article body, the about page? They have headings, links, bold text and images. Isn't that just formatted text?
It depends how it's stored. If the editor saves a blob of HTML, it's unstructured, and the formatting rules of whatever wrote it come along for the ride. If it saves a structured description, this is a heading, this is a paragraph, this word is a link to that page, it's still structured. The words are free-form, but every part of them is labelled, so a different site, an app or a plain-text email can each render it their own way. Most modern editors can work like this. It's worth asking any CMS which one it does.
Where structure goes wrong
Structure can be overdone. A content type with twenty optional fields, half of them empty on most entries, is harder to edit than a paragraph. Modelling layout as content, with fields like "left column width" or "background colour", hands the client the design back under another name. And free text where a link belongs, a venue typed out on every event instead of chosen from a list, quietly undoes the point. Good structure is the smallest set of fields that lets the content be reused.
How we handle it
In Contentive, everything is structured by default. You define the content types and their fields, pages are composed from sections you define, and rich text is stored as structured data rather than HTML. The client's editor is generated from that model, so structure isn't something they have to remember to follow. It's the only thing on offer.
What it costs
Decisions, up front. Someone has to decide that an event has a venue field and that the venue is its own record rather than a line of text. Those decisions take time at the start of a project, and they're easier to get right than to change later. That's real work, and it should be in the scope. How to scope a website project covers how to make it part of the quote rather than an afterthought.
There's also a small cost to the client: they can't put whatever they like wherever they like. Most clients don't miss that. A few do, and they're usually better served by a site builder.
A test for your last site
Open the last site you built and pick one kind of content: events, team members, case studies. Ask one question:
Could a different site reuse this content without anyone copying and pasting?
If the answer is yes, it's structured. If someone would have to open each page and retype it, it isn't, and the next redesign will cost you exactly that retyping. Start the next build with what is a content model.