- Short answer: keep the marketing site and the app as separate deployable units, but serve them under one domain. Share a design system, not a build.
- Speed and SEO: the two are scored on different pages and different users, so a heavy app bundle should never be what your landing pages ship.
- Cost: one codebase is cheaper in the first months. Two stacks cost more to run, but they stop marketing and engineering from blocking each other.
Should your marketing site and web app live in the same codebase? Usually not, if "same codebase" means one build, one deploy and one set of dependencies. The two have different jobs: the marketing site needs to load fast and be edited by non-engineers, while the app needs state, auth and reliability. Early on, a single codebase can still be the right call. The line to draw is between the code and the URL: you can split the code and still give visitors one domain.
Below is how the choice plays out for speed, SEO and cost, and a few setups that work in practice.
What "same codebase" actually means
People use the phrase for three different things, and mixing them up makes the debate confusing.
- One app, one deploy. Marketing pages and the product are routes in the same project, for example one Next.js app.
- One repo, separate apps. A monorepo holds a marketing app and a product app, each built and deployed on its own, sharing components.
- Separate stacks. The marketing site runs on a CMS or site builder, and the app is its own project, possibly on a different framework and host.
The second option is often the sweet spot. You get shared code without shared release risk.
Speed: the two are measured separately
Google's "good" Core Web Vitals thresholds are an LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less. A page passes only if it hits those targets at the 75th percentile for all three, according to web.dev. That means a marketing site and an app behind login are scored separately, on different pages and different real users.
This matters for the architecture. If your landing pages ship the same JavaScript as your dashboard, they carry code that anonymous visitors never use.
Speed is also hard to get right by default. The Web Almanac 2025 found good Core Web Vitals on 48% of mobile sites and 56% of desktop sites, as reported by SiteQwality. On mobile, LCP is the weakest metric: 62% of sites pass it, against 77% for INP and 81% for CLS, per corewebvitals.io.
The same Almanac data shows that 45% of mobile home pages had good Core Web Vitals, against 56% of secondary pages. The home page is usually the most script-heavy, so it is not a stand-in for the whole site.
If you go with a separate stack, the platform matters too. In the Web Almanac 2025 CMS chapter, Duda had the highest mobile Core Web Vitals pass rate at 85% and Wix 74%. WordPress was among the lowest at 45%. These figures come via Optimised Website. They are platform-wide averages, not a guarantee for any one site.
Where a shared codebase hurts speed
- Marketing pages inherit the app's providers, global state and large dependencies.
- A single build gets slower as the product grows, so a typo fix on the pricing page waits behind a full app deploy.
- A product release that breaks the build also blocks marketing changes.
Where a shared codebase helps
With a framework like Next.js, a single project can still be fast if you are disciplined. Incremental Static Regeneration lets you use static generation per page without rebuilding the whole site. On-demand revalidation can purge a specific page when headless CMS content is created or updated. That lets marketers update a Next.js marketing site without slowing page loads. The catch is that you have to keep the marketing routes light, and that is easy to let slip over time.
SEO: domain structure matters more than repo structure
Google does not see your repo. It sees URLs, HTML, links and performance. So the SEO question is really about how you expose the two parts, not how you store them.
Google's Search Central documentation says to choose whichever structure is easiest to organise and manage. For indexing and ranking, Google has no preference between subfolders and subdomains, as Search Engine Journal reports.
There are practical differences, though. Subdomains must be verified separately in Search Console, and subdirectories don't need this. Search Engine Journal infers that it is safe to assume Google treats a subdomain as a separate website. That is the publication's inference, not a Google statement. Still, separate measurement and reporting for app. versus www. is a real cost for a small team.
A secondary report of John Mueller's advice is to use a subdomain only when it offers something genuinely different, such as a different audience or brand, per Quillly. For most SaaS products, the app has the same brand and audience as the marketing site, so there is little reason to split for SEO alone.
Also keep expectations realistic. Google says Core Web Vitals are used by its ranking systems, but it warns that good reports don't guarantee top rankings, because page experience involves more than the scores. See Google's page experience guidance.
One domain, two codebases
You do not have to choose between a clean split and a clean URL. Next.js Multi Zones let you merge two apps, for example one serving /blog and one serving all other pages. Customers browse a single URL while you develop and deploy each app independently.
The mechanics are simple. One app routes some paths to the other apps using rewrites in next.config.js, and all URL paths must be unique across the zones on a domain, as the Next.js zones example explains.
A common layout looks like this:
example.com/,/pricing,/blog: marketing app or CMS-backed site.example.com/apporapp.example.com: the product.
If you want the reporting simplicity of a single site, use the path. If you prefer a clearer separation between the two, a subdomain works, and the cost is the extra Search Console property.
Cost: cheap now versus cheap later
Cost is where the single codebase wins at the start and loses later.
One codebase means one repo, one pipeline, one host bill and one set of engineers who know everything. For a small team building an MVP, that is hard to beat. The cost shows up when marketing needs frequent changes and every change goes through an engineer.
Separate stacks mean two pipelines and two sets of dependencies to patch. In return, marketing can move without a developer, and the app team can ship without worrying about the homepage.
Hosting and tooling prices are worth checking before you commit. Webflow's May 2026 pricing update raised the CMS plan to $25/month billed yearly or $39 monthly, and raised CMS items from 2,000 to 20,000. The Team plan is $2,500 a month on an annual contract. Those figures come from Webflow's help centre and a third-party summary, so verify the Team price on webflow.com/pricing.
On the code side, Vercel Hobby is non-commercial only. Pro is $20/user/month, includes a $20 usage credit, allows commercial use, and comes with 1TB of bandwidth. Pro charges per deploying seat, and viewer seats are free. These come from third-party trackers (ComparEdge and CheckThat.ai), so confirm them on vercel.com/pricing before you budget.
Beyond plan prices, weigh the time people spend waiting on each other. If a headline change has to queue behind engineering work, that delay is part of the real cost of a shared codebase.
Comparing the three setups
| Setup | Speed | SEO | Cost | Best for |
|---|---|---|---|---|
| One app, one deploy | Fine if marketing routes stay light; easy to degrade | Simple: one domain, one property | Lowest at the start | MVPs, small teams, few marketing changes |
| Monorepo, separate apps, one domain | Marketing ships only what it needs | Simple if served on paths | Moderate: two pipelines, shared components | Growing products with an active marketing team |
| Separate stacks (CMS or builder plus app) | Depends on the platform and how it is configured | A subdomain needs its own Search Console setup | Higher setup, lower per-edit cost | Content-heavy sites, non-technical editors |
How to decide
- Who edits the marketing site? If it is non-engineers, give them a CMS and keep it away from the app's release cycle.
- How often does each side change? A product that ships often and a site that changes rarely should not share a deploy.
- How big is the app bundle? If it is heavy, keep it off public pages.
- What is your team size? With a very small team, one codebase is a reasonable trade. Plan the split for when it starts to hurt.
- Do you need one URL? If yes, use paths with rewrites rather than merging the code.
A sensible default: start with one repo and clear boundaries between marketing routes and app routes. Keep shared UI in a package. When the release friction shows up, split the deploys without changing a single URL.
What we see in practice
At Authect, the right answer depends on what the product is. Luka Capital is a brand-led site, so it is mostly a marketing build. Xolt is a data product, an app first, where the dashboard matters more than the public pages. If you are scoping a build and not sure which shape fits, our website development page covers how we approach the public side, and the project planner can help you outline what you need.
FAQ
Does a separate marketing site hurt SEO?
Not by itself. Google has no preference between subfolders and subdomains for indexing and ranking. The practical issue is measurement: a subdomain needs its own Search Console verification, while a subdirectory does not. If you want the simplest setup, serve both under one domain using paths.
Should I put my app on a subdomain?
It is allowed, and it can make sense if you want a clearer split between the two. Just expect separate reporting for app. and www.. If the app shares the marketing site's brand and audience, there is little SEO reason to split it off.
Can I keep one URL but use two codebases?
Yes. In Next.js, Multi Zones let two apps share one domain, each deployed independently, using rewrites. All URL paths must be unique across zones.
Do Core Web Vitals apply to my app behind login?
Core Web Vitals are scored on real users, and a marketing site and an app behind login are scored separately, on different pages. Keep in mind Google's own caution: good scores don't guarantee top rankings.
