Is dynamic rendering still OK for SEO? What Google says now about prerender services
Short answer: Google does not recommend dynamic rendering. Its documentation calls it a workaround and not a recommended solution, and it names server-side rendering, static rendering, or hydration as the alternatives. It does not treat it as cloaking, though. As long as your dynamic rendering produces similar content, Googlebot won't view it as cloaking. If your site builds its pages in the browser and you can't move to server-side or static rendering yet, a prerender service is still a reasonable bridge. That matters most for crawlers other than Googlebot, because other search engines may choose to ignore JavaScript.
The decision comes down to two things: whether you can move your public pages to server-side or static rendering soon, and whether crawlers that skip JavaScript get your content as plain HTML today.
What Google's documentation says now
Google's Search Central page on the topic is clear about its status. It says dynamic rendering was a workaround and not a long-term solution, and that it is a workaround and not a recommended solution. In place of it, the page points to server-side rendering, static rendering, or hydration.
The same page describes how the setup works. A dynamic rendering server detects bots that may have problems with JavaScript-generated content. It serves a server-rendered version without JavaScript to these bots, while showing the client-side rendered version of the content to users. Google describes the original use case as indexable, public JavaScript-generated content that changes rapidly.
On cloaking, the page is direct: as long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking. So the thing to watch is whether crawlers get content that differs from what visitors see.
Google's JavaScript SEO basics page covers how Googlebot handles JavaScript. Google Search runs JavaScript with an evergreen version of Chromium, and Googlebot queues pages for both crawling and rendering. The page may stay on this queue for a few seconds, but it can take longer than that. The same page still says that server-side or pre-rendering is still a great idea, and notes that not all bots can run JavaScript.
Dynamic rendering, server-side rendering and prerendering are different things
These terms get mixed up, and that changes what Google's advice means for your site. The web.dev article Rendering on the Web defines them like this:
| Approach | Definition on web.dev | Where the HTML is produced |
|---|---|---|
| Client-side rendering | Rendering an app in a browser, using JavaScript to modify the DOM. | In the browser |
| Server-side rendering | Rendering an app on the server to send HTML, rather than JavaScript, to the client. | On the server |
| Static rendering | Generally, static rendering means producing a separate HTML file for each URL | One HTML file per URL |
| Prerendering | Running a client-side application at build time to capture its initial state as static HTML. | At build time |
Dynamic rendering sits beside these. With dynamic rendering, users are shown the client-side rendered version, and bots get a server-rendered version without JavaScript. The web.dev article also says client-side rendering can work, but often needs additional testing and overhead, and it mentions dynamic rendering as an option worth considering.
Server-side rendering and static rendering, two of the alternatives Google names, send HTML to every client, not only to bots. That is the long-term direction. Whether you can get there soon depends on your framework and how much of the app you can change.
Why sites still keep a prerender service
Googlebot is not the only crawler to plan for. Google's own dynamic rendering page says other search engines may choose to ignore JavaScript. Vercel reported that none of the major AI crawlers currently render JavaScript, and it advises sites to prioritize server-side rendering for critical content.
On a site that renders entirely in the browser, the content is produced by JavaScript, and not all bots can run JavaScript. Until the site sends real HTML to everyone, dynamic rendering, which serves a server-rendered version without JavaScript to these bots, is one way to cover them.
How to decide: keep it, or move off it
Use these questions to place your site. None of them needs a tool, only an honest look at your stack.
- Does your framework already support server-side rendering or static generation, and do your public pages fit it? If so, plan the move. That is the direction Google recommends, and once it is done you no longer depend on a separate renderer.
- Is a rewrite months away, or out of reach for a small team? Then keep the prerender service as a bridge, and treat it as one: write down which routes depend on it.
- Is your content public, indexable and changing rapidly? That is the case Google's page describes dynamic rendering as a workaround for. Keep cache lifetimes short enough that bots don't get stale copies.
- Do you care about crawlers beyond Googlebot, such as other search engines and AI crawlers? If so, a site that only works with JavaScript needs some form of server-side, static or prerendered HTML.
- Do your crawler pages match your visitor pages? If you've added crawler-only text, remove it. Google ties its cloaking answer to similar content.
How to check what crawlers actually get
Whatever you decide, test what a crawler receives instead of assuming it. These checks work with any setup.
- Inspect the page in Google's tools. Google's troubleshooting guide says to use the Rich Results Test or the URL Inspection Tool to check if the rendered HTML has all content you expect. The guide also notes you can see loaded resources, JavaScript console output and exceptions, rendered DOM, and more information.
- Request the page as a crawler and as a visitor. Send one request with a user agent string your middleware treats as a crawler and one without it, then compare. The crawler response should contain your headings and body text as plain HTML.
- Compare the two versions for meaning, not markup. The crawler copy may skip scripts, but the headings, prices, product text and links should match what a visitor sees.
- Test a page that fails. Find out what a crawler gets when the renderer times out or errors. A clear fallback to your normal page is better than an error page.
- Re-check after deploys. Check again after any change to routes, bot rules or renderer tokens.
curl -s -A "$CRAWLER_USER_AGENT" "$PAGE_URL" | grep -i "<h1"
curl -s "$PAGE_URL" | grep -i "<h1"On a client-rendered site with working prerendering, the first command should print your page heading and the second often prints nothing. If both print nothing, your crawler requests are not getting rendered HTML.
If you keep a prerender service
Treat it as infrastructure you can swap, not a permanent part of your app. Keep the middleware that routes crawler requests in one place, keep the service address and token in configuration, and make sure a failed render falls back to your origin's own page.
Whichever service you use, plan for the day your public pages move to server-side rendering, static rendering, or hydration, the alternatives Google names, and use prerendering until then.
Sources
- Google Search Central: Dynamic rendering as a workaround
- Google Search Central: Understand JavaScript SEO basics
- Google Search Central: Fix Search-related JavaScript problems
- web.dev: Rendering on the Web
- Vercel: The rise of the AI crawler
Questions
Is dynamic rendering considered cloaking by Google?
Not when the content matches. Google's documentation says that as long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking. Serving crawlers text that visitors never see is the part to avoid.
Has Google deprecated dynamic rendering?
Google's documentation calls it a workaround and not a recommended solution, and it points to server-side rendering, static rendering, or hydration instead. It still describes how dynamic rendering works and does not treat matching content as cloaking.
Does Googlebot need prerendered HTML for a React site?
Google Search runs JavaScript with an evergreen version of Chromium, but Googlebot queues pages for rendering, and a page may stay in that queue for a few seconds or longer. Google still says server-side or pre-rendering is a great idea, and notes that not all bots can run JavaScript.
Do AI crawlers need prerendered or server-rendered HTML?
Vercel reported that none of the major AI crawlers currently render JavaScript, and it recommends prioritizing server-side rendering for critical content. If your content only appears after JavaScript runs, plan to serve it as HTML.