---
title: "Robots.txt w Google: co działa, a co nie (AI, emoji)"
description: "Google wyjaśnia, co obsługuje robots.txt: cztery reguły, kodowanie znaków w ścieżkach, tokeny crawlerów AI i granice tego pliku. Co z tego wynika dla SEO."
date: 2026-10-19
category: SEO
tags: ["robots.txt", "Google", "crawlery AI", "SEO techniczne", "indeksowanie"]
url: https://uper.pl/blog/google-robots-txt-co-mozna-wpisac/
---

# Co można wpisać w robots.txt? — reguły dla crawlerów AI, emoji i adresów z polskimi znakami

**Plik robots.txt rozumie tylko cztery pola: `user-agent`, `allow`, `disallow` i `sitemap`. Każdą inną linię parser Google po cichu pomija.** W drugim odcinku serii „Non-Canonical Cabinet” Gary Illyes i Cherry Prommawin z Google omówili, co w tym pliku działa, a co tylko na działające wygląda. Dla mnie najważniejsze są z tej rozmowy trzy rzeczy: emoji i polskie znaki w ścieżkach lepiej zapisywać w postaci percent-encoded, crawlera AI blokuje się jego prawdziwym tokenem, a robots.txt nie ma żadnego wpływu na to, co firma zrobi z treścią, którą już pobrała.

Odcinek zrelacjonował Barry Schwartz w Search Engine Roundtable (21 października 2026). Poniżej zestawiam to, co padło w rozmowie, z dokumentacją Google i standardem RFC 9309.

## Co Google powiedział o robots.txt

Illyes opisał robots.txt jako zwykły plik tekstowy w głównym katalogu witryny, w którym właściciel mówi automatom, gdzie mogą wejść. Reguły czytają crawlery wyszukiwarek, boty zbierające dane do trenowania modeli AI i inne roboty, które w ogóle przestrzegają zasad. Googlebot (i każdy inny „dobrze wychowany” robot) sprawdza ten plik, zanim pobierze cokolwiek innego.

Podstawą jest standard **RFC 9309**, który Google deklaruje, że stosuje. Parser czyta plik linia po linii i szuka czterech pól: `user-agent`, `allow`, `disallow`, `sitemap`. Linię, której nie rozumie, odrzuca i przechodzi do następnej.

Schwartz streścił odcinek w trzech zdaniach: Googlebot i inne crawlery przestrzegające zasad używają robots.txt do ograniczania crawlowania, plik powinien być zgodny z RFC 9309, a emoji i znaki spoza ASCII w ścieżkach reguł warto kodować procentowo, żeby zrozumiał je każdy crawler.

## Cztery reguły i cicho odrzucane linie

Jeśli wpiszesz do pliku coś w rodzaju „nie crawluj sekretnej strony”, parser nie zgłosi błędu. Uzna linię za niepoprawną i ją pominie, a strona zostanie dostępna dla robota. Illyes ujął to tak, że reguła zrozumiała dla człowieka wcale nie musi działać dla maszyny.

Dokumentacja Google dorzuca kilka szczegółów, które przydają mi się na audytach:

- nazwy pól nie rozróżniają wielkości liter, ścieżki już tak,
- reguła `allow` lub `disallow` bez ścieżki jest ignorowana,
- pola inne niż `allow`, `disallow` i `user-agent` (np. `sitemap`) nie kończą grupy reguł, więc linia `sitemap` wstawiona między dwie linie `user-agent` ich nie rozdziela,
- Google nie obsługuje pola `crawl-delay`,
- plik ma być tekstem w UTF-8, a Google przetwarza z niego do 500 KiB i pomija wszystko, co jest dalej.

Komentarze są dozwolone: crawler ignoruje wszystko od znaku `#` do końca linii, więc ASCII art w komentarzach niczego nie zepsuje (choć Illyes nazwał go wprost wątpliwym pomysłem). Prommawin wspomniała o pliku robots.txt, który w 97% składał się z ozdobników, a tylko w 3% z dyrektyw. Parser sobie z tym poradzi, ale robot pobiera niepotrzebne bajty, a ozdoby wstawione obok ważnych dyrektyw łatwo przy edycji uszkodzić, więc lepiej trzymać je z dala od nich.

Składnię od podstaw opisałem w [kompletnym przewodniku po robots.txt](/blog/robots-txt/).

## Emoji i polskie znaki: tokeny kontra ścieżki

Wątek z emoji zaczął się od żartu (padło pytanie, czy da się wpisać `user-agent` z kurczakiem), ale wynika z niego konkretna zasada, osobna dla tokenów i dla ścieżek.

### Token crawlera: tylko proste znaki

W polu `user-agent` emoji ani litery spoza podstawowego zestawu nie zadziałają. Według Illyesa token może składać się wyłącznie z liter i myślników. RFC 9309 jest tu trochę szerszy i dopuszcza litery a-z i A-Z, podkreślnik oraz myślnik. Wniosek się nie zmienia: emoji to wielobajtowy znak UTF-8, który do tego zestawu nie pasuje, więc reguła z nim nie zadziała.

### Ścieżki: stosuj kodowanie procentowe

W ścieżkach `allow` i `disallow` znaki spoza ASCII są potrzebne, bo prawdziwe adresy URL je zawierają: polskie ogonki, niemieckie umlauty, cyrylicę, chińskie znaki, emoji.

Google radzi sobie z surowym UTF-8. Według dokumentacji porównuje reguły z adresami zakodowanymi procentowo i sam przekształca do tej postaci surowe znaki z reguły. Prommawin zwróciła jednak uwagę, że inne albo starsze crawlery mogą się na tym wyłożyć: jeśli nie przetworzą surowego znaku, pominą całą linię `disallow` i wejdą tam, gdzie chciałeś je zatrzymać. Dlatego regułę najlepiej zapisać tak, jak widzi ją serwer, czyli w formie zakodowanej.

Przykład dla katalogu `/łódź/`:

```txt
User-agent: *
# Zamiast: Disallow: /łódź/
Disallow: /%C5%82%C3%B3d%C5%BA/
```

Emoji 🐔 w ścieżce zapisałbyś analogicznie jako `%F0%9F%90%94`. Zresztą RFC 9309 i tak wymaga, żeby znaki spoza ASCII przed porównaniem zostały zakodowane procentowo.

Polskie serwisy rzadko mają ogonki w slugach, ale w starszych sklepach i serwisach ogłoszeniowych to się zdarza. Jeśli blokujesz takie sekcje, sprawdź, jak wpisana jest reguła, i przetestuj ją na prawdziwych adresach, bo reguł dla „ogonkowych” URL-i zwykle nikt nie testował.

## Crawlery AI: token, nie ozdobna reguła

Najwięcej uwagi Illyes poświęcił generatywnej AI. Podkreślił, że według RFC 9309 robots.txt jest **protokołem preferencji dostępu**: mówi botowi, czy może wejść, i na tym jego rola się kończy. Co system zrobi z pobranymi danymi, plik już nie reguluje.

Żeby zablokować konkretnego crawlera AI, trzeba wpisać jego rozpoznawaną nazwę w `user-agent`. Reguła w rodzaju „nie używajcie moich treści do trenowania” jest dla parsera śmieciem i wyleci przy parsowaniu. Tokeny się zmieniają i ciągle dochodzą nowe, więc aktualną listę sprawdzaj w dokumentacji operatora danego bota.

Dobry przykład z oficjalnej dokumentacji Google to token `Google-Extended`. Wydawca kontroluje nim, czy jego treści posłużą do trenowania przyszłych modeli Gemini i do tzw. groundingu (podawania modelowi treści z indeksu wyszukiwarki w momencie zapytania). Według Google ten token nie ma osobnego user-agenta w żądaniach HTTP i działa wyłącznie w robots.txt, a samo crawlowanie dalej odbywa się pod istniejącymi nazwami Google. Dokumentacja zaznacza też, że nie wpływa on na obecność strony w wyszukiwarce ani na ranking.

Kontrolę crawlowania warto też oddzielić od polityki wykorzystania treści. Robots.txt może zablokować dostęp do strony, ale nie zabroni firmie trenowania modeli na treściach, które już ma. Do tego potrzebne są warunki licencyjne, umowy albo regulacje, czyli narzędzia spoza tego pliku.

Podział na boty wyszukiwarek i boty AI omówiłem szerzej w artykule [AI crawlers vs search crawlers](/blog/ai-crawlers-vs-search-crawlers/), a o tym, których botów lepiej nie blokować, jeśli zależy Ci na cytowaniach w ChatGPT czy Perplexity, piszę w tekście o [widoczności strony w LLM](/blog/widocznosc-strony-w-llm/).

## Robots.txt to nie zabezpieczenie

Schwartz przypomniał na koniec, że robots.txt jest prośbą do crawlerów, które zechcą się do niej zastosować, a nie mechanizmem bezpieczeństwa. Nieuprawnionego klienta ani bota, który plik ignoruje, nie zatrzyma, a sam standard mówi wprost, że te reguły nie są formą autoryzacji. Wpisanie ścieżki do „tajnego” katalogu działa wręcz odwrotnie, bo zdradza jego istnienie każdemu, kto otworzy `/robots.txt`.

Treści chroni się uwierzytelnianiem albo regułami na serwerze lub w WAF-ie. Stronę z indeksu wyklucza się przez `noindex` albo kod odpowiedzi, a sam `disallow` tego nie zrobi: Google pisze w dokumentacji, że zablokowany adres może nadal pojawić się w wynikach (bez opisu), bo da się go zaindeksować bez crawlowania zawartości. Więcej o tych różnicach piszę w [przewodniku po robots.txt](/blog/robots-txt/).

## Co zrobić z tą wiedzą

Z odcinka wychodzi mi krótka lista kontrolna:

1. **Zwaliduj składnię.** Czytelna reguła wcale nie musi działać, więc sprawdź ją na konkretnych adresach URL, np. w raporcie robots.txt w [Google Search Console](/blog/google-search-console/).
2. **Usuń z pliku linie, których parser nie zna.** Własne „dyrektywy”, nieobsługiwane pola i dopiski nic nie robią.
3. **Zakoduj procentowo ścieżki z polskimi znakami i emoji**, jeśli reguły mają działać także poza Google.
4. **Używaj prawdziwych tokenów crawlerów AI** i sprawdzaj je w dokumentacji operatora.
5. **Nie traktuj robots.txt jako ochrony** ani jako sposobu na wycofanie danych, które firma już pobrała.
6. **Pilnuj rozmiaru, kodowania i dostępności pliku:** UTF-8, poniżej 500 KiB i odpowiedź 200. Dlaczego robots.txt zwracający 503 wstrzymuje crawlowanie, opisałem przy [wyłączaniu strony na czas łatania PHP](/blog/google-503-wylaczenie-strony-luka-php/).

## Ograniczenia i niewiadome

Odcinek omawia istniejące zasady, a Google nie ogłosił w nim żadnej zmiany w obsłudze robots.txt. Przez całą rozmowę przewija się jedno zastrzeżenie: to, co obsługuje Google, nie musi obsługiwać Bing, DuckDuckGo ani crawlery AI różnych firm. Każdy operator może czytać plik po swojemu, a część botów w ogóle go nie respektuje. W rozmowie nie padła też lista tokenów crawlerów AI, więc ich aktualność trzeba sprawdzać samemu.

## Podsumowanie

Robots.txt ma prostą składnię, przez co łatwo w nim o błąd, którego nikt nie zauważy: rozumie cztery pola, resztę odrzuca bez ostrzeżenia, w tokenach przyjmuje tylko proste znaki, a ścieżki najbezpieczniej kodować procentowo. Crawlera AI zatrzymasz właściwym tokenem, pamiętając, że plik reguluje dostęp, a nie późniejsze wykorzystanie treści. Jeśli trzymasz w pliku coś „na ozdobę” albo „na wszelki wypadek”, usuń to i sprawdź, które reguły faktycznie działają.

<FaqBlog
  questions={[
    {
      question: 'Jakie reguły obsługuje robots.txt w Google?',
      answer: 'Google obsługuje cztery pola: <strong>user-agent</strong>, <strong>allow</strong>, <strong>disallow</strong> i <strong>sitemap</strong>. Pozostałe linie ignoruje, nie wspiera też pola crawl-delay. Nazwy pól nie rozróżniają wielkości liter, ścieżki tak.'
    },
    {
      question: 'Czy w robots.txt można używać emoji i polskich znaków?',
      answer: 'W ścieżkach reguł tak, ale najbezpieczniej zapisać je w postaci percent-encoded (np. <code>/łódź/</code> jako <code>/%C5%82%C3%B3d%C5%BA/</code>). Google radzi sobie z surowym UTF-8, ale inne lub starsze crawlery mogą pominąć taką linię. W tokenie user-agent emoji i znaki spoza podstawowego zestawu nie zadziałają wcale.'
    },
    {
      question: 'Czy robots.txt zablokuje trenowanie modeli AI na mojej treści?',
      answer: 'Tylko częściowo. Plik mówi crawlerowi, czy może wejść na stronę, ale nie decyduje o tym, co firma zrobi z danymi pobranymi wcześniej. Żeby zablokować konkretnego bota AI, wpisz jego właściwy token w polu user-agent i sprawdź go w dokumentacji operatora.'
    },
    {
      question: 'Czy robots.txt chroni przed dostępem do prywatnych stron?',
      answer: 'Nie. Plik jest prośbą do crawlerów, które jej przestrzegają, a wpisana w nim ścieżka jest do tego publicznie widoczna. Treści chroni się uwierzytelnianiem albo regułami po stronie serwera.'
    }
  ]}
  heading="Często zadawane pytania"
  id="faq"
/>

## Źródła

1. **Google Explains robots.txt Rules For AI Crawlers, Emojis, International URLs & More** (Search Engine Roundtable)
[https://www.seroundtable.com/google-video-robots-txt-rules-42355.html](https://www.seroundtable.com/google-video-robots-txt-rules-42355.html)
2. **Robots.txt Specifications** (Google Search Central)
[https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt](https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt)
3. **RFC 9309: Robots Exclusion Protocol**
[https://www.rfc-editor.org/rfc/rfc9309](https://www.rfc-editor.org/rfc/rfc9309)
4. **Google's common crawlers** (Google Search Central)
[https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers)