A regional services company is replacing its website. It publishes services, office locations, team profiles, customer stories and articles in English and Arabic. The first design review looks promising: clear pages, polished cards and a flexible content editor. The difficulty appears when a manager asks to update a service offered at three branches, with a different contact person in each location, while the Arabic translation is still awaiting approval.
Should the editor update one service record, three page copies, or six language-specific pages? Which changes should propagate automatically? What happens when a branch stops offering the service? These questions are not about button placement. They are about the content model—the types of information the CMS stores, their fields, their relationships, and the rules that determine where they appear.
The company and tasks in this article are illustrative, not a Technway client engagement. The example makes a larger point concrete: choosing a CMS does not settle how content should be organized. A good model makes everyday work intelligible and changes proportionate. A poor model can reproduce the current website quickly while quietly creating tomorrow’s migration.
A page layout is not a content model
A page is a presentation of information. A content model describes what the information is independently of a particular presentation. A service might have a name, summary, detailed description, category, hero image, eligibility conditions and contact options. A branch might have an address, hours and a list of services it offers. The page can combine those records without making every visible block a separate copy.
That distinction is easy to miss when a project starts from Figma screens or existing URLs. Teams may create a generic Page collection with fields for title, image and a series of flexible blocks. It offers short-term freedom, especially for one-off campaign pages. But if editors use it to recreate business entities repeatedly, the website stops knowing what a service or branch actually is.
The opposite mistake is equally costly: treating every heading, visual card and decorative variation as a permanent database entity. Over-modeling forces editors through unnecessary relationships and creates migrations for changes that could safely remain presentation decisions. The goal is not maximum structure. It is explicit structure wherever meaning, ownership, reuse or validation depends on it.
Model the business concept before the page template
Return to the regional company. A useful first workshop would inventory the recurring information rather than the number of templates. What qualifies as a Service? Is the same Service offered at several Locations? Does each location have its own pricing disclaimer, opening hours or contact route? Can a staff member belong to more than one location? Which information changes frequently, and who is authorized to change it?
This leads to a practical starting model: Service, Location, Person and Article records, with relationships among them. A service can have a shared description while its availability or contact arrangements vary by location. A location can be hidden without deleting the service. Public pages are then assembled from these records and editorial content where necessary.
Relationships need precise meaning. A link from Service to Location could mean ‘offered here,’ ‘promoted here’ or ‘managed here’; those are different business rules. A many-to-many relation may also need attributes—for example, an availability state or a location-specific booking link. Simply adding a relationship field does not answer who can change it or how the frontend interprets it.
Decision table: what should be structured?
| Information | Likely modeling choice | Reason to test |
|---|---|---|
| Service identity, summary and category | Dedicated Service record | Reused across listings, detail pages and search |
| Branch address and opening hours | Dedicated Location record | Independently maintained and verified |
| Whether a branch offers a service | Explicit relationship or offering record | Availability may differ by branch |
| One-off campaign composition | Flexible page blocks | Layout changes without redefining business data |
| Decorative card styling | Frontend presentation rule | Avoid storing design tokens as business content |
This table is a starting hypothesis, not a universal schema. A small brochure site with three static pages may need much less structure. A multi-brand platform with product availability may need more. Structure earns its cost when the business truly needs consistency, querying, localization or reuse.
Choose fields for meaning, not for the current design
Field names and validation rules influence editor behavior. A free-text ‘details’ field may be convenient but cannot reliably distinguish a short listing summary from long-form explanation. A field called ‘cardDescription’ assumes one display context; ‘summary’ may be a more durable concept if the same information appears in search, recommendations and mobile layouts. Neither is always right: the team must define purpose, maximum useful length, formatting needs and fallback behavior.
Payload’s official field documentation (opens in a new tab) illustrates the principle: schema fields determine stored document structure and the corresponding editing interface. Its relationship fields (opens in a new tab) and localization configuration support structured associations and translated values. Those capabilities are useful only when the project has agreed what the associations and translations mean. A configuration option cannot resolve a missing editorial decision. See Payload Fields and Relationship Field documentation.
A sensible model also specifies what must be present. A published Service might require an approved title and short description for the target language; it might permit an optional illustration. A Location offering a Service may require a contact route or deliberately display a central contact. Required fields, conditional validation and editorial guidance should reflect these actual constraints, not arbitrary uniformity.
Multilingual publishing exposes weak assumptions
On a bilingual site, ‘translate every field’ sounds like a complete requirement until somebody asks whether branch hours, service identifiers, images and URLs should be shared. They should not all follow the same rule.
The service name, summary and detailed description normally need localized text. The underlying service identity and some internal relationships may remain language-independent. A hero image may be shared unless it contains language-specific text or culturally specific content. A slug may need a deliberate locale-specific rule; it must remain unique in its routing scope and stable enough to support links and redirects. The project should never assume translations can be added by duplicating whole pages and reconnecting them by hand.
The publication state requires an equally explicit rule. Can the English version go live while Arabic remains in draft? Does editing one language republish the other? What happens to a fallback when a required localized field is missing? Payload’s localization documentation (opens in a new tab) distinguishes localized fields and, with additional configuration, locale-specific publication status. Such features must be evaluated against the workflow rather than advertised as automatic multilingual governance.
A good acceptance test is straightforward: update the branch hours once, revise the English service description without changing Arabic, preview the pending Arabic changes, and publish only what the assigned approver has accepted. Then check both public routes. If the CMS or frontend cannot make the outcome predictable, the model is not ready.
Publishing is a state transition, not a Save button
Content operations involve authorship, review, preview, approval, publication and sometimes rollback. A model that describes only the visible page omits the conditions under which information becomes trustworthy to publish. Draft and revision features help, but do not automatically define which roles may approve, which references can become stale, or which preview accurately matches production.
Payload documents versions, drafts and access controls (opens in a new tab) as separate capabilities: version history can preserve earlier records; draft mode can separate unpublished changes from published content; access rules can restrict reading or mutation. A project must decide how these fit together, and test role-specific behavior. Permission to edit a record is not necessarily permission to publish it.
Consider a planned location closure. An editor might update the Location status before a new branch page is ready. Does the public site immediately hide the location? What happens to service pages linking to it? Should a ‘temporarily closed’ state preserve the record and direct enquiries elsewhere? The model should express business state rather than force editors to delete data as a workaround for presentation.
A change to the schema is also a migration decision
Content models evolve. A single generic Contact field may later split into a person, team inbox and location-specific phone number. A one-to-one relation may become many-to-many. An Article type may start serving both the website and a mobile application. The important question is not whether change can be avoided. It is whether changes can be understood, migrated and verified safely.
Before renaming or splitting a field, identify existing records, the consuming templates and APIs, validation requirements, query assumptions, any editorial exports and fallback logic. Decide what happens to old content. If content is consumed externally, a schema alteration can break clients even when the new CMS interface appears healthy. Versioning the API or maintaining compatibility temporarily may be cheaper than changing every consumer at once.
WordPress illustrates a related consideration (opens in a new tab): custom post types and taxonomies can be exposed through the REST API when registered for REST use. The presence of an endpoint does not itself guarantee that the stored information is reusable, that custom metadata has the correct public shape, or that another frontend understands the business meaning. The contract needs an owner and tests.
Decision table: signals of a model that needs revision
| Observed problem | Competing causes | Better verification |
|---|---|---|
| Editors change the same service in several places | Duplicated records or intentionally distinct local content | Trace a real update across pages |
| Arabic is accidentally overwritten | Shared-field boundaries or publishing rules unclear | Edit one locale and compare both previews |
| A removed branch remains linked | Missing availability state or stale relationships | Test deactivation through every public route |
| Small redesign needs a data migration | Presentation details embedded in structured records | Change one component without touching content |
| An API consumer breaks after a field change | Contract not documented or migrated | Replay consumer queries against staged data |
Do not interpret every inconvenience as proof the CMS vendor is wrong. The problem might be an ambiguous workflow, an over-complicated custom configuration, insufficient editor training, missing frontend handling, or content quality itself. Diagnose which boundary failed before proposing a platform replacement.
Run an editor acceptance exercise before approving the architecture
A schema diagram is necessary for implementation, but it is a weak substitute for using the system. Before signing off the CMS model, seed representative content: two services, two branches, two languages and a pending translation. Ask the actual editor to create a Service, attach it to two Locations, change one location’s offering, replace an image, preview a draft and retire a branch without deleting shared information.
Observe where the editor makes an uncertain choice, where information must be copied, and where permissions or validation block legitimate work. Then have a developer inspect the public rendering, API payloads, language routes and related records. One small realistic test can expose more material risk than dozens of polished placeholder pages.
Record the decisions made in that exercise. Which record owns the canonical content? Which fields are localized? Which relationships can an editor manage? Who approves publication? What happens to missing translations, deleted references and outdated URLs? A short content-model contract should describe these rules and the evidence that would justify changing them.
The right model makes ordinary changes boring
A well-designed CMS does not need to anticipate every future feature. It needs to represent today’s durable business concepts without confusing them with page decoration, give editors predictable control, and let developers change presentation without silently changing meaning. Some projects will rightly keep a simple page-and-post model. Others will benefit from structured relationships and locale-aware workflows.
For the regional services company, the next sensible decision is not to build all page templates immediately. It is to test one end-to-end content journey and verify that an editor can make the most common changes safely, without duplicates, surprise publication or broken public pages. If that works, the chosen model has earned confidence. If it fails, correcting the schema before content migration is still relatively inexpensive.
