Migrating a React SPA to SSR Without Breaking SEO

A React SPA rendered entirely client-side has a simple problem: until JavaScript executes, the HTML is essentially empty. Googlebot eventually runs the JS in a second crawl wave, but the delay is unpredictable, and most AI crawlers do not execute JavaScript at all. Anthropic explicitly documents that ClaudeBot does not render JavaScript. The Vercel and MERJ study on 500 million GPTBot fetches confirms that AI bots crawl heavily but do not render the client-side DOM. For a site that wants LLM citations in 2026, migrating to SSR or SSG is no longer aesthetic, it is existential. This guide covers the migration on code, redirects, JSON-LD and monitoring without breaking existing SEO.

Why a React SPA is invisible to half the AI crawlers

A standard React SPA serves a near-empty HTML containing a root div and a JavaScript bundle. Content only exists after JS runs in the browser. Googlebot does execute JS, but with delay and budget limits. Most AI crawlers do not execute it at all.

Anthropic's public documentation states that ClaudeBot does not render JavaScript. OpenAI documents that GPTBot crawls the initially served HTML. The Vercel and MERJ study on 500 million GPTBot fetches shows massive AI crawl volume, all on raw HTML. Conclusion: if your SPA has no SSR, you are invisible to Claude and severely under-represented in ChatGPT.

The typical pattern observed on migrated SPAs: stable organic traffic during the first few weeks, then a gradual rise in brand mentions inside LLM responses as AI crawlers re-process newly server-rendered URLs. The lag is real, conditioned on each bot's re-crawl cycle.

Audit current rendering before any migration

Before touching any code, measure what crawlers actually see. Rule: if curl does not return your main content, no AI crawler will see it either.

Run three diagnostic commands. First, curl -A "GPTBot" https://yoursite.com/target-page to see exactly what GPTBot receives. Second, view-source: in Chrome to compare with the post-JS rendered DOM. Third, Google's Mobile-Friendly test or Rich Results Test, which shows the HTML after Googlebot rendering.

Then measure the ratio of textual content present in the initial HTML versus the final DOM. Below 20%, you are running a pure SPA that LLMs cannot index. Between 20 and 60%, you likely have partial misconfigured SSR. Above 80%, your infrastructure is already mostly SSR and migration becomes polish work.

Choosing between Next.js, Remix, Astro and custom framework

Target framework choice depends on existing React code volume and how much client-side logic you must preserve. Three options dominate in 2026: Next.js App Router for complex React apps, Remix for forms and data mutations, Astro for mostly static sites with React islands.

Next.js App Router (versions 15+) offers the best benefit-to-effort ratio when migrating an existing React SPA: you keep components, you add the "use client" directive where state is needed, and the rest becomes server-rendered Server Components. The official Next.js docs detail incremental migration strategy from Create React App or Vite.

Remix (now React Router v7) is more opinionated with its data loader/action model and often forces an API call refactor. Astro is ideal if your SPA is actually a content site in disguise: portfolio, blog, documentation, marketing. For a real SaaS app with a dashboard, Astro is undersized.

The ScoreGeo methodology recommends Next.js in roughly 70% of SPA to SSR migration cases encountered in GEO accompaniment engagements. The reason is pragmatic: the Server Component / Client Component split allows route-by-route migration without a full rewrite.

Migrate route by route, prioritizing organic traffic

A big-bang migration of a production SPA is the worst possible choice. Safe method: migrate route by route, starting with pages that drive organic traffic and AI citability.

Step 1: export the URL list ordered by 90-day organic traffic from Search Console. Step 2: identify the top 20 pages, which typically concentrate 60 to 80% of traffic. Step 3: migrate those 20 pages first to the new SSR stack. Step 4: keep the legacy SPA for the rest during transition. Step 5: use an application proxy or edge middleware to route by path to the old or new stack.

This approach limits risk: if a migrated SSR route breaks, it is isolated and rolls back fast. On sites accompanied through a full implementation, phase 1 systematically targets the 20 priority URLs, with milestones validated over 2 to 3 weeks before expanding scope. To frame this prioritization for your case, the [GEO accompaniment sprint](/accompagnement#form-sprint_geo) starts with that route audit.

Handle 301 redirects without losing SEO equity

The number one risk of a SPA to SSR migration is not rendering, it is URL structure change. If your legacy routes were hash-based (/#/products/123) or query-param based, and your new routes use clean paths (/products/123), you lose 100% of backlinks pointing to the old URLs unless you redirect.

Three non-negotiable rules. First rule: every old URL must return a 301 status to its new equivalent, never 302 or soft 404. Second rule: hash-routed URLs (/#/path) cannot be redirected server-side because the fragment is never sent to the server. You need an SSR route serving minimal HTML with a JS redirect script, or ideally you should have migrated to canonical URLs long ago. Third rule: keep both old and new sitemap.xml live for at least 90 days to signal the redirect map to Google.

The Ahrefs study published in March 2026 on 1885 tested pages shows that pages with structured JSON-LD and clean redirects are cited 2.3 times more often by LLMs than equivalent pages without structured data. Stable URL structure is a trust signal for AI crawlers as much as for Google.

Inject server-side JSON-LD and answer-first formatting

SSR is useless if you don't take the opportunity to optimize structure for LLMs. A SPA to SSR migration is the unique chance to rewrite served HTML in answer-first format and inject clean server-side JSON-LD.

On every critical page, apply this pattern: an <h1> that poses the question, a 50 to 130 word paragraph immediately below answering directly, then development in h2 subsections each opening with a standalone answer. This inverted pyramid format is cited verbatim in the GEO paper by Princeton, Allen Institute and Georgia Tech published in November 2023.

For JSON-LD, inject at minimum the Article, Organization, BreadcrumbList and FAQPage schemas when relevant. Next.js App Router lets you generate JSON-LD directly inside Server Components, guaranteeing presence in the initial HTML served to AI crawlers. This is exactly what the JSON-LD score measures in the ScoreGeo methodology.

Monitor AI crawl and organic traffic over 4 to 8 weeks

A SPA to SSR migration is not validated in a week. You need 4 to 8 weeks of monitoring to confirm SEO has not regressed and AI crawlers are seeing the new content.

Three metrics to track. First, the crawl rate of GPTBot, ClaudeBot, OAI-SearchBot and Googlebot in server logs. You must see these user-agents hitting migrated URLs at a rate comparable to pre-migration, ideally higher. Second, organic Google traffic per URL via Search Console: a drop above 15% on a strategic URL lasting more than 21 days is a red flag. Third, brand mentions inside ChatGPT, Claude, Perplexity and Gemini responses on your target queries, measured manually or via a tracking tool.

Sistrix measured in April 2026 that 58% of Google queries in France trigger an AI Overview. That means half of your future organic traffic depends on AI citability, not just classic SEO ranking. Migrating to SSR without optimizing for LLMs is doing only half the work. For a full methodological framework, check the ScoreGeo methodology and the recurring GEO mistakes on migrated React apps.

Frequently asked questions