How to Verify Googlebot Is Real: The Two-Step Check

Every request that arrives at a website carries a user agent, which is a short line of text the visiting program writes to describe itself. Nothing checks it. A program can put the word Googlebot in that line as easily as it can put anything else, so a log full of Googlebot visits is a log full of claims. Google publishes a real test, it takes two steps, and I ran it live against five addresses to show what passing and failing actually look like. The timing is not idle. On August 29, 2026 the maintainer of the Linux kernel’s public code repository reported that the crawlers overwhelming his servers had stopped identifying themselves and started imitating ordinary browsers.²

Of five addresses I checked, two passed. One of the failures is a genuine Google server, which is exactly why “it belongs to Google” is not the test.

What does a user agent actually prove?

On its own, it proves that somebody typed a string. The user agent travels with the request as a self-description, and no part of the web checks it against anything. Anyone with a command-line tool can send a request wearing any user agent they like, which takes about ten seconds and no special access.

This matters because the string is what most log analysis runs on. A dashboard reporting “Googlebot visited 4,000 times this month” has counted 4,000 self-descriptions. Some of those are Google. Some may be a scraper that would rather not be blocked, and copying the identity of a crawler nobody blocks is the cheapest disguise available.

How do you verify Googlebot for real?

Google documents a two-step check, and both steps are required. Its page “Verify requests from Google crawlers and fetchers” tells you to run a reverse lookup on the address in your logs, then run a forward lookup on the name that comes back.¹

A reverse lookup asks what name is registered to a numeric address. Asking the opposite question, what address a name points to, is a forward lookup. The check passes only when that second answer matches the address you started with. This pairing is old and it has a name: engineers call it forward-confirmed reverse DNS, and it long predates Google’s use of it here.

The reason both steps exist is worth a sentence of its own. Whoever controls an address block also controls the name it reports, so step one can be forged by anyone who owns their own addresses. Step two cannot, because it queries the records for the name itself, and an impostor cannot make googlebot.com point at a machine they own.

Google also names the hostname patterns a genuine crawler resolves to, including crawl-***-***-***-***.googlebot.com, and lists googlebot.com, google.com and googleusercontent.com as the valid domains.¹

What does the Googlebot verification check look like when it runs?

I ran it on September 8, 2026 against five addresses, and two passed. Google’s documentation demonstrates the method with the host command; that tool is not available on the machine I work from, so I used Python’s built-in resolver, which asks the same domain name system and returns the same records.

The two published Googlebot addresses passed both steps cleanly. Address 66.249.66.1 reversed to crawl-66-249-66-1.googlebot.com, and that name resolved forward to 66.249.66.1. Address 66.249.64.100 behaved identically. Both hostnames match the pattern Google documents, character for character.

Three failed, each in a different way, and the differences teach more than the passes do.

Address 8.8.8.8 reversed to dns.google, a real Google-operated machine, and failed anyway because dns.google is not one of the crawler domains. Ownership by Google is not the question the test asks. Address 13.107.21.200 had no reverse record at all, so step one produced nothing to carry into step two. And 45.33.32.156 reversed to scanme.nmap.org, which is a plainly non-Google name and the shape a crude impostor produces.

Why can’t this site run the Googlebot verification check on its own log?

This site’s crawler log records no addresses at all, only the visitor’s self-description and the page it asked for. I established that while walking the collection pipeline for a static site with no server logs can still run real log analysis, and re-read the query on September 8 to be sure nothing had changed. The request to Cloudflare asks for two fields, the visitor’s self-description and the page path, and no field carrying the numeric address the request came from.

So every bot figure this site publishes rests on the user agent, which is the very thing this article says proves nothing. That is an uncomfortable position to be in and I would rather state it than let it sit unmentioned behind a chart.

Two honest consequences follow. Any count of Googlebot activity here is a count of claims, and the true number could be lower. Adding the address field would make the check possible, at the cost of collecting a piece of personal data this site currently does not hold, which is a real trade and not an obvious yes.

What should you do with the Googlebot verification check result?

Verify before you act on an identity, and only when acting on it costs something. Running this check on every request in a busy log would be a lot of lookups for very little, so save it for the moments where being wrong matters.

Three of those moments are common. Before you block traffic that claims to be a crawler, confirm what it is, because blocking a real Googlebot is a costly mistake made in the name of tidiness.

Before you serve different content to a crawler than to a person, verify, since an unverified rule of that shape is a cloaking risk. And when investigating a traffic spike attributed to a search engine, check a sample of the addresses before you build any conclusion on the attribution.

Cache what you learn. An address that passes today will almost certainly still be Google tomorrow, so a short-lived record of verified addresses turns an expensive per-request check into a cheap lookup.