CMS Limits and Scaling
|
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 limits as they were on 2026-10-28, the date on which they were checked against the official documentation and announcements. Limits are the part of the product that changes most often, because Webflow adjusts plans and raises ceilings without version numbers; the Product Changes and Deprecations page tracks what has changed since. Plans are named by tier only (Starter, Basic, Premium, Team and Enterprise) and no prices are quoted. Where a number is not stated in an official source, this page says so instead of guessing, and the practical advice is to treat the figure as something to confirm in the Workspace or with Webflow before committing to an architecture.
The running example is Fernbrook Gardens. Its Plants Collection starts with a few hundred species, the Garden Journal adds a post every week, Events accumulates a new entry for every guided tour and workshop, and a Volunteer Shifts Collection grows every month. The question this page answers is which of those can live comfortably in the CMS, which hit a ceiling, and what to do when one does.
Two kinds of limit
Webflow’s CMS limits fall into two families, and mixing them up is the most common planning mistake.
-
Storage limits are set by the Site plan: how many items the whole site can hold and how many Collections it can have. They decide whether you can create content at all. See Collections and Field Types for what an item and a Collection are.
-
Display limits are set by the way a page is built: how many Collection lists a page may contain, how many items a list shows, and how deeply lists nest. They decide how much content one page can render, regardless of how many items exist. See Collection Lists.
An item that fits within the storage allowance can still be unreachable from a page if the page design hits a display limit, and a generous display limit does not help a site that has no room left to store items.
Storage limits by plan
The Site plan, not the Workspace plan, sets CMS capacity. The plan model is explained on Plans, Workspaces, Seats and Roles; the CMS-relevant part is summarised here.
| Tier | CMS capacity |
|---|---|
Starter |
A free webflow.io site meant for building and testing. It has small limits: 50 CMS items and 20 Collections. |
Basic |
A static site on a custom domain with no CMS. It has no dynamic content, so none of the storage limits below apply. |
Premium |
The tier that replaced the former CMS and Business plans in the May 2026 change. It includes 20,000 CMS items and 40 Collections. |
Team |
A newer annual plan for one site. It includes 100 Collections. |
Enterprise |
Custom limits agreed with Webflow, together with the next-generation CMS described below. |
Three points make these numbers easier to use.
-
The 20,000 items of a Premium site are a site-wide allowance across every Collection, not 20,000 items in each one. If Plants holds 600 items, Garden Journal 400 and Events 3,000, they draw from the same pool.
-
The Collection allowance counts every Collection, including the ones that exist only to support another. A Plant Families Collection used by a reference field, or a Volunteer Roles lookup table, uses a slot exactly as Plants does. Reference and multi-reference fields are described on Reference and Multi-reference Fields.
-
The changes of May 2026 applied to new purchases at once, and to existing sites at their next renewal or billable change on or after 2026-06-29. A site that was created under the old plans may therefore still show the previous limits until that point.
The Team plan’s item allowance and the exact Enterprise ceilings are not stated in the sources reviewed for this page. Enterprise capacity is negotiated rather than published, so size the Fernbrook Gardens migration against the Premium numbers if the site is on Premium, and ask Webflow for written figures if it is on Enterprise.
Draft and archived items
An item that is a draft or archived is still a stored item. The sources reviewed do not describe a separate allowance for them, so the safe planning assumption is that every item that exists in a Collection occupies the same capacity as a published one, whatever its state. Item states are covered on Publishing and Scheduling. Two consequences follow.
-
Archiving old Events hides them from the live site but does not by itself free capacity. To release capacity an item has to be deleted, ideally after exporting it, as described on CSV Import and Export.
-
A bulk import that creates drafts consumes capacity as soon as the drafts exist, before anyone publishes them. Check the remaining headroom before importing several thousand rows.
Display limits per page
The Collection list is the element that renders items on a page, and Webflow documents several ceilings on it. Webflow has been raising them, so the current values come from the help article on dynamic content limits, and older tutorials quote smaller ones.
| Limit | Value in the current documentation | Notes |
|---|---|---|
Collection lists per page |
20 on most plans at the check date; 40 on Enterprise |
Applies to static and dynamic pages alike. |
Items shown per Collection list |
100 unless pagination is enabled |
Pagination is the documented way to reach items beyond the first 100. |
Nested Collection lists |
2 nested lists per page on most plans at the check date, each showing up to 10 items; 10 nested lists showing up to 100 items on Enterprise |
Webflow states that the lower figures are being raised to match Enterprise, with deeper nesting. Older documentation allowed one or two nested lists with a handful of items each. See Collection Lists for the same figures. |
The older figures are still repeated on training pages and in books, which is why a layout that "cannot be done" in a tutorial is often possible today. The claim in the book that a nested list shows only five items belongs to that earlier generation and is not a current limit.
For Fernbrook Gardens this means the Plants index must paginate once the collection passes 100 species, a Visit Planner landing page that wants to show the next three events, five featured plants and the latest journal posts uses three Collection lists of the twenty available, and a Plant Families page that nests Plants inside each family uses one nested list. Pagination and the other list settings are configured as described on Collection Lists.
The next-generation CMS
Webflow rebuilt the architecture that stores and serves CMS content. It first moved Enterprise sites to the new architecture, with expanded storage, schema flexibility and design options, and later announced that every site had moved, so that the expanded design flexibility, including the higher Collection list limits above, is available to all customers. The first announcement is dated January 2026 and the wider release April 2026 in the coverage reviewed.
Practically, the next-generation CMS means two things for a site owner. The display limits in the previous section are the ones to plan against, and the old workarounds that existed only to fit inside smaller limits, such as splitting one page across several to show more lists, are no longer needed. Enterprise storage allowances remain a contract matter, which is why this page gives no number for them.
Pages and bandwidth
Two other ceilings sit beside the CMS and affect the same decisions.
-
Static pages are counted separately from CMS items. A Premium site has 300 static pages, and so does a Basic site. Template pages of a Collection are not counted as one static page per item: a single template page serves every item, which is why a 3,000-item Events Collection costs one template and 3,000 items rather than 3,000 pages. See Collection Template Pages.
-
Bandwidth is allocated per Site plan. A Premium site has 50 GB with add-ons. Image-heavy Collections such as Plants consume it quickly, so serve optimised images as described on Images and Assets and Performance Optimization.
Strategies when a limit is reached
Match the strategy to the limit you hit.
| Symptom | Strategy |
|---|---|
Close to the item allowance |
Delete or export content that no longer earns its place, such as Events from several seasons ago, rather than only archiving it. Merge near-duplicate items. Move rarely used content to a CSV in storage. |
Close to the Collection allowance |
Fold small lookup Collections into option fields where the values are fixed, as explained on CMS Concepts and Content Modeling. Avoid one Collection per page; prefer one Collection with a category field. |
A list needs more than 100 items |
Turn on pagination, or filter the list so each page shows a meaningful subset, for example plants flowering this month. |
Too many lists or nesting on one page |
Split the page into separate pages, load secondary content by link instead of nesting, or use the higher limits of the next-generation CMS. |
Content far beyond the site’s capacity |
Keep the bulk of the records outside the site-plan allowance and fetch them on demand, as described below. |
Using the Data API for large datasets
The Data API can read and write Collection items without the Designer. It is the right tool for bulk maintenance, for example removing expired Volunteer Shifts each night, because a script is faster and less error-prone than deleting items one by one. Reads return a bounded page of items at a time, so a script walks through a large Collection by following the offset until it has everything. The Data API is covered on Data API: CMS, and its rate limits and error handling on Data API: SDKs, Limits and Errors.
Going headless
When a dataset belongs outside the site-plan allowance altogether, for instance a ten-year archive of every plant observation at Fernbrook Gardens, keep it in a database or a purpose-built search service and let a Webflow page show only the curated part. A custom front end can fetch the rest through your own API. The patterns are described on Content Delivery API and Headless. This trades the convenience of one editing interface for capacity, so reserve it for the data that genuinely needs it.
Splitting a Collection
A Collection that has grown unwieldy can be split by a stable criterion, for example Events into current and past, but splitting spends Collection slots and complicates references. Prefer a status or category field and a filtered list, and split only when different editors or different field sets justify it.
Pitfalls
-
Reading a published item count in the Designer as the capacity used. Drafts and archived items occupy storage too.
-
Planning against figures from older books and tutorials. Storage and display limits have both changed, and the numbers on this page are dated for that reason.
-
Assuming the 100-item display limit is a storage limit. It is not; a Collection can hold far more than a list shows at once.
-
Importing a large CSV without checking remaining capacity, which can leave a partial import and a site that cannot create further items until content is removed.
-
Treating Enterprise as unlimited. It is a negotiated ceiling that must be confirmed in writing.
Where to go next
-
To model content so it uses fewer Collections, read CMS Concepts and Content Modeling.
-
To work with the plan tiers themselves, read Plans, Workspaces, Seats and Roles.
-
To script bulk changes, read Data API: CMS.