Dynamic rendering

What is dynamic rendering and how does it work?

Dynamic rendering, also called dynamic bot rendering or bot routing, serves one page in two forms. People get your site as usual. Search engines, link previews and AI crawlers get the same page as finished HTML, rendered ahead of time in a real browser after everything has loaded, so they read all of your content without running a single script. It works on client-side apps and alongside server-side rendering.

In Next.js and Vulkan, dynamic rendering means something else: rendering a route on each request, or drawing without render pass objects. This page is about serving rendered pages to crawlers. How the Next.js meaning differs

Contact sales

The problem

Why crawlers miss content on JavaScript sites

A client-side app sends a near-empty HTML file first. Even a server-rendered page leaves data, deferred sections and widgets for the browser to load. Crawlers mostly read what arrives first.

01Executing scripts requires a browser, and most crawlers don't have one
02Googlebot runs scripts in a separate rendering step, after it crawls the HTML
03No crawler interacts with the page: no clicks to open or dismiss a modal, switch tabs or open FAQ accordions

Swipe to see the full figure

One page, two readersThe browser builds it. Crawlers read what arrives first.

How it works

How dynamic rendering works

Every request to your site passes one check: who is asking. The answer decides which version of the page goes back.

01
Read the user agent

Every request names its client, such as Chrome, Googlebot or GPTBot.
02
Send people to your app

Browsers pass straight through to your host and get the interactive page.
03
Send crawlers the snapshot

Search engines, link previews and AI crawlers get the finished page as HTML or Markdown.
04
Render ahead of time

A headless browser loads each page on a schedule and saves the result, so no crawler waits for a render.

The routing rule in code

const CRAWLERS =
  /googlebot|bingbot|gptbot|claudebot|perplexitybot|linkedinbot/i;

async function handle(request) {
  const ua = request.headers.get("user-agent") ?? "";
  if (CRAWLERS.test(ua)) {
    // Rendered ahead of time
    return getSnapshot(request.url);
  }
  // People get your app as usual
  return fetch(request);
}

The rule is the simple part. The work is in the snapshots: rendering every page in a real browser, keeping them fresh, and serving them fast enough that crawlers never wait.

Compared

Dynamic rendering vs server-side rendering, static generation and client-side rendering

Each approach answers the same question: who builds the HTML, and when. Server-side rendering and static generation build the first response. Dynamic rendering captures the page after everything has loaded. On a client-side app it does the whole job. On a server-rendered site it adds what loads after the first response: client-fetched data, deferred sections and widgets.

Approach	Who builds the HTML	What crawlers get	Changes to your app
Client-side rendering	The visitor's browser, after scripts run	A near-empty HTML shell	None
Server-side rendering	Your server, on every request	The first response, without content the browser loads later	Move the app to a server framework
Static generation	Your build step, ahead of time	Full HTML	A static build; content changes need a rebuild
Dynamic rendering	A headless browser, ahead of time, for crawlers only	The fully loaded page as HTML, or Markdown for AI crawlers	None; one routing rule in front of the site

Google's view

Is dynamic rendering cloaking?

No. Cloaking means showing search engines different content from what people see, in order to rank for it. Google treats dynamic rendering as legitimate when the snapshot carries the same content as the page people get.

Google's documentation now says dynamic rendering was a workaround, and points new builds to server-side rendering, static rendering or hydration. That guidance is about how the first HTML response gets built. It doesn't cover content that loads after that response, or AI crawlers, most of which don't run JavaScript at all. For them, a rendered snapshot is the only complete version of the page.

Encited

How Encited dynamically renders your pages

Encited manages a fleet of thousands of browsers to do the rendering for crawlers beforehand, and serves the most optimal version of your pages to both search and AI crawlers.

01Load your pages in browsers and wait until everything is loaded
02Save the source HTML and post-process it into lean HTML and Markdown
03Store them across 300+ locations and serve them from the one closest to crawlers in milliseconds

Swipe to see the full figure

From empty shell to finished snapshotDone ahead of time, on your schedule

Serving

Request-response cycle for crawlers and humans

The ideal page for humans, search crawlers and AI crawlers is not the same. With Encited, you can treat each of them as a first-class audience.

01Browser requests are passed through to your hosting provider and served interactive pages
02Search and link preview crawlers get the lean HTML
03AI crawlers get HTML or Markdown depending on preference

Swipe to see the full figure

One URL, four readersPlays each request in turn

The pipeline

One page, start to finish

Below is the full process, from the Encited pre-rendering fleet visiting your pages to post-processing and caching them.

The pipelineOne page, start to finish

It starts with your refresh rules

Configure re-caching rules and schedules by URL group, each with its own browser profile.

01Daily, weekly, monthly or quarterly refresh per path
02Assign each URL group its own locale, time zone and device for fully localized snapshots
03Built-in manual re-caching for off-schedule refreshes, no more messy scripts

Swipe to see the full figure

One week of refreshesDue pages join the queue

Health check before render

Each page is probed before it renders, and broken pages raise an alert.

01Page alerts for server errors, redirects and blocked pages
02Broken pages are never cached or served
03No render spent on a page that fails its check

Swipe to see the full figure

A healthy page and a failing oneAlternates

Then, render fleet visits

Pages are rendered on your configured schedule and attached browser profiles.

01Desktop or mobile rendering per path
02Language and time zone per path
03Localized pages render in their own language

Swipe to see the full figure

Three profiles, one siteActive profile in blue

Load and wait until page is settled

Before taking the snapshot, Encited makes sure your page is in its fullest form, with no data left out.

01Waits for the network, event loop and content to settle
02Ignores beacons and connections that never close
03Honors an explicit “ready” signal from your page

Swipe to see the full figure

From navigation to snapshotQuiet periods in green

No accidental DDoSes allowed

Render speed follows your server's response time and error rate.

01Speeds up while your server is fast
02Backs off on slow responses or errors
03No load spikes for your real visitors

Swipe to see the full figure

Concurrency follows the originValues for illustration

Plain rendered HTML is hard to read, though

On average, modern web pages are 70%+ non-HTML, non-content. Scripts, styles, inline SVGs and decorative markup make the real content hard to read and extract.

01Strip scripts and style blocks
02Strip decorative markup
03Strip inline SVGs
04Pure content for search engines and AI agents

Swipe to see the full figure

Tokens per pageOne product page

Frequently asked questions

Dynamic rendering FAQ

Yes. Dynamic bot rendering and bot routing are other names for the same setup: a rule detects crawlers by user agent and serves them a rendered HTML snapshot, while people get your normal app.

No, as long as crawlers and people get the same content. Cloaking means showing search engines something different from what visitors see in order to rank for it. A dynamic rendering snapshot is your own page, rendered in a real browser, so its text, links and structured data match what people see.

Google's documentation now says dynamic rendering was a workaround, and points new builds to server-side rendering, static rendering or hydration. It still treats a correct setup as legitimate, not as cloaking. Its guidance covers how the first HTML response is built. Dynamic rendering also covers content that loads after that response, and AI crawlers that don't run JavaScript.

Pre-rendering is the step that loads a page in a browser and saves the finished HTML. Dynamic rendering is the serving rule: crawlers get that saved HTML, people get your live app. Most dynamic rendering setups, Encited's included, use both.

Most don't. Crawlers such as GPTBot, ClaudeBot and PerplexityBot read the HTML your server sends and don't run scripts, so content that only appears after JavaScript runs is missing for them. A rendered snapshot puts that content in the first response.

Run a URL through the free crawler simulator at encited.com/free-tools/crawler-simulator. It fetches the page as Googlebot or an AI crawler and shows the HTML they get back, so you can compare it with what your browser shows.

No. Encited sits in front of your site after one DNS change, or behind your own middleware through the API. Your app, your builder and your tracking stay as they are.

On the schedule you set for each URL group: daily, weekly, monthly or quarterly. You can also re-cache any page by hand when you ship a change.