---
title: How to view a page as Googlebot · Serpward
url: https://serpward.com/view-page-as-googlebot/
source: Serpward (serpward.com)
---

# How to view a page as Googlebot

Two different questions hide behind “view a page as Googlebot”, and they have different answers. One is *what does my page turn into when Google renders it* — a question about JavaScript, blocked files and layout. The other is *is this page showing Googlebot something it hides from me* — a question about cloaking. The methods below answer one or the other, and it is worth knowing which one you are asking.

Verdict

### Every check we made

All of them, including the ones that could not be made — so you can judge for yourself.

### Get the full report

The screenshots at full size and a paragraph you can paste into a takedown notice — by email.

## Four ways, and what each one proves

### 1. Change the user agent in your browser

In Chrome: DevTools → three dots → More tools → Network conditions → turn off “Use browser default” and pick Googlebot. Reload the page.

The site now sees Googlebot’s **name**, and everything else about you unchanged: your address, your country, your cookies. That makes this the cheapest method and the weakest one. It catches a page that switches on the user agent alone. A page that checks the visitor’s IP address ignores your disguise completely and serves you the ordinary version, which is exactly how most serious cloaking is built.

Google says the same thing from the other side: the user agent [“is often spoofed by other crawlers”](https://developers.google.com/search/docs/crawling-indexing/googlebot), and [“any spammer could name their bot ‘Googlebot’”](https://developers.google.com/search/blog/2006/09/how-to-verify-googlebot). A site that takes cloaking seriously does not trust the name either — it checks the address — and your disguise ends there.

Useful as a first look. Never trust a clean result from it.

### 2. URL Inspection in Search Console

For a site you own and have verified, this is the honest answer: Search Console fetches the page from Google’s own infrastructure and shows you the rendered HTML, the screenshot and the resources that could not be loaded.

It is the best method available — and it only works for your own property. You cannot inspect somebody else’s page this way, which is a problem precisely when you need it most: when the page misusing your brand belongs to someone else.

### 3. Google’s own testing tools

The Rich Results Test accepts any public URL and fetches it from Google’s infrastructure with Googlebot’s user agent. So does PageSpeed Insights, which additionally returns a screenshot of what it was shown.

These are not the real crawler, but the request leaves Google’s address space rather than yours. A cloaker filtering by network sees a Google address and hands over the version it reserves for Google — and now you are holding it.

### 4. A request from Google’s own network

The same idea, one step further: a small script running on Google’s cloud fetches the page for you. The page sees a Google address and a Google signature, not yours. Together with the tools above, this covers the cloaking that keys on where the request comes from, not on what it calls itself.

This is what the checker at the top of this page does, alongside the plain visit and the visit that arrives from a Google search — and then it compares what each one was shown.

## The one thing nobody can do

You cannot make a request from the real Googlebot’s IP addresses. Only Google can. Anything that claims otherwise is either using the user agent (method 1) or borrowing a Google address that is not the crawler’s (methods 3 and 4).

The reverse is possible: when a visit claims to be Googlebot, you can verify it by reverse DNS — a genuine one resolves to `googlebot.com` or `google.com` and back to the same address. Google documents this as [“the best way to verify that a request actually comes from Googlebot”](https://developers.google.com/search/docs/crawling-indexing/googlebot), with the command lines to do it. That tells you whether a visitor was Google. It does not let you become one.

So content served *only* to the crawler’s own addresses cannot be fetched by anyone outside Google. It still leaves a trace: Google’s search result quotes text that is not on the page you can see. That is a probability, not proof — and it is why the checker compares the page with Google’s own snippet as well.

## Checking a page in five minutes

In the order that costs least first, stopping as soon as you have an answer.

- **Open it as you are.** Plain visit, no disguise. Note the final address in the bar, the response, and roughly how much text is on the page. This is the baseline everything else is compared with.

- **Open it again from a search result.** Find the page in Google and click through rather than pasting the address. Many hacked pages key on exactly this: Google’s own spam documentation notes that the redirect [“sometimes depends on the referrer, user agent, or device”](https://developers.google.com/search/docs/essentials/spam-policies). Check you land on the same URL that was indexed.

- **Open it on a phone, or with a mobile user agent.** Google runs two crawlers, desktop and smartphone, and redirects that fire only for mobile visitors are common enough to have their own name in Google’s policies.

- **Switch the user agent to Googlebot** (method 1 above) and reload. Different page? You are done — that is cloaking on the crudest switch. Same page? You have ruled out nothing.

- **Fetch it from Google’s address space.** Your own site: the URL Inspection live test in Search Console, which fetches from Google’s infrastructure and shows the rendered HTML and a screenshot. Someone else’s: the Rich Results Test and PageSpeed Insights do the same for any public URL.

- **Compare against Google’s snippet.** Search for the page and read what Google quotes. Text in the snippet that is nowhere on the page you are looking at means the crawler was shown something you are not being shown.

- **Repeat the plain visit once more.** If the page differs from itself between two identical visits, the differences above prove less than they appear to.

The checker at the top of this page runs steps 1, 2, 4, 5 and 7 at once and lays the results side by side; steps 3 and 6 are worth doing by hand.

## Why a page shows different things to different visitors

Not every difference is cloaking. Worth separating:

- **The user agent.** The crudest switch, and the easiest to catch.

- **The referrer.** The page behaves one way for someone who arrives from a Google search and another for someone who types the address. A common pattern: the search visitor is sent on to somewhere else entirely.

- **The address the request comes from.** Country, network, whether it looks residential. This is why our own check makes its plain visit from a residential address in the United States, where Googlebot crawls from.

- **The visit number.** Money page on the first visit, ordinary page afterwards — a cookie is enough.

- **Rendering.** Content assembled by JavaScript that the crawler does not run, or files it is not allowed to load. This is not deception, it is a mistake, and it is worth fixing rather than reporting.

## Differences that are not cloaking

Three ordinary arrangements produce two different versions of a page and are nobody’s fault:

- **Blocked resources.** If the files a page needs to assemble itself are disallowed in `robots.txt`, the crawler sees a page the visitor never sees. Worth fixing; not worth reporting.

- **A/B tests.** Running two versions is fine as long as the crawler is shown both in the same proportion as people are. Pinning the crawler to one version is where a test turns into cloaking.

- **Content that genuinely varies by device or client.** Say so in the response: the `Vary: User-Agent` header tells Google the page differs by user agent. Google’s own guidance on dynamic rendering draws the line plainly — serving [“completely different content to users and crawlers can be considered cloaking”](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering).

## Reading the difference

Two versions in front of you are not yet a verdict. What actually matters:

- **Was a page served at all.** A refusal is not a substitution. If one side gets 403 and the other 404, nobody was shown a page, and there is nothing to compare — the difference is between two refusals.

- **One side a page, the other a wall.** That is the strong signal: a visitor is stopped and a request from Google walks through, or the reverse.

- **How much the text differs.** Compared against how much the page differs from itself between two identical visits — plenty of pages rotate banners and ad slots on their own. A rule of thumb for a quick look: a gap of more than a fifth in the amount of text between two versions is worth examining; a gap of ten times is not a rotation of banners.

- **Where you end up.** A different final address for one of the visitors is worth more than any amount of differing text.

## If the page is using your brand

A single check tells you about one page on one day. The pages that matter — the ones ranking on your name in markets you sell in — appear, disappear and come back: campaigns are short, domains die, and Google removes what it catches. The page you checked last month is often not the page ranking this month.

Serpward watches the results for your brand on a schedule, captures each unauthorised page it finds, runs this same check on it, and files the takedown with the evidence attached.

[Find out what ranks under your name](https://serpward.com/#contact)
