--- 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-08-23T00: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 Framer CMS collections from zero: creating one, structuring it so it survives a real project, and generating live pages from it. The field structure is where the real work sits. Creating a collection takes about thirty seconds. Choosing the right fields is what decides whether you're still happily adding content in three weeks or quietly rebuilding the whole thing. Both are covered here, in the order you'll actually do them. --- ## What a Collection Actually Is A CMS collection is a structured set of items. Think of it like a spreadsheet: each row is an item (a blog post, a product, a listing), and each column is a field (title, date, image, category). The template is what makes it work. You design one page template for the collection, and Framer generates a live page for every item using that template. Add a new blog post to the collection and it gets its own published page without you building anything new. That's the whole trade. You give up per-page design freedom for every item, and in return you get structure, consistency, and content you can add without opening the design canvas. It's the right trade for anything repeating and the wrong trade for a one-off page, which is why an About page stays a normal page and a blog post becomes a collection item. --- ## Step 1: Create the Collection 1. Open the **CMS** panel from the left sidebar of your Framer project. 2. Create a new collection. Framer lets you start from an empty collection, import a CSV, or start from its sample blog structure. The sample is genuinely useful for a first look, but delete its fields before building for real, they're an example, not a recommendation. 3. Name it with a plural noun that says what the items are: `Blog Posts`, `Properties`, `Job Listings`. Not `Items`, not `Content`. That name follows you into the design panel and into the URL structure for the pages Framer generates, so a vague name gets expensive. 4. Framer starts you with a few default fields. Leave them for now; step 2 replaces them. If you're importing a CSV, still do step 2 before you import. Framer maps CSV columns onto fields, and it is much easier to fix the field structure while the collection is empty. --- ## Step 2: Structure Your Fields Field structure decides how well the rest of the project goes, so give it more planning time than it usually gets. Before you add a single field: - **List every piece of content each item actually needs, from real examples.** Pull up three to five real blog posts or products and write down every distinct piece of information they carry. This catches the fields you'd otherwise discover mid-build, after the template is already designed around the fields you did remember. - **Choose the right field type for each piece of content.** A category should be an option field or a reference, not free text, which invites three spellings of "Design" across ten items. A publish date should be a Date field, not Text, which breaks sorting silently. A price should be a Number, not Text, or you lose the ability to sort or range-filter on it later. - **Mark fields required only when they truly are.** Over-strict required fields make early content entry miserable for no benefit. Too loose, and you end up with half-filled items that break the template. ### Framer CMS field types
Field type What it stores Best used for
Text Short strings Titles, names, labels
Rich Text Formatted content Blog body, long descriptions
Image Image file Cover photos, avatars, thumbnails
URL Web address External links, social profiles
Date Date/time value Publish dates, event dates
Number Integer or decimal Prices, ratings, counts, bedrooms
Boolean True/false toggle Featured flag, active status
Option One value from a fixed list Category, status, property type
Color Hex/RGB value Category color coding
File Downloadable file PDFs, spec sheets
Reference A link to one item in another collection Author on a blog post
Multi-reference Links to several items in another collection Tags on a blog post
Gallery An array of images in one field Property photos, product shots
One hard limit worth knowing before you plan the structure: Framer documents a cap of **30 custom fields per collection** ([Framer developer docs](https://www.framer.com/developers/cms)). That is generous for a blog and tight for a listings collection that tries to hold every specification as its own field, so spend the budget deliberately. Two rules that save the most rework: **Use Number for anything you might ever filter or sort by a range.** Price, bedrooms, square footage, duration, rating. A number stored as Text can be displayed but not compared, and converting the field type after fifty items are entered means re-entering fifty items. **Use Option, not Text, for anything that repeats from a fixed list.** Status, category, property type. An Option field gives content editors a dropdown instead of a blank box, and it's what a filter UI binds to cleanly. --- ## A Worked Example: Blog Collection Field Structure Here's the field structure we'd actually ship for a blog collection, which is the most common first collection people build. This is the version after a few projects, including the fields that got added later because something broke without them.
Field Type Why it exists
Title Text Required. Drives the H1 and the card title
Slug Text Auto-generated from the title; edit it before publishing, never after
Publish Date Date Required. Sorting depends on it, and so does anything date-stamped in the layout
Featured Image Image Used for the card, the detail hero, and the social preview
Excerpt Text Short summary for card and list views, written by hand
Body Rich Text The article itself
Category Option or Reference Option if it's a simple label; Reference if categories need their own pages and metadata
Author Reference Points to an Authors collection. Skip it entirely if there's only ever one writer
Featured Boolean Flags posts for a homepage or hero slot
Reading Time Number Added later. A rich text field can't tell you its own length at design time
Three decisions in that table are worth explaining, because they're the ones that get made wrong: **Excerpt and Body are separate fields, not one field truncated.** Truncating rich text for a card cuts mid-formatting and looks broken about a third of the time. A purpose-written excerpt gives you full control over what shows in a list view, and it's usually better copy than the first two lines of the article. **Category is Option or Reference, decided by whether categories need their own pages.** If you want `/blog/category/design` to exist as a real page with a description and its own listing, category has to be a Reference to a Categories collection. If you only ever show a label on a card, an Option field is simpler and one collection lighter. **Author is a Reference, and it's optional.** On a single-author blog, an Author reference is pure overhead, you'll type the same name into every item and design a byline that never changes. On a multi-author blog it's essential, because a bio update should happen once. --- ## Step 3: Build the Collection Page Template Once the fields exist, design the page template that every item will use. 1. Create the collection's page template from the CMS panel. Framer handles the connection between the template and the collection. 2. Drag fields onto the page the way you'd place any content. A Title field becomes a heading, an Image field becomes an image element, a Rich Text field becomes the body. Framer binds them to live data automatically. 3. **Design for your most content-heavy realistic item, not your shortest.** If the longest description you'll ever publish is three paragraphs, build the layout for three paragraphs, then check how it degrades on a short one. A layout built for a long item handles a short one gracefully. The reverse almost never holds. 4. **Preview several real items before calling it done.** The template that looks perfect on the item you were staring at while designing will break on the one with a 90-character title or a missing optional image. 5. Set the page's SEO title and description from fields rather than hardcoding them, so every generated page gets its own metadata instead of the same string repeated across the site. A component library speeds this up. Pre-built card and detail-page patterns from a [component library](/components) give you a starting point that already handles the long-title and missing-image cases, instead of discovering them yourself on a blank canvas. --- ## Step 4: Add a Collection List to a Parent Page The template handles individual item pages. Visitors also need a way to find them, which means a list or grid on a parent page: a blog index, a product catalog, a listings page. 1. Add a **Collection List** element to your index page. 2. Connect it to your collection. 3. Design the card layout. This is usually a reduced version of the detail page, image, title, excerpt, date, showing just enough to earn the click. 4. Set the sort order deliberately. Newest-first is the right default for a blog and the wrong one for a product catalog. 5. Set an item limit and add pagination if the collection will grow past what one page load should carry. 6. Add native Dynamic Filters if readers need to narrow the list. Bind a filter to an Option field like Category and the list reacts, no plugin required. Native filtering is real and it's free. A single category dropdown or a set of tabs over one field is exactly what native Dynamic Filters are for, and reaching for anything heavier at this stage is over-engineering. --- ## Step 5: Cross-Collection References If your content model has real relationships, a post referencing an author, a product referencing a category, use Reference fields instead of duplicating the information as text in every item. The payoff is maintenance. Update an author's bio once in the Authors collection and it updates everywhere that author is referenced, instead of hunting down every post where the name and title were typed by hand. **Reference** links one item to one item in another collection: a post to its author. **Multi-reference** links one item to several: a post to its tags. On the canvas, a Reference gives you one set of fields to place, while a multi-reference gives you a list you loop over. Framer also supports adding a reference to a different collection from within a CMS detail page, which is how patterns like "related posts" or a link from a product to its parent category page get built without that relationship having to be the primary structure of either collection. The rule we use: create a second collection when the referenced thing needs its own page or its own fields. An author needs a bio, a photo, and an archive page, so Authors is a collection. A status label like "Draft" or "Live" needs neither, so it stays an Option field. --- ## Common Mistakes When Setting Up Collections **Building the template before finalizing the fields.** Changing the field structure after the template is designed means redoing layout work. Nail down fields first, even if the start feels slower. **One collection serving two very different content types.** If half your items are long articles and half are short announcements needing a different layout, that's two collections, not one collection carrying a pile of conditional visibility. **No plan for empty optional fields.** Design the template to survive a missing image or a blank secondary field. Whoever adds content in six months will leave optional fields blank, and they're right to. **Using Text where Number or Option belongs.** This is the one that costs the most later, because it blocks sorting and range filtering and can only be fixed by re-entering data. **Editing slugs after publishing.** Framer generates the item's URL from the slug. Changing it after the page is indexed breaks the link unless you add a redirect. **Skipping the extreme test item.** Add one item with an absurdly long title and one with the bare minimum filled in before you consider the collection done. That's where layout breakage actually gets found. --- ## Beyond Collections: When Native Browsing Isn't Enough Collections plus native Dynamic Filters cover content structure and straightforward browsing well, and for most sites that's the end of the story. Where they stop is advanced browsing on a collection with real scale. Native filtering has no multi-field search across several fields at once, no numeric or price range filtering, no facet counts next to each option, and no result count. If you're building a directory, a real estate listing site, or a job board on top of the structure in this tutorial, that's the wall, and [CMS Filter](/plugins/framer-cms-filter) is our plugin for exactly that gap, with multi-field search, range filters, facets with counts, sorting, and a shareable filtered URL. For where native filtering ends in detail, see our [Dynamic Filters guide](/blog/framer-dynamic-filters-guide). For the rest of the CMS surface beyond collections themselves, the [complete Framer CMS guide](/blog/framer-cms-complete-guide) covers it. ## 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. **How do I create a collection in Framer?** Open the CMS panel in the left sidebar and create a new collection. You can start empty, import a CSV, or start from Framer's sample blog structure. Name it with a plural noun, then replace the default fields with the field structure your content actually needs before you design anything. **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 search, price or date range filtering, facet counts, or a shareable filtered URL across many items. Native collections handle the data structure and basic filtering; a plugin like CMS Filter handles advanced browsing behavior on top of it.