Co oznacza Web Bot Auth, jeśli już blokujesz roboty AI

TL;DR: Web Bot Auth to podpisy HTTP Message Signatures z RFC 9421 zastosowane do ruchu crawlerów. Bot podpisuje każde żądanie kluczem prywatnym, publikuje klucze publiczne w katalogu .well-known, a Ty weryfikujesz podpis zamiast ufać nagłówkowi User-Agent. Google publikuje klucze pod agent.bot.goog dla swojego agenta AI-browsing; klasyczny Googlebot wciąż nie jest podpisany. Prace na 2026 r. polegają na dodaniu ścieżki weryfikacji podpisu bez usuwania reverse-DNS, bo większość ruchu podającego się za Google nadal będzie niepodpisana przynajmniej przez kolejny rok.

Operator, z którym współpracuję, w 2024 r. napisał regułę Cloudflare WAF. Blokuje ona wszystko, czego UA zawiera GPTBot, ClaudeBot lub PerplexityBot, i przepuszcza wszystko, co zawiera Googlebot. Reguła działała dwa lata. Wiosną 2026 w logach pojawił się nowy UA, Google-Agent, z trzema nieznanymi nagłówkami: Signature-Agent, Signature-Input i Signature. Reguła z 2024 r. nie bierze ich pod uwagę – patrzy tylko na UA. Ta luka między regułami opartymi na starym modelu weryfikacji a ruchem nadchodzącym w nowym to temat tego tekstu. Nie „czym jest robots.txt” ani „czy blokować roboty AI”. Chodzi o integrację dla operatorów, którzy już utrzymują zestaw zasad dotyczących botów i muszą wiedzieć, co Web Bot Auth w nim zmienia.

Czym faktycznie jest Web Bot Auth

Web Bot Auth to profil RFC 9421 HTTP Message Signatures dostosowany do botów. Bot podpisuje każde wychodzące żądanie kluczem prywatnym. Strona pobiera klucz publiczny bota z adresu .well-known/http-message-signatures-directory w domenie kontrolowanej przez bota. Strona weryfikuje, czy podpis w przychodzącym żądaniu został utworzony pasującym kluczem prywatnym. Jeśli tak – pochodzenie jest kryptograficznie potwierdzone. Jeśli nie – żądanie jest podrobione.

Pracę wykonują trzy nowe nagłówki. Signature-Agent wskazuje katalog kluczy bota. Signature-Input wylicza, co jest podpisane, plus metadane: keyid, znaczniki czasu created i expires, algorytm oraz dosłowny ciąg tag="web-bot-auth", który oznacza podpis bota (nie inny przypadek RFC 9421). Signature przenosi bajty kryptograficzne.

„Ten dokument opisuje mechanizm tworzenia, kodowania i weryfikacji podpisów cyfrowych lub MAC nad składnikami komunikatu HTTP.” — A. Backman, J. Richer, M. Sporny, RFC 9421 (HTTP Message Signatures, abstrakt)

Profil bota ponad RFC sprawia, że to Web Bot Auth, a nie „po prostu” podpisy komunikatów HTTP. Szkic IETF draft-meunier-web-bot-auth-architecture doprecyzowuje konwencje botów: ciąg tag="web-bot-auth" w wejściu, kształt URL katalogu well-known, zalecane komponenty objęte podpisem (minimum @authority i signature-agent) oraz oczekiwanie, że katalog jest buforowany zgodnie z własnym nagłówkiem Cache-Control. Tego w samym RFC 9421 nie ma. RFC to algebra, Web Bot Auth to przypadek użycia.

Dlaczego weryfikacja UA + IP przestała wystarczać

Stos weryfikacji ma trzy warstwy, każda z defektem. User-Agent to tekst – każdy może go ustawić. Reverse DNS działa dla Googlebota, ale jest niewygodny dla nowszych crawlerów lecących przez infrastrukturę ogólnego przeznaczenia. Whitelisty IP są kruche, bo zakresy chmurowe zmieniają się bez zapowiedzi.

Johannes Ullrich z SANS Internet Storm Center ujął problem spoofowania UA wprost:

„Użytkownicy od dawna wiedzą, że ustawienie user agenta na ‘Googlebot’ potrafi ominąć niektóre paywalle.” — Johannes Ullrich, SANS Internet Storm Center, wrzesień 2025

Strona allowlist IP ma pokrewny problem. Thibault Meunier i Mari Galicer z Cloudflare, którzy pilotowali Web Bot Auth w IETF, opisali to w maju 2025 tak: „połączenia z usługi crawl mogą być współdzielone przez wielu użytkowników, jak w przypadku proxy prywatności czy VPN, a te zakresy, często zarządzane przez dostawców chmur, zmieniają się w czasie”. Whitelist poprawny w poniedziałek może być błędny w piątek.

Zmiana w stronę „agent-traffic” pogarsza stary stos. Gdy crawler działa w imieniu użytkownika w czacie, profil źródła się fragmentuje. Cloudflare wskazało to wprost: „Botami kierują już nie tylko ich właściciele, ale również sami użytkownicy końcowi.”

Weryfikacja kryptograficzna to jedyna szyna odporna na wszystkie trzy stare tryby awarii. Nie obchodzi jej IP źródłowe, nie ufa UA, nie potrzebuje reverse-DNS. Liczy się klucz.

Jak wygląda podpisane żądanie Googlebota

Podpisane żądanie od agenta Google ma kształt opisany w dokumentacji Cloudflare i przewodniku Google. Przybliżona forma, z skróconym keyid:

GET /article/example HTTP/1.1
Host: yoursite.com
User-Agent: Mozilla/5.0 (compatible; Google-Agent/1.0; ...)
Signature-Agent: g="https://agent.bot.goog"
Signature-Input: sig=("@authority" "signature-agent")
 ;created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
 ;alg="ed25519";expires=1735693200;tag="web-bot-auth"
Signature: sig=:MEQCIBmw...truncated...:

Czytaj od lewej do prawej. Signature-Agent mówi, skąd pobrać klucz publiczny. Dosłowne g="https://agent.bot.goog" wskazuje katalog https://agent.bot.goog/.well-known/http-message-signatures-directory. Signature-Input opisuje, co jest atestowane: w tym przypadku komponent @authority (host) i sam nagłówek signature-agent, podpisane w sekundach Unix created i ważne do expires. keyid to odcisk palca JWK wybierający konkretny klucz z katalogu. Signature niesie bajty podpisu ed25519.

Sens każdego parametru w tabeli – to tu operatorzy najczęściej mylą się przy pierwszym czytaniu:

Jedno zastrzeżenie od Google: „Nie wszystkie agenty Google korzystają z Web Bot Auth.” W maju 2026 podpisy składa konsekwentnie Google-Agent, agent AI-browsing powiązany z AI Mode. Klasyczny Googlebot, crawler indeksujący, jeszcze nie. Planuj reguły osobno.

Przepływ weryfikacji – end-to-end

Pełna ścieżka weryfikacji to cztery kroki. Żaden nie jest kosztowny. Ruchome części to cache katalogu i biblioteka algorytmu, nie sama matematyka.

Krok pierwszy. Żądanie przychodzi. Szukasz nagłówka Signature-Agent. Brak? Żądanie niepodpisane, spadasz do starej ścieżki (reverse DNS, UA, IP). W 2026 większość żądań tutaj ląduje.

Krok drugi. Parsujesz Signature-Input. Wyciągasz keyid, created, expires, alg, tag. Odrzucasz, jeśli tag ≠ web-bot-auth. Odrzucasz, jeśli po expires. To dzieje się przed pobraniem klucza.

Krok trzeci. Pobierasz katalog kluczy z URL z Signature-Agent. Szanujesz Cache-Control; katalog Google go ustawia. Buforujesz w RAM lub Redis, odświeżasz przy wygaśnięciu, usuwasz klucze wycofane (rotacja). Wyciągasz klucz z odciskiem keyid.

Krok czwarty. Weryfikujesz podpis wobec komponentów wymienionych w Signature-Input. Sukces = kryptograficzny dowód, że właściciel klucza wysłał żądanie. Porażka = fałszywka.

Cache katalogu to element, z którym operatorzy się mylą. Traktuj Cache-Control jako nadrzędne. Nie cache’uj zbyt długo (przyjmiesz odwołane klucze) ani zbyt krótko (refetch na każde żądanie doda latency i przeciąży katalog). Przy błędzie fetch z wygasłym cache przejdź na ścieżkę niepodpisaną. Nie blokuj się na krótkim błędzie.

Co zmienia się w Twoich regułach blokowania AI-botów

Kluczowa kwestia operatora: masz reguły, protokół się zmienił. Co robisz?

Najpierw dobra wiadomość. Reguły blokujące UA zawierający GPTBot, ClaudeBot czy PerplexityBot pozostają bez zmian. Żądanie nadal ma rozpoznawalny UA, a sfałszowany GPTBot i tak udawał bota, którego chciałeś zablokować. Jeśli Twoje zasady blokują też legalnego podpisanego GPTBota, to świadomy wybór.

Mniej dobra wiadomość. Reguły przepuszczające UA zawierające Googlebot są niedookreślone. Spoofer z UA Googlebot wciąż je przejdzie. Rozwiązanie to nie przepisać całą regułę od ręki (podpisanych żądań jest za mało), lecz dodać równoległą ścieżkę: weryfikuj podpis na podpisanym ruchu Google, a dla niepodpisanego stosuj reverse DNS. Zespół Cloudflare verified-bots podsumował lukę:

„Obecne metody identyfikacji opierają się na kombinacji zakresu IP (współdzielonego lub zmiennego) i nagłówka user-agent (łatwo podrabianego). Mają ograniczenia i braki.” — zespół Cloudflare verified-bots, lipiec 2025

Model „dwa stosy” jest właściwy. Jeden zestaw reguł obsługuje ruch podpisany, weryfikuje podpis, sprawdza keyid, ważność i kieruje według potwierdzonej tożsamości. Drugi obsługuje ruch niepodpisany, robiąc legacy reverse-DNS + UA + IP tak jak dziś. Nie kasuj starych reguł – w połowie 2026 większość prawdziwego ruchu Google nadal przez nie płynie.

Weryfikacja podpisów na originie (gdy nie używasz Cloudflare)

Za Cloudflare praca jest mała. Edge waliduje podpisy i udostępnia wynik w cf.verified_bot_category w WAF Custom Rules i Transform Rules. Twoja reguła sprowadza się do „jeśli cf.verified_bot_category = X, to…”, a kryptografia jest czyimś problemem.

Bez weryfikującego CDN robisz to na originie. To małe middleware przed nginxem lub serwerem aplikacji. Przechwytuje żądania z nagłówkiem Signature-Agent, przy pierwszym spotkaniu pobiera katalog .well-known bota (potem cache), weryfikuje wg RFC 9421 i ustawia wewnętrzny nagłówek X-Verified-Bot, który czytają dalsze reguły.

Zespół Cloudflare research open-sourcował weryfikator w cloudflareresearch/web-bot-auth. Crate Rust i pakiet npm TypeScript (web-bot-auth) zawierają logikę, repo dorzuca plugin do Caddy i przykłady Workerów. Nie są audytowane (README o tym mówi), ale powierzchnia weryfikacji jest mała, a alternatywą jest własna implementacja RFC 9421.

Pragmatycznie: na Cloudflare ścieżka edge jest oczywista. Poza Cloudflare – zainstaluj middleware, wskaż katalogi agentów (dziś agent.bot.goog i inne, które Cię obchodzą) i czytaj jego nagłówek zaufania w istniejących regułach. Tak czy inaczej, nie umieszczaj weryfikacji podpisu w kodzie biznesowym. Trzymaj ją w warstwie frontowej, gdzie można ją audytować i podmienić.

Fallback reverse-DNS nigdzie się nie wybiera

Powtarzam „nie kasuj starych reguł”, bo udział podpisów jest mały. W maju 2026 Googlebot indeksujący nie podpisuje żądań. Podpisuje tylko AI-browsing Google-Agent. Dla większości stron to jednocyfrowy procent całego ruchu Google. Gros widoczności organicznej pochodzi z indeksującego, niepodpisanego Googlebota – dziś i prawdopodobnie do 2027.

Google mówi to wprost. Ta sama dokumentacja, która wprowadza Web Bot Auth, radzi nadal „polegać na adresach IP, reverse DNS i User-Agent” obok nowego protokołu. To nie asekuracja – to model operacyjny. Web Bot Auth to jedna szyna weryfikacji; legacy stack to druga. Działają równolegle, a w 2026 to legacy niesie więcej ruchu.

Cykl audytu: raz na kwartał pobierz próbkę ruchu deklarującego Google z logów, podziel na podpisane i niepodpisane, policz udział podpisanych. Gdy przekroczy 30–40 %, ścieżka podpisów zacznie przeważać. Gdy przekroczy 70 %, reguła UA Googlebot bez podpisu wymaga twardego przeglądu – spooferzy będą najbardziej widoczni w tej mniejszości. Do tych progów utrzymuj obie szyny i traktuj kryptograficzną jako dodatek.

Przestrzegam przed antywzorem: nie pisz dziś reguły blokującej niepodpisany UA Googlebot. W jednym cyklu crawl’owania wypadniesz z indeksu.

Co faktycznie zrobić w tym kwartale

Cztery punkty. Żaden nie wymaga dostawcy.

Po pierwsze, zrób inwentaryzację swoich reguł botów. Oznacz każdą, co naprawdę weryfikuje: UA, reverse DNS, zakres IP czy podpis. Większość audytów odkrywa duplikaty lub przestarzałe reguły. Wyczyść je przed dodaniem nowych.

Po drugie, dodaj ścieżkę weryfikacji podpisu. Na Cloudflare włącz edge verified-bots i dodaj jedną regułę rozgałęziającą na cf.verified_bot_category. Na własnym originie zainstaluj middleware WBA, wskaż agent.bot.goog (i inne potrzebne katalogi) i wystaw nagłówek zaufania do istniejących reguł.

Po trzecie, zostaw reverse DNS dla dużo większej puli niepodpisanego ruchu Google. Nie zacieśniaj, nie zamieniaj – uruchom równolegle.

Po czwarte, zaplanuj kwartalny audyt: udział podpisów w ruchu deklarującym Google, udział podpisów w ruchu agent-AI, procent spooferów złapanych przez podpisy, których stare reguły nie wychwyciły. Liczby rosną wolno w 2026, szybciej w 2027. Struktura reguł powinna za nimi nadążać.

Jeśli Twój zespół prowadzi też szerszą politykę wobec crawlerów AI, playbook crawlerów AI i tekst o wyłączeniu Cloudflare AI-bot-block to lektury uzupełniające po stronie allow/block. Ten tekst dotyczy tożsamości.

Czego to NIE rozwiązuje

Web Bot Auth to tożsamość, nie autoryzacja. Podpis atestuje, że żądanie wyszedł od konkretnego bota. Nic nie mówi, czy bot może czytać dany URL. Zweryfikowany, podpisany Google-Agent nadal może zeskrobać płatną treść, jeśli go przepuścisz. Podpis daje pewność źródła. Polityka należy do Ciebie.

Nie dotyka też robots.txt. Podpisany bot ignorujący robots wciąż jest naruszycielem robots; podpis nie daje dodatkowego dostępu. Jeśli chcesz, by podpisany agent AI-browsing omijał sekcję płatną, określ to w robots i egzekwuj w regułach.

Nie decyduje też, czy treść dla AI-search i tradycyjnego search ma być ta sama. Web Bot Auth mówi „to naprawdę Google-Agent”. Czy Google-Agent dostaje tę samą treść co Googlebot, to Twoja decyzja. Tekst o optymalizacji pod Perplexity, ChatGPT Search i Google AI Mode omawia routing.

Szczera ocena: to jedna z trzech szyn. Podpis dla tożsamości, reverse DNS dla legacy, robots dla autoryzacji. Nowa szyna wzmacnia pierwszą. Operatorzy, którym idzie dobrze w 2026, traktują wszystkie trzy jako kluczowe.

Cadence audytu w miarę wzrostu adopcji

Linia do śledzenia w 2026-2027 to udział podpisów w ruchu deklarującym Google. Dziś to single digits. Gdy przebije 30–40 %, ścieżka weryfikacji zaczyna ważyć. Gdy przebije 70 %, reguła niepodpisanego UA Googlebot wymaga poważnego przeglądu.

Inwentaryzuj co pół roku i przy okazji czytaj aktualną dokumentację crawlerów Google; zmienia się. Kształt katalogu i lista komponentów objętych podpisem to elementy specyfikacji najbardziej podatne na zmiany. Dwa razy do roku wystarczy, by być przed rynkiem.

Dla podstaw o Googlebocie zobacz nasze wyjaśnienie, czym jest Googlebot. Dla ruchu agent-traffic polecam jak zbudować stronę przyjazną agentom.

FAQ

Czy Googlebot już podpisuje żądania? Nie, stan na połowę 2026. Obecne wdrożenie Web Bot Auth obejmuje agenta AI-browsing Google-Agent. Googlebot, crawler indeksujący ruch organiczny, wciąż uwierzytelnia się przez reverse DNS i opublikowane zakresy IP. Planuj reguły oddzielnie.

Czy Web Bot Auth zastępuje robots.txt? Nie. Odpowiadają na różne pytania. Web Bot Auth potwierdza „to naprawdę Google”. Robots.txt określa „ten URL wolno / nie wolno crawlować”. Oba obowiązują, a podpisany bot ignorujący robots wciąż łamie zasady.

Jakiego algorytmu podpisu używa Web Bot Auth? RFC 9421 wspiera kilka. Przykłady Cloudflare i katalog Google używają ed25519 (EdDSA na Curve25519). Twój weryfikator potrzebuje implementacji ed25519 – to pojedyncze wywołanie biblioteki w Go, Rust, Node, Pythonie itp.

Co, jeśli katalog kluczy Google jest niedostępny? Buforujesz katalog wg Cache-Control. Jeśli cache jest świeży, weryfikujesz z cache. Jeśli wygasł, a fetch się nie uda, wracasz do ścieżki niepodpisanej (reverse DNS, UA, IP). Nie blokuj strony na chwilowej niedostępności – tak można przypadkiem wypaść z indeksu, gdy katalog ma czkawkę.

Czy warto porzucić reverse-DNS dla Googlebota? Jeszcze nie, raczej nie w 2026. Udział podpisów jest zbyt mały. Reverse DNS to realna obrona przed UA-spoofingiem podającym się za Googlebota, bo klasyczny Googlebot jest niepodpisany. Oceń ponownie co kwartał wraz ze wzrostem udziału podpisów. Moment na zacieśnienie ścieżki niepodpisanej jest wtedy, gdy stanie się mniejszością prawdziwego ruchu Google, nie wtedy, gdy jest większością.