CMS Concepts and Content Modeling

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page describes the Webflow CMS as it was on 2026-10-28, the date on which its facts were checked against the official documentation. The CMS is part of every Site plan that includes it: the Starter tier has a small allowance, Premium and Team raise it substantially, and Enterprise raises it again and offers the next-generation CMS. Plans are named by tier only on this page; the CMS Limits and Scaling page lists the limits per tier, and the Plans, Workspaces, Seats and Roles page explains the tiers. Webflow is a software-as-a-service product without version numbers, so facts are dated rather than versioned, and the Product Changes and Deprecations page tracks what has changed since.

This is the central page of the CMS part of the sub-section. It explains the vocabulary (Collection, item, field, Collection page), the difference between content that lives in the CMS and content that lives on a static page, and a repeatable method for turning a real organisation into a content model. The following pages then go deeper into each piece: Collections and Field Types, Reference and Multi-Reference Fields, Collection Lists and Collection Template Pages.

The running example is Fernbrook Gardens, the fictitious botanical garden used across the whole sub-section. It has a searchable catalogue of Plants, the Zones of the garden where they grow, public Events, a Garden Journal (the blog) and a Staff directory. All of these are modeled below.

Why a CMS exists

A static page holds content that was typed into it once. That works for an About page, but it fails as soon as the same kind of information repeats. Fernbrook has several hundred plants. If each plant were a hand-built page, three things would go wrong:

  • Consistency. Every page would be built separately, so a change to the layout of a plant page would have to be made several hundred times, and the pages would drift apart.

  • Reuse. The same plant appears on its own page, on a zone page, in the "companions" list of other plants and on the home page as the plant of the month. Copying the content into each place guarantees that the copies disagree.

  • Editing. Updating a care note would mean opening a design tool and finding the right page, instead of editing a record.

A content management system solves this by separating content from presentation. The content is stored as structured records. The presentation is a template that is designed once and applied to every record. In Webflow this separation has three parts, each with a name:

  • a Collection defines a type of content and the fields it has;

  • an item is one record of that type;

  • a Collection page, also called a template page, is a design bound to a Collection that Webflow renders once per item, and Collection lists are design elements that show items of a Collection anywhere else on the site.

The same idea exists in every CMS. For a comparison of how Webflow’s built-in, hosted CMS relates to other architectures, see the CMS landing page; for the way Webflow couples the CMS to its design tool and hosting, see Introduction and Architecture.

The vocabulary

Collection

A Collection is a structured container for one type of content, in the same way that a table is a container for the rows of one entity in a relational database. Typical Collections are blog posts, team members, products or testimonials. A Collection belongs to exactly one site; there is no shared Collection across sites, so a second site that needs the same content needs its own copy or has to read it through the API.

A Collection has:

  • a name (the plural, for example "Plants") that appears in the Designer and in the Editor;

  • a singular name (for example "Plant") that Webflow uses in buttons such as "New Plant";

  • a Collection URL, the slug of the folder in which the item pages live, for example plants;

  • a list of fields that define what an item can hold;

  • an automatically created Collection page (template) and, optionally, settings such as the fields used as the item name and slug.

The Collection URL and the item slug together form the address of an item page, as the slug section below shows.

Item

An item is a single record of a Collection. Fern, lavender and the giant sequoia are three items of the Plants Collection. Every item has:

  • a unique item ID, assigned by Webflow and never reused, which is what the Data API uses to address it;

  • a value, possibly empty, for each of the Collection’s fields;

  • system fields: when it was created, when it was last updated, and when it was last published;

  • a state, which is one of draft, published (live), archived, or scheduled to publish.

The state of an item is separate from the publish state of the site. A site can be live while a given item is still a draft; the item is then invisible to visitors even though the site is published. The Publishing and Scheduling page covers how items move between states.

Field

A field is one named slot of an item. Each field has a type that decides what it can hold and how the Designer lets you bind it to an element. Webflow offers sixteen field types: Plain text, Rich text, Image, Multi-image, Video, Link, Email, Phone, Number, Date/time, Switch, Color, Option, File, Reference and Multi-reference. A Collection can hold up to 60 fields on the standard CMS and 100 on the Enterprise next-generation CMS, and at most 10 of them (20 on Enterprise) can be Reference or Multi-reference fields. A seventeenth type, the User field, belonged to the User Accounts product, which Webflow sunset on 2026-01-29; it should not appear in new models.

Every Collection starts with two fields that cannot be deleted: Name and Slug. Name is the human-readable title of the item, shown in lists in the Designer and the Editor, and used by default as the heading of the item. Slug is the last segment of the item’s URL. All other fields are added by the site builder.

Two properties of fields shape modeling decisions.

  • A field’s type cannot be changed after the field is created. If a Number field should have been Plain text, the only route is to create a new field, copy the data across and delete the old field. Deleting a field deletes all the data stored in it, so the copy step has to come first. The Collections and Field Types page gives the safe recipe.

  • Field validations (required fields, character limits, minimum and maximum values, and so on) are configured in the Webflow interface. The Data API cannot set them, which matters when a Collection is created by a script.

Collection page and Collection list

A Collection page is the template that renders one item. When you create a Collection Webflow creates a blank Collection page for it, which you design on the canvas like any other page, binding elements to fields. It appears in the Pages panel under CMS Collection pages. Every item of the Collection is rendered with the same layout, so editing the template updates every item page at once.

A Collection list is an element that you place on any page. It repeats its contents once per item and can filter, sort and limit which items appear. The Collection list is how the Fernbrook home page shows the three latest events, and how a zone page shows the plants that grow in that zone.

Two consequences follow from the difference between the two.

  • A Collection page shows the current item. Inside it, elements can be bound to the current item’s fields directly, without a Collection list.

  • Anywhere else, dynamic content needs a Collection list. Inside the list, elements are bound to the fields of the item that the list is currently rendering.

Static pages and dynamic pages

Webflow pages come in two kinds, and choosing between them is the first modeling decision.

Static page Collection page (dynamic)

Created from

The Pages panel, one page at a time

Created automatically with each Collection, one template per Collection

Number of pages produced

One

One per published item

Content lives in

The page itself, edited on the canvas

The item’s fields, edited in the CMS or on the canvas

Typical Fernbrook pages

Home, Visit, About, 404, Volunteers

A plant, a zone, an event, a journal post, a staff member

URL

/visit, /about

/plants/lavender, /events/spring-plant-sale

Changing the layout

Edit that page

Edit the template once; every item changes

The rule of thumb is that content that exists once belongs on a static page, and content that exists many times with the same shape belongs in a Collection. Some pages are a mixture: the Fernbrook home page is static, but it contains Collection lists that pull in events and plants. The Visit page is static, but a list on it shows the next three events.

A static page has no item behind it, so a field on it cannot be bound directly. This is the reason Collection lists exist. A Collection page, in contrast, does not need a list to show its own item.

Collection pages are also where a number of page-level settings are driven by fields, such as the page title, the meta description and the Open Graph image. Those are covered on Collection Template Pages and in the SEO and AEO page.

What the generated HTML looks like

Webflow renders a Collection page and a Collection list as ordinary HTML. For one plant, the published Collection page contains the template’s elements with the item’s values substituted. A simplified Fernbrook plant page looks like this:

<!-- /plants/lavender -->
<main class="main-wrapper">
  <section class="section_plant">
    <div class="w-layout-blockcontainer container w-container">
      <h1 class="plant-name">Lavender</h1>
      <p class="plant-latin">Lavandula angustifolia</p>
      <img src="https://cdn.prod.website-files.com/EXAMPLE-SITE-ID/EXAMPLE-ASSET-ID_lavender.jpg"
           alt="Purple lavender flower spikes in full bloom" loading="lazy" class="plant-image">
      <div class="plant-care w-richtext">
        <p>Plant in full sun with well-drained soil. Prune lightly after flowering.</p>
      </div>
      <a href="/zones/mediterranean-terrace" class="zone-link w-inline-block">Mediterranean Terrace</a>
    </div>
  </section>
</main>

Source: Webflow Help Center: Structure and style Collection pages

The class names are the designer’s, the w- classes are Webflow’s, and the src, alt and link values come from the item’s fields. A Collection list produces a wrapper with one repeated item element per record:

<div class="w-dyn-list">
  <div role="list" class="plants-grid w-dyn-items">
    <div role="listitem" class="w-dyn-item">
      <a href="/plants/lavender" class="plant-card w-inline-block">
        <h3 class="plant-card-title">Lavender</h3>
      </a>
    </div>
    <div role="listitem" class="w-dyn-item">
      <a href="/plants/foxglove" class="plant-card w-inline-block">
        <h3 class="plant-card-title">Foxglove</h3>
      </a>
    </div>
  </div>
  <div class="w-dyn-empty">
    <div>No plants found.</div>
  </div>
</div>

Source: Webflow Help Center: Intro to the Webflow CMS

The empty-state block is present in the markup and Webflow hides it when the list has items. The role attributes give assistive technology the list semantics. Understanding that the published output is plain HTML explains two behaviours that surprise newcomers: the items are in the page source, so search engines can read them, and the content is rendered by Webflow at publish time rather than fetched by the visitor’s browser.

The Fernbrook content model

This section applies a modeling method to the Fernbrook Gardens site. Webflow’s own documentation explains the pieces; the method below is a general content-modeling approach that works for any CMS and is described here because the order of the steps matters.

Step 1: List the things the site is about

Start with nouns, not pages. Ask the garden what the site is about. The answer is a list of entities:

  • plants in the collection;

  • zones of the garden where plants grow;

  • events the garden runs;

  • journal posts the garden publishes;

  • staff members the garden wants to introduce.

Each entity that appears many times with the same shape is a candidate Collection. Things that exist once (the opening hours, the mission statement) are not entities of this kind and stay on static pages, or in a settings-like Collection if an editor must be able to change them without the Designer.

Step 2: Decide what each entity needs to say

For each entity, list the facts a visitor needs and the facts an editor will maintain. Separate the facts into attributes (a value belonging to one item) and relationships (a link to another entity). Fernbrook’s plant has attributes such as its common name, Latin name, care notes, photograph, bloom months and whether it is endangered, and relationships such as the zone where it grows and the plants that go well with it.

Do not model what you cannot maintain. A field that nobody will fill in is worse than no field, because it leaves holes in the template. Prefer a few well-filled fields over many empty ones.

Step 3: Choose a type for each attribute

Match each attribute to the narrowest field type that fits. Narrow types give editors better controls and give the Designer more things to do with the value.

Plant attribute Field type Why this type

Name

Name (default)

Required by every Collection; used as the item title

Latin name

Plain text

Short single line, shown as a subtitle

Care notes

Rich text

Headings, lists and links, rendered as w-richtext markup

Photograph

Image

One hero image with its own alt text managed in the asset

Photograph alt text

Plain text

A dedicated field so editors write alt text per use; see Images and Assets

Gallery

Multi-image

Several images shown through a nested Collection list

Bloom months

Option

A fixed, ordered list of choices, usable for filtering

Colour

Color

A colour value that can drive a swatch through a style or an embed

Is endangered

Switch

A boolean used for a badge and for conditional visibility

Hardiness zone

Reference to Zones

One plant grows in one zone, but a zone holds many plants

Companions

Multi-reference to Plants

A plant has many companions, and companionship goes both ways

A rule that saves work later: use an Option field when the set of choices is closed and small, a Reference field when the choices are themselves records with content of their own, and Plain text when the values are free. A hardiness zone has a name, a description, a map and plants of its own, so it is a Collection and not an Option.

Step 4: Model the relationships

Relationships are what separate a content model from a list of spreadsheets. Webflow supports two relationship fields.

  • A Reference field points from an item to one item of another Collection. It models a many-to-one relationship: many plants point to one zone.

  • A Multi-reference field points from an item to several items of another Collection (or of the same one). It models many-to-many: a plant has several companions, and each companion is a plant.

There is no separate "one-to-many" field. The "one" side is found by asking the other direction: to list the plants of a zone, you filter the Plants Collection by its zone reference, which a Collection list on the zone’s template page does by selecting the current zone as the filter. This is covered in depth on Reference and Multi-Reference Fields.

Two practical limits apply to relationships. A Collection can have at most 10 reference and multi-reference fields in total on the standard CMS (20 on Enterprise), and a multi-reference field is limited in how many items it can hold, a limit documented with the other dynamic-content limits on CMS Limits and Scaling. A page that renders a multi-reference list inside a Collection list is a nested list, and nesting has its own limits.

Choose the direction of a relationship deliberately. If events reference zones, the event editor chooses the zone, and a zone page finds its events by filtering. If instead zones referenced events, every zone would need updating whenever an event was added. Put the reference on the side that changes more often.

Step 5: Draw the model

Draw the entities, their fields and the relationships before building anything in the Designer. The Fernbrook model as an entity-relationship diagram:

erDiagram ZONES ||--o{ PLANTS : "hardiness zone" PLANTS }o--o{ PLANTS : "companions" ZONES }o--o{ EVENTS : "taking place in" STAFF ||--o{ JOURNAL : "writes" ZONES { string name string slug richtext description image map } PLANTS { string name string slug string latin_name richtext care_notes image photo string photo_alt multiimage gallery option bloom_months color colour switch is_endangered } EVENTS { string name string slug datetime starts_at link ticket_link richtext summary } JOURNAL { string name string slug richtext body image cover datetime published_on } STAFF { string name string slug string role image portrait email contact }

Source: Webflow Data API: Field Types and Item Values

The diagram is a planning artefact, not a Webflow feature; Webflow has no built-in model diagram. The field types in the diagram map to the sixteen types listed above, and the relationship lines map to Reference and Multi-reference fields. In the diagram the Journal’s author is a reference from Journal posts to Staff, which is the usual way to give a post an author with a photo and a biography.

Step 6: Fix names before building

Collection and field names appear in the Designer, in the Editor, in the API and in CSV files. Choose them once:

  • Collection names in the plural (Plants), with a singular name (Plant) so buttons read well.

  • Field display names that an editor will understand, written in the language the editors use.

  • Field slugs, which Webflow derives from the display name when the field is created and which are what the Data API and CSV imports use as keys. They can be edited when the field is created; renaming the display name later does not change the slug, so an old slug may then disagree with its label.

This is the right moment to follow a consistent naming scheme. The Class Naming Systems page extends the idea to class and component names so that Collection fields, classes and components all use compatible vocabulary.

Step 7: Create the Collections in dependency order

Create the Collections in the order that satisfies the references. A reference field needs its target Collection to exist first. For Fernbrook, create Zones before Plants, add the Plants reference to Zones, and add the Plants-to-Plants companions field after Plants exists. Do not publish a Collection before its references resolve; the Data API documentation states that a Collection must be published to the site before its items can be referenced.

The same creation order can be written down as a Data API request. The following creates the Zones Collection with one required Plain text field and one Rich text field. The identifiers are placeholders.

POST /v2/sites/EXAMPLE_SITE_ID/collections HTTP/1.1
Host: api.webflow.com
Authorization: Bearer EXAMPLE_ACCESS_TOKEN
Content-Type: application/json

{
  "displayName": "Zones",
  "singularName": "Zone",
  "slug": "zones",
  "fields": [
    {
      "displayName": "Description",
      "slug": "description",
      "type": "RichText",
      "isRequired": false,
      "helpText": "Introductory text shown at the top of the zone page."
    },
    {
      "displayName": "Short code",
      "slug": "short-code",
      "type": "PlainText",
      "isRequired": true,
      "helpText": "Two or three letters used on garden maps."
    }
  ]
}

Source: Data API: Managing CMS Collections and Items

The request does not include name or slug, because every Collection has them by default. It also does not set any validation beyond required, because the API cannot set validations such as character limits; those are set afterwards in the Webflow interface. A Reference field in a later request needs a metadata.collectionId that points to the Zones Collection’s ID, which is why the order of creation matters.

A matching item can then be created with a fieldData object. A staged item is a draft until published:

{
  "isArchived": false,
  "isDraft": true,
  "fieldData": {
    "name": "Mediterranean Terrace",
    "slug": "mediterranean-terrace",
    "short-code": "MT",
    "description": "<p>A sunny, sheltered terrace for plants from dry climates.</p>"
  }
}

Source: Data API: Managing CMS Collections and Items

The body shows the two state flags the API uses (isArchived and isDraft) next to the field values, and it shows that rich text is exchanged as HTML. The Data API: CMS page covers the full create, update, publish and delete cycle, including how a script such as the Fernbrook nursery sync stays within the rate limits.

Slugs and URL structure

What a slug is

A slug is the part of a URL that identifies one item. In https://www.example.org/plants/lavender, plants is the Collection URL and lavender is the item’s slug. Webflow generates a slug from the item’s name when you create an item. The documentation says that slugs should be unique within a Collection and written in lowercase without spaces, and that spaces are converted to hyphens.

Because the slug is part of a public URL, three properties follow:

  • Stability. A slug that changes breaks every link, bookmark and search result that points to it. Choose slugs that you will not want to change. If a plant is renamed, keep the old slug or add a redirect from the old URL.

  • Uniqueness. Two items of the same Collection cannot share a slug. Two items of different Collections can, because their Collection URLs differ.

  • Readability. A slug is read by people and by search engines. Short, descriptive, hyphenated words are better than codes.

How the URL is composed

For a Collection page, the final URL is the site’s domain, the Collection URL and the item slug. Static pages, in contrast, take their path from the page settings. A few examples from the Fernbrook site:

https://www.fernbrookgardens.example/                            (static: Home)
https://www.fernbrookgardens.example/visit                       (static: Visit)
https://www.fernbrookgardens.example/plants/lavender             (Collection page: Plants)
https://www.fernbrookgardens.example/zones/mediterranean-terrace (Collection page: Zones)
https://www.fernbrookgardens.example/events/spring-plant-sale    (Collection page: Events)
https://www.fernbrookgardens.example/journal/a-guide-to-pruning  (Collection page: Journal)

Source: Webflow Help Center: Intro to the Webflow CMS

A Collection page URL has one level below the Collection URL, formed by the item slug. A site that wants /plants/herbs/lavender cannot get it from one Collection; it has to flatten the structure (for example by using a category field and a filtered Collection list on a static or template page) or place a reverse proxy in front of the site, which is an advanced option covered on Reverse Proxy and Custom Hosting.

Choosing the Collection URL

The Collection URL is chosen when the Collection is created and can be edited in the Collection’s settings. Changing it changes the address of every item page of that Collection at once, so it should be treated as a migration: set up redirects from the old paths, as described on Redirects and Site Migration, and update internal links that were typed as text rather than bound to the item.

Two templates cannot sensibly own the same path, so avoid a Collection URL that collides with a static page folder or another Collection URL. The usual way to avoid collisions is to give every Collection a plural noun that the static pages do not use, such as plants, zones, events and journal.

Slugs and localization

On a localized site the slug can differ per locale, so the Spanish page for lavender can live at /es/plantas/espliego while the English page stays at /plants/lavender. The structure rules are the same; what changes is that each locale’s item has its own slug. The Localization page explains how localized items are linked.

Reference strategy

References are the part of a content model that is most expensive to change. The following strategy keeps them manageable.

  • Reference the stable thing. Plants reference Zones, not the other way round, because zones rarely change while plants are added constantly.

  • Prefer one relationship to two. If a relationship can be derived by filtering the other direction, do not store it twice. Two stored sides of one relationship go out of sync the first time an editor updates only one of them.

  • Keep the number of reference fields low. Ten is the standard limit, and each reference field is also an extra lookup that a page has to resolve at render time.

  • Use a Collection for anything with its own page or its own content. If a value has only a name, an Option field is simpler and cheaper.

  • Avoid chains of references that are more than two deep. A plant references a zone, and a zone references a region, and a region references a country: each hop is another binding and another place for a page to be empty.

  • Plan for the empty state. A reference field can be empty and a Collection list can return no items. Every template needs a design for the case where a plant has no zone or a zone has no plants. Conditional visibility is covered on Conditional Visibility and Dynamic Embeds.

Self-references

A Multi-reference field can point to the Collection it belongs to. Fernbrook’s companions field does: each plant lists other plants. Webflow stores each direction separately, so listing plant A as a companion of plant B does not list B as a companion of A. If companionship is symmetric, the editor has to set both sides, or a script has to; the strategy above suggests deciding whether the site really needs the symmetric view before modeling it.

References and publishing

A referenced item only appears on the live site if it is itself published. A plant whose zone is still a draft shows an empty zone on the live page, even though the reference exists in the CMS. The safe publishing order is the same as the creation order: publish the target items first, then the items that reference them. The Data API’s staged and live endpoints make this explicit, and webhooks can notify another system when items are published.

Planning for change

A content model is not frozen after launch. Some changes are cheap and some are expensive, and knowing which is which saves rework.

Change Cost Notes

Add a field

Low

Existing items get an empty value; templates can ignore the field until it is bound

Rename a field’s display name

Low

The slug stays the same, so bindings, CSV headers and API keys are unaffected

Change a field’s type

High

Not possible directly: create a new field, copy data, rebind, delete the old field

Delete a field

High

Deletes the data in it for every item; bindings to it break

Change a Collection URL

High

Changes every item URL; redirects needed

Split one Collection into two

High

Create the new Collection, move items by CSV or API, update references and templates

Merge two Collections

High

The reverse; reference fields in other Collections must be rebuilt

The cheap changes are all additive. The expensive ones all involve a field or Collection that other things depend on. The practical consequence is to model slightly more generously than the first version of the site needs, and to prototype with real content rather than lorem ipsum, so that the missing field shows up while changing it is still cheap.

Migration recipe for a wrong field type

Suppose Fernbrook modeled the plant’s bloom season as Plain text and now wants an Option field so that visitors can filter. The sequence is:

  1. Create a new Option field called Bloom months with the choices spelled as the existing values.

  2. Export the Collection to CSV, or read it through the Data API.

  3. Map each old text value to an option and write the value into the new field, by CSV import or by API update.

  4. Rebind every element, filter and template that used the old field to the new one.

  5. Check the Collection list filters and conditional visibility rules that referenced the old field.

  6. Delete the old field only when nothing refers to it.

Always take a backup before a bulk change; the Backups and Recovery page covers backups and the CSV Import and Export page covers the file format.

Where content is edited

The content model is separate from where content is edited, and both matter to who maintains the site.

  • In the Designer, the CMS panel lists Collections and their items for people who have the right to edit them.

  • On the canvas, content editors can edit text and CMS item fields in place, and Marketers can adjust page-level settings. See Content Editing on the Canvas. The legacy Editor was fully deprecated on 2026-10-05, so older tutorials that describe it are out of date.

  • Through the Data API, a script or an integration creates and changes items without opening either tool; this is how the Fernbrook nursery sync works.

Different roles have different rights over the CMS. A Content editor can change items but cannot change the model; changing Collections and fields is a Designer-level action. This is useful in practice: it lets the site owner give editors access to content without any risk to the structure.

Pitfalls

  • Modeling pages instead of content. A Collection called "Landing pages" that holds free-form layouts is a static page with extra steps. Use Collections for repeated, similar content.

  • Free-text instead of references. Typing a zone name into a text field on every plant gives you thirty different spellings of the same zone and no way to list its plants.

  • Skipping the alt-text field. An Image field holds the picture; the alt text of an image in a Collection list is usually bound to a separate text field so that editors write it per use. See Accessibility.

  • Unstable slugs. Editing a slug breaks inbound links; treat it as part of the public address.

  • Too many fields. Sixty fields is a hard ceiling and a long form for editors long before then.

  • Deleting a field to "retype" it. Deleting a field destroys its data; copy first.

  • Forgetting items are drafts. New items created through the API are drafts. They do not appear on the live site until published.

  • Dropping a Collection to start over. Deleting a Collection deletes all of its items.

  • Reaching the plan’s item limit. The CMS limits are per plan and are covered on CMS Limits and Scaling; check them before importing a large catalogue.

Security and privacy

  • CMS content is public once published. Anything in a published item can be read in the page source, and an item’s data can be read by the Content Delivery API when it is published. Do not store personal data or anything private in a Collection that is published to a public site. A staff Collection should contain only what each person has agreed to show.

  • Draft is not secret. A draft item is not served on the live site, but it is stored in the same site and visible to everyone with a CMS role, and the staged API returns it to any token with the CMS read scope.

  • Password protection is not item-level security. Protecting a page restricts the page, not the Collection behind it. The Password Protection and Site Search page explains what it covers.

  • API tokens carry their scopes. A token that can write the CMS can change or delete every Collection it can see. Use the narrowest scope, as described on Data API: Authentication and Scopes.

  • Rich text is HTML. When an integration writes rich text, it writes HTML that Webflow then publishes. Sanitize input that comes from outside before sending it.

What changed and when

  • The CMS field limit per Collection was raised from 30 to 60 fields in July 2024. Older material, including the book mentioned below, still says 30.

  • The Enterprise next-generation CMS raised the per-Collection field and reference limits and the item limits; see CMS Limits and Scaling.

  • The Data API v2 introduced separate staged and live item endpoints and bulk operations, and replaced the v1 API, which has been retired.

  • The User field belonged to User Accounts, which was sunset on 2026-01-29.

  • The Editor, the earlier tool for content editors, was fully deprecated on 2026-10-05 in favour of editing on the canvas.

  • Plan names changed in May 2026 (Starter, Basic, Premium, Team, Enterprise). Limits that older material quotes for the CMS and Business plans now apply to Premium; see Plans, Workspaces, Seats and Roles.

Where the older book is out of date

The book Webflow by Example (Packt, 2021) teaches content modeling in its CMS chapters and its method, to decide the entities first and then the fields and the relationships, is sound and is the method applied above. Where it differs from the official documentation, the documentation is followed here:

  • It gives a limit of 30 fields per Collection. The limit is 60 today.

  • It describes editing content in the Editor. The Editor has been retired and content is edited on the canvas.

  • It uses the older plan names and their item limits. Those plans no longer exist under those names.

  • It was written before localization, the Data API v2 and the next-generation CMS, so it does not discuss locale-specific items, API-driven content or the Enterprise limits.

The wider list is on Where Older Books and Tutorials Are Outdated.

Summary

  • A Collection is a type of content, an item is one record, a field is one value, and a Collection page renders an item.

  • Content that exists once is static; content that repeats with one shape belongs in a Collection.

  • Model nouns first, then attributes, then relationships; pick the narrowest field type; draw the model.

  • Use Reference for many-to-one and Multi-reference for many-to-many; store each relationship once.

  • Slugs are public and permanent; a Collection page URL has one level below the Collection URL.

  • Additive changes are cheap; retyping, deleting, splitting and renaming URLs are expensive.

  • Published content is public; do not store secrets in the CMS.

Where to go next

References