What is dynamic rendering?
Dynamic rendering is a setup where the server checks who is asking for a page: crawlers get a fully rendered HTML snapshot, and browsers get the usual JavaScript application. It was introduced as a way to get client-rendered sites indexed, and Google now describes it as a workaround, not a long-term solution.
It still exists on many older single-page applications, and understanding it helps when you inherit one.
The moving parts
- A request arrives and middleware inspects the user agent.
- If it matches a list of known bots, the request goes to a renderer: a headless browser that loads the page, runs the scripts and returns the finished HTML.
- Everyone else receives the normal shell and JavaScript bundle.
The snapshots are usually cached, because rendering a page in a headless browser on every bot request is slow and expensive.
Browser → GET /pricing → app shell + bundle.js
Crawler → GET /pricing → prerendered HTML, no script needed
Why Google no longer recommends it
Google's guidance is to use server-side rendering, static rendering or hydration instead. The reasons are practical:
- Two versions to keep in step. When the snapshot and the live page drift apart, crawlers index content visitors never see, or miss content they do.
- A second system that can fail quietly. If the renderer times out or serves stale cache, nothing looks wrong in a browser. Only bots get the broken page.
- The bot list goes stale. New crawlers, including AI crawlers that do not run JavaScript, are not on the list until someone adds them, and they get the empty shell.
- Googlebot renders JavaScript itself. The original problem is smaller than it was, although rendering is still a deferred, more fragile step than reading HTML.
Is it cloaking?
Not by itself. Google has said dynamic rendering is not cloaking as long as the content served to crawlers is similar to what users get. It becomes cloaking when the bot version carries different content, such as extra text or links that visitors never see.
What to do if your site uses it
Check that it still works before replacing it. Fetch a page with a crawler user agent and compare it with the rendered page in a browser, and use the URL Inspection tool's live test to view the HTML Google sees. Look for missing main content, a stale snapshot and missing canonical or meta robots tags.
Then plan the move to rendering on the server for everyone. Most frameworks support it, and one version of each page removes the whole class of problems.
WordPress sites almost never need any of this: themes output HTML from PHP on the server. The exception is a headless build where WordPress only supplies data to a JavaScript front end.
Common questions
Does Google penalise dynamic rendering?
No. It is allowed, and it is not treated as cloaking when both versions carry the same content. Google simply advises against it because it is complex and error-prone.
What is the difference between dynamic rendering and server-side rendering?
With server-side rendering every visitor and every crawler receives rendered HTML. With dynamic rendering only detected bots do, and people get a client-rendered app.
Do AI crawlers need prerendered HTML?
Many AI crawlers fetch the raw HTML and do not execute JavaScript, so content that exists only after scripts run may be invisible to them. Rendering on the server solves that for all crawlers at once.