Polskie znaki w robots.txt i czego ten plik nie zablokuje

Krótka odpowiedź

Reguły w robots.txt dla adresów z polskimi literami zapisuj w formie zakodowanej procentowo, na przykład /kategoria/%C5%82%C3%B3%C5%BCka/ zamiast /kategoria/łóżka/. Google zrozumie obie wersje w pliku zapisanym w UTF-8, a surowe litery w pliku w innym kodowaniu mogą przestać działać. Inne roboty mogą surowych liter nie zrozumieć.

Drugiej rzeczy sam standard robots.txt nie zrobi: nie zabroni firmie od AI użycia treści, którą już pobrała. Reguły z RFC 9309 decydują tylko o tym, czy robot może wejść na stronę. Użycie treści regulują w październiku 2026 roku pojedyncze nazwy wprowadzone przez operatorów, jak Google-Extended, a wspólne zasady dopiero powstają w IETF, jako projekt reguły Content-Usage.

Co powiedzieli Gary Illyes i Cherry Prommawin

21 października 2026 roku Google Search Central opublikował drugi odcinek serii „The Non-Canonical Cabinet” pod tytułem „What can you actually put in a robots.txt?”. Prowadzą go Gary Illyes i Cherry Prommawin z zespołu Google Search Relations. Illyes jest też współautorem standardu RFC 9309, który opisuje robots.txt.

Z odcinka wynikają trzy rzeczy ważne dla polskich stron:

• Znaki spoza alfabetu angielskiego w ścieżkach. Prommawin powiedziała, że parser Google radzi sobie z surowymi znakami, ale inne albo starsze roboty mogą się na nich pogubić. Zaleciła wersję zakodowaną. Na ekranie surowa ścieżka miała podpis „działa w Google, u innych może nie”, a zakodowana „bezpieczny, standardowy sposób”.
• Nazwy robotów. Illyes przypomniał, że nazwa w linii User-agent może zawierać tylko litery i myślniki. RFC 9309 dopuszcza jeszcze znak podkreślenia.
• Granica pliku. Według Illyesa robots.txt, tak jak go definiuje RFC 9309, to protokół preferencji dostępu. Nie decyduje o tym, co system zrobi z danymi, które już pobrał.

Specyfikacja robots.txt w dokumentacji Google, w wersji z 23 października 2026 roku, podaje przykład: reguły Disallow: /foo/bar/ツ i Disallow: /foo/bar/%E3%83%84 parser traktuje identycznie. Dodaje też, że zakodowane ścieżki łatwiej przetwarzać narzędziom innych firm.

Sprawdziliśmy, jak parser Google dopasowuje „łóżka”

Google udostępnia kod swojego parsera robots.txt jako otwartą bibliotekę na GitHubie. Skompilowaliśmy ją (wersja z 1 kwietnia 2026) i sprawdziliśmy, czy reguła Disallow zablokuje adres /kategoria/łóżka/, który przeglądarka i robot wysyłają jako /kategoria/%C5%82%C3%B3%C5%BCka/.

Kod tłumaczy, skąd te wyniki. Parser zamienia każdy bajt spoza ASCII w regule na zapis procentowy i ujednolica wielkość liter w istniejących kodach. Nie sprawdza jednak, w jakim kodowaniu zapisano plik. W UTF-8 litery „łóż” to sześć bajtów, które dają %C5%82%C3%B3%C5%BC, czyli dokładnie to, co wysyła przeglądarka. W Windows-1250 i ISO-8859-2 te same litery to trzy inne bajty, więc reguła zamienia się w /kategoria/%B3%F3%BFka/. Adres kategorii ma inne kody, więc reguła po cichu go nie blokuje.

Dokumentacja Google ujmuje to krócej: plik musi być w UTF-8, a znaki spoza UTF-8 Google może zignorować, przez co reguły mogą przestać działać.

Trzy pułapki przy polskich adresach

Plik zapisany w starym kodowaniu

Windows-1250 i ISO-8859-2 to starsze standardy zapisu polskich liter. Jeśli plik zapisano w jednym z nich, reguły z polskimi literami mogą nic nie blokować. Zakodowane reguły składają się wyłącznie ze znaków ASCII, więc w UTF-8, Windows-1250 i ISO-8859-2 mają te same bajty. Cały plik i tak zapisz w UTF-8, bo tego wymaga specyfikacja.

Wielka i mała litera to dwa różne kody

Ścieżki w robots.txt rozróżniają wielkość liter. Przy polskich znakach widać to w kodzie: „ł” to %C5%82, a „Ł” to %C5%81. Reguła dla /kategoria/łóżka/ nie obejmie /kategoria/Łóżka/. Jeśli sklep generuje oba warianty, potrzebujesz dwóch reguł albo porządku w adresach.

Ta sama litera zapisana na dwa sposoby

Literę „ó” można zapisać jednym znakiem albo jako „o” z doklejonym akcentem. Na ekranie wyglądają identycznie, ale kodują się inaczej: %C3%B3 albo o%CC%81. W naszym teście reguła skopiowana z drugim zapisem nie zablokowała zwykłego adresu kategorii. Zakodowanie reguły od razu pokaże, który zapis masz w pliku.

Podobny problem z dwoma zapisami tego samego adresu opisał John Mueller z Google przy nawiasach: surowe i zakodowane nawiasy w adresie to dla Google dwa różne adresy, więc w całym serwisie warto trzymać się jednej formy.

Jak zapisać reguły z polskimi literami

Najprościej: otwórz w przeglądarce stronę, którą chcesz objąć regułą, otwórz konsolę w narzędziach dla deweloperów i wpisz encodeURI('/kategoria/łóżka/'). Wynik to gotowa ścieżka do reguły. Dla „ą” dostaniesz %C4%85, dla „ł” %C5%82. Obok reguły zostaw komentarz z czytelną ścieżką, żeby za rok ktoś wiedział, czego dotyczy.

User-agent: *
# /kategoria/łóżka/ z sortowaniem
Disallow: /kategoria/%C5%82%C3%B3%C5%BCka/*?sort=
# /poradnik/jak-wybrać-łóżko/
Disallow: /poradnik/jak-wybra%C4%87-%C5%82%C3%B3%C5%BCko/

Ten plik sprawdziliśmy w parserze Google. Blokuje wpis poradnika i kategorię, w której sortowanie jest pierwszym parametrem, na przykład ?sort=asc. Adresu z ?page=2&sort=asc ta reguła nie obejmuje, a samą kategorię /kategoria/łóżka/ zostawia dostępną. Komentarze z polskimi literami niczego nie psują, bo roboty je pomijają, ale cały plik i tak zapisz w UTF-8.

Podstawy pliku, czyli gwiazdki, kolejność reguł i różnicę między blokowaniem a noindex, opisujemy w tekście o tym, co blokuje plik robots.txt i jak go ustawić.

Czego robots.txt nie zablokuje: użycia treści przez AI

Dopisanie botów AI do robots.txt łatwo uznać za zamknięcie sprawy. Plik robi jednak mniej, niż się wydaje. RFC 9309 opisuje wyłącznie pobieranie stron. O tym, co firma zrobi z treścią, którą pobrała wcześniej, nie ma w nim ani słowa. Illyes porównał w odcinku Disallow do prośby „nie wchodź do pokoju”. Prośba dotyczy wejścia. Tego, co robot wyniósł wcześniej, nie obejmuje.

Praktyczne skutki:

• reguła dodana dziś działa na kolejne wizyty, gdy robot odczyta nową wersję pliku; RFC 9309 nie nakazuje usunięcia treści pobranych wcześniej ani nie określa, jak wolno ich używać;
• standard sam zaznacza, że reguły nie są formą kontroli dostępu, więc robot, który ich nie przestrzega, i tak stronę pobierze;
• Google-Extended nie jest osobnym robotem. Google pisze, że nie ma własnego identyfikatora w zapytaniach HTTP, stronę pobierają zwykłe roboty Google, a nazwa w robots.txt służy jako przełącznik zgody na trening przyszłych modeli Gemini (Gemini Apps i Vertex AI) oraz na użycie treści do uzupełniania odpowiedzi w Gemini Apps i w Grounding with Google Search na Vertex AI. Na obecność w wyszukiwarce i ranking nie wpływa.

Które boty AI odpowiadają za trening, a które za odpowiedzi z wyszukiwaniem, i co się dzieje po zablokowaniu każdego z nich, rozpisaliśmy w tekście o tym, które boty AI możesz zablokować bez utraty widoczności.

Content-Usage: zasady użycia treści, które dopiero powstają

Brakującą część próbuje uzupełnić grupa robocza IETF o nazwie aipref. Pracuje nad dwoma dokumentami:

• draft-ietf-aipref-attach, którego współautorami są Gary Illyes z Google i Martin Thomson z Mozilli. Wersja 05 z 19 sierpnia 2026 dodaje do robots.txt regułę Content-Usage i nagłówek HTTP o tej samej nazwie. Allow i Disallow nadal decydują o pobieraniu, a Content-Usage mówi, do czego wolno użyć treści, i to tylko tych adresów, które robot może pobrać. Przykład z projektu: Content-Usage: /ai-ok/ train-ai=y.
• draft-ietf-aipref-vocab, wersja 08 z 14 września 2026. Definiuje słownik: train-ai (trening modelu generatywnego), ai-use (podanie treści na wejście modelu generatywnego, gdy nie dostarczył jej sam użytkownik) i search (wyszukiwanie, które kieruje do źródła, bez generowania podsumowań). Każdą kategorię oznacza się y albo n.

Stan na 29 października 2026 roku: oba dokumenty są projektami. Słownik ma na początku zastrzeżenie, że jego treść nie odzwierciedla konsensusu grupy roboczej. Sam projekt mówi też, że odbiorca decyduje, czy zastosuje się do preferencji, i że nie są one zabezpieczeniem. Żadna z dokumentacji Google, które sprawdziliśmy, nie podaje, że Google odczytuje już Content-Usage. Dopisanie tej reguły dziś niczego nie zepsuje, bo roboty pomijają reguły, których nie znają, ale też nie daje pewności, że ktokolwiek ją uszanuje.

Co sprawdzić w swoim pliku

1. Otwórz twojadomena.pl/robots.txt i poszukaj reguł z polskimi literami.
2. Zamień je na formę zakodowaną przez encodeURI i dopisz komentarz z czytelną ścieżką.
3. Zapisz plik w kodowaniu UTF-8.
4. Sprawdź, czy sklep nie generuje tych samych adresów z wielką literą albo w dwóch wariantach zapisu.
5. W narzędziu do sprawdzania adresów URL w Search Console wklej adres, który ma być zablokowany, kliknij „Test wersji opublikowanej” i sprawdź pole „Czy skanowanie jest dozwolone”. Bez testu narzędzie pokazuje dane z ostatniego skanowania.
6. Jeśli zależy Ci na ochronie treści przed treningiem AI, potraktuj robots.txt jako jedną z warstw. Reguły blokujące pobieranie działają na kolejne wizyty i tylko u robotów, które ich przestrzegają.

Przy dużym sklepie z tysiącami kategorii warto sprawdzić robots.txt razem z logami serwera, bo pokazują, co roboty naprawdę pobierają. Przykładowe żądania Googlebota widać też w raporcie Statystyki indeksowania w Search Console. Kontrolę reguł robots.txt robimy w ramach audytu SEO i GEO.