The Complete Guide to Webflow CMS Collection Setup

Every Webflow project starts with collections. And most Webflow projects that fail at scale fail because of decisions made in the first hour of CMS setup — wrong field types, flat structures where relational ones were needed, naming conventions that made sense to the developer but not to anyone editing content six months later.

This guide covers everything: what CMS collections actually are, how to think about their structure, the field types available to you and when to use each one, naming conventions that hold up across teams, and the hard limits you need to design around. Whether you are setting up your first Webflow CMS or your fiftieth, the goal is the same — build a structure that does not need to be rebuilt.

What a CMS Collection Actually Is

A CMS collection in Webflow is a structured content type. Think of it as a database table: you define the shape of the data once (the fields), and then every item in that collection follows the same shape. A "Blog Posts" collection might have a Title (plain text), Body (rich text), Author (reference to an Authors collection), Category (option field), and Published Date (date field).

The collection defines the schema. Items are the rows. Collection pages are the templates that render each item. This is straightforward, but the implications are not.

Webflow gives you up to 40 CMS collections on the top-tier plan, with up to 10,000 items per collection. That sounds like a lot until you realize that most structural problems emerge well before you hit those limits. The constraint that matters most is not size — it is design.

The Most Common Setup Mistakes

After reviewing hundreds of Webflow CMS setups (through Trellis audits and client work), the same problems appear over and over:

1. Wrong field types from day one

This is the most expensive mistake because Webflow does not let you change a field's type after creation. You chose Plain Text when you needed Rich Text. You used an Option field when you needed a Reference. Now you have 200 items in the collection and your only option is to create a new field with the right type, manually migrate the data, and delete the old field. This is not a theoretical problem — it has 138 votes on the Webflow wishlist and has been open for years.

The fix is not complicated: spend ten minutes thinking about how content will actually be used before creating any fields. Will this field ever need formatting? Rich Text, not Plain Text. Will this value be shared across items? Reference, not Option. Will editors need to select multiple values? Multi-Reference, not a comma-separated text field.

2. Flat structure where hierarchical was needed

A portfolio site with a single "Projects" collection seems clean. But then the client wants to filter by service type, and each project has multiple team members, and some projects belong to a case study series. Suddenly you need an Option field for services (but wait, projects can have multiple services), a text field for team members (but wait, you want team member profile pages too), and a category field that keeps growing.

The right structure was probably: Projects, Services (referenced from Projects via Multi-Reference), Team Members (referenced from Projects), and Case Studies (referencing Projects). Four collections instead of one. More setup time, but the site actually works.

3. No reference architecture

References are how collections relate to each other. A Blog Post references an Author. A Project references a Client. Without references, you end up duplicating data — typing the same author name into 40 blog posts instead of selecting from a list. When the author name changes, you update it in one place (the Author item) instead of forty.

Webflow limits you to 10 reference fields per collection. That is usually enough, but it forces you to be deliberate about which relationships you formalize and which you leave as plain text.

Field Type Guide

Webflow offers about a dozen field types. Here is when to use each one, and more importantly, when not to.

Plain Text vs. Rich Text

Plain Text — titles, slugs, short descriptions, meta fields, any content that should never have formatting. Use this for anything that appears in a design element where you control the styling (headings, card titles, navigation labels).

Rich Text — long-form body content where editors need headings, bold/italic, lists, images, and embeds. Rich Text fields render as a block of HTML, and you style them via the Rich Text element in the Designer. Use this for blog post bodies, service descriptions, anything where content structure is determined by the editor, not the designer.

The mistake: using Rich Text for short content that should be Plain Text. Rich Text carries formatting overhead and is harder to style consistently. If a field will always be a single line of unformatted text, Plain Text is correct.

Option vs. Reference

Option — a fixed set of choices defined at the field level. Good for status fields (Draft / Published / Archived), simple categories where the list rarely changes, or any enumeration that does not need its own page or metadata.

Reference — a link to an item in another collection. Use this when the related entity has its own data (an author has a bio, photo, social links), when you need to filter or sort by the related item, or when the list of options is managed by content editors.

Rule of thumb: if the "option" could ever need a description, image, or its own page, it is a collection with a reference, not an option field.

Multi-Reference

Same as Reference, but allows multiple selections. A blog post can have multiple tags. A project can have multiple services. Multi-Reference creates a many-to-many relationship.

The limit: each collection can have up to 5 Multi-Reference fields, and each Multi-Reference field can link to up to 10 items per CMS item. Design around these limits early.

Image, File, Video, Color, Number, Date/Time, Switch, Link

These are mostly self-explanatory, but a few notes:

• Image — always set a descriptive alt text field name so editors remember to fill it in. Accessibility is not optional.
• Number — useful for sort order fields when you need manual control over item ordering beyond alphabetical or date-based.
• Switch — boolean toggle. Good for "Featured" flags, "Hide from listing" controls, or any yes/no editorial decision.
• Date/Time — use for publish dates, event dates, anything that needs chronological sorting. Do not store dates as plain text.
• Link — for external URLs. Do not use Plain Text for URLs; the Link field type provides basic validation.

Naming Conventions That Scale

Naming seems trivial until your third project on the same Webflow account, or until a client asks a new developer to make changes. Consistent naming prevents confusion, especially across teams.

Collection naming

Use plural nouns: Blog Posts, Team Members, Case Studies. Not Blog, Team, Case Study. The collection holds multiple items — name it that way.

Avoid abbreviations. Testimonials, not Testis. Portfolio Projects, not PP. Names should be readable by anyone opening the project for the first time.

Field naming

Be explicit about what the field contains and where it appears:

• Hero Image — not Image (which image?)
• Card Description — not Short Desc
• SEO Meta Title — not Meta
• Author Reference — not Author (unless it is a plain text name)

Prefix related fields: SEO Meta Title, SEO Meta Description, SEO OG Image. This groups them visually in the Webflow editor and makes the CMS panel easier to scan.

Slug patterns

Webflow auto-generates slugs from the Name field, but you can override them. Keep slugs lowercase, hyphenated, and descriptive. For blog posts: webflow-cms-collection-setup, not the-complete-guide-to-webflow-cms-collection-setup-2026. Short, keyword-rich slugs outperform long ones for SEO and are easier to share.

The 60-Field Limit

Each Webflow CMS collection supports up to 60 fields. That includes system fields (Name, Slug, Created, Updated, Published, Archived). So you have roughly 54 custom fields to work with.

Fifty-four sounds generous until you build a collection for a complex page template. A landing page collection might need: hero headline, hero subtext, hero image, hero CTA text, hero CTA link, section 1 headline, section 1 body, section 1 image... and suddenly you are at 30 fields and you have not touched SEO metadata yet.

The 60-field limit is a design constraint, not a bug. If you are hitting it, your collection is probably doing too much. Split it. A "Landing Pages" collection with 55 fields is almost certainly better modeled as a "Landing Pages" collection (core fields) plus a "Page Sections" collection (referenced from Landing Pages via Multi-Reference).

The cost of splitting: more complexity in the Designer and more conditional visibility logic. The cost of not splitting: an unmanageable editing experience and no room to grow.

Reference Field Best Practices

You get up to 10 reference fields (single or multi) per collection. Here is how to use them well:

• Single Reference for required 1:1 relationships — every Blog Post has exactly one Author. Every Project belongs to one Client.
• Multi-Reference for many-to-many — Blog Posts have multiple Tags. Projects involve multiple Services.
• Avoid circular references — if Collection A references Collection B and Collection B references Collection A, you create maintenance headaches. It works technically, but every new item requires updates in two places.
• Name reference fields clearly — Author Reference, not Author. When someone sees the field list, they should know immediately that this links to another collection.

The Field-Type Lock-In Problem

This deserves its own section because it is the single most painful limitation in Webflow CMS. Once you create a field and choose its type, you cannot change that type. Ever. You cannot convert a Plain Text field to Rich Text, an Option to a Reference, or a single Reference to a Multi-Reference.

The workaround is manual: create a new field with the correct type, copy data from the old field to the new one (item by item, or via CSV export/import), update all Designer bindings to point to the new field, and delete the old field.

For a collection with 10 items, this takes fifteen minutes. For a collection with 500 items, it takes a full day. For a collection with 2,000 items and rich text content, it is a project unto itself.

This is why planning matters. Spending thirty minutes mapping out your field types before building saves hours — sometimes days — of migration work later. If you are not sure whether a field should be Rich Text or Plain Text, default to Rich Text. You can always use Rich Text simply, but you cannot upgrade Plain Text later.

Structures by Site Type

Different sites need different collection architectures. Here are starting points for common project types:

Blog

The classic: Blog Posts, Authors, Categories (or Tags). Blog Posts reference Author (single) and Categories (multi). Keep it simple — most blogs do not need more than three collections.

Fields on Blog Posts: Name, Slug, Body (Rich Text), Excerpt (Plain Text), Featured Image, Author (Reference), Categories (Multi-Reference), Published Date, Featured (Switch), SEO Meta Title, SEO Meta Description, SEO OG Image.

Portfolio / Agency

Projects, Services, Clients, Team Members. Projects reference Services (multi), Client (single), Team Members (multi). If you want case study pages, add a Case Studies collection that references Projects.

SaaS

Features, Use Cases, Integrations, Changelog Entries, Help Articles. Features might reference Use Cases (multi). Changelog Entries might reference Features (multi) to cross-link what changed. Help Articles might reference Features (single) for contextual help.

E-Commerce (content-only, not Webflow E-Commerce)

Products, Product Categories, Product Features. Products reference Categories (multi) and Features (multi). If products have variants, consider a Variants collection referencing Products.

Multi-Locale

Webflow's native localization handles field-level translation, but you need to plan for it at setup time. Decide which fields need localization (all text fields, certainly; images, maybe) and which are locale-independent (references, numbers, switches). This affects field count, since localized fields effectively multiply your content management workload.

How Trellis Fits In

Most of the work described in this guide is planning and manual setup. Trellis automates the parts that can be automated without taking decisions away from you.

The audit analyzes your existing CMS structure and flags problems — unused fields, missing references, naming inconsistencies, fields approaching the 60-field limit. The setup tool lets you define collections and fields in a structured interface and push them to Webflow. And the Airtable sync keeps your CMS connected to the tools your team already uses for content planning.

None of this replaces the thinking. You still need to decide on your collection architecture, choose field types deliberately, and name things well. But the execution — creating 15 fields with the right types and settings, auditing a CMS that someone else built, migrating data from Airtable — is where Trellis saves you hours.

See pricing or try it free.