In short. Reverse DNS bot verification checks a logged IP against an operator's documented hostname and confirms that the hostname resolves back to the same IP.

Definition: Reverse DNS bot verification checks a crawler's claimed identity by resolving its logged IP address to a hostname, checking the operator's documented domain, and resolving that hostname back to the original IP address.

As of October 2026, Google's verification procedure uses the requesting IP address recorded in server logs. DNS means Domain Name System; a reverse lookup maps an address to a hostname, while a forward lookup maps that hostname to an address.

Key facts

Google's request verification procedure requires the forward lookup to return the original accessing IP address.
Google's common crawler documentation warns that the HTTP user-agent string, the request text identifying a client, can be spoofed.
Common Crawl's CCBot documentation describes dedicated address ranges with reverse DNS, except for IPv6 requests.

How do the reverse and forward checks work?

Google's command-line instructions begin with a reverse lookup using the host command. The returned hostname must belong to a documented Google domain. The next lookup uses that exact hostname and checks whether the result matches the logged address.

Google provides this example:

host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

The first result supplies crawl-66-249-66-1.googlebot.com; the second returns 66.249.66.1. Both checks form the verification procedure. The values above reproduce Google's documentation example; an investigation starts with the address from the request being examined.

Which hostname should the check accept?

Google's verification table separates common crawlers, special-case crawlers and user-triggered fetchers. Common crawlers such as Googlebot use hostname patterns under googlebot.com, including geo.googlebot.com. Special-case crawlers such as AdsBot use the rate-limited-proxy hostname pattern under google.com.

The same table associates user-triggered fetchers with google.com or gae.googleusercontent.com hostnames, depending on the address list. A measurement report therefore needs the documented crawler category alongside the hostname match. Treating every Google-related hostname as Googlebot would merge the categories that Google distinguishes.

Other operators publish their own conventions. Common Crawl's verification example uses a hostname under crawl.commoncrawl.org and shows the corresponding forward lookup. Google's domain list applies to Google's verification procedure.

How can larger request sets be checked?

Google's automatic verification guidance recommends comparing crawler IP addresses with its published address lists for large-scale lookups. It lists common-crawlers.json for common crawlers such as Googlebot and separate files for other request categories. This offers a documented alternative to performing paired DNS lookups for each address.

Common Crawl also publishes its address ranges through https://index.commoncrawl.org/ccbot.json. Its documentation states that reverse DNS is unavailable over IPv6. For those CCBot addresses, the published range list supplies the documented verification route.

FAQ

Is a reverse lookup enough?

Google's procedure also requires you to check the domain and perform a forward lookup. You then compare the returned address with the original request address in your logs.

Can I use Google's hostname rules for CCBot?

Use the operator's own documentation. Common Crawl demonstrates a hostname under crawl.commoncrawl.org and provides its own address-range file.

Sources

Check how a page reads to answer engines. Open the GEO score analyzer