How prerendering works
A job runs away from the visitor: it opens each URL in a headless browser, waits for the JavaScript to finish drawing the page, and saves the resulting HTML as a file. Later requests are answered with that saved snapshot instead of an empty shell. It usually appears in one of two forms — a step inside the build pipeline of an existing single-page application, working from a list of routes, or a hosted service that sits in front of the site and keeps snapshots of its own.
One point of confusion worth clearing up: browsers use the same word for something else. Speculative prerendering means a browser quietly loading a page you are likely to click next so it appears instantly. That is about perceived speed for one visitor, not about what search engines can read.
Why prerendering matters
It gives crawlers a complete document on the first request without anybody rewriting the application. Headings, body copy, internal links, the canonical tag and the meta description are all in the response, so indexing no longer depends on a rendering queue or on a script executing successfully somewhere down the line.
Visitors gain too, as long as they are served the same snapshot. A saved file arrives and paints while the JavaScript bundle is still on its way, which is the difference between a page that feels usable on a mid-range phone and one that shows a blank screen for an uncomfortable stretch. For a client sitting on an existing single-page application with no budget for a rebuild, this is often the honest, affordable step.
Where prerendering goes wrong
Snapshots age. The saved file reflects the moment it was taken, so a price change, a new article or a removed product only reaches search engines when the snapshot is regenerated. If that job is manual, it stops happening within a month or two of launch.
Worse, snapshots can capture the wrong moment entirely. If an API was slow or failing when the job ran, the saved HTML may contain a loading spinner, an empty state or an error message — and that is then served confidently to every crawler until someone checks. The route list is the other weak point: pages created after it was written are simply never captured. And if the snapshots go only to crawlers while people get the JavaScript version, this stops being prerendering and becomes dynamic rendering, which brings its own problems.
What to do about it
Serve the prerendered HTML to everyone. Deciding what to send based on who is asking adds risk and helps nobody; sending the same document to all visitors makes the site faster and the setup easier to verify.
Regenerate automatically when content is published rather than on a calendar reminder, and build the route list from the XML sitemap so new pages are picked up without anyone remembering. Then validate the output: crawl the snapshots and search them for tell-tale strings such as loading text, empty titles or error copy, and use the URL Inspection tool in Search Console to confirm that what Google holds matches the live page. Treat the whole arrangement as a stage rather than a destination — static site generation or server rendering does the same job with fewer moving parts, and is where a maturing technical SEO setup should end up.