How Tech Stack Choices Affect Your SEO Performance

Most SEO problems on a startup site trace back to one early decision: how the pages get rendered. By the time you notice the symptom — pages not appearing in the index, ranks plateauing, Core Web Vitals failing — the framework choice has already shaped what is hard to fix and what is easy. This post walks through the actual rendering options, what each one means for crawlability and performance, and where the common pitfalls are.

How Google sees your pages

Google crawls in two passes. The first pass fetches your raw HTML. The second pass, called rendering, runs the JavaScript and looks at what the page actually contains after JS executes. The two passes happen at different times — sometimes minutes apart, sometimes weeks.

The implication: anything important that only appears after JavaScript runs is not seen during the first pass. It might be seen later. It might be partially seen. It might be missed if the rendering queue is backed up. For pages where indexing speed matters — landing pages tied to a launch, blog posts you want crawled immediately — that delay is a real cost.

This is the foundation for why rendering strategy matters. Different stacks produce HTML at different points in the request lifecycle, and that timing is what Google's crawler ends up seeing.

The four rendering modes

Client-Side Rendering (CSR / SPA). The server returns a near-empty HTML shell with a JavaScript bundle. The browser downloads the bundle, executes it, fetches data, and only then renders the actual content. Tools: Create React App, plain Vue with vite, the typical jamstack-without-pre-rendering setup.

For Google: the first pass sees nothing. Indexing depends on rendering working correctly later. Even when it works, you wait days for new content to be picked up. For pages behind authentication this is fine — Google will not crawl them anyway. For marketing pages, blog posts, or landing pages, this is a self-inflicted SEO problem.

Server-Side Rendering (SSR). Each request hits the server, which runs the framework, fetches data, renders HTML, and returns it. The browser gets a fully populated page on the first paint. Tools: Next.js (default), Nuxt, SvelteKit, Remix.

For Google: the first crawl sees the full page. Indexing is fast. The cost is server compute and a more complex deployment story. For most marketing sites this is the right choice.

Static Site Generation (SSG). Pages are pre-built at deploy time into HTML files served from disk or CDN. Tools: Next.js (with static generation), Astro, Hugo, Jekyll, Eleventy.

For Google: the same as SSR from the crawler's perspective — full HTML on first request — but with much lower server cost and faster delivery. Best for content that does not change often: marketing pages, documentation, blog posts.

Incremental Static Regeneration (ISR). A hybrid. Pages are built statically, but each page can be marked to revalidate after a period. The first request after expiration serves the stale version while the framework rebuilds in the background. Subsequent requests get the fresh version. Tools: Next.js, Nuxt with similar features.

For Google: identical to static rendering, plus the ability to keep dynamic data reasonably fresh without a full rebuild. This is what most modern Next.js sites use for content that updates daily but does not need to be live-fresh.

Common framework choices and what they are best for

Next.js is the most flexible option in the React ecosystem. You can mix SSR, SSG, and ISR per route. Defaults are reasonable for SEO. Trade-off: complexity and an opinionated build pipeline.

Astro is built around content-heavy sites — blogs, documentation, marketing sites. Renders to static HTML by default, ships almost no JavaScript unless you opt in. Excellent Core Web Vitals out of the box.

SvelteKit offers SSR and static generation with smaller runtime overhead than React-based stacks.

Hugo and Jekyll are pure static site generators. No runtime JavaScript framework. Fastest possible delivery. Best for content sites that do not need much interactivity.

Nuxt is the Vue equivalent of Next.js. Same trade-offs apply.

Plain HTML and a CMS like WordPress. Often dismissed by indie makers, but for a content site that needs to rank in search, a well-tuned WordPress install with good caching outperforms a poorly-configured SPA every time.

Core Web Vitals and framework defaults

Google's Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — are direct ranking signals for the page experience. Framework choice affects each.

LCP is helped by static generation and CDN delivery. SPAs hurt LCP because the meaningful content does not appear until the JS bundle parses and the data fetches.

INP measures responsiveness. Heavy JS bundles increase INP because the main thread is busy parsing and executing during user interaction. Astro's "ship no JS by default" approach makes good INP cheap to achieve.

CLS is mostly a styling and image-handling concern, not a framework one, but frameworks that encourage explicit width and height on images (Next.js Image component, for example) make it easier to avoid layout shifts.

When a SPA is the right call

SPAs make sense for the part of the product that lives behind authentication. A dashboard does not need to rank in search. A real-time editor does not need crawler visibility. The mistake is using a SPA architecture for the marketing site that does need to rank.

The pragmatic split: marketing pages, blog, and documentation as SSR or static. Application pages as SPA. Most modern frameworks let you do this in one codebase.

A decision shortcut

If you are starting today and the site needs to rank: Next.js or Astro. Next.js if you have application pages mixed with content. Astro if it is purely content.

If you have an existing CSR site struggling to rank: the cheapest fix is often pre-rendering critical pages (Next.js static export, prerender.io, or a build script that crawls your own routes and saves the HTML). The hardest fix is the right one — migrating to SSR — but staged pre-rendering can buy time.

The framework decision is one of the few choices that is much harder to undo than to make. Picking the right one early saves a year of working around the wrong one.