Plan the rebuild around reusable facts
Imagine an advisory firm preparing to replace its website. Its service names sit in navigation settings, page headings and brochures. Consultant biographies have been copied into articles and service pages. Location details differ between the contact page and the footer. Proof lives inside rich-text blocks, so nobody can reliably find every claim that depends on it.
The pages may still look coherent, but the content has no agreed source of truth. A change to one consultant, office or service becomes a search through templates and pasted copy. Migration requires people to interpret old pages one by one. New components inherit whichever wording happened to be available first.
A content model changes the unit of planning. It identifies the business facts that deserve their own records, the fields that describe them and the relationships that let templates assemble them. Do that work before developers encode old inconsistencies in new templates.
This article focuses on the CMS planning layer. Our broader guide to structuring a website for search and AI systems covers the full relationship between visible pages, semantic HTML, metadata, schema, proof and links.
What a website content model actually controls
Three related ideas are often called structured content.
In a CMS, structured content means reusable records made from defined types, fields and references. A Service record might hold a name, summary, audience, proof references and responsible person. Contentful's explanation of structured content uses this architecture vocabulary to distinguish reusable content from copy shaped for one page or channel. It's useful modelling guidance from a CMS vendor rather than independent evidence of better rankings.
On the visible page, structure means the semantic HTML and hierarchy generated by templates. A CMS field doesn't help a reader merely because it exists. The template still has to render it well. The W3C guidance on headings explains that heading levels communicate page organisation and that a logical hierarchy supports navigation and comprehension.
Structured data is another output. Schema.org's data model provides types and properties for describing entities and their relationships. It isn't a replacement for the CMS model. Editorial and business needs should determine the records first, then eligible visible facts can map to an external vocabulary.
A useful content model controls what records exist, what fields they contain, how records relate, what rules keep them valid and who owns each fact. It can supply several outputs while leaving layout to the component system.
The American search phrase content modeling describes the same planning discipline. In this guide, we use Australian spelling for the work itself.
Start with reusable business facts
Begin with a content inventory based on business facts rather than reproducing the current sitemap as content types. Ask where a fact originates, where it appears, how often it changes and who may change it.
For the fictional advisory firm, seven candidates emerge.
- Organisation holds the maintained business name, logo, contact details and profiles. It earns independence because those facts appear across the site. Our organisation identity guide covers the downstream schema implementation.
- Service defines one offer, its audience, scope, outcomes and supporting evidence. It appears on a dedicated page and in related cards, navigation and calls to action.
- Person stores a consultant's name, role, biography, expertise and profile image once, then lets services and articles reference that record.
- Location represents a real office or governed service area rather than a line pasted into multiple pages. Location and privacy decisions need their own rules.
- Article owns its headline, summary, author, publish date and meaningful update history. That makes the visible byline, metadata and downstream Article markup easier to align.
- Proof represents a review, case example, credential or other evidence that has its own source, approval status and usage constraints.
- Call to action deserves a record only when the same meaningful next step is deliberately reused. Creating a record for every button label would add editorial work without improving control.
Independence has a cost. Every type adds references, permissions and decisions for editors. A proposed record should earn its place through genuine reuse, separate ownership, distinct validation or a lifecycle that differs from the page around it.
Give every field a contract
A field name alone doesn't tell an editor what belongs there or a developer what to render. Off Piste's recommended practice is to give each reusable field a small contract. Record its purpose, shape, rule, destination and owner before implementation.
This compact service example keeps the decisions visible without tying them to a particular CMS.
| Field | Shape and rule | Output and owner |
|---|---|---|
| Service name | Short text, required and unique | Page H1, cards and metadata. Service owner |
| Summary | Plain text, required, with editorial length guidance | Page introduction and cards. Content lead |
| Audience | References to approved audience terms | Fit section and relevant listings. Service owner |
| Outcomes | Repeatable short statements with evidence checks | Visible outcomes section. Service owner |
| Evidence | References to approved proof records | Proof modules. Content lead |
| Delivery locations | Optional location references | Availability copy. Operations owner |
| Responsible person | Optional Person reference with active status | Expert module. Practice lead |
| Primary next step | One approved CTA reference | Page action. Marketing owner |
Schema mapping comes after the visible content decision. First ask whether the fact is useful to a buyer and maintainable by the business. Then use the schema prioritisation framework to decide which visible facts justify structured-data implementation. When the Service record is ready, the Service schema guide covers property-level markup.
The contract matters because it gives design, development and editorial teams the same acceptance criteria. Before a field reaches the build, the team should be able to test it consistently.
Model relationships before templates
Relationships are where a set of fields becomes a useful model. The advisory firm's Service can reference its responsible Person, relevant Locations, approved Proof and related Articles. The page template can then select current records rather than asking an editor to paste biographies, office details and case summaries into one rich-text field.
Make those references intentional. A service-to-person relationship might mean “responsible expert”, while an article-to-person relationship means “author”. A generic “related content” field hides that difference and leaves every template to guess what the connection means.
Relationships can also support more relevant internal links. A service page can lead to evidence and explanatory articles because those relationships were editorially chosen. An article can guide a reader towards the service it genuinely supports. Automatic matching can still help, but it shouldn't replace the strongest maintained connections.
Later, governed records can feed linked data. The JSON-LD 1.1 Recommendation defines linked data as identifiable nodes connected through properties and identifiers. The CMS record and JSON-LD node aren't automatically the same object, but a reliable record gives templates a consistent source. When the model is settled, use the connected schema graph guide to define stable IDs and cross-template graph rules.
Separate facts from presentation choices
Store durable meaning in the content model and let components decide how to present it. “Plain-language service summary” is a content field. “Two-column hero text” is a layout instruction and belongs in the component system.
That separation lets one summary appear as an introduction on the service page, concise text in a related-service card and a source for carefully written metadata. It also lets a redesign change visual hierarchy without forcing editors to migrate the underlying business fact again.
Formatted text still has a role. An article body, nuanced service explanation or case narrative needs links, lists and editorial rhythm. Use structured fields when the value has a distinct meaning, needs validation, is reused or must be selected independently. Use rich text for developed thought that belongs together.
Templates remain responsible for accessible output. If a design promotes a styled paragraph as though it were a heading, the CMS model hasn't solved the semantic problem. Heading fields and component rules should generate a logical hierarchy in line with the W3C's page-structure guidance.
This boundary is central to website design that joins CMS architecture with maintainable components. Editors need enough flexibility to communicate clearly, while the system protects the facts and hierarchy the website depends on.
Set validation and editorial ownership
Validation should prevent meaningful defects while keeping routine publishing efficient. Require a field when an entry needs the value to perform its job. Add format checks for URLs, dates and identifiers. Use controlled vocabularies where a consistent classification powers filters or templates. Check that references point to active, approved records.
Some rules are contextual. A service may operate without a physical location, so forcing a location reference would produce false information. A consultant profile may need an approval state before it can appear publicly. A private operating address shouldn't become public merely because a location record exists.
Ownership makes these rules sustainable. Marketing may govern organisation details, a practice lead may own service scope, operations may maintain locations, and a content lead may control article history and proof approval. Record a review path for facts that cross those boundaries.
Visible content and machine-readable output should draw from the same governed fact. Google's general structured data guidelines require structured data to represent the main visible content and warn that valid markup doesn't guarantee a search feature. Every JSON-LD claim should also appear on the page.
The same restraint applies to AI search. Google says AI Overviews and AI Mode use normal Search foundations, with no special AI file or special schema required. A good model makes accurate reuse possible. It doesn't cause a ranking, citation or recommendation.
When governance exposes conflicting indexing, markup or search requirements, a focused SEO review can help resolve the policy and validation work without turning the CMS into a collection of speculative fields.
Test the model against real publishing tasks
Don't approve the model from a diagram alone. Put it through the work an editor and template must actually perform.
- Create a service with its required name, summary, audience and next step. Confirm that the editor understands every field without a separate explanation.
- Assign an existing person, location and proof record. Check that each relationship has a precise meaning and rejects inactive or inappropriate records.
- Render the service page and its listing card. Confirm that headings, summaries, links and missing optional sections behave correctly.
- Generate the title and description inputs from governed content, while preserving editorial control where automated text would be weak.
- Emit only eligible JSON-LD that matches the visible page. Test a service without a location rather than inventing one to satisfy a template.
- Change a shared fact once. Confirm that every intended output updates and that historical content doesn't change where it should remain fixed.
- Deactivate a person who leaves. The page should remove or replace the relationship without deleting authored articles or producing a broken module.
Test the editor experience as seriously as the front end. Clear labels, help text and useful error messages often determine whether the content remains governed six months later. Permissions and review states should reflect real responsibility without turning a minor correction into an approval maze.
Once the model and templates are deployed, use a structured data audit to inspect rendered markup, compare it with visible content and route defects to the correct owner. Build validation and live validation answer different questions, so both matter.
A stronger model makes the next build easier
A structured content model gives migration decisions a stable centre. Services, people, locations, proof and publishing details can be managed as facts with known relationships instead of rediscovered inside pages whenever the design changes.
Before approving the templates, choose one representative field and ask four questions. What business fact does it store? Who keeps it accurate? What validation protects it? Which visible and justified machine-readable outputs use it? If the team can't answer all four, the field contract or template system still needs work.
That is the practical approval test. A stronger model makes the website easier to build because its meaning, rules and responsibilities have already been agreed.