What is structured content?
An event has a title, a date, a place and a cover image. Structured content stores them as four fields. The alternative is one block of formatted text, and everything downstream gets harder.
The short answer
Structured content is content stored as named, typed fields, such as a title, a date or an image, according to a model defined in advance and kept separate from its presentation. The same content can then be validated, translated, queried, reused, and edited by people or AI agents without touching the design.
Fields, not a blob
Content is structured when there is a model (an event has a title, a date, a place), each field has a type (the date is a date, not the characters "12 March"), and the entry holds no presentation. The design lives in a template that reads the fields.
In a rich-text editor, the same event is formatted text in one body field, a blob: the date cannot be sorted on, and the next editor may format the next event differently. Rich text keeps its place for prose. The point is to stop using it for things that are data.
| One rich-text field | Structured content | |
|---|---|---|
| Where design lives | Mixed into the content, by the editor. | In templates, by the designer. |
| Reuse | Copy and paste. | Query the same entry from any page. |
| Translation | Duplicate the page, redo the layout. | Translate field by field; layout is shared. |
| Redesign | Rework every page. | Rewrite the templates; content is untouched. |
Why it matters
- Clients cannot break the design. An editor who sees a title field, a date picker and an image slot cannot choose the wrong font size, because the choice does not exist.
- One entry, several places. The agenda, a card on the home page and an RSS feed are different templates over the same event.
- Languages without duplication. The title is translated; the date and the cover are shared, and each language gets its own URL.
- A publishing workflow. Fields can be reviewed one by one, and roles decide who writes, who reviews and who publishes.
- A model you can version. Declared in files, the model is reviewed and versioned with the templates, like the rest of the code.
- Agents can target one field. An agent connected through an MCP server can set one date without rewriting the page around it.
How Quilium models content
Quilium is structured by default. Page types, content types (the blocks editors place in a page), collections and global fields are declared in YAML, and the back office is generated from them. A block never copies collection data in. It declares a query field, and the engine hands the matching entries to the template:
latest:
type: query
label: Articles
config:
itemSet: articles
limit: 6
sort:
- date: desc
The sort and the limit are configuration, not template code. Pages are edited in draft and published as a new revision; collection entries go live when saved, so the model also decides where a review step is needed. The reasoning is in The content model, and every field type in the custom fields reference.
Questions people ask about structured content.
Is structured content the same as a headless CMS?
No. Headless describes delivery: the CMS serves content through an API and you build the frontend. Structured describes storage. A CMS can be structured and still render and host the site itself.
Is structured content harder for editors?
A form with a title, a date picker and an image slot asks fewer decisions than a blank canvas. What editors lose is the ability to improvise a layout, which is the intent.
Can I move an existing site to structured content?
Yes. List the repeating things on the site, such as articles, team members and events, give each a model, then move the content into it. An AI agent suits the extraction step, for you to review.
Model your first collection.
Bring an HTML prototype and turn its repeating parts into fields. Building is free, you pay when the site goes live.