Zakresy IP robotów Google przeniesione: aktualizacja allowlist w NGINX

Pliki JSON z zakresami IP robotów Google zmieniają adres. Stare miejsce: /search/apis/ipranges/. Nowe miejsce: developers.google.com/crawling/ipranges/. Każdy skrypt, który zasila allowlistę w NGINX albo w firewallu, musi więc dostać nową ścieżkę. Google opublikowało ogłoszenie o nowej lokalizacji 31 marca 2026 roku i podaje, że stary adres na razie działa, a w ciągu sześciu miesięcy zostanie przekierowany. Wpuszczasz Googlebota po IP i pobierasz te pliki automatycznie? W takim razie ta poprawka jest po Twojej stronie.

Co się zmieniło w zakresach IP robotów Google?

Adres URL. I tyle. Pliki opuszczają katalog /search/apis/ipranges/ w serwisie developers.google.com i leżą teraz pod developers.google.com/crawling/ipranges/. Uzasadnienie Google: zakresy dotyczą nie tylko robotów wyszukiwarki, więc należy im się bardziej ogólne miejsce. Niech będzie. Żądania do poprzedniej ścieżki dziś nadal się udają, a później odpowiedzią na nie będzie przekierowanie. W ogłoszeniu nie ma nic o zmianie zawartości plików ani notacji CIDR, więc parser może zostać dokładnie taki, jaki jest.

Które pliki JSON obejmują które roboty?

Google dzieli swoje roboty na trzy grupy, a każda grupa ma własny plik. To, jak traktują robots.txt, jest opisane na stronie o weryfikacji żądań od Google:

• Roboty ogólne, takie jak Googlebot, wymienione w common-crawlers.json, przy automatycznym crawlowaniu zawsze przestrzegają reguł robots.txt.
• Roboty do zadań specjalnych, takie jak AdsBot, wykonują konkretne zadania dla produktów Google i mogą przestrzegać robots.txt albo nie.
• Narzędzia pobierające uruchamiane przez użytkownika, takie jak Google Site Verifier, ignorują robots.txt, bo o pobranie poprosił człowiek.

Ta ostatnia grupa jest najbardziej zagmatwana. Obejmuje pliki user-triggered-fetchers.json, user-triggered-fetchers-google.json i user-triggered-agents.json. Adresy z pliku -google rozwiązują się do nazwy hosta w domenie google.com, a te z user-triggered-fetchers.json do gae.googleusercontent.com. Moja rada: wybierz grupy, których Twoja strona naprawdę potrzebuje, i pomiń resztę, zamiast importować wszystko na wszelki wypadek. A wiedza o tym, skąd Googlebot crawluje strony, jest równie ważna jak znajomość jego adresów.

Jak zaktualizować skrypty, które pobierają JSON z zakresami IP Googlebota?

Podmień starą ścieżkę wszędzie, gdzie występuje, i spraw, żeby krok pobierania był wybredny wobec tego, co przyjmuje. Ja zrobiłbym to w tej kolejności:

1. Przeszukaj grepem zadania crona, zarządzanie konfiguracją, pipeline’y CI i narzędzia firewalla pod kątem /search/apis/ipranges/.
2. Wstaw nowy adres /crawling/ipranges/ dla każdego pliku, którego używasz.
3. Każ klientowi HTTP podążać za przekierowaniami, żeby odwołanie, o którym zapomniałeś, przetrwało zmianę.
4. Sparsuj odpowiedź jako JSON, zanim odczyta ją cokolwiek innego.
5. Zakończ działanie błędem, gdy plik jest pusty, uszkodzony albo nie zawiera żadnych prefiksów.

Trzymaj ostatnią dobrą kopię obok skryptu. Nieudane pobranie nie może nigdy wyczyścić allowlisty. Nigdy. Adresy przychodzą w formacie CIDR, a Twój kod musi obsługiwać prefiksy zarówno IPv4, jak i IPv6 (o tym drugim łatwo zapomnieć).

Budowanie allowlisty Googlebota w NGINX na podstawie plików

Nie wpisuj zakresów ręcznie. Generuj plik include z JSON-a. Główna konfiguracja nie powinna zawierać żadnych prefiksów - ma tylko wskazywać osobny plik, który skrypt nadpisuje przy każdym uruchomieniu. Dobrze pasuje tu blok geo:

geo $google_crawler {
    default 0;
    include /etc/nginx/generated/google-crawlers.conf;
}

location /restricted/ {
    if ($google_crawler = 0) {
        return 403;
    }
}

Każda linia wygenerowanego pliku to jeden prefiks, a po nim 1;. Proste. Jest jednak jeden haczyk: jeśli przed Twoim hostingiem stoi reverse proxy NGINX z adresami z UE albo USA, takie jak Jalvo, zastosuj regułę na serwerze źródłowym, gdzie widać prawdziwe IP klienta. A czy to jest cloaking? Nie. Zmienna decyduje wyłącznie o dostępie, a każdy odwiedzający, który przejdzie, dostaje identyczną treść. Ta sama wygenerowana mapa przydaje się, gdy konfigurujesz ochronę przed hotlinkowaniem w Google Images i chcesz wyłączyć z niej prawdziwe roboty.

Odświeżaj według harmonogramu i testuj na sucho

Ustaw zadanie pobierania i przebudowy w harmonogramie, żeby allowlista nadążała za tym, co publikuje Google. Ale każde uruchomienie powinno zaczynać się od próby na sucho:

• zapisz nowy include do pliku tymczasowego,
• porównaj go diffem z działającym,
• uruchom nginx -t,
• przeładuj tylko wtedy, gdy test przejdzie.

Loguj każdy dodany i usunięty prefiks. Wysyłaj alert, gdy pobieranie się nie powiedzie albo diff jest nieoczekiwanie duży. A po przejściu na nową ścieżkę przejrzyj logi dostępu pod kątem odrzuconych żądań z user agentem Googlebota. Zdradzają one brakującą grupę albo nieaktualny plik.

Jak zweryfikować IP Googlebota, gdy żądanie wygląda podejrzanie

Google opisuje dwie metody: ręczne sprawdzenie w DNS dla pojedynczych przypadków oraz automatyczne dopasowywanie do opublikowanych list przy dużej skali. Jednorazowo wykonaj odwrotne zapytanie DNS dla adresu i potwierdź, że nazwa hosta kończy się na googlebot.com, google.com albo googleusercontent.com. Potem wykonaj zapytanie w przód i porównaj wynik z pierwotnym IP. A co z nagłówkiem user agent? Niczego nie dowodzi, bo wysłać go może każdy. Liczy się adres.

Cała robota z zakresami IP robotów Google sprowadza się więc do czterech rzeczy: skieruj skrypty na nową ścieżkę, pozwól im podążać za przekierowaniami, przebudowuj allowlistę według harmonogramu i trzymaj prefiksy z dala od ręcznie pisanej konfiguracji.

FAQ