Google is moving crawler IP range files to a new home
Google has announced that the JSON files listing IP ranges for its crawlers are moving from developers.google.com/search/apis/ipranges/ to developers.google.com/crawling/ipranges/. The announcement is published on the Google Search Blog and applies to crawler traffic used across several Google products, not only Google Search.
The previous location will remain available for a six-month transition period and then redirect, but Google has already updated its documentation to point to the new path. If your organisation fetches these JSON files automatically, or you have internal documentation that references the old URL, this is the moment to update it.
Why Google made this change
A clearer separation between Search documentation and crawling infrastructure
The practical reason is organisation: the IP ranges support crawling for multiple Google products such as Search, Shopping, AdSense, and Gemini. Housing IP ranges under a /crawling/ section better reflects that these lists serve a broader crawling ecosystem, rather than being a Search-only resource.
What stays the same for site owners
The move is primarily a URL change for the published JSON. It does not indicate that Google is changing its crawling identity model, how robots.txt is interpreted, or how Googlebot should be verified. What changes is where you retrieve the “source of truth” for IP allowlists.
What is in the IP range files
Different crawler categories, different operational expectations
Google publishes separate JSON files that group IP ranges by crawler type. The categories matter because Google operates multiple crawlers with different purposes. Some are standard web crawling agents associated with indexing, while others support advertising verification or user-triggered actions in Search Console.
Daily updates and a large, shifting set of CIDR blocks
Google’s crawler IP ranges are extensive, spanning both IPv4 and IPv6 CIDR blocks and refreshed on a frequent cadence. This detail is important operationally: if you are using allowlists, you are not dealing with a static set of addresses that you can update once a year. You need a process that keeps pace with change.
What this means for technical SEO and site operations
It is a reminder to treat “allowlisting Google” as an engineering workflow
Many SEO teams only discover firewall allowlisting issues after a crawl drop, delayed indexing, or repeated “URL is not on Google” messages in Search Console. Google’s update highlights a broader point: if you maintain any controls that restrict bot access, your controls should be managed as living configuration, not a one-off task.
If your security policy requires explicit allowlisting for inbound traffic to staging, pre-production, APIs, or parts of your site, make sure the automation that retrieves Google’s IP ranges now pulls from the new /crawling/ipranges/ path. Treat the six-month transition period as a grace window, not a comfort blanket.
How the change can show up as an SEO issue
A surprising number of indexing and rendering problems are self-inflicted by network policies. If your rules stop matching Google’s current ranges, Googlebot can be partially blocked. That can present as slower discovery of new URLs, incomplete rendering for JavaScript-heavy pages, missed resources such as CSS, or sudden volatility in crawl stats.
Even if the main HTML is accessible, blocking supporting assets can affect how Google renders pages and understands layout, navigation, and interactivity. That can have knock-on effects for how content is interpreted and, in some cases, how it performs in search results.
Questions and answers
Do I need to do anything if I do not block bots?
If you do not use IP allowlisting, you may not need to change anything. This announcement mainly affects organisations that programmatically fetch Google’s published ranges for firewalls, WAF rules, ACLs, rate limits, origin protection, or log classification.
Should I rely on IP allowlisting alone to verify Googlebot?
IP allowlisting helps, but it is not the only verification method. A robust approach is to combine Google’s official IP ranges with DNS-based verification for specific requests when needed. That matters if you are investigating suspicious traffic claiming to be Googlebot, or when you need to be confident about granting elevated access.
Will this change how robots.txt works?
No. Robots rules are evaluated based on user-agent behaviour, not which URL hosts the IP range files. That said, different Google crawlers can behave differently. Some are standard crawling agents associated with indexing and typically respect robots.txt, while other specialised crawlers may have different constraints depending on the feature they support.
Could this affect my crawl budget?
Indirectly, yes. Crawl budget issues often become visible when Google encounters repeated errors, slow responses, blocked resources, or inconsistent access. If a firewall configuration becomes stale because it still references the old download location and your automation fails, you may end up blocking new ranges and increasing error rates. Over time, that can reduce crawl efficiency and delay updates appearing in the index.
Practical ways to adapt without creating new risk
Update the retrieval URL now, then confirm you are still receiving fresh data
Switch any scripts, integrations, or vendor tooling to the new developers.google.com/crawling/ipranges/ location. After the change, validate that your jobs still run on schedule and that the fetched content changes over time, rather than silently failing and leaving you with an out-of-date allowlist.
Use the right scope when you allowlist
A common mistake is to allowlist only “Googlebot” while forgetting other legitimate Google fetchers used by Search Console or product-specific crawlers. If your workflow depends on tools such as URL Inspection, live tests, or other user-triggered fetches, ensure your policy aligns with those needs. Overly narrow allowlisting can create confusing behaviour where Search Console fetches fail even though normal crawling appears fine, or the other way around.
Example: protecting an origin server without blocking rendering
Suppose you serve HTML from an origin protected by a WAF, with images, CSS, and JavaScript coming from a CDN. If you allowlist Google to the HTML origin but forget that essential CSS is behind a separate firewall rule, Google may fetch the HTML successfully but fail to render the page properly. A better setup is to ensure that every critical resource required for rendering and navigation is equally accessible to Google’s relevant crawlers, not only the document URL.
What to watch over the next six months
Keep an eye on crawl errors and sudden dips in fetches
During the transition window, teams may update some systems but miss others. If you have multiple environments, vendors, or legacy scripts, it is easy to leave a hidden dependency pointing at the old location. Monitor crawl error trends, server logs for Google crawler requests, and Search Console signals that indicate fetch problems.
Plan for redirects rather than relying on them
Google has indicated the old location will redirect after the transition period. Redirects are helpful, but security and automation tooling can treat redirects differently, sometimes rejecting them or failing to follow them. Treat the redirect as a backup, not a design requirement.
Takeaway for SEO teams
This is a technical housekeeping change with real operational consequences
The announcement is not a ranking update, but it can still affect organic performance if it causes accidental blocking or delayed crawling. SEO teams should use this moment to audit how their organisation handles crawler access: confirm where allowlists live, how they are updated, which Google crawler categories are required for business workflows, and whether critical rendering resources remain reachable.
