Verified versus spoofed Googlebot
also called Bot verificationGooglebot IP verification
Definition
How many requests claiming to be Googlebot came from an address Google publishes, and how many did not.
How it's calculated
Log records whose declared bot type is Googlebot are joined to an address lookup that flags whether the requesting address is a Google one, and counted on each side of that flag. The join is an INNER one on the requesting address, so a request whose address is absent from the lookup table is dropped from the result entirely rather than landing on the unverified side.
Scope, grain and dimensions
- Grain
- One count per verification state per date range.
- Dimensions
- bot_type · is_googlebot_ip
- Required filters
- date_range
- Aggregation
- Counts per verification state. The two sides do NOT add to the total of declared-Googlebot requests, anything whose address the lookup does not know is excluded by the join, so the split describes only the addresses the lookup recognises.
- Metric type
- raw measure · log requests, split by verified and unverified
Data sources
Where you'll see this
Named reports that normally include this metric.
AI bot activity reportCrawl log reportTechnical SEO audit report
Skills and analyses that use it
Skills carry the judgment; the analysis verbs do the reading.
Analysis verbs
bot_verification
Method rungs and levers
This sits on the bottom rung: if it reads badly, every measurement above it is unreliable.
levers L1 Technical & crawl health
Ask Quattr
- "Are fake Googlebots hitting us?" Simulate this →
- "Can we trust our crawler traffic?" Simulate this →
How to read it
The only claim in this set that separates what a client said it was from what it demonstrably is. The split itself is the finding, a large unverified share means the crawl numbers describing that bot are worth less than they look. Read it as a floor on spoofing rather than a measurement of it: the join keeps only requests from addresses the lookup already knows, so an impostor arriving from an address nobody has catalogued never reaches either column.
Caveats, freshness and failure modes
The two sides do not reconcile to the declared-Googlebot total. The address lookup is joined INNER, so unknown addresses are dropped rather than counted as unverified, never compute one side by subtracting the other from a hit count.
For the same reason the unverified figure UNDERSTATES spoofing, and by an unknown amount: the requests most likely to be missing from an address catalogue are exactly the ones least likely to be Google.
Googlebot only. The tool filters to the declared Googlebot type and joins a Google-specific address lookup; there is no equivalent verification for any answer-engine crawler.
That means AI-bot figures elsewhere in this set rest on user-agent strings alone, with no address check behind them.
Verification is a per-request property, so a single source can appear on both sides of the split within a period.
Same origin-only caveat as all log reads.
- Freshness
- hours to nightly, depends on how logs are shipped; the card carries the ingestion time.
Common failure modes
- Treating the two counts as a partition of declared-Googlebot traffic, or deriving one from the other.
- Quoting the unverified count as the amount of spoofing rather than as a lower bound on it.
- Assuming AI crawler counts are verified the same way, they are not.
- Including unverified traffic in a crawl-coverage verdict.
Not the same as
The confusions that cause the most wrong decisions.
Verified versus spoofed Googlebot Bot hits Compare definitions →
Hit counts are matched on the declared user agent alone. Only this metric establishes whether the requester was who it claimed to be, and only for Googlebot.
Watch this metric read in a real run
All runs →
Related metrics and workflows
Metrics
Verification
A definition is the smallest part of this.
The measurement matters because something acts on it. Here is the rest of the showcase, in the order most people find useful.