Every article about Webflow CMS limits opens with the item cap, which is the least interesting number in the product. Ten thousand items, twenty thousand, whatever the current figure is. Almost nobody hits it. The sites I have watched leave Webflow left over the publish model, the search ceiling, and a locale bill that grew faster than their traffic, and none of those three appear on the pricing page.
So this is the version I would want to read before putting a client's marketing site on the platform: what the numbers actually are as of August 2026, which of them are structural and which are just a purchase order, and what the exit looks like now that Webflow hosts Next.js itself.
What Are Webflow's Actual CMS Limits in 2026?
A Premium site holds 20,000 CMS items across 40 collections, each collection schema takes up to 60 fields, and the API hands back 100 items per request. That is the shape of the box.
Webflow's May 2026 pricing update folded the old CMS and Business tiers into a single Premium plan at $25 per month billed yearly, $39 monthly. BRIX Templates' breakdown of that change records the detail most summaries skip: the CMS item add-ons were retired at the same time, because Premium now ships with the 20,000 items those add-ons used to buy. Former Business sites traded in the other direction on bandwidth, from 100GB down to 50GB before add-ons. Legacy plans start transitioning June 29, 2026, with Freelancer and Agency workspaces running to November 16.
| Limit | Value | Structural or purchasable? |
|---|---|---|
| CMS items per site (Premium) | 20,000 | Purchasable (Enterprise goes higher) |
| Collections per site (Premium) | 40 | Purchasable (Team plan carries 100) |
| Fields per collection | 60 | Structural |
| Items per API list request | 100 | Structural, paginate around it |
| Items per Collection List on a page | 100 | Structural, paginate or filter |
| API requests per minute | 60 on Starter and Basic, 120 on CMS-tier and above | Purchasable on Enterprise |
| Successful site publishes | 1 per minute | Structural |
The field count and the pagination ceiling come straight from Webflow's CMS documentation; the request budget from the published rate limit reference. Worth noticing that the rate limit page still lists its budgets under the pre-May plan names, which tells you roughly how load-bearing that table is treated internally. Read the docs, then verify against your own account.
The Item Cap Is Not What Forces a Migration
The constraint that actually decides architectures is the publish model, not the item count. Webflow's own CMS docs put it plainly: to publish a collection or any collection items, you publish the entire site. There is no per-item publish in the Data API. Set that next to the rate limit reference, where site publishes are capped at one successful publish per minute, and the real ceiling comes into focus.
Think about what that means for content that is not editorial. A nightly import of 400 products from an ERP is fine on the request budget, and every one of those writes lands as staged data that a visitor cannot see until somebody publishes the site. One publish covers all 400 at once. That is genuinely elegant for a marketing team.
That sounds worse than it is, so let me back up. For a site with a weekly publishing rhythm, whole-site publishing is a feature. Content ships as one atomic release, staging is free, and nobody accidentally pushes half a campaign. The trouble starts when your content stops behaving like content. A price that changes hourly, a stock badge, an availability window, a support article that has to be corrected inside ten minutes at 4pm on a Friday. Every one of those wants an independent write path to the reader, and Webflow gives you a publish button and a one-per-minute door.
Ask yourself which of your collections would break if it could only reach visitors once an hour. If the answer is none, the item cap will never be your problem either.
How Much Does the Localization Tax Actually Cost?
Localization is billed per locale on top of your site plan, starting at $9 per locale per month, and it is the subscription rather than the item cap that does the damage.
Tunel Studio's breakdown of the Localization plans puts Essential at $9 per locale per month billed yearly, $12 billed monthly, covering up to three locales, with Advanced at $29 and $35 for up to five. Four languages means three paid locales. Every month. Forever, or until you leave.
Now the part where the internet is confidently wrong. A large share of the articles ranking for this query state that translated items eat your item allowance, so 500 English posts plus 500 French translations burn 1,000 of your 20,000. I went looking for that rule and could not find it stated anywhere by Webflow. The Data API localization documentation describes the opposite shape: locale variants of an item are linked by a shared itemId that represents the whole item group, with a cmsLocaleId identifying each variant. A community thread asking this exact question sat without a definitive answer. So price the locales, which are certain, and verify the item math against your own account before you make an architectural decision on the strength of a blog post. Including this one.
Here is where that lands in practice. Pizzeria Bestek, the ordering platform I built for a family-run pizzeria in Biograd na Moru on the Croatian coast, runs in four languages. It went live in September 2025 and has been taking five to ten orders a day since, seven days a week. It is React on Supabase, so the translations live in the schema and cost nothing per locale, forever. The same four languages on Webflow would have meant three paid locales stacked on the site plan for as long as the restaurant keeps the site. For a ten-page brochure site that trade is fine, and the editor experience you get back is worth real money. For a coastal restaurant serving four nationalities of tourists on a fixed-price build, a recurring per-language bill is the wrong shape.
Search Is the Quiet One
Native site search returns results from the current locale only, does not paginate, and stops at 60 results per page, per Webflow's site search documentation. CMS edits do not reindex until a full-site publish runs. For a 40-page site, unnoticeable. For a 4,000-item docs library, your users find the gap in about a week.
Signals You Have Actually Outgrown It
- Your content is data. Prices and availability. Stock counts. Anything where a human publish step sits between a database and a visitor is a staleness bug waiting for its first support ticket, and no plan tier fixes it.
- A second consumer needs the same content. A mobile app, or in-product help. The Data API can feed them, but at that point you are paying a design tool to work as a headless CMS, and paginating 100 items at a time to do it.
- Editorial workflow beyond staging. Approvals and per-author permissions.
- Relationship depth. Reference fields are cheap to add and expensive to render; once your templates are chasing references across three collections to build one page, you are hand-rolling joins in a design tool.
Two or more of those firing at once is a real signal. One of them, on its own, is usually a workaround.
Before you conclude you have outgrown anything, try the cheap thing first. A surprising share of "we need to migrate" turns out to be one workflow gap, and wiring Webflow to Zapier closes more of those than people expect. Migration is the expensive answer to a question that sometimes has a $20 one.
Where Do You Go If You Leave?
The exit is no longer automatically a rebuild, because Webflow now hosts coded applications against the same project you already publish from. Webflow Cloud takes an existing Next.js 15+ or Astro app straight from GitHub and mounts it at a subpath like /app on your existing site, or on its own subdomain. You add a real code surface to one part of the site without moving the marketing pages at all.
| Path | What you keep | What it costs you | Best when |
|---|---|---|---|
| Next.js app mounted on Webflow Cloud | Designer, editor, hosting, every existing page | Engineering time; you own an app now | One area needs real code: search, a catalogue, a calculator |
| Webflow as headless source, front end elsewhere | Editor experience your content team already knows | 100-per-request pagination and publish-driven cache invalidation | The content team loves Webflow and the developers do not |
| Headless CMS plus a Next.js rebuild | The content, and nothing else | Full rebuild, new editor training, new hosting bill | The structural limits are the problem, not the front end |
The middle row is where most teams land and the one they think about least. You keep the editor, you read collections through the Data API, and you accept that your revalidation strategy is now downstream of somebody clicking publish. Webhook-driven revalidation works well here as long as you remember the write path is still whole-site.
If the third row is where you are heading, the choice of CMS matters more than the framework. I compare the realistic options in my rundown of the best CMS platforms for marketing sites, and if the decision has narrowed to two, the Contentful versus Webflow comparison covers that fork directly. Teams arriving from the other direction, weighing a self-hosted editor against a bespoke front end, will get more from WordPress versus a custom website build. Budget for the rebuild honestly before you commit; what a custom website build actually costs is the number that decides most of these arguments, not the feature matrix.
Run the Publish Test Before You Decide
- Open your CMS and find the collection that changes most often. Note how many times it changed last week, and how many of those changes needed to be live within an hour.
- Multiply your source item count by the number of locales you will support in eighteen months. Compare that number to 20,000, then add $9 or $29 per month for every locale past the first.
- Run your ten most common site-search queries against your own site. Count how many return something useful inside the first 60 results.
- Answer one question in writing: does anything other than this website need to read this content in the next year?
- Price all three exits from the table above, including the editor retraining nobody costs.
If step one comes back with zero urgent changes and step four comes back "no", stay where you are and put the migration budget into content. That answer is more common than the migration content on the internet would suggest.
Which of the five steps did your site fail? I would guess step one for product catalogues and step three for documentation sites, and I am curious whether that matches what you find.
