AI Summary
Google publishes its official Googlebot IP ranges as a downloadable JSON file, so you can verify a crawler by its IP address instead of trusting a user agent string that anyone can forge. Confirm Googlebot with a reverse DNS lookup that resolves to google.com or googlebot.com, or by matching the request IP against the published ranges.
- The Googlebot ranges live in a JSON file at developers.google.com and change over time, so fetch them rather than hardcoding.
- Reverse DNS plus a forward confirmation is the classic verification method and still works reliably.
- Google also publishes separate JSON files for its special crawlers and user triggered fetchers.
- A request whose user agent says Googlebot but whose IP is not on the list is a spoof. Never allowlist by user agent alone.
List of Googlebot IP addresses released provides valuable insights for SEO practitioners. This resource examines approaches and considerations that can improve organic search performance.
Why an official IP list matters
The user agent string is just text the client sends, and anyone can set it to Googlebot. Scrapers, bad bots, and load testers do exactly that to slip past crude rules. Before Google published its ranges, the only trustworthy check was a reverse DNS lookup. Now there is a second, simpler option: match the request IP against a maintained JSON file that Google updates as its infrastructure changes.
This matters in three places: firewall and rate limit rules that should never throttle real Googlebot, log analysis where you want to separate genuine crawl activity from noise, and analytics filtering so fake crawler hits do not pollute your numbers. If you are new to the crawler itself, our Googlebot glossary entry and user agent entry give the background.
Two ways to verify Googlebot
Method 1, reverse DNS. Run a reverse lookup on the requesting IP, confirm the hostname ends in googlebot.com or google.com, then run a forward lookup on that hostname to confirm it resolves back to the same IP. The round trip is what defeats a forged PTR record.
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.1Method 2, match the published ranges. Download the JSON file, then test whether the request IP falls inside any listed CIDR block. Because Google maintains the file, you get automatic coverage as ranges are added or retired, with no reverse DNS round trip per request.
The files Google publishes
There is more than one list, and using the right one avoids blocking a legitimate fetch. The current set:
| File | Covers | Typical use |
|---|---|---|
| googlebot.json | Core Googlebot crawling for Search | Verify normal crawl traffic and protect it in firewall rules |
| special-crawlers.json | Special case crawlers such as AdsBot and the site verification fetcher | Avoid throttling product specific crawls |
| user-triggered-fetchers.json | Fetches a user or product action starts, such as Rich Results testing | Recognize on demand fetches that are not scheduled crawling |
All three are linked from Google Search Central under crawler verification. Fetch them on a schedule and cache the parsed ranges; do not paste the addresses into a rule by hand, because they change.
Putting it to work
A practical pattern for a busy site: in your edge or firewall layer, allow requests whose IP verifies against googlebot.json to bypass rate limits, and never serve them a challenge page or a CAPTCHA. In log analysis, tag verified Googlebot hits so crawl budget and coverage reports reflect the real crawler. In analytics, drop unverified hits that merely claim to be Googlebot. For blocking versus allowing crawlers by rule rather than by identity, pair this with a clean robots file: see our robots.txt complete reference.
What has changed since this list was announced
When Google first published Googlebot IP ranges in late 2021 it was a single verification file, and the reverse DNS method was the older fallback. Since then the picture has widened in two ways. First, Google split the published data into multiple files so you can distinguish core crawling from special crawlers and from user triggered fetchers, which prevents accidentally blocking a legitimate on demand fetch. Second, the rise of AI crawlers made crawler identity a live topic again: Google Extended and other AI user agents are separate from Search crawling, and site owners increasingly filter them deliberately. Our overview of AI bot user agents covers who is who. The verification principle is unchanged: trust the IP, never the user agent string.
Frequently asked questions
Google publishes them as JSON at developers.google.com/search/apis/ipranges. The main file is googlebot.json, with separate files for special crawlers and user triggered fetchers. The ranges change, so fetch the file rather than hardcoding addresses.
Use one of two methods: run a reverse DNS lookup and confirm the hostname ends in googlebot.com or google.com, then forward confirm it resolves back to the same IP; or match the request IP against Google's published range files. Do not trust the user agent alone.
Yes, trivially. The user agent is just a text header the client controls, so any scraper can claim to be Googlebot. That is exactly why you verify by IP or reverse DNS instead of allowlisting a user agent string.
Usually yes. A request that says Googlebot but comes from an unlisted IP is almost always a spoof or a scraper. Blocking or challenging it is reasonable, while verified Googlebot should always bypass rate limits and challenges.
Yes. Google updates the JSON files as its infrastructure changes, which is the main reason it publishes them in machine readable form. Fetch and cache the current ranges on a schedule instead of pasting fixed addresses into a rule.
Both are valid. The IP list is simpler and gives automatic coverage as ranges change, with no per request lookup. Reverse DNS needs a round trip but works without downloading a file. Many sites use the IP list for speed and keep reverse DNS as a fallback.
This resource contributes to the knowledge base SEO practitioners need for effective optimization in an evolving search landscape.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
