Fixing SPA SEO Rendering Issues Without a Full Rebuild

The client's engineering team heard 'SEO rendering problem' and immediately proposed a six-month migration to a server-rendered framework. That wasn't happening on the timeline the business needed, and honestly it wasn't necessary for the actual problem we had.

Googlebot does render JavaScript, but it does so on a second, deferred rendering pass that can lag the initial crawl by days to weeks, and other crawlers that matter for this client — certain AI answer engines, some social preview bots — didn't render JavaScript at all. They were seeing an empty shell.

The targeted fix

Instead of rearchitecting the whole app, we added a pre-rendering layer at the edge that detected bot user agents and served a fully rendered HTML snapshot for just the pages that mattered for discovery — product and category pages, roughly 15% of total routes. Human users and the rest of the app kept working exactly as before.

Request comes in
  -> is user agent a known crawler?
       yes -> serve pre-rendered static HTML snapshot
       no  -> serve normal SPA bundle

You don't need to rebuild the app to fix what the crawler sees. You need to fix what the crawler sees.

What it cost and what it bought

• Added a caching layer for the pre-rendered snapshots to avoid regenerating them on every crawl hit
• Needed a process to invalidate those snapshots on content updates, which was the trickiest part
• Delivered in three weeks instead of the six-month rewrite timeline
• Didn't touch a single line of the app's actual rendering logic

Indexed page count for product and category pages roughly tripled within a month, and social and AI-crawler previews started showing real content instead of blank cards. This wasn't a permanent architectural fix — eventually the team did move toward server-side rendering on their own schedule — but it bought back the discoverability the business needed immediately without betting the quarter on a rewrite.