Planning CMS Architecture Before You Build

Why planning matters

The most common CMS mistake is not structural — it is skipping the planning step entirely. Teams jump into creating collections, realize halfway through that their blog posts need authors, their events need venues, and their case studies need both clients and services. Then they spend twice as long restructuring.

Fifteen minutes of planning saves hours of rebuilding.

Step 1: Start with your sitemap

Open your site's navigation (or sketch it out) and list every page or section that displays dynamic content:

• /blog — list of articles, each with its own page.
• /team — grid of team members, each with a bio page.
• /services — list of offerings, each with a detail page.
• /case-studies — portfolio pieces, each with a detail page.
• Homepage — features testimonials, latest posts, client logos.
• /events — upcoming events calendar.
• /faq — accordion of questions and answers.

Each of these is a candidate for a CMS collection. But not every one needs to be separate — and some pages need multiple collections behind them.

Step 2: Identify your content types

Group the items from your sitemap into distinct content types. A content type is a group of items that share the same structure:

Content type	Fields it probably needs	Gets its own page?
Blog Posts	Title, body, author, date, category, image	Yes
Team Members	Name, role, photo, bio, department	Yes
Services	Name, description, icon, features, pricing	Yes
Case Studies	Title, client, challenge, solution, results, images	Yes
Testimonials	Quote, author name, company, rating, photo	No (cards only)
FAQ	Question, answer, category	No (accordion)
Client Logos	Name, logo image, URL	No (logo grid)
Events	Title, date, location, description, registration link	Yes

Notice the "Gets its own page?" column. This determines the display context and affects which fields you need. Items with pages need slugs, SEO fields, and richer body content.

Step 3: Map relationships

Draw lines between content types that reference each other:

• Blog Posts → Authors (team members who write posts).
• Blog Posts → Categories (a fixed set like Engineering, Design, Product).
• Case Studies → Clients (the company featured).
• Case Studies → Services (which services were used).
• Events → Speakers (team members or external speakers).

Each line becomes a Reference or Multi-Reference field. The direction matters:

• Many posts → one author = Reference field on Blog Posts pointing to Team Members.
• Many posts → many tags = Multi-Reference field on Blog Posts pointing to a Tags collection.
• Fixed list, no pages needed = Option field (no separate collection required).

Step 4: Spot the common patterns

Most websites follow one of a few patterns. Recognizing yours speeds up planning:

Pattern 1: Blog + Authors + Categories

The classic content site. Three collections: Blog Posts, Authors (or Team Members), and Categories. Posts reference one author and one or more categories.

Pattern 2: Products + Categories + Reviews

E-commerce or product showcase. Products reference categories. Reviews reference products using a companion collection pattern — each review links back to one product.

Pattern 3: Portfolio + Clients + Services

Agency or freelancer site. Case studies reference both the client and the services provided. Clients and services each get their own collection if they need pages; otherwise, use Option fields.

Pattern 4: Directory + Locations + Categories

Listing site (restaurants, properties, businesses). Each listing has a location (reference or address fields), categories (multi-reference), and potentially a companion collection for photos.

Step 5: Avoid the "everything in one collection" mistake

The single biggest anti-pattern is cramming unrelated content into one collection. Signs you are doing this:

• The collection name is vague — "Content," "Items," "Pages."
• Half the fields are empty on most items — events have no "Author," blog posts have no "Location."
• You use a "Type" option field to distinguish items — "Type: Blog Post" vs "Type: Event" in the same collection.
• Filtering gets complicated — you need to filter by type on every Collection List.

If items have fundamentally different fields, they belong in separate collections. A blog post and an event share almost no structure — forcing them together creates a mess of empty fields and fragile filters.

Step 6: When to split vs merge

Split when:

• Items have mostly different fields.
• Items serve different purposes on the site.
• You need different page templates for each type.
• One type updates frequently, the other rarely.

Merge when:

• Items share 80%+ of their fields.
• They display in the same lists and grids.
• The only difference is a category or type flag.
• Splitting would create two collections with 3 items each.

A good rule: if merging two types means more than 3 fields sit empty on most items, split them.

Putting it all together

Before you create your first collection, write down:

1. The collections you need (usually 3-7 for a typical site).
2. The fields each collection requires (start lean — you can always add more).
3. The relationships between collections (reference, multi-reference, or option).
4. Which collections need pages vs which are card/list-only.

Then build in order: create referenced collections first (Authors, Categories), then the collections that reference them (Blog Posts, Case Studies). This ensures reference fields have targets when you set them up.

Next steps

• Read Your First Content Structure for a hands-on walkthrough of building your first collections.
• Read When to Use Reference vs Option vs Multi-Reference for help choosing relationship types.
• Read Companion Collections Explained for handling multi-image and repeating data patterns.