What Is Rendering? How Search Engines Process JavaScript Explained

Rendering is the step where a search engine takes the raw HTML it crawled and actually executes the JavaScript on the page to see what a real browser would show a visitor. It sits between crawling and indexing in Google’s pipeline, and it exists because a huge share of the modern web doesn’t put all its content directly in the initial HTML response. Frameworks like React, Vue, and Angular often build pages by running JavaScript in the browser to assemble content after the initial page load. If a search engine only read the raw HTML and never ran that JavaScript, it would see an empty shell on a lot of sites.

Crawling, rendering, and indexing are three separate stages

It helps to be precise about these terms because they’re often used loosely.

Crawling is when Googlebot requests a URL, checks whether it’s allowed to fetch it (robots.txt and similar rules), and reads whatever the server returns in the initial response.
Rendering is when Google executes the JavaScript on that page using a browser engine, so that any content the JavaScript builds or modifies becomes visible the way it would for a real user.
Indexing is when Google processes the resulting content (after rendering) and decides whether and how to store it for retrieval in search results.

Google’s official documentation describes this explicitly: Googlebot first crawls a URL by making an HTTP request, then if resources allow, the page is queued for rendering, where “a headless Chromium renders the page and executes the JavaScript,” and the rendered output is then used for indexing (Google Search Central, Understand JavaScript SEO Basics). Crucially, Google states that all pages returning a 200 status code get queued for rendering regardless of whether JavaScript is present, but the documentation also acknowledges that a page “may stay on this queue for a few seconds, but it can take longer than that,” meaning rendering isn’t instantaneous and the gap between crawling and rendering can vary.

How Google’s rendering actually works

Google renders pages using what it calls the Web Rendering Service, built on an evergreen version of Chromium, meaning it’s kept continuously updated to a recent stable version of Chrome rather than running on an old, frozen browser engine. This matters practically: it means Googlebot can generally execute modern JavaScript features the way a current browser would, which was not always true in the past when Google’s rendering engine lagged years behind current browser capabilities.

That said, rendering still consumes more computing resources than simply reading static HTML, so it isn’t unlimited or instant for every page on every site. The practical implication for SEO is straightforward: content that depends entirely on JavaScript execution to appear is reachable by Google, but it goes through an extra processing step that plain server-delivered HTML doesn’t need, and that extra step introduces both delay and a greater chance of something going wrong along the way (a script error, a blocked resource, a timeout) compared to content that’s simply present in the initial HTML.

Client-side, server-side, and hybrid rendering

How and where your JavaScript actually executes affects both SEO reliability and the user-perceived load time. The main approaches:

Approach	What happens	SEO tradeoff
Client-side rendering (CSR)	Browser (or crawler) downloads minimal HTML plus JavaScript, then builds the page content in-browser	Simplest to build, but content depends entirely on successful JS execution and an extra rendering step before it's visible to crawlers
Server-side rendering (SSR)	Server runs the JavaScript and sends fully-formed HTML on each request	Content is present immediately in the initial response, no rendering wait required for crawlers; more server resources needed per request
Static site generation (SSG)	HTML is pre-built at deploy time, served as static files	Fast and crawler-friendly like SSR, but not suited to highly dynamic, frequently-changing content without rebuilds
Hybrid / hydration	Server sends pre-rendered HTML, then JavaScript "hydrates" it in the browser to add interactivity	Combines fast, crawlable initial content with the interactivity of a JS app, generally considered a strong default for content-heavy sites

There’s no single right answer for every site. A highly interactive web application behind a login wall, where SEO visibility doesn’t matter, can reasonably lean on client-side rendering. A content-driven site that depends on organic search traffic benefits from server-side rendering, static generation, or hydration, because it removes the rendering step as a point of failure for getting indexed.

Dynamic rendering: a legacy workaround, not a long-term fix

Dynamic rendering is a pattern where a server detects whether a request is coming from a search engine crawler versus a regular user, and serves the crawler a pre-rendered, fully-formed HTML version of the page while serving regular users the standard client-side-rendered version. For a period, this was suggested as a practical workaround for sites that couldn’t easily convert to server-side rendering but had rendering problems with crawlers.

Google’s current documentation is direct about this no longer being the recommended approach: it states plainly that “dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,” and that it “creates additional complexities and resource requirements” (Google Search Central, Dynamic Rendering as a workaround). Google’s documentation now points toward server-side rendering, static rendering, or hydration as the better long-term solutions instead. If your site currently relies on dynamic rendering, treat it as a stopgap to migrate away from over time rather than a permanent architecture, both because it adds ongoing maintenance overhead (you’re effectively running two rendering pipelines) and because there’s always some risk in serving meaningfully different content to crawlers versus users, even when the intent is purely technical rather than manipulative.

That guidance is specific to Google, worth flagging on a topic that spans search engines broadly. Bing’s own webmaster documentation has taken a different position, calling dynamic rendering “a great alternative for websites relying heavily on JavaScript” and confirming it isn’t considered cloaking, since bingbot’s JavaScript processing is more limited at scale than Googlebot’s (Bing Webmaster Blog, bingbot Series: JavaScript, Dynamic Rendering, and Cloaking). Independent testing has also found Bing’s JavaScript rendering to be inconsistent in practice, sometimes mixing pre-rendered and raw HTML on the same page (Screaming Frog, Is Bing Really Rendering and Indexing JavaScript?). If a meaningful share of your traffic comes from Bing or other engines, server-side rendering or static generation is still the safer universal default, since it sidesteps the question entirely rather than leaning on an approach Google now actively discourages.

Performance, Core Web Vitals, and rendering

How a page renders has a direct relationship to the Core Web Vitals metrics Google uses to assess real-world page experience. The three current Core Web Vitals, per Google’s own thresholds, are:

Largest Contentful Paint (LCP): should occur within 2.5 seconds of when the page starts loading, for a “good” rating.
Interaction to Next Paint (INP): should be 200 milliseconds or less.
Cumulative Layout Shift (CLS): should stay at 0.1 or less.

These thresholds are measured at the 75th percentile of real page loads, across both mobile and desktop traffic, for a site to be assessed as “good” overall (web.dev, Web Vitals). Note that INP replaced First Input Delay (FID) as the official interactivity metric; FID is retired and shouldn’t be cited as a current Core Web Vital.

Heavy client-side rendering tends to push these metrics in the wrong direction: large JavaScript bundles delay when meaningful content actually paints (affecting LCP), and content that shifts around as it loads or hydrates can hurt CLS. Server-side rendering and static generation generally produce faster, more stable initial paints because the browser doesn’t need to execute as much JavaScript before content is visible.

A note on unofficial “timeout” numbers

You’ll frequently see specific numbers circulated in SEO discussions claiming Googlebot has a fixed timeout, like a five-second budget for initial load or a twenty-second cap on total JavaScript execution. These figures are not published anywhere in Google’s official documentation, and Google has not confirmed a fixed timeout of that kind. Treat any specific timeout figure you encounter as an unverified, industry-repeated approximation rather than a documented Google limit, and prioritize Google’s actual published guidance on JavaScript SEO rather than these recycled numbers when making technical decisions.

How to test and debug rendering issues

Search Console’s URL Inspection tool is the primary way to check how Google currently sees a specific page. Its “Test Live URL” feature triggers a fresh, real-time fetch using Googlebot, renders the page in a recent version of Chromium, and shows you the resulting rendered HTML, along with any resources that were blocked or failed to load (Search Console Help, URL Inspection tool). This is the most direct way to confirm whether content you expect to be visible after JavaScript execution is actually showing up in what Google renders.

Common JavaScript SEO pitfalls worth checking for:

Blocked resources. If your robots.txt disallows crawling of JavaScript or CSS files the page depends on, Google may not be able to render the page correctly, since it can’t fetch the files it needs to execute.
Content that only loads on user interaction. Content hidden behind a click or hover handler may never be seen, since Google Search doesn’t interact with your page the way a person does. Scroll-triggered lazy loading is a related trap worth calling out separately: Googlebot doesn’t generate scroll events, it expands its virtual viewport to load the page in one pass, so any script waiting on a scroll event to fire content in never runs. Lazy loading built on the IntersectionObserver API or the native loading="lazy" attribute avoids this problem and is what Google recommends (Google Search Central, Fix lazy-loaded content).
Reliance on browser-only APIs without fallbacks. If a feature depends on something not available in Google’s rendering environment, that content can silently fail to appear.
Excessive rendering delay. Pages with very large JavaScript bundles or many sequential network requests before content appears risk not being fully rendered before Google moves on.
Soft 404s from client-side routing. Single-page apps that return a 200 status for every route, including invalid ones, can confuse crawlers about which pages are real content versus error states.

The practical takeaway

Rendering is simply the step where a search engine turns your JavaScript into something it can actually read, sitting between crawling and indexing. Google’s renderer is capable and kept current, but rendering still costs more time and resources than reading static HTML, and it introduces more points of failure. For any site where organic visibility matters, leaning toward server-side rendering, static generation, or hydration over pure client-side rendering removes rendering as a recurring risk, and regularly checking real pages with the URL Inspection tool is the most reliable way to confirm your content is actually visible the way you intend it to be.