Webflow limits to check before a build

I build in Webflow for a living, which is exactly why this list is worth writing. Before choosing the platform, check the content model, the publishing workflow, the integrations and anything application-shaped against what it actually does.

None of this is a complaint. A tool with no limits is a tool with no opinions, and Webflow’s opinions are most of why it is good.

Plan limits and implementation constraints

Some of these move with the plan, some have documented ways around them, and a few are genuinely the edge of the tool.

Collections and items are capped per site plan, with the caps moving between plans and changing over time. The useful question is not a number in isolation: it is your content volume alongside the relationships between types, the editorial workflow and what has to be searchable, weighed against the plan you would actually be on.

A collection list renders 100 items at a time. Past that there is pagination, a load-more pattern, or several lists with offsets, all of which are documented and none of which is a wall. What it does mean is that “show all our products on one page” is a decision with consequences rather than a layout choice. Source: Collection list element

Custom code fields hold 50,000 characters each, with no build step of their own. That is generous for a tracking snippet, and anything larger is loaded as an external file built and minified elsewhere, which is the normal answer rather than a workaround. Source: Custom code in head and body tags

Redirects need a paid plan, with a recommended ceiling around a thousand rules rather than a hard one. On a large migration the map can approach that, so it is worth planning the patterns rather than assuming every address needs its own rule. Source: Webflow pricing

The Data API allows 60 a minute, or 120 on a CMS-capable plan, and bulk writes go 100 items at a time, with some endpoints and plans behaving differently again. Any sync of real size is a queue rather than a loop. Source: Webflow Data API rate limits

Browser code and server-side work are different

Custom code added to a Webflow page runs in the visitor’s browser, which decides what it can safely be trusted with. A key meant to be public, like a maps key restricted to your domain, belongs there. A private credential does not: anything in a code field is in the page source.

So a privileged operation belongs in a server-side application or a trusted service, with the page calling out to it. That is why connecting Salesforce is a different shape of job from adding an analytics script.

That application can run on Webflow Cloud or on another platform. Which one depends on the integration, on where the data has to live and on who is maintaining it afterwards. Either way the distinction that matters is not Webflow against everything else: it is what happens in the browser against what has to happen somewhere the visitor cannot reach.

Where custom code earns its place

I write a lot of custom code in Webflow. It is most of what distinguishes a build that does what a team actually needs. But there is a line, and the line is about who maintains the result.

The same technique, two situations

Custom code earning its place

• An interaction the Designer cannot express
• A third-party widget wired in properly rather than pasted
• A calculator or configurator with real logic
• A CMS-driven pattern Webflow has no native shape for

Custom code worth a second look

• Rebuilding layout the Designer already does
• Fetching and rendering content that belongs in a collection
• Keeping application data where editorial content belongs
• Changes your team needs that it does not expose

The right-hand column is how a Webflow site quietly becomes a codebase with a visual editor bolted to it, which takes on a developer dependency while keeping the platform’s constraints. Some developer-maintained functionality is entirely appropriate; what makes it a problem is nobody knowing what it does or being able to change the parts they need.

Where the two actually meet

Webflow alone

• Every marketing page
• CMS-driven listings and detail pages
• Interactions and motion
• Forms, as far as the submission

Both, wired together

• A form that reaches the CRM with attribution intact
• Gated content and member areas
• Checkout that Webflow leads into
• Calculators reading real prices

A server-side application

• Private credentials
• Validation that has to be trusted
• Database access
• Authorization and protected data

That application may run on Webflow Cloud or on another platform. The choice is about the integration, the data and the maintenance rather than about Webflow’s edge.

What to reach for instead

Per case, because “use something else” is not advice.

More content than the plan holds. Keep Webflow for the pages that need to rank and hold the rest in a system built for it: Airtable or Sanity as the source of truth, publishing the subset that needs pages. That subset still has to fit Webflow’s own limits, which is the part people skip.

Something must stay secret. A small serverless function between Webflow and the service. Webflow’s form webhook fires, your function holds the credential and does the work. This is the standard shape for any CRM write worth trusting.

Commerce beyond the native setup. Shopify fits when the catalog, the inventory, the tax handling or the order operations are the business rather than a shelf beside it. Webflow takes everything before the cart.

Gated content. The question is what authentication and authorization you need, and whether protected content is genuinely withheld from a visitor who is not entitled to it rather than hidden from view. Memberstack covers the common cases; anything genuinely sensitive belongs behind something that does not send it to the browser at all.

The site has outgrown the platform. Then it has, and that is a legitimate outcome rather than a failure. Moving to Astro or Next with a headless CMS is a real option, and I do it. Content editing can survive the move if a CMS comes with it; what changes is the editing and development workflow, and how much of it depends on a deploy.

The useful version of this list

None of these is hidden. They are just not on the page that is selling you the platform, and knowing which ones your project meets is the difference between a design decision and a discovery.

So the question worth asking anyone quoting a Webflow build is not whether they can do it. It is which of these they expect to run into, and what they plan to do about it.

Not sure whether your requirements fit Webflow?

Send your site and the functionality you need. I will tell you what fits the native tools, what needs an integration and what may need an application behind it.

Discuss your requirements

Checked against the linked documentation in September 2026. Limits and availability vary by plan and change over time, so confirm the ones that matter for your site before building around them.