The Next.js documentation lists 13 features that stop working when a site is exported as plain static files, among them cookies, rewrites, redirects, headers, draft mode and server actions. That list is the most practical test we know for a marketing site. If none of your requirements touch it, you are paying for a server you do not use, and most of what remains on the list is already handled by Webflow's hosting.
This guide turns that list into a decision, works through five common reasons for choosing Next.js that do not pass it, and sets out the middle options Webflow added for teams that need some code: React code components and Webflow Cloud. Figures come from the Next.js and Webflow documentation, the Webflow and Vercel price lists and HTTP Archive, all read on 28 October 2026.
The test: does any page need to read the request?
A marketing page is the same for every visitor, or it changes only after the browser has loaded it. A page that must be different in the HTML itself, because of who asked for it, needs code running on a server at request time. That is the job Next.js does well, and it is the line Webflow's hosting does not cross: you cannot run your own logic on the request path of a Webflow page.
The static exports guide in the Next.js documentation makes the split concrete. It lists what cannot be computed at build time: dynamic routes not known at build, route handlers that read the request, cookies, rewrites, redirects, headers, the proxy layer, incremental static regeneration, the default image optimiser, draft mode, server actions and intercepting routes. Sort that list by what Webflow already does for you and very little is left.
| Next.js feature that needs a server | What it does on a marketing site | Webflow equivalent |
|---|---|---|
| Redirects | 301s after a migration or slug change | Yes, set in site settings |
| Headers | Security headers, caching rules | Partly, managed by Webflow hosting |
| Default image optimisation | Resized, modern-format images | Yes, handled on upload |
| Draft mode | Preview unpublished content | Yes, staging domain and Designer preview |
| Incremental static regeneration | Refresh a page without a full rebuild | Not needed, publishing is direct |
| Dynamic routes not known at build | Pages created from live data on request | No, pages come from CMS items |
| Rewrites | Serve another app under your domain | Partly, through Webflow Cloud mount paths |
| Proxy | Logic before every request: geo, auth, flags | No |
| Cookies | Read who the visitor is on the server | No |
| Route handlers that read the request | Your own API endpoints | No, unless hosted on Webflow Cloud |
| Server actions | Form posts handled by your server code | No, forms go to Webflow or an integration |
| Intercepting routes | Modals with their own URL | No |
| Dynamic routes with dynamicParams | Unknown slugs rendered on demand | No |
Source: Next.js documentation, How to create a static export, updated 2026-08-09; Webflow pricing and Webflow Cloud documentation, read 2026-10-28
The bottom half of that table is where a marketing site genuinely needs Next.js. If your brief has nothing in it, the five arguments below are usually what is left, and none of them needs a server. We build marketing sites in Webflow and applications in Next.js, so read what follows knowing we sell both and lean towards Webflow for marketing pages.
Five reasons that do not need Next.js
1. "It has to be fast." HTTP Archive's September 2026 Core Web Vitals report measured 59,483 Webflow origins and 395,345 Next.js origins on real Chrome users. On mobile, 71.3% of Webflow origins passed all three metrics and 35.7% of Next.js origins did. Interaction to Next Paint, the metric most hurt by heavy JavaScript, passed on 88.0% of Webflow origins and 59.7% of Next.js origins. The Next.js figure includes applications, so it does not prove a well-built Next.js marketing site is slow, but it shows that speed is something a Next.js team has to keep earning. Webflow gives you that baseline by default. Our Webflow page speed fixes cover what moves the numbers on a Webflow site.
2. "Our developers want React." Since code components arrived, React and Webflow are no longer a choice of one or the other. Webflow's DevLink imports React components into the Designer, where a marketer places them and edits their props like any other element. Webflow's own architecture page says each one runs in its own Shadow DOM with a separate React root, renders on the server by default and hydrates in the browser. That is enough for a pricing calculator, a multi-step form or an interactive chart. The trade-off is isolation: components cannot share React context, and site styles have to be imported into each one on purpose.
3. "We will need an app later." Then build the app in Next.js when it exists. Webflow Cloud can host a Next.js app under a path of the Webflow site, so /app or /tools/roi can be code while the rest stays in the Designer. A subdomain such as app.company.com, hosted anywhere, is the older and still sensible answer. Rebuilding forty marketing pages in React today because an application might ship next year buys nothing the marketing team will use.
4. "We want to test and personalise." Webflow sells this as Optimize: A/B tests, AI-weighted variants and personalisation by segment, including firmographic data such as industry and company size, according to its product page. It is priced through sales rather than on the public pricing page. Server-side personalisation in Next.js is stronger when the input is your own data, such as an account's plan or contract terms, but campaign, geography and firmographic targeting do not need a server you maintain.
5. "We need full control of SEO." Both stacks expose titles, descriptions, canonicals, Open Graph tags, sitemaps, structured data and per-page indexing. We compared them in detail in Webflow or Next.js for a marketing site, and the verdict there holds: neither ranks a site, content and links do.
When Next.js genuinely earns the whole site
Three situations pass the request test for most of the site, not for one page.
The site and the product are the same surface. Logged-in visitors see a different header, their plan, their usage or a "go to dashboard" state on every marketing page. That reads a cookie on the server for every request, and splitting it across two stacks creates more problems than it solves.
Pages come from a database, not from writers. Tens of thousands of location, integration or catalogue pages built from an internal data source, refreshed daily, sit badly against a CMS item cap. Webflow's Premium plan allows 20,000 CMS items across 40 collections; our Webflow CMS limits guide covers the workarounds and where they stop. Past that, generating pages in code is the cleaner design.
Engineering owns the site and nobody else edits it. Some developer-tool companies run the marketing site as part of the product repository, with copy changes made in pull requests. If no marketer will open an editor, Webflow's main advantage disappears.
Outside those three, the usual pattern is a Webflow site with one code-shaped hole in it, and in 2026 there are three ways to fill the hole.
The middle options: code components, Webflow Cloud and a separate app
| Pattern | Where the code runs | Who edits the marketing pages | Fits |
|---|---|---|---|
| Webflow only | Nowhere you maintain | Marketing team in the Designer | Most B2B marketing sites |
| Webflow with React code components | Server render, then hydrated in the browser, inside Webflow pages | Marketing team, placing components and editing props | Calculators, configurators, multi-step forms |
| Webflow with a Webflow Cloud app on a path | Webflow Cloud workers, under the site's own domain | Marketing team for pages, developers for the app path | Tools, gated areas, small apps under /app |
| Webflow with a Next.js app on a subdomain | Vercel, your cloud or self-hosted | Marketing team for pages, developers for the app | Full product apps |
| Next.js multi-zones with a headless CMS | Next.js servers, one per zone, routed by rewrites | Marketers in the CMS, developers for layout | Engineering-owned sites with request-aware pages |
| Next.js for everything | Next.js servers | Developers, with marketers in a headless CMS | The product and site are one surface |
Source: Webflow DevLink and code components documentation, Webflow Cloud documentation, Next.js multi-zones guide, read 2026-10-28
Two notes on the rows. DevLink needs a paid Workspace plan or a CMS, Business or Ecommerce site plan, according to Webflow's DevLink overview. And multi-zones is the Next.js documentation's own name for serving several apps on one domain; links between zones must be plain anchor tags, and moving from one zone to another is a full page load.
Webflow Cloud limits that change the decision
Webflow Cloud is the newest option and the one most likely to be misused, so its limits are worth reading before anyone plans a build on it. Its documentation describes it as a deployment and hosting environment for Next.js, Astro, Vite and static apps, deployed from a GitHub repository, with SQLite, key-value and object storage. The "Bring your own app" page says Webflow Cloud installs the OpenNext Cloudflare adapter for Next.js, requires Next.js 15 or later and Node.js 22, supports only npm, and warns that the Edge runtime offers a limited set of APIs.
| Limit | Value | What it means |
|---|---|---|
| Apps per site | 5 on Starter and Basic, 15 on Premium-tier plans | Enough for a handful of tools |
| Requests per month | 1 million on Basic, 2 million on Premium, then $2 per million | Every page view of the app path counts |
| CPU time per month | 15 minutes on Basic, 30 minutes on Premium, then $2 per 5 CPU hours | Fine for light server work |
| CPU time per request | 30 seconds | Long jobs belong elsewhere |
| Request timeout | 20 seconds | Slow third-party APIs will fail |
| Memory per instance | 128 MB | No heavy image or PDF processing |
| Bundle size | 10 MB per deployment, 100 MB compressed build output | Large dependency trees fail at build |
| Cache-Control | Replaced with private, no-cache on responses | App pages are not cached at the edge |
Source: Webflow pricing, Webflow Cloud usage table; Webflow Cloud documentation, Limits page; read 2026-10-28
The last row decides most cases. Because Webflow Cloud replaces your caching headers, a content page served from a Cloud app is rendered for every visitor and counted against your request and CPU quota. That is right for a logged-in area or a tool and wrong for the blog. Keep content in the Webflow CMS and put only request-aware paths in the app.
For comparison, Vercel's Pro plan costs $20 a month per deploying seat with 1 TB of data transfer included and overage from $0.15 a GB, and its Hobby plan is for personal, non-commercial use only. A separate app on Vercel costs more per seat but has none of the edge-runtime limits above.
How to run the decision on your own brief
Take the page list from your brief and mark each page with one of three labels.
- Static. Same HTML for everyone. Webflow page or CMS template.
- Interactive. Same HTML, behaviour in the browser: a calculator, a filter, a quiz. Webflow page with a code component or an embed.
- Request-aware. Different HTML depending on who asked: account state, permissions, server-side data with a secret. Next.js, either in Webflow Cloud on a path or on a separate host.
If the request-aware column is empty, build in Webflow. If it holds one to three paths, build in Webflow and add those paths as an app. If it holds most of the site, build in Next.js with a headless CMS and accept that every layout change becomes a developer task. Our guide to a website the marketing team can actually edit describes what that costs after launch.
When we scope a project this way, we would expect the request-aware column to be empty for most B2B marketing briefs we see, and to fill up for products where the marketing site and the logged-in app share a header.
What this means for choosing your stack
Choose by the request, not by the framework your team likes. A marketing site needs Next.js when its pages must know who is looking before the HTML is sent; it does not need Next.js to be fast, to use React components, to host an app later, to personalise for campaigns or to control SEO. For the cases in between, a Webflow site with code components or a Webflow Cloud app on one path keeps the marketing team in the Designer and the developers in a repository. If your brief has a request-aware column that is filling up, our web apps service page explains how we scope the Next.js side.
