React SEO Without a Rewrite: HTML, Canonicals and Real 404s

Open a direct response for a subpage and inspect its title, canonical and readable body. If every route returns the homepage’s metadata and an empty root, the server has not delivered a page-specific document. A browser may later correct some of that after JavaScript runs, but not every reader or crawler executes that path.

Server rendering and build-time prerendering address this in different ways. One renders when requested; the other emits a document during the build. Either can fit a mostly editorial site. The important question is whether the content, status and metadata are correct for that URL before relying on client-side navigation.

A developer journal with stable articles often does not need a complete framework migration to deliver useful HTML. The current portfolio already has a server-rendering entry and static fallback generation. The other workspace records describe build-time page generation and capture strategies for similarly stable public content.

That does not make prerendering universally sufficient. Frequently changing personalised content, authentication and server actions have different requirements. Keep private application routes separate from public editorial pages. Rendering a public article early should not accidentally include a signed-in user’s data in a static output directory.

A canonical tag expresses the preferred URL for a document. Internal links, the sitemap and social metadata should normally point to that same final form. If the page says one address, the navigation points to a redirecting variant and the sitemap lists a third, the site has created unnecessary ambiguity.

A self-referencing canonical also needs to match the actual page. Sending every recipe or article to the homepage canonical is not a harmless default. Conversely, a canonical does not replace a redirect when an old URL has genuinely moved. The purpose of each mechanism should be clear before adding more rules.

A page that contains useful prerendered HTML can still misbehave when React attaches if the client expects a different initial tree. Rotating text, current-time labels, random content and viewport-triggered animations are common sources of mismatch. A capture script should not merely freeze a flattering screenshot; it should preserve a document the application can reuse.

The Aptixlabs implementation records include attention to text-node boundaries and predictable capture state. The general lesson is to verify both no-JavaScript delivery and hydrated behaviour. A static document passing a content check does not establish that navigation, menus and interactions remain healthy once the application runs.

A catch-all rewrite can serve an app shell with status 200 for an unknown article. The frontend may then display “not found,” but the server still reported success. That mismatch can create soft-404 confusion and poor behaviour for direct consumers.

A real 404 response can still use the site’s normal visual shell and useful navigation. It should not appear in the sitemap or be presented as a published article. Keep appropriate noindex handling on deliberate error pages; “remove every noindex tag” is too broad a rule. Indexability should follow the page’s actual purpose.

A manually maintained sitemap can drift when publication flags, routes and content live in separate places. A better fit for this journal is deriving sitemap entries from the same route/content registry used for rendering. Then a published entry has one source of identity and a draft can be excluded intentionally.

Modification dates should represent real changes, not the current build time stamped onto every unchanged page. Adding more URLs is not itself an SEO improvement. Each listed address needs a useful, reachable page with a distinct intent. A thousand variations of the same thin answer are a content problem that rendering cannot repair.

Redirect normalisation should avoid unnecessary hops, but a hosting provider may control part of the HTTP-to-HTTPS sequence. Document the actual behaviour rather than promise a one-hop result the application cannot enforce. At minimum, internal links should point directly to final canonical URLs.

Static images need their own review. A broad forced redirect for article routes can accidentally intercept a nested image path and return HTML instead of WebP. Check both the status and content type of referenced assets, and keep their namespace separate where appropriate. A successful 200 response is insufficient if the bytes are an error document.

For every public page, inspect the direct status, visible H1, title, description, canonical, structured data and internal links. Repeat a representative sample with JavaScript enabled and disabled. Include unknown slugs, mobile navigation and image loading. This is a meaningful delivery check, not a ranking test.

Then inspect the deployed output rather than assume a local build proves hosting behaviour. Search Console can later show Google’s indexed state and selected canonical, which a normal live fetch cannot establish. Keep those kinds of evidence separate. A clean technical audit makes discovery easier; it does not guarantee that Google will choose to index or rank the page.

Scroll the table horizontally to see all columns.

Does Google ignore all React sites? No. Google can render JavaScript, with limitations and processing stages. Directly useful HTML also serves readers and tools that do not run the application.

Do I need a new sitemap after every article? The existing successfully submitted sitemap can be updated in place. Repeated submission is not a mechanism for forcing rank or index coverage.

Does FAQ schema improve every article? It must match visible content and supported requirements. Structured data describes a page; it is not a substitute for useful writing or a promise of a rich result.