- Article
- 3 minutes read
- Reviewed August 3, 2026
A content model defines the objects a website manages, their attributes, classifications, relationships, workflows and public behaviour.
Planning the model before configuring plugins reduces duplicated content, unstable URLs and editor interfaces built around assumptions rather than requirements.
Step 1: Define the Project Goals
Begin with what the website must help users and the organization achieve. A directory, publication and booking platform may all contain locations, but they use them differently.
Write the main user tasks, editorial tasks and integration requirements before naming WordPress features.
Step 2: Inventory Existing Content
Collect representative content, spreadsheets, old pages, forms and external-system fields. Identify repeated information and inconsistent terminology.
Do not model only the most polished example. Edge cases reveal whether fields are optional, repeatable or conditional.
Step 3: Identify Primary Objects
List the real nouns managed by the project: Event, Venue, Speaker, Course, Lesson, Property or Agent.
An object may deserve a post type when it needs independent records, fields, URLs, permissions, status or relationships.
Step 4: Define Attributes
For each object, list the information that belongs to one record. Define type, format, required behaviour, default and source of truth.
Separate narrative content from attributes that must be queried or reused.
Step 5: Define Classification
Identify reusable vocabularies such as topic, region, industry or difficulty. Decide whether terms form a hierarchy and who can create them.
Avoid duplicate taxonomies that ask the same question with different names.
Step 6: Define Relationships
Map how objects connect and state the direction and cardinality. An event may have one venue and many speakers; a speaker may appear at many events.
Decide whether relationships are required, ordered and visible to editors or visitors.
Step 7: Define Lifecycle and Permissions
Document who creates, reviews, publishes, updates and deletes each object. Include drafts, scheduled content, imports and archived records.
The model is incomplete if it describes fields but ignores the people and systems that maintain them.
Step 8: Plan URLs and Archives
Choose which objects and taxonomies need public single pages or archives. Define stable slugs and redirect requirements.
Not every internal object needs an indexable URL. Public pages should satisfy a visitor intent rather than exist only because WordPress can generate them.
Step 9: Plan Templates and Queries
Sketch single pages, archive cards, filters, search results and related-content components. Verify that every required display value exists in the model.
Also identify queries that may become expensive, such as sorting a large catalogue by several metadata values.
Step 10: Plan Integrations and Portability
List API consumers, imports, exports, analytics, email systems and external identifiers. Define canonical formats and ownership.
Avoid tying essential content to one theme or undocumented serialized structure.
Step 11: Prototype with Real Examples
Create a small set of realistic entries, including missing values and edge cases. Ask editors to complete the form and visitors to use the output.
Revise labels and rules before migrating thousands of records.
Step 12: Document the Model
Record keys, slugs, field formats, relationships, permissions and retention rules. Documentation allows future teams to distinguish deliberate architecture from historical accidents.
Content Model Deliverables
- Object and post type inventory.
- Field dictionary with types and validation.
- Taxonomy vocabulary and governance rules.
- Relationship diagram.
- Roles and editorial workflow.
- URL and archive map.
- Template and query requirements.
- Integration and migration plan.
- Ownership and maintenance documentation.
Frequently Asked Questions
Should I choose a plugin before planning the model?
Plan the information and workflow first. Then evaluate whether a plugin supports the required schema, portability and maintenance.
How detailed should a content model be?
Detailed enough that editors, designers and developers agree on the meaning, format and lifecycle of every important value.
Can the model change later?
Yes, but changes to keys, slugs and relationships require migration and redirect planning. Early validation reduces costly changes.