How to Design CMS Collections: Blog, Updates, Pages, and Templates

Overview

A CMS doesn’t become powerful when it can store content. It becomes powerful when your collections match how you publish.

Most teams make the same mistake early:

• they create too many collections just in case

• or they put everything into one collection called Pages

• or they treat the CMS like a rich-text folder system

The result is predictable:

• inconsistent pages

• duplicated layouts

• messy URLs

• slow publishing

• weak SEO structure (because nothing is modeled)

This article gives you a practical method to design the most important CMS collections Blog, Updates, Pages, and Templates with clean fields, predictable routing, and a structure that scales.

What is a collection, in practical terms?

A collection is a repeatable content type. If a content format will be published more than a few times, it should usually be a collection.

Examples:

• Blog post (repeatable)

• Update post (repeatable)

• Release note (repeatable)

• Template page (repeatable)

• Documentation article (repeatable)

A collection is not just a container. It defines:

• what fields exist

• which fields are required

• what routes are generated

• what SEO metadata can be produced automatically

• how internal linking can be structured

A simple rule: If content needs a template, it needs a collection.

Start with the publishing surface, not the CMS

Before creating collections, list what you actually publish. Most product websites publish content across four surfaces:

1. Evergreen content (Blog, Guides)

2. Fresh content (Updates, Releases)

3. Marketing pages (Landing pages, product pages)

4. Reusable assets (Templates, Sections, Components)

Those surfaces map cleanly to these collections:

• Blog

• Updates (and optionally Releases)

• Pages

• Templates

This model is simple, but it covers a large percentage of production websites.

Collection 1: Blog (evergreen authority)

What it’s for

Blog is your evergreen content engine:

• guides

• comparisons

• tutorials

• how to articles

• topical authority building

Recommended fields

Minimum:

• title

• excerpt

• body (markdown/rich text)

• cover_image

• published_at

• author_name

• reading_time

• featured

SEO growth fields:

• type (pillar | cluster)

• pillar_ref (reference to pillar blog)

Optional but useful:

• tags (multi-select)

• category

• canonical_url (advanced)

• noindex (boolean)

Routing

Common pattern:

• /blog/[slug]

This should remain stable for years. Blog URLs are long-term assets.

Publishing behavior

Blog content should:

• be optimized for search intent

• have internal links (especially cluster → pillar)

• be kept updated (refreshing old winners matters)

Collection 2: Updates (freshness + product narrative)

What it’s for

Updates are not blog posts. They serve a different strategic purpose:

• ship logs

• progress updates

• feature announcements

• short product storytelling

Updates help with:

• freshness signals

• brand credibility (this product is alive)

• keeping the website active even when you’re not publishing long guides

Recommended fields

Minimum:

• title

• summary (short)

• body

• hero_image

• published_at

Nice-to-have:

• version (string)

• highlights (rich text)

• breaking_changes (rich text)

• migration_notes (rich text)

Routing

Common patterns:

• /updates/[slug]

• or /changelog/[slug]

Publishing behavior

Updates should be:

• easier to write than blogs

• shorter, sharper, more frequent

• internally linked from relevant blog posts (and vice versa)

Collection 3: Pages (marketing pages without chaos)

Why “Pages” can be dangerous

Many CMS setups create a collection called Pages and store everything inside it. That works… until you scale.

Because Pages becomes:

• landing pages

• legal pages

• product pages

• documentation

• campaign pages

• SEO pages

• all mixed together

That creates:

• inconsistent layouts

• routing conflicts

• unclear ownership

• difficulty applying SEO logic per type

The right way to structure “Pages”

You can keep a Pages collection, but it needs clear structure.

Recommended fields

Minimum:

• title

• slug

• body (or a block-based layout field)

• published_at (optional)

• featured (optional)

Strong additions:

• page_type (landing | legal | product | misc)

• folder (optional) for nested routes

• seo_title

• seo_description

• noindex

Routing

Two common approaches:

A) Single-level pages

• /${slug}

Best for small marketing sites.

B) Folder + slug

• /${folder}/${slug}

Best for larger marketing sites to avoid URL collisions.

Publishing behavior

Pages should:

• follow strict slug rules (because conflicts are expensive)

• be heavily reusable (sections, components)

• avoid duplication (one Pricing page, not four copies)

Collection 4: Templates (programmatic SEO + product discovery)

Templates are one of the highest leverage collections for SEO and conversion. Because they allow:

• scalable pages (many templates = many landing pages)

• high intent search capture (portfolio template, saas landing template)

• direct conversion journeys (discover → preview → use)

Recommended fields

Minimum:

• title

• slug

• description

• cover_image

• preview_images (optional gallery)

• category or template_category_ref

• published_at (optional)

• featured

Important product fields:

• use_case (portfolio, agency, saas, ecommerce)

• industry (optional)

• stack (Next.js, React, Tailwind)

• seo_title, seo_description (if needed)

Routing

Common patterns:

• /templates/[slug]

• /templates/s/[category] (category pages)

Publishing behavior

Templates should:

• have consistent metadata

• link to relevant blog posts (guides on choosing templates)

• be linked from blogs back to templates (Here’s a real template that matches this structure)

How many collections do you need?

Most teams should start with:

• Blog

• Updates

• Templates

• Pages (structured)

Then later add:

• Docs (if product complexity grows)

• Case studies (if sales motion requires proof)

• Glossary (if SEO strategy expands)

A useful constraint: If you can’t name the URL pattern and template for a collection, don’t create it yet.

The “routing-first” method (prevents SEO chaos)

Before you publish anything, define the route patterns for each collection:

• Blog → /blog/[slug]

• Updates → /updates/[slug]

• Templates → /templates/[slug]

• Pages → /${slug} or /${folder}/${slug}

Then enforce:

• unique slugs per collection

• reserved words (blog, updates, templates, api, auth, builder)

• consistent casing (lowercase + hyphens)

This method prevents:

• broken internal links

• SEO migrations later

• collisions between marketing pages and CMS content

How this ties into pillar/cluster strategy

Your Blog collection becomes more than a feed when you add:

• type (pillar | cluster)

• pillar_ref

This creates an internal linking system that scales:

• each pillar becomes a hub

• each cluster targets a specific long-tail keyword

• clusters reinforce the pillar

• the pillar consolidates authority

You do not need separate collections for pillars/clusters. They are types inside the Blog collection plus a reference field.

A recommended starting blueprint

If you want a CMS structure that supports fast publishing and long-term SEO, start with:

Blog

type + pillar_ref for authority building

Updates

short, frequent product posts

Templates

scalable discovery + conversion pages

Pages

structured with page_type and optional folder

Then enforce:

• stable route patterns

• slug rules

• sitemap generation per collection

• robots rules per host (app vs tenant)

Next steps

Once these collections are in place, the next level is:

• adding tag/category pages (programmatic pages)

• adding author pages (optional)

• generating hub pages that group content by intent

• building internal linking automation (related posts, recommended templates)

A CMS is either:

• a storage box for content

• or a publishing system that scales

Collections are the decision point.