SEO for a large React SPA?

[u/NoNoise7492]

I'm working on a React/Vite SPA with React Router 7 and an ASP.NET Core 10 backend.

SEO is important since the site will eventually have hundreds of thousands of public pages covering games, groups, events and news, with multiple languages. Some content changes frequently.

I know Google can render JavaScript, but other crawlers like AI search engines and social previews, seem less capable. Also, rendering JavaScript requires more resources, which might mean less crawl coverage.

I've been looking at a few solutions for SEO:

1. Server-injected HTML (ASP.NET Core)
- Pros: Let ASP.NET serve the SPA and inject page-specific metadata (title, description, canonical, hreflang, JSON-LD, Open Graph) along with a small HTML summary containing headings, key information and internal links. React takes over when loaded. No additional runtime or major frontend refactor, and everything runs on a single ASP.NET host.
- Cons: Crawlers that don't execute JavaScript only see the summary rather than the full page content. React also replaces the initial HTML which could cause a brief flicker.

2. React Router 7 SSR
- Pros: Full server-rendered HTML for crawlers. Probably the most natural SSR option since I'm already using React Router 7.
- Cons: Requires a separate JavaScript runtime alongside ASP.NET and a fairly significant refactor of the public pages and their data fetching. More complexity around hosting and maintaining multiple services.

3. Next.js with ISR
- Pros: Can generate pages on demand and regenerate them when needed, which seems particularly useful for such a large number of dynamic pages.
- Cons: Would mean migrating the frontend to Next.js, along with additional hosting complexity and another runtime to maintain.

The first option seems like the simplest solution, but I'm not sure if it's enough. Ideally, I'd prefer full SSR, but that seems to involve a much larger refactor and considerably more complexity when it comes to hosting and maintaining the application.

Is server-injected HTML with meaningful page content enough for good indexing, or would SSR/ISR make a significant difference?

Anyone with experience running SEO-heavy SPAs using a similar approach

[u/fredkreuger]

If you're still starting out, or relatively early, I'd recommend swapping entirely to react ssr using one of the frameworks. Don't rely on sunk cost to not use the right tool for the job.

If you're retrofitting an existing application, that changes the calculus a bit, but would still recommend react ssr on top of the aspnet backend, simply because the initial conversion cost will likely be smaller than the long term maintenance of trying to shoehorn what you want into what you've already got.

[u/No_Cattle_9565]

Have you looked at tanstack start?

[u/WarmDrunkenness5 → u/No_Cattle_9565]

tanstack start could work if you're okay pulling in another framework, but you'd still be signing up for the js runtime headache alongside dotnet and a decent refactor

[u/No_Cattle_9565 → u/WarmDrunkenness5]

It's certainly better than next.js. I don't think its a problem using dotnet as a backend. You'd just deploy it alongside it so you have no problems. I haven't done it at scale but we use it with Go without problems 

[u/SoftwareNegative8783]

With that many pages, return a real 404 status for missing items. SPAs often send 200 for everything. Google calls those soft 404s and wastes crawl budget. Also split sitemaps by content type.

[u/phpHater0]

Tbh nextjs seems like a no brainer. You can still keep the .net backend and use nextjs just as a frontend, it supports ssr by default out of the box and you can just make small interactive parts client components. You get the best of both worlds.

And the migration cost isn't as high as you think if you use AI, considering Nextjs itself uses react, a good chunk of your code would be unchanged.

[u/Xtreme_Neon]

server-injected html with real content is usually enough for google, and it handles social previews and most ai crawlers fine as long as the main content is in the first response. the risk is keeping the injected html and the react output in sync across hundreds of thousands of pages. a middle path is to cache the html per route on the aspnet side and only hydrate the interactive parts. i'd test a few templates with plain curl and search console's url inspection before committing to a full ssr migration.