Hassaan Javed
Content architecture
A CMS should connect publishing needs to reusable pages
Start with the work editors repeat, then model the content and relationships that support it.- Publishing needsResources, updates and customer stories
Identify repeatable jobs before choosing fields.
- Content modelFocused collections
Give each real content type a stable purpose and URL pattern.
- RelationshipsAuthors, categories and services
Reference shared information instead of duplicating it.
- PresentationTemplates and components
Keep spacing, responsive rules and accessibility outside the CMS.
- Editorial controlPreview, review and publish
Test the complete workflow with realistic content before launch.
Start with publishing jobs, not a list of fields
Interview the people who publish product updates, resources, customer stories, integration pages, and campaigns. Record what they create repeatedly, what they reuse, and what currently requires a developer.
A CMS is useful when it removes repeated layout work. If editors still duplicate static pages and manually repair spacing, the content model is not solving the publishing problem.
- Content types published more than once
- People responsible for drafting and approval
- Reusable relationships between content types
- Fields editors should never need to control
Create one collection for each real content type
Use separate collections when items have a distinct purpose and template. Resources, authors, case studies, integrations, industries, and testimonials often need different fields and different publishing rules.
Do not create a new collection only because two layouts look different. Presentation variants belong in components when the underlying content is still the same type.
- A clear purpose for every collection
- A stable URL pattern for indexable content
- Required fields limited to genuine requirements
- Help text for fields that editors may misunderstand
Use references to prevent duplicated information
Reference fields are useful for relationships such as a resource and its author, a case study and its industry, or an integration and its category. Update the shared item once instead of repeating names, portraits, and descriptions across many records.
Avoid turning every small label into a referenced collection. Excessive relationships make editing slower and can create unnecessary nested Collection Lists on templates.
- Author and category relationships
- Case study, service, and industry relationships
- Fallbacks when a reference is empty
- Collection List and nested-list limits reviewed
Keep layout rules inside the template and components
The CMS should store content, while the template controls spacing, typography, responsive behavior, and accessibility. Editors should choose meaningful options such as featured or resource type, not enter CSS values or visual offsets.
Use conditional visibility for optional sections, but test the empty state. Hidden content should not leave blank wrappers, stray dividers, or unexplained space.
- Reusable template sections and components
- Meaningful option or switch fields only
- Conditional sections tested when empty
- Long titles, summaries, and rich text tested
Design the editorial workflow before importing content
Define naming, slugs, image requirements, metadata ownership, preview checks, and approval. A technically clean CMS can still fail if no one knows who owns incomplete fields or when an item is ready to publish.
Import a small representative sample first. Check old posts, unusually long content, missing media, special embeds, and relationships before committing to a full migration.
- Draft, review, and publish ownership
- Image dimensions and alt text guidance
- SEO title, description, and canonical rules
- Representative import tested before bulk migration
Sources and further reading
Platform behavior and search guidance can change. These primary references support the technical details in this guide.