What does a Googlebot view show?
Googlebot does not see the page you see. It is served a response by a server that can choose to answer differently for a crawler — and often does, without anyone deciding to: a cookie wall, a paywall stub, a geo or language switch, a bot filter that returns an empty shell. This tool requests the URL twice, once with Googlebot's user agent and once with an ordinary browser's, and reports what came back from each and what differs.
It also answers the four questions that decide whether the page can rank at all, before any question of quality comes up: is Googlebot allowed to fetch it by robots.txt; does the page tell Google to keep it out of results, in the HTML or in an `X-Robots-Tag` header; does it name a canonical, and is that canonical itself; and is there readable text in the HTML at all, or is the page an empty shell waiting for JavaScript.
The one thing it does not do is run JavaScript, for either request. That is the point rather than a limitation: the first response is what Googlebot reads before it decides whether to render the page, and if the first response contains nothing, indexing depends entirely on Google choosing to render — which is a risk you can measure here and usually should not accept.
How to see a page as Googlebot is served it
- Enter the full address of the page, including the scheme. Use the exact URL you care about — a trailing slash and a canonical hostname change which robots rule applies.
- Press See the Googlebot view. Two requests are made: one with `Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)` and one with a desktop Chrome user agent, both with the same headers.
- Read the checks first. Robots.txt, indexing, canonical, how much text is in the HTML, the title, and whether the two responses differ.
- Look at the comparison table. Rows that differ are highlighted: a different title or a different word count between the two requests is what cloaking looks like from the outside.
- Read the heading outline to see what a crawler can actually parse — the H1s and H2s in the HTML, in order, without any JavaScript having run.
- If the text count is low and the script count is high, treat that as the finding to act on: fetch server-side rendered HTML, or accept that ranking depends on Google's renderer.
Googlebot view limits and rules
| Item | Limit |
|---|---|
| Requests made | Two: Googlebot's user agent, then a desktop Chrome user agent, with identical Accept and Accept-Language headers |
| User agent | Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) |
| JavaScript | Not executed, for either request. This is the first response, which is what Googlebot reads before deciding whether to render |
| Checked | robots.txt permission, noindex in the HTML and in X-Robots-Tag, canonical agreement, title, text in the HTML, and any difference between the two responses |
| Not the real crawler | Google's verification only works from Google's own IP ranges. This request comes from this server, so a site that filters by IP — rather than by user agent — will answer it as it answers anyone else |
| robots.txt | Read for the target origin and matched against the path for the Googlebot token, using the same most-specific-token rule a crawler uses |
| Per request | 12 seconds per fetch, 6 of them for the connection |
| Rate limit | 40 checks per minute per visitor |
| Not included | Rendering, Core Web Vitals, whether Google has indexed the page, and anything the server only sends to a verified Google IP |
When to use it
- Confirming that a page is not carrying a `noindex` that was meant for staging and shipped by accident — the single most common reason a page will not rank.
- Checking whether a paywall, cookie wall or bot filter is serving Googlebot an empty shell where a browser gets the article.
- Diagnosing a JavaScript-heavy site: if the first response has 30 words and 40 script tags, that is why the page is indexed poorly, and it is worth knowing before blaming the content.
- Checking that the canonical points at the page itself rather than at another hostname or another page.
- Confirming that robots.txt allows a URL that has disappeared from search results, before spending time on other explanations.
Is it private?
The comparison has to be made from this site's server: a browser cannot set a Googlebot user agent on a cross-origin request, and even if it could, it would not be allowed to read the response. When you press the button, your browser sends the address to this site's own endpoint, which makes both requests with a crawler user agent, parses the two responses and returns the comparison. The site you check sees two requests from this server and learns nothing about who asked. No cookies, credentials or browser details are forwarded, and neither response is stored.
Frequently asked questions
No, and the difference matters. URL Inspection runs inside Google, from Google's own crawlers, on properties you have verified in Search Console — it tells you what Google actually saw, including whether it has indexed the URL. This tool makes two ordinary requests from a server, which is enough to check robots.txt, `noindex`, canonicals, and whether a crawler gets different content, but it cannot tell you what Google has in its index or what its renderer produced.
Four things this tool cannot see: the site may be entirely new and simply not crawled yet; the page may be linked from nowhere, so nothing leads a crawler to it; the canonical on some other page may be pointing at a different URL, which consolidates the two; or the content may be near-duplicate of something already indexed. This tool answers whether the page is blocked or empty, which is the part you can fix quickly, and leaves the rest to Search Console.
A different status code, a different title, a large difference in the amount of text, or a different number of scripts between the two requests — each row that differs is highlighted. The most common innocent version is a cookie wall: a browser is served a consent screen and Googlebot is not, so the text counts differ. The most common guilty version is a bot-specific template serving keywords to crawlers and something else to people, which is a penalties issue rather than an optimisation one.
Because the content is rendered by JavaScript after the first response, and this reads the first response. Search engines do render pages, so a JavaScript site is not automatically a problem — but rendering is queued, not instant, and it is the reason some pages are indexed with content that is months out of date. If the first response has almost no text, server-side rendering or pre-rendering the important parts is the fix that removes the dependency.
Both exist. Googlebot's classic token is `Googlebot/2.1`, and the desktop and smartphone crawlers have used Chrome-like user agents with `Googlebot/2.1` still inside them for years. Which one a site sees depends on the crawler. This tool sends the classic token, because that is the string robots.txt matching and most bot filters key on, and it is the one a site that serves crawlers differently will react to.
That is usually a caching or hostname problem rather than cloaking: a CDN edge cache holding an old copy for one user agent, a `Vary` header the cache ignores, or a load balancer sending the two requests to different backends. Make sure both requests land on the same hostname and that the cache is purged, then run it again. A difference that survives a purge is worth investigating properly, because serving crawlers and people different content is against search guidelines.
Related tools
Written and maintained by Md. Nur Hossain Repon.