Defining content models before selecting a CMS
Content types, fields, relationships, and variants should be described independently of the product. This allows a CMS to be selected based on suitability.
For website operators and editorial teams, "Defining the Content Model Before Choosing a CMS" shows the difference between "Semantic Content Type" and "Explicit Relationship." A "UI-driven model" is a typical warning sign.
Published: 3 min read · Author: Sebastian Geier
Why should the content model be created before selecting a CMS?
Entities such as service, person, location, or article with meaning and relationships are derived from user tasks and editorial workflows. Only this neutral model enables the comparison of CMS capabilities, migration, multilingualism, and reuse without early vendor lock-in.
Channel-Independent Core
Proportion of business-related types and relationships that a candidate natively or with reasonable extensions represents.
Number of layout-bound free-text fields and manual duplicate entries in the prototype compared to the neutral model.
Explicit Relationship
Inventory user tasks, editorial objects, existing data, and desired channels without using system terminology.
Describe content types, fields, relationships, variants, and governance as a neutral model with real-world examples.
Prototypically test CMS candidates and migration using this model and explicitly document any necessary compromises.
UI-driven model
UI-driven model – Existing input fields of the system determine the structure, and important relationships end up as free text or plugin workarounds.
Layout as content – Texts and data are stored in nested page structures and are hardly usable outside of this representation.
Overmodeling – Every small text variation receives its own type, making editing and migration unnecessarily abstract and difficult to use.
Semantic content type
Test criterion
Semantic content type
Each type describes a real editorial object and not merely a visual module or a single page.
Test criterion
Explicit Relationship
Links, cardinality, translatability, mandatory status, and lifecycle are documented in a technically understandable way.
Channel-Independent Core – Key facts can be used in websites, search results, feeds, or future channels without conveying layout code.
Cross-check: “UI-driven model”
Locations are currently listed as separate sections on service pages. The model integrates location, contact information, and services offered into linked units; two CMS candidates now clearly demonstrate which one maps this relationship without redundant maintenance or a proprietary builder.
Which decisions "Defining the Content Model Before the CMS" complements
When is a CMS truly necessary? Expands on the "Semantic Content Type" checkpoint. The guiding question is: Which requirements justify a CMS over a simpler website architecture?
A complementary perspective is offered Building an entity data model as a common source for websites and profilesAnswers the question: "How does an entity data model become the common source for the website and external profiles?"
If you want to put "Defining the Content Model Before Choosing the CMS" into practice, you can refer to Robust Website Systems This document focuses on "CMS and Architecture Selection" and "Semantic Content Type."
Conclusion: Defining the Content Model Before Choosing the CMS
A content model translates editorial reality into a permanent system requirement. This makes CMS selection comparable and later migrations less dependent on current user interfaces.
Sources and Further Information
The classification of "Defining the Content Model Before Choosing the CMS" is based on the following official documentation and standards.
Static Exports – Next.js DocumentationOfficial Next.js documentation on static delivery, supported features, and the limitations of dynamic, server-dependent requirements.
Content Models – Contentful Help CenterOfficial Contentful documentation on content types, fields, and relationships as a business foundation before choosing a technical platform.
Requirements – WordPress.orgOfficial WordPress requirements for PHP, database, HTTPS, and server operation; they make the operational footprint of a traditional CMS directly comparable.
Key Thesis
The model translates editorial requirements into stable structures without binding them to a user interface. Only then can systems, migration, and future channels be reliably compared.
What This Is Not About
The content model should neither be derived from the standard fields of a preferred CMS nor prescribe a complete copy of current page layouts.
What it's about
It describes long-lasting content types, fields, relationships, variants, and governance, independent of the user interface and output channel.
CMS & WordPress systems
Preparing an exit strategy from complex CMS setups
As a separate step in the process of "defining the content model before the CMS," consider the question: What data and dependencies must an exit strategy for a complex CMS safeguard?
CMS & WordPress systems
Weighing page builders against long-term maintainability
Supplementing "defining the content model before the CMS" with a separate decision: When do the benefits of a page builder outweigh its long-term maintenance costs?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Semantic Content Type: A Path to Control
A central page should be broken down into facts, relationships, and pure presentation. Anything that retains meaning outside the layout belongs in the neutral model.