We checked the homepages of 30 well-known SaaS companies on 29 October 2026. Of the 25 where the login link could be read, 15 send users to a separate host such as app., dashboard. or login., and at least 3 of the other 10 serve the login page from a visibly different stack than the homepage (Octo Agency check). The pattern is consistent: the marketing website and the product live apart, even when they share a domain.
This guide sets out why separation is the right default and how to wire the seams so visitors never notice. Sources are MDN, Google, the Next.js and Webflow docs, OWASP, HTTP Archive and two vendor surveys, read on 29 October 2026.
What a marketing website and a product have in common, and what they do not
They share a brand, a domain and often a header. A marketing website is a publishing system; a product is software that holds customer data. One repository means one release process and one security boundary for two very different jobs.
| Dimension | Marketing website | Product app |
|---|---|---|
| Main editor | Marketing team, daily | Engineers, through pull requests |
| Release rhythm | Many small publishes a week, no review gate | Planned releases with tests and code review |
| Content | Pages, CMS items, campaign variants | Screens driven by account data |
| Third-party scripts | Analytics, tags, chat, consent | As few as possible |
| Search engines | Every public page should be indexed | Nothing behind login should be indexed |
| Cost of a bad change | A broken page | Lost data or a breach |
| Right tool, in our view | A visual CMS such as Webflow | A framework such as Next.js |
Source: Octo Agency, compiled from the sources below; ownership data from Webflow 2026 State of the Website
We build marketing sites in Webflow and applications in Next.js, so we have a stake in this split. The argument below holds for any pair of tools, including two Next.js projects in separate repositories.
Reason one: the teams and their release cycles do not match
Webflow's 2026 State of the Website survey found 97% of marketing leaders and 94% of technical leaders saying their own team owns website strategy. It is a vendor survey, from a company that sells a visual site builder, but the tension it describes is familiar. When the marketing site lives inside the product repository, engineering owns it by default, because every change goes through engineering's process.
That process is correct for the product, but applied to a headline change it turns a ten-minute job into a ticket. ButterCMS surveyed more than 600 marketing and growth professionals in 2025 and found 81% rely on developers for basic updates, with 45% saying changes take multiple days. ButterCMS sells a headless CMS, so read these as vendor figures.
Separate codebases let marketing publish without a deploy and engineering ship without campaign pages in the build. Our guide to a website the marketing team can actually edit covers the CMS rules that keep the marketing side self-serve after launch.
Reason two: marketing scripts do not belong next to customer data
Marketing pages collect third-party code. The HTTP Archive Web Almanac 2024 found about 92% of pages use at least one third party, with a median of 27 third parties on the top million sites and 66 on the top thousand. Consent tools, video players and customer-success widgets led the categories it could identify.
OWASP's cheat sheet on third-party JavaScript explains that a tag runs with the page's privileges and can read the DOM, including form inputs, and that a tag manager can run custom code edited outside any release process. It calls the compromise of a third party's server the single greatest risk.
On a marketing page the worst case is a leaked demo-form email. In an application, the same script could read anything the logged-in user can see.
Origins do the isolation for you. MDN's same-origin policy guide defines an origin as scheme, host and port, and shows that a different subdomain is a different origin. Web Storage and IndexedDB are separated by origin, so a script on www.example.com cannot read what app.example.com stores in the browser. Put the app on its own host and that boundary exists without anyone configuring it.
What 30 SaaS companies actually do
We fetched 30 SaaS homepages on 29 October 2026, read the platform from HTML markers and followed the navigation's login link. Five could not be read: two blocked automated requests and three had no login link in the HTML.
| Pattern | Count | Examples |
|---|---|---|
| App on its own subdomain | 15 | Stripe (dashboard.), Asana, HubSpot, Ramp, Notion (app.) |
| Login on the marketing host, different stack from the homepage | 3 | Linear, Figma, Airtable |
| Login on the marketing host, same visible stack or unclear | 7 | Vercel, Zendesk, Calendly, Webflow, Lattice, Dropbox, Slack |
| Not readable | 5 | Canva, Gusto, Miro, Loom, DocuSign |
Source: Octo Agency check of 30 SaaS homepages, 29 October 2026
Two cautions. A login page on the marketing host does not mean one codebase, because a proxy can route /login to a separate application. And of the 30 homepages, 19 carried Next.js markers and 3 carried Webflow markers (Monday.com, Lattice and Webflow itself), but the stack says nothing about whether repositories are shared. Our B2B SaaS CMS statistics cover platform share across a larger set.
Subdomain or subpath: how to choose
App on a subdomain. The marketing website runs at the root domain, the product at app.example.com, each with its own hosting and security headers. It is the most common pattern in our check.
App under a path, routed by a proxy. The visitor sees example.com/app, but a proxy or rewrite sends that path to a separate application. The Next.js multi-zones guide describes this: separate applications on one domain, each deployed independently, at the cost of a full page reload when moving between zones. Webflow Cloud does a version of it, hosting Next.js, Astro or Vite apps under a path of a Webflow site. Our upcoming guide, When a Marketing Site Genuinely Needs Next.js, covers its limits.
Search does not decide it. John Mueller of Google said in 2018 that Google sees subdomains and subdirectories much the same, while personally preferring to keep related content together, as Search Engine Journal reported. A product behind login should not rank anyway, so a subdomain costs the marketing site nothing.
The seams: what to wire so visitors never notice
| Seam | What goes wrong | How to handle it |
|---|---|---|
| Login state | Logged-in users still see "Sign up" | A non-sensitive hint cookie with Domain=example.com |
| Analytics | App-to-site visits show as self-referrals | One GA4 property, one cookie domain, referral exclusions |
| Search indexing | App or staging pages appear in search | Robots.txt and noindex on each non-marketing host |
| Design | Buttons and type drift apart | One set of design tokens exported to both |
| Navigation | Cross-links break after a slug change | Absolute links kept in one shared list |
Source: MDN cookies guide; Google Analytics Help, cross-domain measurement; Google Search Central, robots.txt introduction; Next.js multi-zones guide
Login state. MDN's cookie guide explains that a cookie set with Domain=example.com is available on that domain and its subdomains, while a cookie set without Domain stays on the host that set it. So keep the session cookie host-only on the app, and share a separate flag with no secrets that only says "this browser has an account".
Analytics. Google's help page on cross-domain measurement recommends the setup for subdomains: tag every page, make sure subdomains share the same cookie domain, and add them to the referral exclusion list. Our post on Webflow for B2B SaaS covers where a Webflow site stops and the app takes over.
Search indexing. Google Search Central states that a robots.txt file applies only to the host, protocol and port where it is served, and that a robots.txt on one subdomain is not valid for another. Give the app host its own file and noindex anything that renders without a login.
Design. Keep one source for colours, type and spacing and export it to both sides. A component library shared between marketing and product is a real reason to keep the marketing website in code; we list it among the five cases in Webflow or Next.js for a marketing site.
When one codebase is the right answer
The marketing pages read the logged-in account. If every page renders the visitor's plan or usage on the server, the two are one surface.
Engineering is the only editor. If no marketer will open an editor, a visual CMS loses its main advantage.
The company is a handful of people before launch. A landing page inside the app repository is fine for a waitlist. We would plan the split before the first marketing hire starts.
Outside those cases, a shared codebase usually exists because nobody decided otherwise.
What this means for your marketing website
Treat the marketing website and the product as two systems with two owners, joined on purpose. Put the app on its own subdomain unless there is a strong reason for a path, and wire the five seams in the first week of the build, not after launch. In our four-week marketing-site process this is a Week 1 decision, because the domain plan affects the tracking map and the page templates. Our marketing websites service page explains how we scope a marketing site that sits alongside an existing product.
