Webflow's Page Limits: Where They Bite and How to Route Around Them
Webflow has three different page-shaped limits, and they show up at different points in a project. The plan page describes them, but doesn't tell you which one is going to be the wall you hit. This post is the per-limit breakdown plus the three workarounds we've seen actually used.
The three limits, by plan
As of May 2026, on Site plans:
| Plan | Static pages | CMS items | Localized variants |
|---|---|---|---|
| Basic | 150 | 0 | No |
| CMS | 150 | 2,000 | No |
| Business | 300 | 10,000 | Yes |
| Enterprise | Custom | Custom | Yes |
(“Localized variants” counts as each language version of each page if you use Webflow Localization.)
Three things to note:
- Static pages and CMS items are counted separately. A blog with 500 posts is 1 static template + 500 CMS items, not 501 static pages. This usually helps.
- Folders in the Designer count as pages. Empty folder pages are easy to leave around accidentally and they each count.
- Localized variants explode the count fast. A 300-page Business site with 4 locales is 1,200 effective pages and you're likely above the variant cap.
Where the limit usually first bites
The pattern, from sites we've helped migrate:
- Marketing-only sites rarely hit static-page limits. 150 pages is a lot for a marketing site. They almost never run into the cap.
- Documentation sites hit static-page limits frequently. Docs naturally sprawl — one page per API method, per concept, per tutorial — and 150 is easy to exceed.
- High-volume publications hit CMS item limits. A site that's been blogging weekly for five years has ~260 posts. Add case studies, authors, categories, and locations and you're at 1,000+ items quickly.
- International e-commerce or content sites hit localized-variant limits. Every locale multiplies everything.
If you're building a docs site or running a content operation that's aging well, the page limit is the constraint you should be planning around before it bites.
The three workarounds
Workaround 1: Restructure to use CMS for what looks like static pages
This is the cheapest move — works inside Webflow, requires no migration. The pattern: anything you'd normally build as a static page (a feature page, a comparison page, a landing variant) becomes a CMS item in a generic “Pages” collection.
The 2,000 CMS items on the CMS plan is much more headroom than 150 static pages. We've seen sites compress 200 “real” pages into a dozen static templates plus a flat “Pages” collection with 200 items. Same URLs, same SEO, way more room.
Trade-off: less Designer flexibility (one template applies to all items), and refactoring an existing site to this shape is genuine work. Useful for new sites; painful for retrofitting.
Workaround 2: Split the site across multiple Webflow sites
Webflow Workspace pricing is per-site for the Site plans. You can put yourdomain.com on one site and docs.yourdomain.com on a second site, each with its own page limit. It's ugly from a billing perspective and creates two CMSes to maintain, but it does work.
Trade-off: double the cost, two Designers to manage, navigation between subdomains is friction-y. Use only when the two sub-sections are genuinely independent (e.g. marketing site + docs).
Workaround 3: Export the heavy section, keep Webflow for the rest
This is the pattern that's actually elegant once you've done it once: keep Webflow for the parts that benefit from it (landing pages, marketing content, the parts the marketing team edits), and export the parts that don't fit (docs, the blog, the long tail of CMS-heavy content) onto a static framework with no page limit.
The mechanics:
- The Webflow site lives at
yourdomain.comand handles the marketing pages. - A separate static site (Next.js, Astro, Hugo) lives at
yourdomain.com/blog/,yourdomain.com/docs/, etc., served from the same domain via reverse proxy or path-based routing. - Content in the static section comes from a Webflow CMS export — Webflow stays the editing surface, but the rendered output bypasses the page limit entirely.
Why this is the most-recommended approach: it's the only one that's “limit-free.” The static section can have 10,000 pages, 100,000 pages, whatever — no Webflow plan needs to change. And the marketing team keeps editing in Webflow, which is what they're fast in.
The setup typically looks like:
| URL path | Served by | Source of content |
|---|---|---|
/ | Webflow hosting | Webflow Designer (marketing) |
/about | Webflow hosting | Webflow Designer |
/pricing | Webflow hosting | Webflow Designer |
/blog/... | Next.js / Astro | Webflow CMS, exported to MDX |
/docs/... | Next.js / Astro | MDX in the repo |
Path routing via Vercel rewrites or Cloudflare Workers stitches the two together so users see one domain. The implementation is in Webflow to Next.js if you go that route.
A specific decision tree
The cheapest workaround to the most expensive:
- Are you mostly hitting the static-page limit? Try Workaround 1 — restructure to CMS items. No money, ~1 day of work.
- Are you mostly hitting the CMS item limit? Upgrade to Business ($49/mo, 10,000 items) before doing anything fancy. The upgrade is cheaper than the engineering time to migrate.
- Hitting both, or hitting the variant cap? Workaround 3 — export the heavy section to a static framework. Higher up-front cost, but no recurring page-limit pressure ever.
- At Enterprise scale and the custom limits are still bottle-necking? That's the cue to consider whether Webflow is still the right platform for the content section. Workaround 3 with the marketing site staying on Webflow indefinitely is a fine long-term state.
What people get wrong
A few common mistakes to skip:
- Deleting CMS items to stay under the cap. Webflow charges per item, not per published item, but archived items still count. Toggle to archive, but the math doesn't change. The fix is structural, not editorial.
- Building two parallel CMSes. If you split sites or split frameworks, don't end up maintaining two CMS schemas for the same content. Webflow stays the source of truth and the static side reads from the export.
- Assuming page limits = SEO limits. Webflow's page limit is a billing artifact, not a search constraint. Sites with 50,000 pages on static hosting rank fine. The limit is purely about what you can put inside the Designer.
How Webflow Export fits
For Workaround 3 specifically — the most-recommended one — Webflow Export is the bridge. It pulls CMS collections out of Webflow as .md / .mdx / .json files that drop straight into Next.js, Astro, or Hugo. Marketing keeps editing in Webflow; the heavy content section renders from the export on whatever framework you picked.
For the broader story on what survives the export, see Export Webflow CMS and the existing what survives a Webflow CMS export guide.