Introduction: A marketing site isn't a product — don't reuse its frontend

Many SaaS teams ask the same question at kickoff: "Can the marketing site and the product share one codebase?" The answer is yes — but "can share" doesn't mean "should share."

A marketing site serves a business purpose: it must get indexed by search engines, communicate instantly, and be forwardable in group chats. An SPA (single-page application), by contrast, is a frontend form tailored to the logged-in product: interaction-heavy, stateful, and unconcerned with SEO. Wrapping a marketing site inside an SPA shell is like dressing a salesperson in firefighter gear — it fits, but it falls apart the moment the real work begins.

This article breaks down four reasons a SaaS website shouldn't be built as an SPA.

1. SEO: SPA's two-wave rendering keeps your content out of the index

The biggest SPA problem isn't whether search engines can index it — it's how long indexing takes.

Google uses two-wave indexing: wave one crawls the raw HTML your server returns, and wave two queues the page for a headless-browser pass that executes JavaScript and re-fetches content. The trouble is —

  • Your SPA homepage often returns little more than an empty <div id="root"></div>, so wave one finds no body content;
  • Real content waits for wave two, and that render queue can back up for hours, days, or even weeks;
  • Googlebot has a rendering-timeout budget; dense pages may be discarded mid-render;
  • Large numbers of pages end up "Crawled – currently not indexed."

The result: the product descriptions, pricing logic, and help docs you carefully wrote have almost no presence in the eyes of search engines. If your product data or user reviews load via async API calls, crawlers may never see them at all.

Worse, many SPAs use hash routing (#/pricing), squashing the whole site into a single URL — so crawlers treat your entire catalog as "one page." And every page needs its own HTTP status and canonical tag to be parsed correctly, which SPAs don't provide by default.

Takeaway: Search engines prioritize pages where content lives in the HTML and JS is merely progressive enhancement. An SPA hard-binds content to JavaScript, effectively raising a barrier to SEO — while your competitor's SSR page enters the index in a day, you wait a week.

2. Performance: Core Web Vitals and the "white-screen tax" on first render

A homepage's first impression decides conversions, yet an SPA buries the cleanest content behind the heaviest technology.

Client-side rendering (CSR) works like this: the browser gets a nearly empty HTML → downloads a JS bundle of hundreds of kilobytes → parses and executes it → then paints text, images, and buttons. On mobile, this serial waterfall produces a visible blank white screen.

Industry data points:

  • "Hello World" builds in mainstream frameworks ship well over 200KB of JS (Next.js ~248KB, Remix ~228KB, Nuxt ~191KB) — and that's an empty project; the bigger the product, the bigger the bundle;
  • Real-world tests show a large SPA may not paint until the JS bundle is fully parsed, with white-screen times running to several seconds or more;
  • Google itself acknowledges that MPAs have a structural advantage on Core Web Vitals — full-page navigations hit more cached sub-resources, improving the 75th-percentile distribution used for metrics;
  • SPA hydration blocks the main thread, so visitors see a page that "looks loaded" but doesn't respond — precisely the scenario penalized by INP/TTI.

Takeaway: Of the three conversion-critical metrics — LCP (largest contentful paint), CLS (layout shift), and INP (interaction delay) — SPA is a disadvantage on all three by default. And your homepage is the first place a prospect ever meets your brand. Leave them staring at a white screen for three seconds and they won't wait to sign up.

3. Social sharing: links look "unclaimed" on WeChat, LinkedIn, and Slack

A sizable share of marketing traffic comes from social forwarding. When you send your product page to a client, drop it in a group, or post it to a feed, the thumbnail, title, and description visitors see are your brand's storefront.

The problem: social crawlers (WeChat, LinkedIn, X, Slack, WhatsApp) largely don't execute JavaScript. They only read the HTML returned by the first request. An SPA returns an empty page with no og:title, og:image, or og:description, so —

  • The share renders as a blank or placeholder image with a misleading title like "React App";
  • No thumbnail, no summary — click-through rates collapse;
  • Even if you painstakingly add Open Graph tags to an SPA, they fail unless they're in the initial HTML response.

Takeaway: A marketing site exists to be shared. If sharing it produces a blank card, it's like your sales team posting an empty ad. An SSR/SSG page, by contrast, gives social crawlers everything on the first fetch — thumbnail, title, description — every time.

4. Conversion and perception: every slow second is money

All of the above eventually lands on one word — conversion.

  • A 1-second load delay cuts conversion by roughly 7%;
  • A 100ms lag can cost about 1% of revenue;
  • 53% of mobile users abandon a page that takes over 3 seconds to load;
  • Monolithic JS bundles over 2MB routinely cause multi-second first loads on mobile.

For a SaaS marketing site, every second maps to real sign-ups, trials, and deals. Weigh the trade-off: is the development time you save with an SPA really worth the exposure and conversions you lose? Usually, it isn't.

5. What you should actually build: a hybrid SSR/SSG + SPA architecture

The fix isn't abandoning frontend frameworks — it's using the right tool in the right place. The mainstream, mature answer is a hybrid architecture:

Area Recommended approach Why
Public pages (homepage, pricing, blog, docs) SSR or SSG (pre-rendered HTML) Content gets indexed, loads fast, social previews work
Authenticated product area (dashboard at app.copyark.com) SPA / client components Interaction-heavy, no SEO needed; performance only for logged-in users

Framework docs endorse this exact split: Next.js's official docs state that SSG/SSR are the best choices "for SEO," while CSR suits pages that "don't need to be in a search-engine index." Often you can even keep it in one Next.js project — /pricing and /blog server-rendered, /app authenticated and client-rendered. Almost no extra code, yet the SEO and performance problems disappear.

Conclusion: a facade deserves facade-grade architecture

In one line: your SaaS website isn't just a website — it's your sales funnel. The place where you build your funnel needs to be seen, understood instantly, and shareable. An SPA saves you some development hours today but costs you long-term search rankings, failing Core Web Vitals, and blank social cards — exactly the levers that decide early-stage SaaS growth.

Reserve SPA for the logged-in product, and give SSR/SSG to your facade. That seemingly "pedantic" technical choice is often one of the best technology investments a SaaS team makes.