React SEO Without a Server-Side Rendering Migration

Server-side rendering computes HTML for each request. Static generation computes HTML for each route during a build and serves the resulting files. Both can give crawlers a complete response without waiting for client JavaScript. For a publication whose articles change at deploy time rather than per user, build-time rendering is often the smaller system.

The critical property is not the acronym. Request an article URL and inspect the response body before scripts execute. The title, description, canonical, robots directive, H1, paragraphs, links, and structured data should already be present. If the response contains only a root element and loading label, the page still depends on rendering regardless of how fast it appears in a local browser.

Define each canonical route with its title, H1, description, publication date, update date, content record, sitemap state, and related links. The router, metadata layer, static generator, sitemap, JSON-LD, and index page should all consume that registry or a derived view. Duplicated arrays eventually publish a route that the application knows but the sitemap does not—or a sitemap URL whose component no longer exists.

Build only publishable records. A draft should be absent rather than exposed as a thin page or hidden behind a noindex convention that leaks into internal links. Fail on duplicate paths, titles, descriptions, or H1s. Route inventory is content integrity, not merely routing configuration.

The strongest generator imports the article record and React component, renders that tree to static markup, and injects it into the built route file. A separate SEO template is cheaper initially but can diverge in headings, links, dates, or claim text. Shared rendering makes the static response an authored view, not a crawler-only shadow page.

If the client hydrates the markup, use a hydratable server API and deterministic output. If the static body is replaced on boot rather than hydrated, preserve focus and avoid a visible blank handoff. renderToStaticMarkup is appropriate when the output is intentionally not hydrated; React documents that its result cannot be hydrated. Choose deliberately and test the chosen lifecycle.

A static host needs rewrites or generated directories that resolve clean URLs to their corresponding index.html. Verify direct cold requests, not only in-app navigation. Missing routes should return 404, moved routes should return a real redirect, and canonical routes should return 200. Serving the app shell with 200 for every unknown URL creates soft-404 ambiguity.

Use ordinary anchors with href values for internal discovery even when a client router intercepts navigation. Keep canonical URLs in the initial head. Google can render JavaScript, but it still recommends pre-rendering or server-side rendering as a useful approach, and other crawlers may not execute the application at all.

For every generated route, parse the built HTML and assert canonical, title, description, robots, one H1, the substantive body, internal links, and matching JSON-LD. Start a production-like preview and crawl the public paths. Then inspect representative pages at desktop and mobile widths, with JavaScript disabled, at 200% zoom, and by keyboard.

Use Google’s URL Inspection evidence after deployment for selected production URLs, but do not wait for Google to discover structural mistakes. A local build can prove most publishing invariants immediately. The outcome is not “React is SEO friendly.” The outcome is a route set with complete, consistent responses and an explicit boundary for anything that still requires client execution.