Content Engineering
Treating content as structured data, not as prose in a box
Content engineering is the practice of modelling published content as structured data: defining content types and their fields, building reusable components, mapping those components to schema.org, and constructing templates that emit correct markup automatically rather than relying on an editor to remember.
The problem it solves is familiar to anyone who has run a content programme at scale. A team agrees a standard, follows it for three months, then drifts. New writers join and do not know the convention. A redesign drops the markup. Six templates emit six different structures for the same kind of information. Within a year the site is inconsistent, and inconsistency is precisely what confuses retrieval systems.
Engineering fixes this at the source. When a service page template requires a service name, a summary, a set of key facts and a set of questions as separate structured fields, the correct output becomes the only possible output, and it stays correct without ongoing policing.
Scope
What content engineering delivers
This is CMS and front-end work informed by editorial requirements, delivered by people who do both.
Content modelling
Defining each content type as a set of typed fields rather than a single body blob. A service becomes name, summary, quick answer, key facts, delivery stages, deliverables, questions and related services, each stored and rendered separately.
Component library
Reusable blocks for answer summaries, key-fact lists, comparison tables, step sequences, definitions and question sets. Each one renders consistent HTML and emits its own structured data.
Schema mapping
A documented mapping from each content field to its schema.org property, implemented in the template layer so markup is generated from the same data the page displays and cannot contradict it.
Taxonomy and linking architecture
A controlled vocabulary for services, industries and topics, with internal links generated from those relationships rather than inserted by hand. This keeps link structure coherent as the site grows.
Editorial tooling
Fields, guidance and validation inside the CMS so writers are prompted for a quick answer of the right length and warned when a required element is missing, without needing to understand markup.
Migration and remediation
Restructuring existing content into the new model, including automated extraction where the source content is consistent enough to parse reliably.
Example
A service page content model
| Field | Purpose | Maps to |
|---|---|---|
| Service name | H1 and entity label | Service.name |
| Quick answer | 40 to 65 word extractable summary | WebPage.description, speakable region |
| Key facts | Label and value pairs | Service.additionalProperty (PropertyValue) |
| Delivery stages | Ordered steps with title and description | HowTo.step |
| Deliverables | List of named outputs | Service.serviceOutput |
| Questions | Question and answer pairs | FAQPage.mainEntity |
| Related services | Controlled taxonomy references | Service.isRelatedTo |
| Last reviewed | Editorial freshness date | WebPage.dateModified |
Outcome
What changes after the work
Correct by construction
New pages emit valid, complete structured data because the template does it, not because someone remembered.
Consistent across the site
The same kind of information is expressed the same way everywhere, which is what allows a retrieval system to build a confident picture of the organisation.
Survives redesigns
Content lives as structured fields rather than as HTML pasted into an editor, so a front-end rebuild does not destroy the markup.
Editable without specialists
A marketing team can publish a compliant page without knowing what a PropertyValue is.
Reusable across channels
Structured content can be rendered to a website, a feed, an llms.txt index or an internal retrieval-augmented assistant from one source.
Measurable compliance
Because structure is enforced by the template, coverage can be reported as a number rather than assessed by sampling.