Count your content against Webflow's CMS limits before you build, not after
The short answer
Webflow's CMS has two ceilings and they behave differently. The structural ones don't move with what you pay: a Collection list shows 100 items unless you paginate, and one page holds ten nested lists. The plan ones do move, and a site on a legacy plan sits below the published numbers. Count both before you build.
Nobody finds a CMS limit at the start. You find it eleven months in, when the page listing every case study quietly stops at a hundred, or when one more reference field turns a filter somebody asked for on Monday into a fortnight of workarounds. All of it is countable in advance, on paper, in an afternoon.
References are where a content model meets a ceiling
Collections, items and fields are explained on the Webflow page above this one. The word that decides whether you ever meet a limit is the one proposals skip: the reference.
A reference is a field on one item pointing at an item in another Collection. A post pointing at one category. A multi-reference points at several at once: a case study naming three services, two locations and a person.
Every multi-reference renders as a nested list, and nested lists are what the limits below count. So the number worth being honest about isn't how many pages you want. It's how many kinds of entry you'll hold, how many of each in two years, and which point at each other.
Item
the entry
One entry in a Collection, with its own page from a shared template. Plan limits count items.
Reference
one target
A field pointing at one item in another Collection. A post and its category.
Multi-reference
many targets
The same field pointing at several. It renders as a nested list.
The limits that don't move with what you pay
Two of the numbers are structural. Paying more doesn't change them, and no tier makes them go away.
Webflow documents a Collection list as displaying a maximum of 100 items unless you turn on pagination. Everything past that is still in the CMS with its own page. It just isn't on that list. A directory of 250 people sorted alphabetically shows A through roughly H, and whoever notices is usually in the second half of the alphabet.
The second is nesting. Webflow documents a page as holding ten nested Collection lists, each showing up to a hundred nested items per parent. That sounds generous until you count a real template. A case study page rendering its services, then its locations, then the people, then a strip of related work has already spent four.
Both cap display rather than storage, which is why they surprise people. Published limits change, so read Webflow's current documentation rather than trusting an article, this one included.
The limits that move, and the one that already moved
The plan limits are a different kind of number. They move with what you pay, and they move again when the vendor reorganises its plans, which is what happened here.
Since the consolidation Webflow announced in May 2026, its Premium site plan holds 40 Collections and 20,000 items per site. Existing sites move onto it at their next renewal or billing change rather than all at once, and that gap is the thing to check. A site still on a legacy CMS plan is running against 20 Collections and 2,000 items today.
Check the plan in the billing panel of the workspace that owns the site, not the plan you'd get signing up today. Treat every number here as the start of a question.
| The limit | The documented number | Does it move? | What it caps |
|---|---|---|---|
| Items shown in one Collection list | 100, unless pagination is on | No, on every plan | What one list renders, not what the CMS stores |
| Nested Collection lists on one page | Ten, each showing up to 100 items per parent | No, on every plan | How much related content one template pulls in |
| Collections per site, Premium plan | 40, since the May 2026 consolidation | Yes, with the tier | How many kinds of thing the site holds |
| Items per site, Premium plan | 20,000, same consolidation | Yes, with the tier | Total entries across every Collection |
| Collections and items, legacy CMS plan | 20 Collections and 2,000 items | Yes, at renewal or a billing change | What an older site is against today |
Count your own model before anyone opens a builder
This takes an afternoon and a sheet of paper, and it's the one part of a platform decision a non-technical person can do alone. Do it before you shortlist anything.
Each count gets checked against a different limit, so work in this order.
1. Count the kinds of thing, not the pages
Write down every type of entry the site will hold. Services, locations, case studies, team members, posts. Then the ones nobody mentions until month four: press coverage, guides, event listings, partners. Each one is a Collection. Check the total against the Collection cap on the plan you'll actually be on.
2. Put a two-year number next to each one
Beside each kind, write how many entries you expect two years out rather than today. Fifty case studies. Twelve locations. Four hundred posts if you publish weekly. Add them up and check against the item cap. The models that fail here are usually directories.
3. Draw the lines between the lists
Mark which lists point at which. A post pointing at one category costs you nothing to think about. A case study pointing at three services, two locations and a named person is a multi-reference, and it becomes a nested list when the page renders.
4. Count what your busiest template renders
Pick the page pulling in the most related content, usually a case study or service template. Count every Collection list on it, including the ones inside components and the related-items strip. Check that against the ten-list limit.
5. Flag every list that will pass a hundred
Mark any list where a reader needs to sort or filter more than a hundred entries at once. A directory, a resource library, a location finder. Each flag becomes a deliberate decision that costs an hour now instead of a rebuild later.
The workarounds, and what each one costs
Every limit above has a way around it. Each is a trade rather than a fix, and the cost usually lands on somebody who wasn't in the room.
Two of them are ordinary and two change what you're building. Pagination and splitting a Collection are normal decisions with a known price. Fetching content from another system with custom code, or running a second system alongside the site, put software back into a project that chose a builder to avoid owning software. Neither should appear just because a list came out forty items too long.
| The workaround | What it buys | What it costs | When it's the right call |
|---|---|---|---|
| Turn on pagination | A list longer than the display limit | Sorting and filtering the set from one screen | An archive people read rather than search |
| Split one Collection into several | Headroom on list length | A single sort, and every field change happens twice | Groups that never appear as one list |
| Load everything, filter in the browser | Filtering that feels like an application | Page weight, and it fails as the list grows | A set near the limit that stays there |
| Fetch the content from another system | No ceiling on that dataset | Custom code inside a platform picked to avoid it | Data that was never site content, with a named owner |
| Run a second system alongside the site | A proper home for the data | Two places to publish, two things to learn | Content with different readers and a different lifecycle |
The signal that you should stop writing around it
One workaround is a build decision. Two on the same page is a warning. Three means the answer is to re-ask what you're building, not to look for a fourth.
The first signal is that a routine content change needs the person who wrote the custom piece. Editing without a developer was the reason to be on a builder at all, and it's moved back behind one.
The second is that the model needs a record belonging to one person and not another. A saved view, a submitted application, a quote in progress. No tier fixes that, because it's a different kind of thing from a page.
The third is subtler. Somebody proposes reshaping the content to suit the platform: merging two Collections that are genuinely different because you're near a cap. When the model bends to the tool, the tool has stopped being free.
Put the plain question to whoever is quoting. What breaks first, and what does moving off cost, priced now rather than discovered later.
Worth knowing before you start
Check the plan in the workspace billing panel, not on the pricing page. A site that predates a plan change is against the ceiling it was sold until it renews.
Export a Collection to CSV once, early, while nothing depends on it. Five minutes tells you what moving off involves, and the answer is usually reassuring about the content and sobering about the design.
Count the Collection lists on your template pages, not the homepage. The template rendering related items on every entry is the one quietly holding four lists and growing a fifth.
Add reference fields early or accept that somebody fills them in by hand. A reference added to a Collection already holding 300 items is 300 small edits, landing on whoever is least able to say no.
Write your counts, your plan and the limits you checked against onto one dated page. In a year it's the answer to why a list stops where it does.
Common questions
Nothing breaks and nothing is deleted. The list renders the first hundred in its sort order and stops. Every item past that is still in the CMS with its own page, reachable by URL and by search. It just isn't on that list.
Check before you assume you have headroom, because a Collection's total isn't always the same as what's live. That's a question for Webflow's current documentation, and it matters most on a site carrying a large drafts backlog.
For the plan limits, yes. That's what the tiers are for, and moving up one is a billing change rather than a rebuild. For the display and nesting limits, no. Those are the same on every plan, so a page rendering too many lists gets restructured either way.
The billing panel of the workspace that owns the site says so. Ask to see that screen rather than a description of it. Plans consolidate and sites move over at renewal, so "we're on the CMS plan" can mean two different ceilings.
A category is usually a single reference: this post belongs to that one. A multi-reference points at several at once, which is what a tag list looks like. Nested lists are what the page limit counts.
Roughly in order of cost: paginate or restructure the page that's over, split the Collection, move the oversized dataset into a system built for it and leave the marketing pages alone, or rebuild. The third gets skipped most often and is frequently the cheapest.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.