By Mehdi HassanShould a SaaS marketing site live separately from the product app?
Yes, for most SaaS companies the marketing site should live separately from the product app. The two have different jobs, different editors and different rules for search, and forcing them into one codebase slows both down.
The marketing site needs to be indexed, fast, and editable by marketers without a deploy. The app needs authentication, frequent releases and no search indexing at all. When they share one codebase, every landing page waits behind product releases and every product release risks breaking a landing page.
Separating them doesn't mean two brands or two domains. It means two systems behind one domain name, routed either by subdomain or by path. If you're moving the marketing side into a visual builder as part of this, our hub on moving from code to Framer or Webflow covers the full migration.
Subdomain vs subfolder: what are the options?
There are three common setups: app on a subdomain, app on a path behind a proxy, and marketing content on a path behind a proxy. Each one trades simplicity against keeping everything under one hostname.
Setup | Marketing | App | Complexity | Best for |
|---|---|---|---|---|
App subdomain | example.com | app.example.com | Low | Most SaaS startups |
App path via proxy | example.com | example.com/app | Medium to high | Existing deep links, shared sessions |
Blog path via proxy | example.com/blog on a separate CMS | app.example.com | Medium | Keeping blog under the root |
All in one codebase | example.com | example.com/app | Low at first, high later | Very early teams only |
The subdomain setup needs only DNS records: the root points to your marketing host, and the app subdomain points to your app host. The proxy setups need one system in front that inspects each request path and forwards it to the right origin.
How does each setup affect SEO?
For SEO, what matters is that marketing content lives on one hostname and that app pages stay out of the index. Whether the app is on a subdomain or a path barely affects marketing rankings, because the app shouldn't be indexed anyway.
The subdomain vs subfolder debate matters more for content. Google has said it can handle both, but many SEO practitioners prefer keeping the blog and resources in a subfolder of the main domain so links and authority build in one place. That's why a blog on blog.example.com is the setup we most often recommend changing, and why our guide to subdomain to subfolder migration exists.
- Marketing pages: on the root domain, indexed, in the sitemap.
- Blog and resources: on the root domain or a subfolder, linked from marketing pages. Our guide to topic clusters and pillar pages explains why that internal linking matters.
- App pages: noindex, behind login, excluded from the sitemap.
- Login and sign-up pages: fine to index for branded searches, but keep them lightweight.
How do you set up app.example.com?
You set up app.example.com by pointing the root domain at your marketing host and adding a DNS record for the app subdomain that points at your app host. It's the setup with the fewest failure points.
Point the root domain at marketing
Follow your marketing platform's custom domain steps, for example Framer's or Webflow's domain settings, and set the www redirect.
Add the app subdomain
Create a CNAME or A record for app pointing to your app host, such as Vercel, and add the domain in the host's dashboard.
Update auth settings
Change allowed callback URLs, cookie domains and single sign-on settings to the app subdomain.
Redirect old app paths
If the app used to live at example.com/app or /dashboard, add 301s from those paths to the subdomain.
Block app indexing
Add a noindex header or meta tag to app pages, and keep them out of the marketing sitemap.
Connect analytics
Use one analytics property with cross-subdomain tracking so sign-ups from marketing pages are attributed.
How do you serve /app and the marketing site on one domain?
You serve both on one domain by putting a reverse proxy in front: it reads the path of each request and forwards it to either the app or the marketing origin. The proxy can be your app framework, your host's routing rules, or an edge worker.
Pattern 1: Next.js app in front, marketing behind
Next.js rewrites can run in a fallback group, which is checked only after Next.js has tried its own pages and routes. Add one rewrite there with a catch-all source and your marketing site's published address as the destination.
Result: /app, /login and /api are served by Next.js, and any other path, such as /pricing or /blog/post-name, is fetched from Framer or Webflow and returned under your domain. Our Next.js to Framer migration guide covers this in more detail.
Pattern 2: an edge worker routes by path
A worker at your DNS provider, for example a Cloudflare Worker, receives every request. It checks the path: anything starting with /app or /api goes to the app origin, and everything else goes to the marketing origin.
This keeps both platforms independent, because neither one has to know about the other. You maintain the worker, so keep its rules short and documented, and set cache rules separately for app and marketing paths.
Before relying on a proxy, check that the marketing platform supports being served this way on your plan. Support varies, and both Framer and Webflow document their custom domain options. If you need two builders on one domain, see our guide to running Webflow and Framer side by side.
What goes wrong with proxy setups?
Proxy setups usually go wrong on canonicals, caching, assets and cookies. They work well when someone owns them and poorly when they're set up once and forgotten.
Pros
- One hostname for everything, with no redirects for existing app links
- Blog authority stays on the root domain
- Each platform can still be deployed independently
- Can mix platforms page by page during a migration
Cons
- Canonical tags may point at the origin's own domain instead of yours
- Caching can serve stale marketing pages after publishing
- Asset paths can break if the origin uses relative URLs
- Another system to monitor, debug and pay for
Localized sites add another layer, because locale paths like /de must route consistently across both systems. If that applies to you, read moving a localized site to Framer before choosing a setup.
Which platform should run the marketing side?
Pick the marketing platform by who edits it. Framer or Webflow suit marketing teams, and Next.js with a headless CMS suits teams where engineers stay involved. The split works the same way with any of them.
Our comparison of Webflow, Framer, WordPress and Next.js for a marketing site covers the platform choice. If you keep marketing in code but want it separate from the app, a second Next.js project with a CMS like Payload is a common pattern; our notes on setting up Payload CMS for a marketing site explain how we run it.
