---
title: "Framer CMS Collections: The Complete Tutorial"
description: "A hands-on tutorial for Framer CMS collections: creating one, structuring fields, connecting a page template, and generating dynamic pages from scratch."
canonical_url: "https://framerhub.io/blog/framer-cms-collections-tutorial"
last_updated: "2026-11-24T00:00:00.000Z"
---

CMS collections are the feature that turns Framer from a static site builder into something that can power a blog, a product catalog, or a directory. If you've only built static pages so far, this is the tutorial that walks through collections from zero — creating one, structuring it well, and generating real dynamic pages from it.

## What a Collection Actually Is

A CMS collection is a structured set of items — think of it like a spreadsheet, where each row is an item (a blog post, a product, a listing) and each column is a field (title, date, image, category). The key thing that makes it powerful: you design **one page template** for the collection, and Framer automatically generates a live page for every item using that same template. Add a new blog post to the collection, and it gets its own page without you building anything new — the template already exists.

## Step 1: Create the Collection

1. In your Framer project, open the CMS panel and create a new collection.
2. Name it clearly and specifically — "Blog Posts," "Products," "Team Members" — not something generic like "Items," especially if you'll have more than one collection in the project later.
3. Framer starts you with a few default fields; you'll customize these in the next step.

## Step 2: Structure Your Fields

This is the step that determines how well the rest of the project goes, and it's worth more planning time than it usually gets. Before adding fields:

- **List every piece of content each item actually needs**, based on real examples, not assumptions. If you're building a product collection, look at 3-5 real products and write down every distinct piece of information they'd need — this catches fields you'd otherwise forget until you're mid-build.
- **Choose the right field type for each piece of content** — a category should usually be a defined option set (not free text, which invites inconsistent spelling across items), a publish date should be a date field (not text, which breaks sorting), and an author or category that repeats across items is often better as a reference to another collection than duplicated text.
- **Mark fields required only when they truly are.** An overly strict required-field setup makes early content entry annoying for no real benefit; too loose, and you'll end up with inconsistent, incomplete items later.

Common field types you'll use across most collections: Text, Rich Text (for body content with formatting), Image, Link, Date, Boolean (for flags like "featured"), Color, and Reference (for connecting to another collection).

## Step 3: Build the Collection Page Template

A well-structured component library helps here too — a [component library](/components) with pre-built card and detail-page patterns gives you a faster starting point for the template than building every card and layout element from a blank canvas. Once your fields exist, design the page template that every item will use:

1. Create a new page and set it as the collection's page template (Framer's CMS panel handles this connection).
2. Drag your fields onto the page as you would any content — a title field becomes a heading, an image field becomes an image element, and so on. Framer connects these to the live data automatically.
3. Design for your *most content-heavy realistic item*, not your shortest one. If your longest product description is three paragraphs, design the layout assuming that length, then check how it looks with a much shorter one — it's easier to handle a short item gracefully in a layout built for a long one than the reverse.
4. Preview several different real items, not just one, before considering the template done. A template that looks great on the one item you were staring at while designing it can break in unexpected ways on an item with a much longer title or a missing optional image.

## Step 4: Add a Collection List to a Parent Page

The template handles individual item pages; you also need a way for visitors to discover items — typically a list or grid on a parent page (a blog index, a product catalog page):

1. Add a Collection List element to your index page.
2. Connect it to your collection.
3. Design the card/list-item layout — this is often a simplified version of the full detail page, showing just enough (image, title, short excerpt) to get someone to click through.
4. Set a sensible item limit and enable pagination if your collection is going to grow past what fits on one reasonable page load.

## Step 5: Cross-Collection References

If your content model has real relationships — a blog post referencing an author who's also a CMS item, a product referencing a category — use Reference fields rather than duplicating that information as plain text in every item. This keeps things consistent: update the author's bio once in their own collection item, and it updates everywhere that author is referenced, instead of hunting down every post where you typed their name and title manually.

Framer also supports adding a reference to a different collection directly within a CMS detail page — useful for patterns like showing "related posts" or linking from a product to its parent category page, without that relationship needing to be the primary structure of either collection.

## A Worked Example: Blog Collection Field Structure

To make this concrete, here's a realistic field structure for a blog collection, the most common first collection people build:

<table>
<thead>
  <tr>
    <th>
      Field
    </th>
    
    <th>
      Type
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Title
    </td>
    
    <td>
      Text
    </td>
    
    <td>
      Required
    </td>
  </tr>
  
  <tr>
    <td>
      Slug
    </td>
    
    <td>
      Link/Text
    </td>
    
    <td>
      Usually auto-generated from title
    </td>
  </tr>
  
  <tr>
    <td>
      Publish Date
    </td>
    
    <td>
      Date
    </td>
    
    <td>
      Required, used for sorting
    </td>
  </tr>
  
  <tr>
    <td>
      Featured Image
    </td>
    
    <td>
      Image
    </td>
    
    <td>
      Optional but recommended for social sharing previews
    </td>
  </tr>
  
  <tr>
    <td>
      Excerpt
    </td>
    
    <td>
      Text
    </td>
    
    <td>
      Short summary for list views, separate from the full body
    </td>
  </tr>
  
  <tr>
    <td>
      Body
    </td>
    
    <td>
      Rich Text
    </td>
    
    <td>
      The full article content
    </td>
  </tr>
  
  <tr>
    <td>
      Category
    </td>
    
    <td>
      Reference or Option Set
    </td>
    
    <td>
      Reference if categories have their own metadata; option set if simple
    </td>
  </tr>
  
  <tr>
    <td>
      Author
    </td>
    
    <td>
      Reference
    </td>
    
    <td>
      Points to a separate Authors collection if you have multiple writers
    </td>
  </tr>
  
  <tr>
    <td>
      Featured
    </td>
    
    <td>
      Boolean
    </td>
    
    <td>
      Flags posts to highlight on the homepage
    </td>
  </tr>
</tbody>
</table>

Notice that Excerpt and Body are separate fields rather than one field truncated for the list view — this is a small decision that saves real design headaches, since a truncated rich-text field often cuts off mid-formatting in ways that look broken, while a purpose-built excerpt field gives you full control over what shows in a card or list view.

## Common Mistakes When Setting Up Collections

- **Building the template before finalizing the fields.** Changing your field structure after the template is built means redoing layout work. Nail down fields first, even if it means a slower start.
- **One collection trying to serve two very different content types.** If half your "posts" are long articles and half are short announcements needing a completely different layout, you likely want two collections, not one collection with a lot of conditional logic trying to handle both.
- **No plan for empty or optional fields.** Design your template to handle a missing optional image or a blank secondary field gracefully — don't assume every field will always be filled in by whoever adds content later.
- **Skipping a test item with unusually long or short content** before considering the collection "done." This is where layout breakage actually gets discovered.

## Beyond Collections: When Native Browsing Isn't Enough

Collections and their native list/filter tools handle content structure and basic browsing well. Where they run into a real wall is **advanced browsing behavior on collections with real scale** — multi-field filtering, price ranges, and realtime search aren't part of what a native Collection List supports. If you're building a directory, real estate listing, or job board on top of the collection structure covered in this tutorial, [CMS Filter](/plugins/framer-cms-filter) is the tool that extends what you've built here into something that actually handles a large, filterable dataset. For the fuller picture of collections plus the CMS features beyond this specific tutorial's scope, our [complete Framer CMS guide](/blog/framer-cms-complete-guide) covers the rest of the surface area.

## FAQ

**What's the difference between a CMS collection and a page in Framer?**
A page is a single, unique piece of your site. A collection is a set of structured items (blog posts, products, listings) that each generate their own page automatically from one shared template — you design the template once, and it applies to every item.

**Can one CMS detail page reference a different collection?**
Yes — Framer supports adding a reference to another collection from within a CMS detail page, useful for related content patterns like "related posts" or a product's category page.

**How many fields should a collection have?**
As many as the content genuinely needs, and no more. Every additional field is something a content editor has to fill in and something you have to design for — unused optional fields add maintenance overhead without adding value.

**Can I use one collection for pages with different layouts?**
Not directly — a single collection uses one shared template. If you need meaningfully different layouts for different content types, you generally want separate collections, or a field that conditionally shows/hides sections within one shared template.

**When do I need a plugin instead of just native collections?**
When you need capabilities collections don't natively support well — multi-field filtering, realtime search, or price-range queries across many items. Native collections handle the data structure; a plugin like CMS Filter handles advanced browsing behavior on top of it.
