Webflow CMS caps you at 2,000 items on CMS plan, up to 20,000 on Business, and custom on Enterprise. If you've hit that wall, you have four real options: stay inside Webflow with automation, move public content behind a reverse proxy, push private content client-side via Wized + Xano, or rebuild on a code stack like Next.js + Supabase.
I've shipped all four in client projects, including the first version of a platform that later served 400K+ users. Here's how I decide which one to use, and the trade-off nobody tells you about.
Webflow CMS Limits by Plan
| Plan | CMS Items | Collections |
|---|---|---|
| Basic | 0 | 0 |
| CMS | 2,000 | 20 |
| Business | up to 20,000 | 40 |
| Enterprise | Custom | Custom |
SEO-friendly Solutions
If your content needs to be public and easily indexed by search engines, but you have reached or are close to the 20,000-item limit in Webflow CMS, you have two main options:
1. Webflow CMS Automation (or Enterprise Plan)
If you want to stay inside Webflow, the trick is to keep the CMS itself lean. Build an automation that archives stale items into an external database once they no longer need to be public, for example after X days. The alternative is upgrading to Webflow Enterprise, which lands somewhere between $15k and $60k per year depending on your scope.
The reason this constraint exists at all: SEO-friendly content has to be generated on the backend, and on Webflow that means going through their CMS.
2. Reverse Proxy
A reverse proxy lets you host content on an external platform (typically a Next.js app) while keeping it under your Webflow domain. Visitors hitting yoursite.com/blog don't see the boundary, but the content lives outside Webflow's infrastructure. Result: CMS item limit gone, SEO intact.
The Content Editing Experience
The usual concern when moving content out of Webflow is losing the editor. In practice, you connect a Headless CMS (Payload, Sanity, Contentful) and the editorial team gets an interface as good as Webflow's, sometimes better. The frontend still loads under your Webflow domain.
There are two main ways to set this up:
The Classic Reverse Proxy
Historically, setting up a reverse proxy was a technically complex process, requiring external server configuration, DNS management, and ongoing maintenance.
The main trade-off: being hosted outside of Webflow meant losing access to the Webflow Designer. Your external platform wouldn't share Webflow's built-in UI components and templates, so you needed to rebuild your frontend separately.
Native Reverse Proxy (Webflow Cloud)
To solve these issues, Webflow introduced a native reverse proxy solution through Webflow Cloud. This allows you to host apps built with traditional code (like Next.js) directly inside Webflow's hosting infrastructure.
With this approach, you simply specify which route your custom app should be served from (for example, /blog), and Webflow handles the proxying natively.
It also tries to solve the UI trade-off. With Webflow DevLink, you design components inside Webflow (Navbar, Footer, anything reusable) and import them into your Next.js project as React components. On paper you keep the Webflow Designer for visuals and gain unlimited CMS via code.
In practice I haven't shipped this in production yet. Webflow Cloud is still recent, the surface is moving, and I expect rough edges that are not worth absorbing on a client product. When unlimited CMS really matters, my default is hosting the Next.js app on Vercel and pointing the reverse proxy at it from your Webflow domain. The UI is built directly in Next.js (no DevLink imports), so the layer that matters most for performance, accessibility and SEO stays under your full control. I'll revisit Webflow Cloud once it has a longer track record.
Non SEO-friendly: The WWX Stack
If your content doesn't need to be indexed, for example, everything inside a restricted or members-only area, and you want to stay on Webflow, you can pair it with Wized (client-side logic) and Xano (backend and database), commonly known as the WWX stack.
Wized lets you fetch data from Xano and inject it into your Webflow components, bypassing the CMS entirely. Since the content is loaded client-side via JavaScript, it won't be immediately available to search engine crawlers1, but that's fine for dashboards, member portals, and internal tools.
In my experience this stack only makes sense for small dynamic additions on top of a Webflow site: a custom form, rendering data from one API, a lightweight gated section. For anything more custom (real auth, multi-role logic, several integrations talking to each other) the trade-offs pile up fast: testing stays manual, the architecture is tightly coupled to Webflow's rendering layer, and complex apps get harder to maintain as they grow. For products planning that kind of complexity, I default to a code stack from day one.
Going Custom: Code-Based Architecture
A code stack (Next.js + Supabase is what I default to) removes the platform constraint entirely. You get unlimited content, custom data models, version control, automated testing, and a deploy pipeline that catches bugs before users see them. Multi-role logic, integrations with any API, server-side SEO rendering: all under your control, with no visual builder ceiling to fight.
Why a code stack pays off long-term
SEO-ready out of the box
Pages are server-rendered, so Google receives them fully ready to index on every visit.
Automated testing
The code checks itself before every release, catching regressions before users ever see them.
Granular role-based access
Each user sees only what their role allows, with permissions enforced directly at the database.
Any integration, no middleman
Connect directly to any API with retry logic and real-time sync, no Zapier or third-party glue.
Code review and rollback
A Git workflow with PR review and instant rollback gives you a safety net for every release.
No platform ceiling
Unlimited records and custom data models let content, fields, and logic grow with the product.
The cost is real: development expertise, longer initial timeline, and a mindset shift from "I edit content in a CMS" to "I ship features in releases". On Unobravo's first platform we went this route from day one. Some parts have been rewritten since, but that early architecture turned out to be a solid base they kept building on as the product grew into what it is today.
Frequently Asked Questions
What is the Webflow CMS item limit?
The Webflow CMS item limit depends on your plan: 2,000 items on the CMS plan, up to 20,000 on Business, and custom limits on Enterprise. The Basic plan doesn't include CMS access.
What are the Webflow CMS collection and field limits?
On the CMS plan you get 20 collections, on Business 40. Each collection supports up to 60 fields regardless of plan.
Can I increase the Webflow CMS item limit without upgrading to Enterprise?
Yes. If your content doesn't need to be SEO-indexed, you can bypass the limit entirely by moving your data to an external database and loading it client-side (e.g., Webflow + Wized + Xano) or by building a fully custom application (e.g., Next.js + Supabase). If SEO is required, you can either automate the removal of old items to stay under the limit, or use a Native Reverse Proxy (Webflow Cloud) with a Headless CMS to serve unlimited pages under your existing Webflow domain.
What happens when I hit the Webflow CMS limit?
Webflow will prevent you from adding new items to any collection until you either delete existing items, upgrade your plan, or move content to an external database.
Is Webflow CMS good for large-scale content?
For up to 20,000 SEO-indexed items it works well. Beyond that, you'll need the Enterprise plan, a Webflow Cloud native reverse proxy with a Headless CMS, or a fully custom code-based architecture that removes platform limits altogether.
How I'd choose, in one minute
- Under 20k items, SEO matters, low product complexity → stay on Webflow CMS. Add automation if you're approaching the cap.
- Public content, SEO-required, scaling past 20k → Webflow Cloud native reverse proxy + headless CMS is the official path, but it's still early. My default is hosting Next.js on Vercel and reverse-proxying it from your Webflow domain, with the UI built directly in Next.js (no DevLink imports), until Webflow Cloud has more production miles on it.
- Private or dashboard content, SEO doesn't matter → Wized + Xano. Fast to build, fine for members-only areas.
- Frequent updates, multi-role logic, complex integrations → Next.js + Supabase. Higher upfront cost, lowest long-term ceiling.
If you're stuck between two of these, the question is rarely about the CMS itself. It's about how complex your product will be 12 months from now. Happy to look at your case if you're not sure: book a free strategy call.
Footnotes
-
To be exact, since 2014, Google has claimed to be quite skilled in rendering JavaScript websites but has always advised caution on this topic because rendering isn't always guaranteed. If the JavaScript code is incorrect or generates errors, Google may not be able to render the page correctly. Therefore, if you want to ensure that crawlers can read your content reliably, the best and safest option is still server-side rendering. This way, the content is generated on the server and delivered fully formed to the crawlers, without requiring them to interpret any JavaScript. ↩
