Webflow as the Marketing Front for Next.js

The split that works is simple. Webflow owns every page a stranger can reach. Next.js owns every page that needs a login. The marketing site, the blog, the pricing page, the careers page and the legal pages live in Webflow so that whoever writes them can ship them without a deploy. The product, the dashboard, the onboarding flow and anything that reads your database live in Next.js.

If you have already decided to run both, the interesting questions are not which one is better. They are where exactly the line goes, how you serve both from one domain, and what quietly breaks in month two. Those are the three things this covers.

Where the line goes, route by route

Webflow takes the root, the marketing pages under it, and the content collections. So the home page, the product and solution pages, pricing, about, careers, the blog and the changelog. These change often, they are written by people who are not engineers, and none of them need to know who is looking at them.

Next.js takes everything behind the login and everything that has to be generated per user. So the app itself, account and billing screens, invite and onboarding flows, share links, embed views and any page that renders from your own data. If a page needs a session to be correct, it is a Next.js page.

Two routes sit in the middle and cause most of the arguments. Documentation usually belongs wherever your engineers will actually keep it current, which is normally the code repository rather than a CMS. Signup and login pages belong in Next.js even though they are unauthenticated, because they touch auth state and you do not want a marketing edit to break the front door.

Serving both from one domain

You want one domain. Splitting the marketing site onto its own subdomain is easier to set up and costs you the thing you set all this up for, which is having the blog pass authority to the pages that sell.

There are two normal ways to do it. The first is to put Next.js at the domain and proxy the Webflow paths to it. Next.js supports rewrites in its config, so a request for a marketing path can be fetched from the Webflow site and returned under your own domain. The second is to do the same routing one layer earlier at the CDN, with a worker or edge function that looks at the path and sends it to one origin or the other.

The edge approach is usually the calmer one. It keeps the routing table in a single small file that neither the Webflow editor nor a Next.js deploy can accidentally change, and it does not make every marketing page request travel through your application server. Whichever you choose, write the route list down somewhere both teams can see it. This is the piece that rots.

Four things that break, and how to catch them

The first is the sitemap. Both platforms generate their own and both want to live at the same address. Only one can. Pick a sitemap index at the root that points to each system's sitemap, or proxy one of them to a second path and list both. If you skip this, half your pages stop being announced and nobody notices for a quarter.

The second is analytics. Two systems means two chances to install a tracking snippet slightly differently, and when that happens a visitor who reads the blog and then signs up shows up as two sessions. Install the same snippet, with the same configuration and the same cookie domain, on both sides. Then actually test it by walking the path yourself in a fresh browser.

The third is the 404. Requests that match no rule have to land somewhere deliberate. Decide which system owns unmatched paths and make sure the response is a real 404 status, not a page that looks like a 404 while returning a 200. Search engines treat those differently, and the soft version quietly fills your index with rubbish.

The fourth is the navigation bar. There are now two of them, in two systems, and they will drift. The header on the marketing site will gain a link that the app header does not have, and a logged in user will click back to the marketing site and see a menu that behaves differently. Pick one source of truth and rebuild the other to match it whenever it changes, or accept the drift on purpose and make the two headers visibly different so nobody expects them to match.

Who owns what after launch

Write this down on the day you launch, not the day it goes wrong. Marketing owns Webflow content and can publish without asking anyone. Engineering owns the routing rules, the proxy, and everything in Next.js. Changes to the route list are a shared decision because a new marketing path that collides with an app path takes the app path down.

The rule that saves the most trouble is this. Nobody adds a top level path without checking the route list first. A marketing page at a path the app already uses is the single most common way this setup fails, and it fails in production, on a Friday.

When not to do this

Skip it if your marketing site is five pages that change twice a year. The whole point of Webflow here is letting non engineers publish, and if nobody is waiting to publish, you have added a second system and a proxy for nothing. Keep the pages in Next.js and move on.

Skip it too if your marketing pages need live product data, like a public directory built from your own records or pricing that changes per visitor. Webflow is not the place for that, and the workarounds are worse than just building the page in Next.js.

If you are still deciding between the two rather than running both, the comparison of Next.js and Webflow for tech companies covers that choice instead.

The short version

Public pages in Webflow, authenticated pages in Next.js, one domain, routing handled at the edge, and a written route list that both teams check before adding a path. Get the sitemap and analytics right in the first week and the rest is maintenance.

If you would rather hand the whole arrangement to someone who has built it before, we keep a rated list of Next.js development agencies working with AI devtools, with what each publishes on price.

We set this split up for AI and SaaS teams as part of a fixed scope website build, usually three to four weeks including the routing and the handover document. If you want a second opinion on where your line should go, book a 30 minute call.