blog single

Content modeling for a site that will grow

Content editor arranging page sections on a large screen

Published on:

July 11, 2024

TAG:

WEB PLATFORM

BY:

Edgeless Team

Read Time:

5 MIN READ

post detail

Most websites are built page by page. A designer draws a home page, a services page and a contact page. A developer builds each one. The site works until the business needs a new service, a case study template or a regional variant, and suddenly every change means copying a page and editing it in five places. The design is rarely the problem. The site has no content model.

A page is a view of content

The home page is a place where several kinds of content appear: services, testimonials, recent projects and a contact prompt. A services page is a list of service entries. A case study is one project with a client, a sector, a result and a set of images. When the model names these things, a page becomes a view of them rather than a container that owns copies.

Teams that skip this step end up with content trapped inside layouts. The same testimonial is pasted into four pages, and when the client changes their logo, three of the copies are missed. Naming the thing once and referencing it everywhere is the core move in content modeling, and it pays back on the first content change.

Start with the things

List the nouns in the business: service, project, person, location, article, event, job, product, document. Each noun becomes a content type with its own fields. Then list how they relate. A project has one client and several services. A person has a role and may author articles. A location has an address and a set of staff.

Write the list on a wall with the client in the room. The exercise surfaces disagreements early. Marketing may think a service has a price, while delivery knows the price depends on scope. Sales may think a case study always names the client, while legal knows some clients refuse. Those differences belong in the model as optional fields or approval flags, not as exceptions handled by email.

Keep the first version small. Six or seven content types cover most business sites. A model with thirty types is usually an attempt to represent every future need, and it makes the editing experience heavy before anyone has written the first page.

Give each content type a clear name that the editors already use.
Separate required fields from optional ones and explain why each required field exists.
Use references for anything that appears in more than one place.
Store dates, numbers and choices as structured fields rather than free text.
Keep images and documents in a shared library with descriptive names.
Version the model when a field changes so old entries remain readable.

Team sketching a content model on a whiteboard — The model should use the words the editors already use. If they need a glossary to publish a page, the model is wrong.

Separate content from presentation

A field should describe the content, not the layout. A field called blue headline box will be useless when the design changes. A field called short summary can be rendered as a box, a card or a meta description. The same principle applies to images. Store the image and its alt text, then let the template decide the crop and size.

This separation is what makes a redesign cheap. If the content holds meaning, a new template can present the same entries in a new way. If the content holds layout instructions, every redesign becomes a content migration, and the team postpones it because the migration looks risky.

Relationships carry the structure

References are where a model earns its keep. A project references the services it used, the sector it belongs to and the people who worked on it. Those references let the site build a related projects section, a sector landing page and an author page without duplicating content. They also let editors answer questions such as which projects used this service, which is useful when a service page needs proof.

Decide the direction of each relationship. One project belongs to one sector. One sector has many projects. One person can author many articles. Writing the direction down prevents the classic problem where two teams each maintain a list and the lists disagree.

Plan for the second editor

The person who built the model will not be the person who uses it in a year. Write short guidance inside the editing interface. Explain what the summary field is for, where the image will appear and what happens when a required field is empty. Guidance at the point of editing is read far more often than a handbook.

Add previews that show the entry in context. Editors who can see where a field appears make better decisions about length and tone. Previews also catch layout problems before publication, which reduces the back and forth between content and development.

A content model is a description of the business written in fields. Get the nouns right and the pages become easy.
Edgeless Team

A model you can test

Before building templates, create ten real entries for each content type. Use current content, not placeholder text. Then build two pages from those entries and see whether the model holds. Missing fields show up quickly, as do fields that are always filled with the same value because they are really settings rather than content.

Run the test with an editor, not only a developer. Ask them to publish a new project without help. If they hesitate, the labels or the required fields need work. The goal is a model that a trained non technical person can use without a ticket.

Editorial workflow belongs in the model

Publishing is a process, and the model should describe it. Who drafts, who reviews, who approves and who can publish. A case study may need sign off from the client before it goes live. A job listing may expire on a date. Those rules can live in the CMS as states and permissions rather than in an email chain.

Keep the workflow as simple as the team can tolerate. A single draft and published state covers small teams. Larger teams need review and approval, but every extra state adds a place for content to sit unnoticed. Name the person who can move an item forward at each stage.

Plan for content that expires. Events, offers and seasonal pages should carry an end date so they can be unpublished automatically. A site with three year old offers on it signals neglect, and the model can prevent that without anyone remembering to check.

When the model changes

The model will change. A new service line appears, a field becomes required, a relationship is renamed. Treat those changes as migrations with a plan. Add the new field, backfill existing entries, update the templates, then make the field required. Doing it in that order avoids empty pages and a rush of manual edits.

Keep a short record of why each change happened. When someone asks in two years why projects have two client fields, the answer should be in the repository, not in someone's memory. Documentation at the model level is small and it prevents accidental reversals.

We design content models and editorial workflows for sites that expect to grow, including previews, references and migration paths.

Explore web development

A content model is invisible on the finished site, which is why it rarely gets attention. It determines how expensive the next five years of content work will be. Spend a week on the nouns before the templates, and the rest of the project gets simpler.

CMS

Content Strategy

Architecture

Content modeling for a site that will grow

Let's Talk About Your Project