Sites built with frameworks like React or Vue often show above-the-fold content only after JavaScript finishes running. Traditional crawlers can execute JS, but it costs time and budget, and they may not run it fully. If the spider gets an empty HTML shell, indexing and rankings both suffer — the hidden pitfall of SPA sites.
Prerendering and dynamic rendering are the two mainstream fixes, and both aim at letting the spider grab complete HTML directly instead of running scripts itself. At heart, both approaches come down to one thing: first get clear on “what does the spider actually see.” Which one to pick depends on site scale and team resources — the rendering chapter of the technical SEO handbook lays out the thinking. Prerendering generates static HTML at build time and suits sites with a manageable page count; dynamic rendering serves the full version to spiders while keeping the original for users, suiting large dynamic sites. Whichever you choose, verify with real crawling in the end — don’t assume it works just because you configured it.
The crawling challenge of JS rendering
On a purely client-side rendered page, the initial HTML holds only a mount point and scripts; the body gets injected after JS executes. If the spider has limited JS-execution ability or tight budget, it may only catch an empty shell — title, body, and internal links all missing — effectively hiding your content, and even the best article won’t rank.
Even when search engines can render, they pay extra time and compute, and such pages get pushed back in the crawl queue. For content sites, delayed indexing is delayed traffic. So the rendering approach isn’t a pure engineering choice — it directly decides whether content enters the index in time and in full, affecting the whole site’s performance.
What prerendering is
Prerendering renders pages into complete static HTML at the build stage and stores them on the server; both users and spiders get ready-made content without running JS on the spot. It moves “runtime rendering” earlier to “publish-time rendering” — most spider-friendly, and it also improves first-screen speed as a bonus, two birds with one stone and great compatibility.
The cost: a large page count lengthens builds and eats storage, and content updates require regeneration. It suits “few pages, stable” scenarios like landing pages, docs, and blogs. If a site has hundreds of thousands of pages changing frequently, prerendering’s cost and freshness get tight — consider other options rather than forcing it.
What dynamic rendering is
Dynamic rendering decides at the server whether the visitor is a spider or a human: spiders get a pre-rendered complete HTML set, ordinary users get the interactive SPA as usual. It doesn’t change the user-side experience — it just opens a “fast lane” for crawlers. Google named it a recognized transitional solution years ago, and it works quickly.
The benefit is friendliness to huge dynamic sites — no need to rebuild the whole site as static; just one transformation at the middle layer. The cost: maintaining a rendering service and accurately identifying UA — a misjudgment serves the wrong version to users or spiders. It suits the transitional period when “the frontend can’t be touched yet,” serving as a stepping stone.
How to choose between the two
A simple rule: if the page count is manageable and updates are infrequent, prefer prerendering — steadiest and fastest; if pages are massive, highly dynamic, and the architecture can’t change short-term, use dynamic rendering as a bridge. The former treats the root cause, the latter treats the symptom — when the team has time, treat dynamic rendering as a stepping stone and evolve toward prerendering or SSR to solve it at the source.
You can also mix: core index pages go prerendered, long-tail dynamic pages go dynamic rendering. The key is listing exactly which content “must be indexed” and treating it accordingly instead of a site-wide one-size-fits-all. With limited resources, protect the full rendering of traffic pages first; long-tail pages can be topped up in batches — get the priority order right.
Impact on indexing
For the same content, once the spider gets the complete HTML, the title, body, structured data, and internal links are all visible — indexing quality immediately rises and ranking chances get steadier. Conversely, even if an empty-shell page gets indexed, its thin content usually suppresses its weight. The rendering approach writes directly into the index result — the difference is big.
Also watch out: if the “spider version” and “user version” differ severely, the site may be judged as cloaking and penalized. Dynamic rendering serves a complete version of equivalent content, not a different article — this red line can’t be crossed. When verifying, compare both ends’ body text for consistency, avoiding accidental mistakes.
How to verify the spider gets complete HTML
The most direct way is GSC’s URL Inspection tool’s “rendered page,” comparing whether the body appears in the source. You can also check site logs for the status returned after spider requests, plus third-party spider-snapshot tools, to confirm it’s not an empty shell with only a mount point — so you have confidence.
More hardcore: on the server, return the page source for the Googlebot UA and inspect it, or use a headless tool to fetch as a crawler and look at the DOM by eye. Whichever way, this verification step can’t be skipped — configuring rendering doesn’t equal it working; combine it with crawl budget optimization to verify what the spider actually retrieves.
Performance and cost trade-offs
Prerendering adds build time and storage; dynamic rendering adds a layer of middleware service ops. Both need the numbers run: does the saved “spider-JS budget” plus improved indexing outweigh the ops cost? For most content sites, prerendering’s marginal cost is low while the payoff is solid — try it small first, then scale.
Don’t expect a rendering solution to fix content quality for you. It only guarantees “the spider can see it”; once visible, it comes down to the content itself. Treat rendering as an entry ticket rather than the deciding move; combined with flattening your site architecture so deep pages get crawled in time, the whole thing runs — none of it can be missing.
Pair it with the handbook
Write the rendering strategy into the site’s technical standard instead of doing it piecemeal. Make clear which pages prerender, which go dynamic, and how the build flow generates them, so new teammates don’t get lost. Bind it to monitoring — if the rendering service goes down, alert immediately, avoiding quietly falling back to empty shells while traffic drains silently.
The overall thinking can enter the technical SEO handbook as the practical detail of the rendering chapter. Rendering, caching, and architecture are all intertwined — looking at any one alone is incomplete; together they form the full picture of a spider-friendly site, easier to promote across the team as a long-term mechanism.
One table comparing the two approaches
Figure: Prerendering and Dynamic Rendering — Core Points (compiled by YunyingGO)
| Dimension | Prerendering | Dynamic rendering |
|---|---|---|
| Generation timing | At build time | By UA at request time |
| Suitable scale | Few pages, stable | Massive and dynamic |
| User-side experience | Fast static | Original SPA |
| Ops cost | Low | Needs a rendering service |
| Evolution direction | Treats the root | Transitional, treats symptoms |
When getting started, don’t rush to roll out a solution — first use GSC’s URL Inspection to see what the spider actually renders, and confirm the empty-shell problem before acting. Choose prerendering or dynamic rendering by page count; with dynamic rendering, make sure both ends’ content matches and never touch the cloaking red line; then hook rendering status into monitoring so a failure alerts immediately. Once these steps are done, an SPA site’s content stops being invisible assets the spider can’t see.
