Agent użytkownika

TL;DR — User agent to krótka linia tekstu, którą każda przeglądarka i każdy bot wysyła z każdym żądaniem, mówiąc „oto kim jestem”. Robot Google podaje się za Googlebota; Binga — za bingbota. W robots.txt nie wpisujesz całej linii — używasz krótkiej nazwy („tokena”), np. Googlebot. I tu jest haczyk: ta linia to tylko tekst, więc każdy może ją sfałszować. Jedynym pewnym sposobem, aby sprawdzić, czy bot jest tym, za kogo się podaje, jest zweryfikowanie, skąd faktycznie pochodzi jego żądanie.

Czym jest user agent

Za każdym razem, gdy Twoja przeglądarka ładuje stronę, wysyła krótką etykietę tekstową, która mówi, czym jest — coś w rodzaju „Jestem Chrome na Macu”. Ta etykieta to user agent, i podróżuje w nagłówku HTTP przy każdym żądaniu. Serwery mogą ją odczytać i zareagować na nią.

Ważny haczyk na początek: klient sam wypełnia tę etykietę. Nikt tego nie sprawdza. To deklaracja, a nie poświadczenie — więc user agent, który mówi „Googlebot”, to nie to samo co żądanie faktycznie zweryfikowane jako Googlebot.

Roboty indeksujące robią to samo. Gdy Googlebot pobiera Twoją stronę, wysyła user agent, który zawiera Googlebot. Gdy Bingbot ją pobiera, user agent zawiera bingbot. W ten sposób bot przedstawia się w logach Twojego serwera.

Ciąg znaków a krótka nazwa

Tak naprawdę ludzie mają na myśli dwie rzeczy, mówiąc „user agent”, a mylenie ich powoduje sporo zamieszania:

• Ciąg user-agenta to pełna linia w nagłówku żądania. Ciąg Googlebota jest długi i wygląda bardzo podobnie do przeglądarki.
• Token user-agenta to krótka nazwa, której używasz w robots.txt, aby kierować do konkretnego bota — np. Googlebot lub bingbot. Token to tylko fragment pełnego ciągu, a nie całość.

Więc gdy piszesz regułę w robots.txt, używasz krótkiego tokena:

User-agent: Googlebot
Disallow: /private/

Nie wklejasz tam ogromnego ciągu wyglądającego jak przeglądarka.

Nie możesz ufać ciągowi

To jest jedna rzecz, którą warto zapamiętać. Linia user-agenta to zwykły tekst, więc wszystko może ją sfałszować. Każdy skrypt może w jednej linii kodu podać się za Googlebota — i wiele tak robi, aby ominąć blokady. Sam Google przyznaje, że nagłówek Googlebota jest „często sfałszowany”.

To oznacza, że nigdy nie powinieneś decydować o tym, kto ma dostęp do Twojej witryny, wyłącznie na podstawie user-agenta. Jeśli naprawdę musisz potwierdzić, że odwiedzający to prawdziwy Googlebot (powiedzmy, czytasz logi), weryfikujesz to, sprawdzając skąd pochodzi żądanie — a nie to, co mówi o sobie. Zakładka Zaawansowane pokazuje dokładnie, jak to zrobić.

Kilka pułapek

• Nazwy user-agentów w robots.txt są niewrażliwe na wielkość liter — Googlebot i googlebot to to samo.
• Zablokowanie wszystkiego za pomocą User-agent: * nie blokuje wszystkich botów Google — jego roboty reklamowe i robot bezpieczeństwa ignorują symbol wieloznaczny.
• Pokazywanie jednej wersji strony robotowi indeksującemu, a innej prawdziwym ludziom to cloaking, a Google traktuje to jako spam.

Chcesz pełny obraz — tabele tokenów, każdy robot Google i Binga, dokładne polecenia weryfikacji i zasady cloakingu — przełącz się na zakładkę Zaawansowane.

TL;DR — User agent to nagłówek żądania HTTP, który każdy klient wysyła, aby się zidentyfikować; to opcjonalne, wypełniane przez klienta metadane, a nie uwierzytelniona tożsamość. Jego wartość to ciąg user-agenta. Osobno od tego istnieje token user-agenta (token produktu) używany w robots.txt — RFC 9309 mówi, że POWINIEN być podciągiem ciągu, co jest silną konwencją z udokumentowanymi wyjątkami (Google-Extended nie ma żadnego ciągu żądania). Dopasowywanie nie uwzględnia wielkości liter, numery wersji/wildcardy w linii tokena są ignorowane, najbardziej specyficzna grupa wygrywa, a grupy z tym samym tokenem łączą się, ale nigdy nie łączą się z *. Ciąg można trywialnie sfałszować — Google nazywa swój własny “często sfałszowany” — więc weryfikuj przez odwrotny i bezpośredni DNS (za jakimkolwiek proxy/CDN, użyj prawdziwego IP klienta) względem googlebot.com/google.com/googleusercontent.com dla Google lub search.msn.com dla Binga, albo dopasuj opublikowane zakresy IP — a nawet zweryfikowane żądanie tylko dowodzi, że żądanie dotarło, a nie że strona została zaindeksowana, pobrana lub użyta do trenowania AI. AdsBot i Google-Safety ignorują User-agent: *. Chrome również zamraża szczegóły w ciągach UA przeglądarek (redukcja User-Agent); Client Hints to strukturalny, ale opcjonalny zamiennik, a żaden z nich nie zastępuje weryfikacji crawlera. Adaptacja user-agenta może być uzasadniona, ale zwodnicze pokazywanie crawlerom znacząco innych treści może być cloakingiem.

Nagłówek, ciąg i token

Trzy rzeczy, a ich rozróżnienie to większość tego tematu.

• Nagłówek. User-Agent to nagłówek żądania HTTP. Wysyła go każdy klient: twoja przeglądarka, curl, crawler, bot. Zgodnie z RFC 9110 (podstawowy standard semantyki HTTP) to opcjonalne pole wypełniane przez klienta — dostarczane przez klienta metadane opisowe, a nie uwierzytelniona tożsamość zweryfikowana przez serwer.
• Ciąg. Wartość nagłówka — swobodna linia opisująca oprogramowanie, wersję, silnik renderujący, a czasem system operacyjny.
• Token. Krótki identyfikator używany w liniach User-agent: w robots.txt do kierowania do crawlera — Googlebot, bingbot, Google-Extended.

Relacja to część, która sprawia ludziom problemy. RFC 9309 (formalny standard Robots Exclusion Protocol) mówi, że token “SHOULD be a substring of the identification string that the crawler sends… in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (tłumaczenie) „POWINIEN być podciągiem ciągu identyfikacyjnego, który wysyła crawler… w przypadku HTTP token produktu POWINIEN być podciągiem w nagłówku User-Agent.” To SHOULD, a nie MUST — silna konwencja zalecana przez standard, a nie twardy wymóg, do którego każdy crawler jest mechanicznie zobowiązany. Google-Extended (poniżej) to najczystszy przykład udokumentowanego wyjątku od tego. Nie czytaj reguły podciągu jako uniwersalnej tylko dlatego, że Google stosuje ją do większości swoich własnych tokenów. Token jest częścią ciągu, gdy dostawca taki dostarcza; kierujesz do tokena w robots.txt i czytasz ciąg w swoich logach.

Własne ujęcie Google dotyczące tego, jak identyfikują się jego boty, jest tutaj przydatne: “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (tłumaczenie) „Crawlery Google identyfikują się przez trzy rzeczy: nagłówek żądania HTTP user-agent, źródłowy adres IP żądania oraz odwrotną nazwę DNS źródłowego IP.” Zauważ, że user-agent to tylko jedna z trzech — pozostałe dwie to jak faktycznie go weryfikujesz.

Google-Extended: token bez ciągu

Najczystszą ilustracją token ≠ ciąg jest Google-Extended. Kontroluje on, czy Google może używać twoich treści do trenowania Gemini i uziemiania — i nie ma żadnego dedykowanego ciągu user-agenta w żądaniu HTTP. Samo indeksowanie odbywa się z istniejącymi ciągami Googlebot; Google-Extended istnieje tylko jako token kontrolny robots.txt. Nigdy nie zobaczysz „Google-Extended” w nagłówku żądania w swoich logach.

Praktyczna konsekwencja: zablokowanie Google-Extended wpływa tylko na wykorzystanie Twoich treści do szkolenia AI — nie powstrzymuje Googlebota przed indeksowaniem i skanowaniem Twojej witryny pod kątem wyszukiwarki. To osobne decyzje kontrolowane przez osobne tokeny. (Szerszy obraz botów czytających Twoją witrynę znajdziesz w artykułach o botach AI i o botach indeksujących.)

Ciągi znaków user-agenta Googlebota

Googlebot jest „evergreen” — działa na najnowszej wersji Chrome, a wersja Chrome w jego ciągu znaków jest aktualizowana okresowo (od grudnia 2019). Dlatego wersja pojawia się jako symbol zastępczy W.X.Y.Z:

Googlebot Smartphone (mobile):

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Dwie rzeczy do zapamiętania. Po pierwsze, nie koduj na sztywno wersji — W.X.Y.Z się zmienia, a dopasowanie do niej się zepsuje. Zamiast tego dopasowuj stabilny token Googlebot. Po drugie, nie możesz rozdzielić mobile od desktop w robots.txt. Obie wersje dzielą jeden token Googlebot, więc reguła w robots.txt dotyczy obu.

Tokeny robotów Google

Google prowadzi całą rodzinę robotów i pobieraczy, każdy z własnym tokenem. Te, które spotkasz najczęściej:

Oraz te, które łamią zwykłe zasady — specjalne roboty, które ignorują User-agent: *:

• AdsBot (AdsBot-Google) i AdsBot Mobile (AdsBot-Google-Mobile) — nie przestrzegają symbolu wieloznacznego. Aby je zablokować, musisz je wymienić jawnie.
• AdSense (Mediapartners-Google) — to samo; ignoruje globalny *.
• Google-Safety — używany do wykrywania złośliwego oprogramowania/nadużyć; całkowicie ignoruje robots.txt.

Implikacja, którą ludzie przeoczają: User-agent: * nie blokuje AdsBota ani Google-Safety. Jeśli „zablokujesz wszystkie boty” symbolem wieloznacznym i założysz, że AdsBot zniknął, to tak nie jest. (To dokładnie ten rodzaj niespodzianki, który prowadzi do sytuacji, gdy strona jest zaindeksowana, ale zablokowana przez robots.txt — zobacz robots.txt, aby poznać pełną historię kontroli.)

Ciągi znaków user-agenta Bingbota

Bing przebudował ciąg Bingbota w 2022, aby odzwierciedlić, że renderuje on w Microsoft Edge. Obecne ciągi:

Bingbot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot Mobile:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

Token robots.txt to po prostu bingbot. Na co uważać: po 2022 ciąg Bingbota wygląda prawie jak prawdziwa przeglądarka Chrome/Edge — jedyną wskazówką jest fragment bingbot/2.0 w środku. Jeśli masz jakąkolwiek logikę, która filtruje lub wykrywa boty po UA, ta zmiana ma znaczenie.

Jak robots.txt faktycznie dopasowuje token

Kilka zasad określa, której grupy reguł przestrzega robot (zgodnie ze specyfikacją robots.txt Google i RFC 9309):

• Najbardziej szczegółowe dopasowanie wygrywa. Google „określa właściwą grupę reguł, znajdując… grupę z najbardziej szczegółowym user-agentem, który pasuje do user-agenta robota.” Grupa Googlebot wygrywa z grupą * dla Googlebota.
• Grupy z tym samym tokenem łączą się — ale nigdy z *. Wiele grup wymieniających tego samego agenta jest łączonych w jedną. Grupa dla konkretnego agenta i grupa * nie są łączone; * jest tylko fallbackiem, gdy nic konkretnego nie pasuje.
• Niewrażliwe na wielkość liter. Zarówno nazwa pola, jak i wartość — Googlebot, googlebot, GOOGLEBOT są równoważne.
• Numery wersji i symbole wieloznaczne w linii tokena są ignorowane. Według Google, „zarówno googlebot/1.2, jak i googlebot* są równoważne z googlebot.” Nie możesz napisać User-agent: Googlebot*, aby dopasować rodzinę — * tam nic nie robi.

Zatem linia User-agent: przyjmuje token i dopasowuje go jako zwykły (niezależny od wielkości liter) podciąg tożsamości crawlera — bez przypinania wersji, bez wildcardów w środku.

Dlaczego nie możesz ufać temu stringowi — i jak to zweryfikować

String user-agenta to dowolny tekst. Cokolwiek może go ustawić. Jedna linia curl może udawać Googlebota, a wiele narzędzi i złośliwych botów robi dokładnie to, aby ominąć blokady. Google mówi o tym w swojej dokumentacji Googlebota: “the HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (tłumaczenie) „nagłówek żądania HTTP user-agent używany przez Googlebota jest często podszywany przez inne crawlerów.” Jak ująłem to w moim przewodniku po Googlebocie, “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (tłumaczenie) „Wiele narzędzi SEO i niektóre złośliwe boty udają Googlebota. Może im to pozwolić na dostęp do stron, które próbują je zablokować.”

Więc nigdy nie podejmuj decyzji o dostępie ani treści na podstawie samego stringa. Zamiast tego zweryfikuj.

Jeden warunek wstępny przed obiema metodami: zdobądź prawdziwy adres IP źródła. Jeśli Twoja strona jest za odwrotnym proxy, load balancerem lub CDN, adres w domyślnym logu dostępu może być adresem proxy, a nie crawlera — potrzebujesz oryginalnego adresu IP klienta (zwykle przekazywanego w nagłówku takim jak X-Forwarded-For, poprawnie skonfigurowanym na Twoim proxy), w przeciwnym razie żadna z poniższych metod weryfikacji nie ma sensu.

Metoda 1 — odwrotny + zgodny DNS (najlepsza do pojedynczych sprawdzeń). Dwa kroki Google:

1. “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (tłumaczenie) „Wykonaj odwrotne wyszukiwanie DNS dla adresu IP z logów, używając polecenia host. Sprawdź, czy nazwa domeny to googlebot.com, google.com lub googleusercontent.com.”
2. “Run a forward DNS lookup on the domain name retrieved in step 1… Verify that it’s the same as the original accessing IP address from your logs.” (tłumaczenie) „Wykonaj zgodne wyszukiwanie DNS dla nazwy domeny uzyskanej w kroku 1… Sprawdź, czy jest taka sama jak oryginalny adres IP z logów.”

Dla Bingbota ten sam dwukrokowy taniec, ale hostname musi kończyć się na search.msn.com (nie domena z marką Bing — częsta niespodzianka). Polecenia są w zakładce Skrypty.

Metoda 2 — opublikowane zakresy IP (najlepsza na dużą skalę). Google nie publikuje statycznej listy dozwolonych adresów do hardkodowania (“these IP address ranges can change” (tłumaczenie) „te zakresy adresów IP mogą się zmieniać”), ale publikuje maszynowo czytelne pliki CIDR JSON, które możesz dopasowywać (common-crawlers.json i szersze pliki crawlerów). Bing również publikuje swoje zakresy. Zbudowałem narzędzie do weryfikacji IP Googlebota właśnie do tego — wklejasz adresy IP, a ono je klasyfikuje. Bing Webmaster Tools ma też wbudowane narzędzie „Verify Bingbot”.

DNS jest lepszy do jednorazowego sprawdzenia logu; dopasowanie zakresów IP jest lepsze do weryfikacji na dużą skalę. Użyj tego, co pasuje — ale użyj jednego z nich. I traktuj zarówno oczekiwane hostname, jak i pliki zakresów jako aktualne na dziś, nie stałe — Google i Bing zmieniały te ścieżki wcześniej (pliki JSON z zakresami IP zostały przeniesione i przemianowane od czasu pierwszej publikacji tego artykułu), więc sprawdź ponownie aktualny dokument weryfikacji, jeśli wyszukiwanie, które działało, przestaje pasować.

Dopasowanie UA nie jest dowodem na dalsze wyniki

Nawet w pełni zweryfikowane żądanie — prawdziwy adres IP Googlebota, potwierdzony zgodnym DNS, wszystko się zgadza — dowodzi tylko jednego: to żądanie dotarło do Twojego serwera. Kusi, aby zaokrąglić to do znacznie większego twierdzenia, ale każde z poniższych to osobny fakt wymagający osobnych dowodów:

• Żądanie odebrane — żądanie z tym agentem użytkownika trafiło na Twój serwer. (To faktycznie dowodzi weryfikacja logów.)
• Tożsamość potwierdzona — żądanie naprawdę pochodzi od robota, za którego się podaje. (To dodaje dopasowanie odwrotnego DNS / zakresów IP.)
• Treść pobrana i wyrenderowana — robot pomyślnie wyrenderował stronę (bez błędów, bez zablokowanych zasobów). Nie jest to gwarantowane tylko dlatego, że żądanie dotarło.
• Zaindeksowane — URL trafił do indeksu wyszukiwarki. Udane pobranie nie gwarantuje indeksowania.
• Użyte do wyszukiwania, cytowania lub trenowania — szczególnie w przypadku robotów AI (Google-Extended, GPTBot i inne), przeszukanie nie jest dowodem, że Twoje treści zostały pobrane dla konkretnej odpowiedzi, zacytowane lub użyte w trenowaniu modelu. To osobne, w większości nieobserwowalne kroki po przeszukaniu.

Zweryfikowane trafienie Googlebota w Twoich logach to realny sygnał — tylko nie rozciągaj go dalej, niż faktycznie pokazuje.

Web Bot Auth: dokąd zmierza weryfikacja

W 2026 roku Google zaczął eksperymentować z Web Bot Auth — “eksperymentalnym protokołem kryptograficznym używanym do uwierzytelniania żądań wysyłanych przez boty.” Chodzi o to, aby “wyjść poza łatwe do sfałszowania nagłówki w kierunku zweryfikowanej tożsamości i oddzielić tożsamość agenta od adresów IP.” Boty podpisują kryptograficznie swoje żądania; witryny weryfikują podpis względem opublikowanych kluczy publicznych Google, a podpisane żądania niosą nagłówek Signature-Agent. Zastrzeżenie Google ma znaczenie: “Nie podpisujemy każdego żądania konkretnego agenta. Upewnij się, że korzystasz z ustalonych metod weryfikacji botów.” Więc to rozszerzenie, a nie zamiennik — odwrotny DNS i zakresy IP pozostają Twoim punktem wyjścia.

Przeglądarki też są coraz trudniejsze do sparsowania z ciągu UA

Wszystko powyżej dotyczy robotów, ale ta sama zasada “nie ufaj za bardzo ciągowi” dotyczy przeglądarek i jest coraz silniejsza. Chrome wdraża redukcję User-Agent: zamrażanie lub zgrubianie części ciągu UA (pełna wersja przeglądarki, wersja systemu operacyjnego, model urządzenia) zamiast raportowania ich dokładnie, aby ciąg nie mógł być użyty do identyfikacji konkretnego użytkownika. Ujęcie Google: “Stopień granularności i bogactwo szczegółów mogą prowadzić do identyfikacji użytkownika. Domyślna dostępność tych informacji może prowadzić do ukrytego śledzenia.” Praktycznie oznacza to, że parsowanie ciągu UA pod kątem dokładnej wersji przeglądarki/systemu/urządzenia — analityka, wykrywanie urządzeń, triage błędów — jest coraz mniej niezawodne i będzie tylko gorzej.

Zamiennikiem, który zaleca Chrome, są User-Agent Client Hints (UA-CH): dane strukturalne, które przeglądarka wysyła tylko wtedy, gdy serwer wyraźnie o nie poprosi. Wskazówki o niskiej entropii (marka przeglądarki, główna wersja, flaga mobilna) są wysyłane domyślnie; wskazówki o wysokiej entropii (dokładna wersja, wersja platformy, model urządzenia) wymagają, aby serwer wyraził zgodę za pomocą nagłówka odpowiedzi Accept-CH — to wyraźne negocjowanie, a nie rozgłaszanie. Dwa zastrzeżenia, zanim na tym polegniesz: to mechanizm rodziny Chrome/Chromium, nie coś, co wysyła każda przeglądarka, a nawet tam, gdzie jest obsługiwany, “wartość może być pusta, niezwrócona lub wypełniona zmienną wartością.” Client Hints rozwiązują problem ciągu przeglądarki; nie są mechanizmem weryfikacji robotów — Google i Bing nadal weryfikują swoje roboty przez DNS i zakresy IP, a nie przez Client Hints.

Targetowanie na User-Agent i cloaking

Kuszący ruch — “wykryj Googlebota po UA i serwuj mu coś specjalnego” — jest zarówno technicznie kruchy, jak i naruszeniem polityki.

Kruchy, bo Google nie indeksuje jednym UA. Musiałbyś poprawnie obsłużyć Googlebota (mobilnego i desktopowego), Google-InspectionTool, AdsBot, GoogleOther i inne, z rotujących adresów IP — praktycznie niemożliwe do czystego whitelistowania.

Naruszenie zasad, ponieważ serwowanie różnych treści robotowi indeksującemu i użytkownikom to cloaking: “przedstawianie różnych treści użytkownikom i wyszukiwarkom w celu manipulowania rankingami wyszukiwania i wprowadzania użytkowników w błąd.” Kara obejmuje od obniżenia pozycji algorytmicznej po całkowite usunięcie z indeksu. Zwróć uwagę na granicę: uzasadniona adaptacja (responsywne układy, negocjacja treści) jest w porządku — to zamiana samej treści między botami a użytkownikami przekracza granicę cloakingu.

Aby zobaczyć, gdzie w większym potoku znajduje się user agent, zobacz crawling (centrum) i crawler. Aby kontrolować, co te boty mogą pobierać, zobacz robots.txt.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Trzy rzeczy, które należy rozróżniać: nagłówek żądania User-Agent — opcjonalny, wypełniane przez klienta metadane zgodnie z RFC 9110, nie uwierzytelniona tożsamość; jego wartość, czyli ciąg user-agenta; oraz token używany w robots.txt. Zgodnie z RFC 9309 token POWINIEN być podciągiem ciągu — silna konwencja, nie uniwersalna reguła.
• Niektóre tokeny nie mają ciągu. Google-Extended to udokumentowany wyjątek: istnieje tylko jako kontrola robots.txt (trenowanie Gemini); crawling używa normalnych ciągów Googlebota. Zablokowanie go nie wpływa na indeksowanie w Search.
• Ciągi Googlebot/Bingbot są wiecznie aktualne — wersja Chrome wyświetla się jako W.X.Y.Z i zmienia się; dopasowuj stabilny token (Googlebot, bingbot), nigdy wersję. Mobilny i desktopowy Googlebot mają jeden wspólny token. Po 2022 r. Bingbot wygląda jak prawdziwa przeglądarka, z wyjątkiem fragmentu bingbot/2.0.
• Dopasowywanie w robots.txt: wygrywa najbardziej szczegółowa grupa; grupy z tym samym tokenem łączą się, ale nigdy z *; dopasowywanie nie uwzględnia wielkości liter; numery wersji i symbole wieloznaczne w linii User-agent: są ignorowane (Googlebot* = Googlebot).
• AdsBot i Google-Safety ignorują User-agent: * — blokuj je po nazwie albo wcale.
• Ciąg można trywialnie sfałszować (Google sam nazywa go “często fałszowanym”). Najpierw uzyskaj prawdziwy adres IP klienta (proxy/CDN mogą go maskować w Twoich logach), a następnie zweryfikuj przez odwrotne + zwykłe DNS (googlebot.com/google.com/googleusercontent.com; Bing → search.msn.com) lub opublikowane zakresy IP — pliki, które Google już wcześniej zmieniał, więc sprawdź ponownie aktualny dokument, jeśli wyszukiwanie przestaje działać. Nigdy nie ufaj ciągowi do kontroli dostępu.
• Zweryfikowane żądanie nadal nie jest dowodem na wszystko w dalszym potoku. Otrzymanie żądania, potwierdzenie tożsamości, wyrenderowanie treści, zaindeksowanie strony oraz pobranie/cytowanie/trenowanie na treści to osobne twierdzenia wymagające osobnych dowodów — trafienie w logu dowodzi pierwszego, niczego innego automatycznie.
• Web Bot Auth (2026, eksperymentalne) podpisuje żądania kryptograficznie — dodatkowo, z DNS/IP jako wciąż działającym rozwiązaniem awaryjnym.
• Ciągi UA przeglądarek też stają się trudniejsze do parsowania: redukcja User-Agent w Chrome usuwa z ciągu dokładne informacje o wersji/systemie/urządzeniu; Client Hints to ustrukturyzowany, opcjonalny zamiennik — ale są specyficzne dla Chrome i nie zastępują weryfikacji crawlera.
• Serwowanie różnych treści w zależności od UA to cloaking — naruszenie zasad antyspamowych, i kruche, ponieważ Google indeksuje przy użyciu wielu UA.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek i standardu.

Google

• Przegląd robotów Google i pobieraczy (user agents) — trzy sygnały identyfikacyjne i pełna lista robotów.
• Typowe roboty Google — tabela tokenów i ciągów user-agent.
• Specjalne roboty Google — AdsBot, Mediapartners-Google, Google-Safety i wyjątki *.
• Weryfikacja żądań od robotów i pobieraczy Google — dwuetapowa metoda DNS i pliki zakresów IP.
• Czym jest Googlebot — ciągi Googlebota i uwaga o „częstym podszywaniu się”.
• Jak Google interpretuje specyfikację robots.txt — dopasowywanie tokenów, brak rozróżniania wielkości liter, ignorowane symbole wieloznaczne.
• Uwierzytelnianie żądań za pomocą Web Bot Auth (eksperymentalne) — protokół podpisu kryptograficznego.
• Aktualizacja user-agenta Googlebota (2019) — dlaczego ciąg pokazuje W.X.Y.Z.
• Zasady dotyczące spamu — cloaking — definicja i kara.

Bing / Microsoft

• Ogłoszenie zmiany user-agenta dla Bingbota (kwiecień 2022) — aktualne ciągi dla desktopu i urządzeń mobilnych (Fabrice Canel).
• Jak zweryfikować, że Bingbot to Bingbot (sierpień 2012) — metoda odwrotnego DNS *.search.msn.com.
• Bing Webmaster Tools — Weryfikacja Bingbota — wbudowane narzędzie weryfikacji.

Standard

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — podstawowa specyfikacja HTTP: User-Agent to opcjonalne pole dostarczane przez klienta, nie uwierzytelniona tożsamość.
• RFC 9309: Robots Exclusion Protocol — formalna definicja na poziomie SHOULD tokenu produktu jako podciągu ciągu user-agent.
• MDN — nagłówek User-Agent — składnia HTTP samego nagłówka.

Ciągi UA przeglądarek

• Chrome Privacy Sandbox — redukcja User-Agent — co jest zamrażane/zagęszczane w ciągu UA Chrome i dlaczego.
• Chrome for Developers — User-Agent Client Hints — wskazówki o niskiej i wysokiej entropii oraz opcja Accept-CH.

Cytaty ze źródła

Oświadczenia na piśmie od Google, Bing i RFC. Każdy link to link bezpośredni, który przenosi do cytowanego fragmentu na stronie źródłowej.

Google — jak roboty się identyfikują

• “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (tłumaczenie) „Roboty Google identyfikują się za pomocą trzech rzeczy: nagłówka żądania HTTP user-agent, adresu IP źródła żądania oraz odwrotnej nazwy DNS adresu IP źródła.” — dokumentacja Google Search Central. Przejdź do cytatu

Google — ciąg jest podszywany

• “The HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (tłumaczenie) „Nagłówek żądania HTTP user-agent używany przez Googlebota jest często podszywany przez inne roboty.” — dokumentacja Google Search Central. Przejdź do cytatu

Google — weryfikacja przez DNS

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (tłumaczenie) «Wykonaj odwrotne wyszukiwanie DNS dla adresu IP z logów, używając polecenia host. Sprawdź, czy nazwa domeny to googlebot.com, google.com lub googleusercontent.com.» Przejdź do cytatu
• “Google doesn’t post a public list of IP addresses for website owners to allowlist because these IP address ranges can change.” (tłumaczenie) «Google nie publikuje publicznej listy adresów IP, które właściciele witryn mogliby dodać do listy dozwolonych, ponieważ te zakresy adresów IP mogą się zmieniać.» Przejdź do cytatu

Google — dopasowanie tokenów w robots.txt

• “All non-matching text is ignored (for example, both googlebot/1.2 and googlebot* are equivalent to googlebot).” (tłumaczenie) «Cały tekst, który nie pasuje, jest ignorowany (na przykład zarówno googlebot/1.2, jak i googlebot* są równoważne googlebot).» — specyfikacja robots.txt Google. Przejdź do cytatu

Google — Web Bot Auth

• “An experimental cryptographic protocol used to authenticate requests sent by bots.” (tłumaczenie) «Eksperymentalny protokół kryptograficzny używany do uwierzytelniania żądań wysyłanych przez boty.» Przejdź do cytatu
• “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” (tłumaczenie) «Nie podpisujemy każdego żądania konkretnego agenta. Upewnij się, że korzystasz z ustalonych metod weryfikacji botów.» Przejdź do cytatu

Google — cloaking

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (tłumaczenie) «Cloaking odnosi się do praktyki prezentowania różnych treści użytkownikom i wyszukiwarkom w celu manipulowania rankingami wyszukiwania i wprowadzania użytkowników w błąd.» — Google Search Essentials, Zasady dotyczące spamu. Przejdź do cytatu

RFC 9309 — token jest podciągiem ciągu

• “The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (tłumaczenie) «Token produktu POWINIEN być podciągiem ciągu identyfikacyjnego, który robot wysyła do usługi. Na przykład w przypadku HTTP token produktu POWINIEN być podciągiem w nagłówku User-Agent.» Przejdź do cytatu

Patrick Stox — o podszywaniu się

• “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (tłumaczenie) «Wiele narzędzi SEO i niektóre złośliwe boty udają Googlebota. Może to pozwolić im na dostęp do witryn, które próbują je blokować.» — z mojego przewodnika o Googlebocie na Ahrefs. Przeczytaj

Robot → token → ciąg → weryfikacja

Tabela referencyjna. Token to to, co umieszczasz w robots.txt; hostname weryfikacyjny to to, do czego odwrotnie rozwiązuje się autentyczne żądanie.

Zasady dopasowywania robots.txt w skrócie

Szybkie fakty

• Token = podciąg ciągu UA (RFC 9309). Nie cały ciąg.
• Mobilny i desktopowy Googlebot mają jeden token — nie można ich rozdzielić w robots.txt.
• Wersja Chrome w ciągu to W.X.Y.Z — zmienia się; nigdy jej nie koduj na sztywno.
• Ciąg UA jest trywialnie podrabiany — weryfikuj przez DNS lub IP, nigdy nie ufaj ciągowi.

Weryfikacja bota przez odwrotny i zwrotny DNS

Ciąg user-agent można sfałszować w jednej linii curl. Potwierdź, że bot jest prawdziwy, sprawdzając IP, z którego faktycznie przyszedł. Wzorzec jest taki sam dla Google i Bing — różni się tylko oczekiwany hostname.

Najpierw uzyskaj właściwe IP: jeśli żądania przechodzą przez reverse proxy, load balancer lub CDN, zanim trafią na Twój serwer, Twoje domyślne logi mogą pokazywać adres proxy, a nie robota. Użyj prawdziwego IP klienta (z poprawnie skonfigurowanego nagłówka forwarding) przed uruchomieniem którejkolwiek z poniższych kontroli.

macOS / Linux

# --- Googlebot ---
# 1) Reverse DNS the IP from your logs — must end in googlebot.com, google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# --- Bingbot ---
# Reverse DNS must end in search.msn.com, then forward-confirm back to the IP
host 157.55.39.1
host <the-hostname-it-returned>

Windows

:: Googlebot
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

:: Bingbot
nslookup 157.55.39.1
nslookup <the-hostname-it-returned>

Jeśli odwrotne wyszukiwanie nie kończy się w oczekiwanej domenie — googlebot.com / google.com / googleusercontent.com dla Google, search.msn.com dla Bing — lub zwrotne wyszukiwanie nie pasuje do oryginalnego IP, to nie jest prawdziwy bot, niezależnie od tego, co mówi ciąg user-agent.

Dopasowanie do opublikowanych zakresów IP (na dużą skalę)

Aby zweryfikować wiele trafień, pomiń DNS dla każdego żądania i dopasuj IP do opublikowanych zakresów CIDR silnika. Google publikuje JSON czytelny maszynowo:

https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json

Pobierz plik, zbuduj zestaw CIDR i przetestuj każde zalogowane IP pod kątem przynależności. (Zbudowałem narzędzie do weryfikacji IP Googlebota, które robi to za Ciebie.) Bing również publikuje swoje zakresy, a Bing Webmaster Tools ma wbudowaną kontrolę „Verify Bingbot”.

Lista kontrolna sanityzacji user-agenta

Zanim napiszesz reguły UA lub zareagujesz na bota w swoich logach:

• Celujesz w token w robots.txt (np. Googlebot), a nie wklejasz całego ciągu UA.
• Żadnych numerów wersji ani * w linii User-agent: — są ignorowane (Googlebot* nic nie robi).
• Nie zakładasz, że User-agent: * blokuje AdsBot lub Google-Safety — nie blokuje; nazwij je jawnie, jeśli potrzebujesz.
• Jeśli zablokowałeś Google-Extended, rozumiesz, że wpływa to tylko na użycie w trenowaniu AI — Googlebot nadal indeksuje i przeszukuje dla wyszukiwarki.
• Nie opierasz kontroli dostępu ani treści na surowym ciągu UA — można go sfałszować.
• Każda kontrola “czy to naprawdę Googlebot?” przechodzi przez odwrotne + zwykłe DNS (googlebot.com / google.com / googleusercontent.com) lub opublikowane zakresy IP — dla Bing przez search.msn.com.
• Nigdzie nie ma dopasowania UA z przypiętą wersją — część Chrome W.X.Y.Z się zmienia.
• Nie serwujesz innej treści botowi niż użytkownikom (to cloaking).

Narzędzia do pracy z user agentami

Trzy moje własne darmowe narzędzia pokrywają trzy zadania, z którymi ludzie przychodzą do tego tematu: potwierdzenie, że deklarowany bot jest prawdziwy, sprawdzenie, które user agenty faktycznie odwiedzają Twoją witrynę, oraz sprawdzenie, co mogą robić boty AI.

Googlebot Verifier — narzędzie do dokładnie tego problemu, do którego ten artykuł ciągle wraca: ciąg user-agent to tylko tekst, więc nie możesz mu ufać samemu. Wklej adres IP z logów, wybierz, którym crawlerem się podaje (Googlebot, Bingbot i inne), a narzędzie wykona za Ciebie odwrotne + zwykłe sprawdzenie DNS oraz dopasowanie do opublikowanych zakresów IP, a następnie zwróci werdykt w skali — potwierdzony przez odwrotne DNS, w opublikowanych zakresach, sfałszowany, nie do zweryfikowania lub nieznany crawler. Masz cały dzień trafień do sprawdzenia zamiast jednego IP? Wklej do 500 adresów IP lub surowych linii logów w pole zbiorcze.

Log File Analyzer — do pytania “które user agenty faktycznie indeksują moją witrynę?” Wrzuć log dostępu serwera (nginx, Apache, IIS/W3C lub JSON), a narzędzie przeanalizuje go w całości w Twojej przeglądarce, rozbijając aktywność indeksowania według bota i sekcji, flagując marnotrawstwo kodów statusu, oddzielając boty AI od botów wyszukiwarek oraz — co najważniejsze dla tego tematu — generując raport o spooferach, który wskazuje żądania podające się za token user-agenta znanego crawlera bez potwierdzenia adresem IP.

AI-Crawler Access Checker — dla nowszej rodziny tokenów, które nie zachowują się jak Googlebot czy bingbot. Wpisz URL, a narzędzie sprawdzi Twój robots.txt pod kątem każdego głównego tokena user-agenta botów AI (GPTBot, ClaudeBot, PerplexityBot, Google-Extended i inne), pokaże dokładną regułę, która wygrywa dla każdego, i wskaże, czy istnieje plik llms.txt. Przydatne do potwierdzenia, że token taki jak Google-Extended robi to, co myślisz, że robi — ponieważ, jak omówiono powyżej, nie ma własnego ciągu żądania, który można by zauważyć w logach.

Prompty do zadań z user agentami

Dwa prompty zbudowane wokół konkretnych pułapek, które stawia ten temat — spoofing i składnia tokenów w robots.txt — a nie generyczne wypełniacze “audyt mojego SEO”. Wklej własne dane w miejsca oznaczone jako placeholdery.

Prompt 1 — triage partii ciągów user-agent z logów pod kątem oznak spoofingu

Wklej kolumnę surowych ciągów user-agent pobranych z logu dostępu (nie adresy IP — ten prompt nie może zweryfikować tożsamości, tylko wykryć niespójności w samym ciągu):

Here is a list of raw User-Agent strings from my server access log, one per
line. For each one:
1. Say which crawler token it claims to be (e.g. Googlebot, bingbot,
   GPTBot), or "no recognizable token" if none.
2. Flag anything internally inconsistent for that claimed crawler — e.g. a
   claimed Googlebot string missing "compatible; Googlebot" or the
   "+http://www.google.com/bot.html" URL, a claimed bingbot string missing
   "bingbot/2.0", or a Chrome version that looks hand-typed rather than a
   real evergreen build.
3. Remind me that this is a text-pattern check only — it cannot confirm
   identity. Real verification requires reverse+forward DNS or matching
   against the crawler's published IP ranges.

[paste user-agent strings here]

Prompt 2 — sprawdź robots.txt pod kątem błędów dopasowania tokenów

Wklej cały plik robots.txt:

Review this robots.txt file for user-agent token mistakes:
1. Flag any User-agent line that includes a version number or a wildcard
   inside the token (e.g. "Googlebot/1.2" or "Googlebot*") — these are
   ignored, not matched as a family.
2. Check whether User-agent: * is being relied on to block AdsBot-Google,
   AdsBot-Google-Mobile, Mediapartners-Google, or Google-Safety — these
   ignore the wildcard and need their own named group if I want them
   blocked.
3. Note any duplicate groups for the same token that could be merged, and
   confirm token matching here is case-insensitive so I don't need
   near-duplicate groups for casing variants.
4. List which named groups exist and which of Google's/Bing's common
   crawler tokens (Googlebot, Googlebot-Image, Google-Extended, bingbot)
   have no explicit group at all, so I know they're falling through to *.

[paste robots.txt here]

Sprawdź się: user agent

Pięć szybkich pytań o nagłówek, ciąg, token i jak zweryfikować, czy bot jest prawdziwy. Wybierz odpowiedź na każde, a potem sprawdź.

Zasoby warte Twojego czasu

Moje powiązane artykuły

• What Is Googlebot & How Does It Work? — pełne ciągi UA Googlebota, metody weryfikacji i moje narzędzie do weryfikacji IP.
• Indexed, though blocked by robots.txt — gdzie blokowanie oparte na UA i blokowanie przez robots.txt wchodzą w konflikt.
• Robots.txt and SEO: Everything You Need to Know — jak faktycznie działają grupy user-agentów i reguły.
• Meet the New Web Crawlers: AI Bots Are Closing in on Search Engine Bots — zmieniająca się obsada user-agentów w Twoich logach.

Oficjalne / standardy

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — podstawowa definicja: opcjonalne metadane dostarczane przez klienta.
• RFC 9309: Robots Exclusion Protocol — formalna definicja SHOULD-poziomu produkt-token-jako-podciąg.
• Google Overview of crawlers and fetchers i Verify Google crawlers.
• Chrome Privacy Sandbox — User-Agent reduction i User-Agent Client Hints — dlaczego ciągi UA przeglądarek stają się trudniejsze do parsowania i co je zastępuje.

Od innych

• John Mueller — Bots that impersonate Googlebot — o spoofingu i dlaczego odwrotny DNS jest rozwiązaniem.
• MDN — User-Agent header — widok nagłówka w specyfikacji HTTP.
• r/TechSEO — społeczność do debugowania crawl i logów.
• Web Bot Auth: Google’s new experimental method to validate authentic bots (Search Engine Land, Barry Schwartz, maj 2026) — najlepsze podsumowanie z działu wiadomości o tym, jak działa kryptograficzne podpisywanie botów i co oznacza w praktyce.
• Google-Agent user agent identifies AI agent traffic in server logs (Search Engine Land) — omawia nowego fetchera wyzwalanego przez użytkownika, który ignoruje robots.txt i używa Web Bot Auth.
• Google Is Testing New Bot Authorization Standard (Search Engine Journal) — szerszy kontekst branżowy dotyczący standardu IETF i tego, które firmy (Amazon, Cloudflare, Akamai, OpenAI) go wspierają.
• Announcing future user-agents for Bingbot (Bing Webmaster Blog, Fabrice Canel, grudzień 2019) — oryginalne ogłoszenie przejścia Bingbota na renderowanie oparte na Edge przed wdrożeniem w 2022 roku.
• Microsoft list of Bingbot IP addresses released (Search Engine Land) — relacja z decyzji Binga o opublikowaniu zakresów IP do weryfikacji botów na dużą skalę.

Dziennik zmian