How dynamic rendering works
The server looks at who is asking. If the request carries a user agent it recognises as a search engine crawler, it is passed to a separate rendering service — usually a headless browser — which loads the page, executes the JavaScript and returns the finished HTML. Everyone else gets the ordinary application, which builds itself in their browser as normal. One URL, two delivery paths, decided by identity rather than by content.
The setup exists to hand crawlers something readable when the site itself only produces readable pages after JavaScript has run. It was never meant to improve anything for visitors, and it does not.
Why dynamic rendering matters
It matters mainly as something to recognise, because it is no longer the answer. Google documented the technique as a workaround for sites that could not be rebuilt quickly, was explicit at the time that it was not a long-term solution, and has since deprecated that guidance. Googlebot renders JavaScript as part of normal indexing, so the original justification has gone.
It still turns up in inherited codebases, in older technical audits and occasionally in proposals from vendors who sell a pre-rendering service. If you see it in a quote for a new build, that is worth questioning: paying to bolt on a crawler-only pipeline is a sign the rendering strategy was decided by habit rather than by need.
Where dynamic rendering goes wrong
The two copies drift apart. The crawler version is generated by a service that caches its output, and when that cache is not invalidated properly the search engine keeps reading a page that no longer reflects the site — old prices, retired products, missing new sections. Because visitors see the correct version, nobody in the business notices.
Silent failure is the same story in a harsher form. If the rendering service times out, runs out of quota or breaks, crawlers receive empty pages or error responses while the site looks perfectly healthy to everyone in the office. Detection is brittle too: the bot list has to be maintained, and crawlers that are not on it — including the newer AI crawlers — simply fall through to the JavaScript version. And there is a policy edge to respect. Serving equivalent content to both audiences is acceptable; the moment the crawler copy is given extra text or different keywords, it becomes cloaking.
What to do about it
Do not build it into a new site. If the pages need to be found, produce their HTML on the server or ahead of time, so that crawlers and visitors receive the same thing and both benefit. Server-side rendering and pre-building are more work up front and less work forever afterwards.
If you have inherited a dynamic rendering setup, keep it alive while you plan its removal rather than switching it off in a hurry. Check that the crawler copy matches the live page, that the rendering service is actually responding, and that the user agent list covers the crawlers you care about; the crawl stats report in Search Console will show you if responses to Googlebot have gone strange. Then schedule the replacement as part of the wider technical SEO plan, and retire the extra pipeline once the templates that matter render properly on their own.