Does Googlebot run JavaScript?

Yes. Googlebot renders pages with an evergreen Chromium as a second phase after the initial HTML fetch. The catches are timing and rationing: the first pass sees only the raw HTML, rendering is queued according to how worthwhile a page appears, and a page that looks empty in its raw form competes poorly for that queue. Rendering exists; relying on it is the gamble.

Why does URL Inspection show a blank or partial page?

Three candidate reasons, matching the three causes: the page is client-rendered and the capture caught the pre-JavaScript state, a resource needed for rendering was blocked by robots.txt or failed to load in time, or the request was intercepted by bot protection and the capture shows a challenge page. The crawled HTML tells you which — a framework shell, missing resources, and a challenge page all look different.

Can Cloudflare or my WAF block Googlebot by accident?

Yes, and it is a routine misconfiguration. Bot management exists to stop automated traffic, and crawlers are automated traffic; an over-broad rule serves them challenges or 403s instead of the site. Most vendors support allowlisting verified crawlers, which validates that a request claiming to be Googlebot genuinely is. Enable it, then confirm with a live test in Search Console.

Do AI crawlers like GPTBot render JavaScript?

As a rule, no. Most AI crawlers fetch the raw HTML and move on, with no rendering phase at all — client-rendered content simply does not exist for them. This makes the raw response more consequential than it has been in years: it is the only version of a page that search crawlers, AI crawlers, and social scrapers are all guaranteed to receive.

What replaced Fetch as Google?

URL Inspection in Search Console absorbed it. The live test performs a fresh fetch and render on demand, and View crawled page shows the stored capture from the last real crawl. The two can disagree — the live test reflects your site now, the crawled view reflects what the index was last built from — and that disagreement is itself diagnostic after a recent fix.

HomeFixGooglebot can't see content

Googlebot can't see your content. One of three things is true.

Short answer

When Googlebot can't see content, one of three things is true: the content is built by JavaScript after the HTML is sent, the request is blocked before real HTML is served — by robots.txt, bot protection, or a firewall — or a directive like noindex tells Google to ignore it. Comparing the raw response with the rendered page identifies which.

The phrase covers three different failures with three different fixes, owned by different people — your developers, your infrastructure team, or a one-line directive change. The expensive mistake is starting the wrong project: weeks of rendering work on a site whose actual problem was a Cloudflare rule, or a WAF investigation of a site that was simply client-rendered. This page is the fifteen minutes that prevents that.

The three causes, and how each one looks

Cause	The tell	Who fixes it
Rendered late	The raw HTML is a shell or missing key sections; the rendered page is complete. Search Console's crawled HTML looks like the shell.	Developers — rendering strategy
Blocked	The raw request gets a 403, a challenge page, or a captcha instead of your HTML. Search Console may report fetch errors or show the challenge page itself.	Infrastructure — CDN / bot protection / robots.txt
Told to ignore	The HTML is complete and fetchable — but carries a noindex, a canonical to another URL, or nosnippet markup. Google sees everything and obeys your instruction not to use it.	Whoever can edit a template — minutes, not weeks

Start with Google's own evidence

Search Console's URL Inspection tool has a feature most people never open: View crawled page, showing the exact HTML and a screenshot from Google's capture. This is not a simulation of what Googlebot might see — it is the record of what it saw. If your product grid is absent from that HTML, the complaint is confirmed at the source.

Two limits worth knowing. The crawled view reflects the last crawl, which may predate your latest deploy — use the live test for current state, and note the two can legitimately disagree. And the tool tells you that content is missing, not why — a shell from client rendering and a shell from an intercepted request can look identical there. Distinguishing them is what the comparison below is for.

The blocking case: when Googlebot never gets your HTML

Bot protection doesn't always know Googlebot is a friend

CDN bot management, WAF rules, rate limiters and geo-blocks are configured to stop automated traffic — and a crawler is automated traffic. Misconfigured protection serves Googlebot a challenge page or a 403 instead of your site, and everything downstream of that is garbage-in: nothing to render, nothing to index, sometimes a challenge page's text indexed in your place. Most protection vendors support verified-crawler allowlisting; the fix is turning it on and confirming with a fresh live test — not rewriting a single line of your application.

One honesty note that applies to every checking tool, including this one: bot protection can also block the checker. When that happens we say so explicitly rather than mislabeling your site — a blocked check is an answer about your protection layer, not about your rendering.

Measure the rendering gap

If the fetch works, the remaining question is how much of your page exists before JavaScript. Run the page that's missing content — the specific URL, not the homepage:

Compare what's served with what's rendered

https://

Where to go from your result

This page's job is routing, so the table routes — verdict to destination:

Result	Diagnosis and destination
CSR	Cause one, total form: the page is client-built. Go to the fix for your stack — React for shell-shipping SPAs, or the empty-view-source triage if you're not sure what you're running.
HYBRID	Cause one, partial form: specific sections are client-built. The missing-elements list names them. On Next.js this usually means client-side data fetching — that page covers the exact mechanism.
SSR	Rendering is not the cause. Recheck causes two and three: fetch blocking and directives. If URL Inspection still shows missing content on a green page, a directive or a crawler-specific block is nearly certain.
BLOCKED	Cause two, mid-diagnosis: protection intercepted the check itself. Your priority is the allowlisting conversation with your CDN or security vendor — rendering can't even be evaluated until requests get through.

Image slot

Screenshot: URL Inspection's 'View crawled page' beside our raw-vs-rendered result for the same URL — the two instruments agreeing.

Two instruments, one diagnosis: Google's own capture and the raw-vs-rendered comparison.

The diagnosis protocol

Six steps, each one narrowing the differential. Unlike our other fix pages, the remediation itself lives on the destination pages — this protocol gets you to the right one with evidence in hand.

Get Google's own evidence first

In Search Console, run URL Inspection on an affected page and open “View crawled page”. The crawled HTML and screenshot are what Google actually captured — not a simulation. If the content is missing there, the complaint is confirmed and real.

Establish whether Googlebot can fetch the page at all

Before diagnosing rendering, rule out blocking. Check robots.txt for the specific path, check whether your CDN or bot protection challenges crawler requests, and check the inspection's page-fetch status. A blocked fetch makes every rendering question moot.

Measure the rendering gap

If the fetch succeeds, compare the raw response against a full render. A large gap means the content is JavaScript-built and arrives after the capture. A small gap with the content present means rendering isn't your problem — move to directives.

Check what the page is telling Google

Content Google can technically see but won't use points to directives: a noindex in the HTML or headers, a canonical pointing elsewhere, or nosnippet attributes. Check the rendered HTML for these, not just the source — a directive added by JavaScript still counts.

Route to the matching fix

Rendered late → move rendering to the server via your framework's path. Blocked → configure bot protection to verify and allow legitimate crawlers, and correct robots.txt. Directive → remove or fix the directive. These are different projects with different owners; don't start the wrong one.

Verify with both instruments

Re-run the raw-vs-rendered comparison to confirm the content is served, then re-inspect in Search Console to confirm Google's next capture includes it. When both agree, request reindexing on representative URLs and let recrawl do the rest.

Beyond Googlebot: the question got bigger

"Can Googlebot see my content" was the whole question for twenty years. It no longer is. Googlebot renders JavaScript — eventually, in a rationed second pass. Most AI crawlers gathering content for answer engines do not render it at all: what's in the raw response is the entirety of what they know about your page.

The practical consequence: content Googlebot cansee via rendering can still be invisible to the systems increasingly answering your customers' questions directly. Server-rendered HTML stopped being merely the safe choice for Google and became the only version of your site that every consumer — search crawlers, AI crawlers, social scrapers, and failed-JavaScript browsers alike — is guaranteed to receive.

Common questions

Search Console's URL Inspection tool, via View crawled page, shows the HTML and screenshot from Google's actual capture of your URL — the closest thing to ground truth available. Pair it with a raw-versus-rendered comparison to explain what you find there: the inspection shows that content is missing, and the comparison shows whether late rendering, blocking, or neither is the reason.