What Happens When Googlebot Renders Your Page?

What actually happens when Googlebot renders your page?

Three separate things, in order, with gaps between them. Google's documentation describes processing JavaScript web apps in three main phases: crawling, rendering, and indexing. They are not one event, and the gap between crawling and rendering is where most JavaScript-related search problems actually live.

Most people picture a crawler that arrives, looks at the page, and files it. What happens is closer to a crawler that arrives, takes the raw response, puts the page in a queue for later processing, and comes back to the rendering part when there is capacity.

Understanding that sequence changes how you diagnose problems, because it tells you which of three different systems to blame, and they have completely different fixes.

Why is rendering a separate phase at all?

Because executing JavaScript is expensive and fetching HTML is cheap. Google is explicit that a page may stay on the render queue for a few seconds, but that it can take longer than that. That deliberately vague statement is the most honest thing in the documentation and the most important thing to internalise.

What it means practically is that there can be a window where Google has your page but has not yet seen what your JavaScript produces. For a site where the content is in the initial HTML this is irrelevant. For a site where it is not, it is everything.

Google describes the problematic case directly, saying that some sites use the app shell model where the initial HTML does not contain the actual content, and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates. If that describes your site, rendering is not an implementation detail for you, it is the critical path.

Which HTML does Google actually index?

The rendered one. Google states that it also uses the rendered HTML to index the page, as distinct from the initial HTTP response. So the document that matters is the one that exists after the JavaScript has run, not the one your server sent.

This is why viewing source is a poor diagnostic and inspecting the rendered DOM is a good one. The two can differ substantially, and the version you are worried about is the second one.

It also explains a failure mode that confuses people, where a page looks fine in a browser and behaves strangely in search. Your browser ran the JavaScript successfully with a warm cache and a real user session. The renderer did not necessarily have either of those things.

What browser is doing the rendering?

Google says it renders with an evergreen version of Chromium. That is genuinely good news and it removes a whole category of old anxiety about unsupported syntax, because the renderer tracks a current browser rather than lagging years behind.

What it does not mean is that the renderer behaves like your Chrome. It is Chromium in a specific configuration with specific restrictions, and those restrictions are where the surprises are rather than in the JavaScript features themselves.

So the useful mental model is a very fast, very impatient, completely anonymous visitor using a modern browser with most of the conveniences switched off. Almost every rendering problem I have seen makes sense once you picture that visitor.

What does the renderer refuse to do?

Quite a lot, and the specifics matter. Google's documentation says local storage and session storage data are cleared across page loads, and that HTTP cookies are cleared across page loads. It also says that the Web Rendering Service does not retain state across page loads.

So anything your page does that depends on remembering a previous visit will behave as though every visit is the first one. A consent flow, a "you have seen this" flag, or a progressive experience built on stored state all present the renderer with the cold-start version of your page.

It also declines user permission requests, such as camera access, and does not support connection types like WebSockets or WebRTC, only HTTP requests. If your content arrives over a socket, it does not arrive at all as far as indexing is concerned.

What about content that loads on click or scroll?

It is not seen. Google's guidance is that content requiring user interaction such as clicking or scrolling will not be accessed unless it is served in the initial HTML response. The renderer does not scroll your page and it does not click your buttons.

This is the single most common real-world version of this problem. Infinite scroll, load-more buttons, and content revealed by interaction all look fine to a human and are invisible to the process that decides what your page is about.

Google also says not to rely on URL fragments to load content, because the deprecated AJAX-crawling scheme is not executed. If your content addressing depends on what comes after a hash, that content does not have a distinct address as far as Google is concerned. This is the same territory as how AI crawlers handle JavaScript-rendered content, though those are different systems with different behaviour.

What happens to resources you have blocked?

They do not run. Google states plainly that Google Search won't render JavaScript from blocked files or on blocked pages. If robots.txt disallows the path your scripts live on, the renderer gets the page without them.

This is a genuinely common own goal, usually inherited rather than deliberate. Somebody blocked a directory years ago for a sensible reason, the build process later started putting bundles in a subdirectory of it, and now the rendered page is missing its content for reasons nobody connected to a robots.txt line.

The check is quick. Take the script and stylesheet URLs your page actually requests, and test each one against your own robots file. It takes ten minutes and it eliminates an entire category of confusing symptoms.

Does caching help or hurt here?

Both, and this is an underappreciated detail. Google says the Web Rendering Service may ignore caching headers, which means it can use a resource that is older than you expect rather than fetching a fresh copy.

The practical consequence is that after you ship a fix, the renderer may still be working with a previous version of a script for some period. If you deploy a change and test immediately, you may be measuring the old behaviour and concluding your fix did not work.

The way around this is versioned filenames rather than trusting cache headers to expire. If the URL changes when the content changes, there is no stale version to reuse, which is a habit worth having anyway.

How should you diagnose a rendering problem?

In the order the phases happen. First confirm Google can fetch the URL at all, then confirm the rendered output contains your content, then worry about indexing. Skipping to the last one is why so much time gets wasted on this.

The most useful single test is to look at the rendered HTML rather than the source, and specifically to check whether the words you expect to rank for are present in it. If they are not, nothing downstream matters and no amount of content work will help.

Then separate a rendering problem from a crawling one, because they look similar from the outside and are different things. A page that is not being fetched often enough is a different conversation, and I got into that in how crawlers decide how often to recrawl.

What should you do next?

Take your most important page and check one thing: is the content you care about present in the rendered HTML without any interaction. Not in the source, and not after you scroll. That answer determines whether you have a rendering problem at all.

If it is present, stop worrying about rendering and go and look at something else, because this is not your bottleneck. If it is absent, the fix is almost always to serve that content in the initial HTML response rather than to make the JavaScript cleverer.

If you are looking at a site where content appears for you and not in search, and you cannot tell which phase is failing, reach out. It is usually a twenty minute diagnosis and it saves people from rebuilding things that were never the problem. Performance work is a separate question again, and worth keeping separate, as I argued in field data versus lab data and what to fix first.