Tester robots.txt - sprawdź dostęp robotów do strony

Tester robots.txt sprawdza, co plik robots.txt Twojej strony mówi robotom Google, Bing i Apple oraz botom AI: ChatGPT, Claude, Perplexity, Common Crawl i innym. Podaj domenę, a pobierzemy plik z serwera, albo wklej jego treść, żeby sprawdzić zmiany przed wdrożeniem. Raport pokazuje, który robot ma dostęp do witryny i która grupa User-agent o tym decyduje, listę problemów od najpoważniejszego, stan map witryny, werdykt dla podanych adresów oraz objaśnienie pliku linia po linii. Poniżej znajdziesz opis składni, zasadę rozstrzygania konfliktów między regułami, listę najczęstszych błędów oraz wyjaśnienie, dlaczego w WordPressie tego pliku nie ma na dysku.

Co pokazuje raport testera

• W skrócie - czy stronę mogą pobierać Google, Bing, wyszukiwarki AI i roboty trenujące modele AI.
• Do sprawdzenia - problemy uporządkowane od najpoważniejszego: blokada całej witryny, reguły grupy * pomijane przez roboty z własną grupą, zablokowane pliki CSS i JavaScript, dyrektywa Noindex, literówki w nazwach dyrektyw, reguły z pełnym adresem zamiast ścieżki, Crawl-delay i błąd serwera na samym pliku.
• Mapy witryny - czy adresy z dyrektyw Sitemap odpowiadają (sprawdzamy do trzech).
• Roboty - werdykt dla każdego robota z listy i grupa, która o nim decyduje. Googlebot-Image i Googlebot-News bez własnej grupy stosują reguły grupy Googlebot, a Storebot-Google - grupy *.
• Sprawdzone adresy - do 20 ścieżek naraz. Przy każdej widać, którym robotom reguła blokuje dostęp i która to reguła.
• Linia po linii - każda linia pliku z objaśnieniem, a linie z błędem są wyróżnione.

Wklejony plik analizujemy w całości w przeglądarce, bez wysyłania go na serwer, więc możesz tak sprawdzić także plik ze środowiska testowego. Przy sprawdzaniu po adresie pobieramy wyłącznie /robots.txt i nagłówki map witryny, samej strony nie. Czy serwer naprawdę wpuszcza boty AI i czy strona pozwala wykorzystać swoją treść, pokazuje osobny test widoczności dla botów AI.

Czym jest plik robots.txt i gdzie musi leżeć

robots.txt to plik tekstowy w katalogu głównym hosta, w którym właściciel witryny wskazuje robotom, których adresów nie powinny pobierać. Google opisuje jego rolę jednoznacznie: plik służy głównie do tego, żeby nie przeciążać serwera żądaniami, i nie jest mechanizmem trzymania strony poza wyszukiwarką (dokumentacja Google Search Central). To rozróżnienie jest źródłem większości nieporozumień wokół tego pliku i wracamy do niego w ostatniej sekcji.

Reguły z pliku obowiązują wyłącznie dla tego hosta, protokołu i portu, pod którym plik jest udostępniony. Plik z adresu https://www.przyklad.pl/robots.txt nie dotyczy więc ani https://przyklad.pl/, ani https://sklep.przyklad.pl/ - każda subdomena potrzebuje własnego pliku. Adres jest sztywny: plik musi leżeć bezpośrednio w katalogu głównym, a jego nazwa jest pisana małymi literami. Kopia w podkatalogu nie działa i nie jest przez roboty szukana.

Rozmiar też jest ograniczony. Google deklaruje limit 500 kibibajtów i ignoruje wszystko, co znajduje się po jego przekroczeniu, a norma RFC 9309, opisująca protokół wykluczania robotów, wymaga od crawlerów parsowania co najmniej takiej objętości. W praktyce plik dłuższy niż kilkadziesiąt linii prawie zawsze da się skrócić - długie listy pojedynczych adresów to sygnał, że problem należy rozwiązać gdzie indziej.

Jak wygląda składnia robots.txt

Plik składa się z grup. Grupa zaczyna się od jednej lub kilku linii User-agent, po których następują reguły Allow i Disallow obowiązujące wskazane roboty. Google podaje, że obsługuje tylko cztery pola: user-agent, allow, disallow oraz sitemap - pozostałe, w tym popularne crawl-delay, są przez jego roboty pomijane. Dyrektywa Sitemap jest niezależna od grup i dotyczy całej witryny, więc jej miejsce w pliku nie ma znaczenia.

Typowy plik WordPressa wygląda tak:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://przyklad.pl/sitemap_index.xml

Która reguła wygrywa, gdy przepisy się kłócą

Robot wybiera najpierw grupę, a dopiero potem regułę - i te dwa kroki mają osobne zasady. Zgodnie z RFC 9309 crawler dopasowuje swoją nazwę do linii User-agent bez rozróżniania wielkości liter, a grupę z gwiazdką traktuje wyłącznie jako zapasową: stosuje ją tylko wtedy, gdy nie znalazł grupy dla siebie. Oznacza to, że robot, który ma własną grupę, w ogóle nie czyta reguł z grupy *. To jeden z najczęstszych błędów w interpretacji pliku: dopisanie grupy dla pojedynczego bota potrafi mu nieświadomie otworzyć wszystko, co blokowała gwiazdka.

Wewnątrz wybranej grupy konflikt rozstrzyga długość wzorca. RFC 9309 mówi, że wygrywa dopasowanie najbardziej szczegółowe, czyli to o największej liczbie znaków, a przy wzorcach równie długich pierwszeństwo ma Allow. Dlatego domyślna para reguł WordPressa działa poprawnie: Disallow: /wp-admin/ zamyka panel, ale dłuższa reguła Allow: /wp-admin/admin-ajax.php wyjmuje spod blokady jeden potrzebny plik.

We wzorcach ścieżek działają dwa znaki specjalne: * zastępuje dowolny ciąg znaków (także pusty), a $ oznacza koniec adresu. Same ścieżki są dopasowywane z uwzględnieniem wielkości liter, więc /Katalog/ i /katalog/ to dla robota dwa różne adresy.

Najczęstsze błędy w robots.txt

• Zapomniane Disallow: / ze środowiska testowego - plik przeniesiony razem z witryną na produkcję zamyka całą stronę przed robotami. To najkosztowniejszy błąd z tej listy i jednocześnie najłatwiejszy do przeoczenia, bo strona działa normalnie dla ludzi.
• Blokowanie arkuszy stylów i skryptów - reguła obejmująca cały katalog z zasobami motywu uniemożliwia wyszukiwarce wyrenderowanie strony tak, jak widzi ją użytkownik, więc ocena strony opiera się na niepełnym obrazie.
• Dyrektywa Noindex: wpisana do robots.txt - Google obsługuje w tym pliku wyłącznie cztery pola wymienione wyżej, więc taka linia jest po prostu ignorowana. Zakaz indeksowania ma swoje miejsce w znaczniku meta lub w nagłówku HTTP, nie tutaj.
• Serwer zwracający błąd 5xx na /robots.txt - RFC 9309 nakazuje wtedy przyjąć pełny zakaz pobierania. Awaria samego pliku działa więc jak tymczasowe zamknięcie całej witryny, choć strona odpowiada poprawnie. Google w takiej sytuacji wstrzymuje pobieranie na 12 godzin, a przez kolejnych 30 dni posługuje się ostatnią poprawnie pobraną wersją pliku, ponawiając próby.
• Plik zwracający HTML zamiast czystego tekstu - typowy objaw miękkiego błędu 404, gdy serwer zamiast pliku podaje stronę „nie znaleziono” z kodem 200. Robot dostaje wtedy dokument, którego nie potrafi sparsować.
• Reguły dla jednego robota rozbite na kilka grup - przy powtórzonej nazwie w kilku miejscach pliku łatwo stracić kontrolę nad tym, co ostatecznie obowiązuje. Jedna nazwa, jedna grupa.

Przegląd tego pliku wypada w pierwszych krokach każdego audytu SEO - właśnie dlatego, że pojedyncza linia potrafi tu unieważnić miesiące pracy nad treścią.

Jak WordPress generuje robots.txt

W WordPressie plik robots.txt zwykle nie istnieje na dysku - jest generowany w locie przy każdym żądaniu. Odpowiada za to funkcja do_robots() z pliku wp-includes/functions.php, która wypisuje minimalny zestaw reguł (grupa *, blokada /wp-admin/ i wyjątek na admin-ajax.php), a następnie przepuszcza wynik przez filtr robots_txt. Z tego filtra korzystają wtyczki: to w ten sposób do pliku trafia linia Sitemap dodawana przez wtyczkę SEO. Szukanie pliku przez FTP kończy się więc komunikatem „nie znaleziono”, mimo że pod adresem /robots.txt treść jest podawana poprawnie.

Ma to jedną praktyczną konsekwencję: jeśli ktoś wgra fizyczny plik robots.txt do katalogu głównego, serwer poda jego zawartość i cała warstwa WordPressa przestaje mieć znaczenie. Zmiany wprowadzane w panelu wtyczki nie dają wtedy żadnego efektu, choć interfejs pokazuje, że zostały zapisane. Przy diagnozie zaczynaj więc od sprawdzenia, czy plik fizycznie istnieje.

Warto też wiedzieć, czego ustawienie „Proszę wyszukiwarki o nieindeksowanie tej witryny” nie robi. W aktualnym WordPressie nie dopisuje ono do robots.txt reguły Disallow: / - zamiast tego dokłada do stron znacznik meta z dyrektywami noindex, nofollow (funkcja wp_robots_noindex() w wp-includes/robots-template.php, sprawdzone w kodzie WordPressa 7.0.3). Plik robots.txt wygląda przy tym zupełnie czysto, a witryna i tak jest wypisywana z indeksu. To częsty powód sytuacji, w której poprawny robots.txt nijak nie tłumaczy zniknięcia strony z wyników.

Czego robots.txt nie robi

robots.txt nie ukrywa strony przed wyszukiwarką. Google podaje wprost, że adres zablokowany w tym pliku nadal może zostać zaindeksowany, jeśli prowadzą do niego linki z innych witryn - do wyniku trafia wtedy sam adres, bez opisu, bo robot nie mógł pobrać treści. Żeby strona nie pojawiała się w wynikach, służy dyrektywa noindex w znaczniku meta albo w nagłówku X-Robots-Tag, hasło na serwerze lub usunięcie strony.

Z tego wynika pułapka, która regularnie unieruchamia oba mechanizmy naraz: noindex i blokada w robots.txt wzajemnie się wykluczają. Google zaznacza, że aby dyrektywa noindex zadziałała, strona nie może być zablokowana w robots.txt i musi być dla robota dostępna - inaczej crawler nigdy tej dyrektywy nie zobaczy, a adres może dalej pojawiać się w wynikach. Jeśli chcesz wypisać stronę z indeksu, zostaw ją otwartą w robots.txt.

Plik nie chroni też niczego przed dostępem. Jest publiczny i czytelny dla każdego, więc lista zablokowanych katalogów bywa gotową mapą miejsc, których właściciel woli nie pokazywać. I wreszcie: stosowanie się do niego jest dobrowolne. Boty AI mają tu własne reguły gry - część z nich pobiera stronę dopiero na wyraźne żądanie użytkownika i wtedy dyrektywy z robots.txt bywają pomijane. Sprawdzisz to w teście widoczności strony dla botów AI, który zamiast samej składni pliku bada, czy treść może w ogóle trafić do odpowiedzi asystenta. Szerszy kontekst tych zmian opisujemy w przewodniku o SEO pod AI.

Najczęstsze pytania

Czy zablokowanie strony w robots.txt usunie ją z wyników wyszukiwania?

Nie. Blokada w robots.txt zabrania pobrania strony, ale nie usuwa jej z indeksu - Google podaje, że adres zablokowany w tym pliku nadal może zostać zaindeksowany, jeśli linkują do niego inne witryny. Żeby strona nie pojawiała się w wynikach, użyj dyrektywy noindex w znaczniku meta lub w nagłówku X-Robots-Tag i jednocześnie nie blokuj tej strony w robots.txt, bo wtedy robot nigdy nie zobaczy dyrektywy noindex.

Która reguła wygrywa, gdy Allow i Disallow pasują do tego samego adresu?

Wygrywa reguła o dłuższym wzorcu, a przy wzorcach tej samej długości pierwszeństwo ma Allow - tak opisuje to norma RFC 9309. Dlatego para reguł „Disallow: /wp-admin/” i „Allow: /wp-admin/admin-ajax.php” zamyka panel administracyjny, ale zostawia otwarty pojedynczy plik: druga reguła jest dłuższa, więc dla tego adresu to ona obowiązuje.

Gdzie znajdę plik robots.txt w WordPressie, skoro nie ma go na serwerze?

W WordPressie robots.txt jest domyślnie generowany dynamicznie przez funkcję do_robots() i nie istnieje jako plik na dysku, dlatego widać go pod adresem /robots.txt, ale nie widać przez FTP. Treść zmienia się przez filtr robots_txt, z którego korzystają wtyczki SEO. Jeśli w katalogu głównym pojawi się fizyczny plik o tej nazwie, ma on pierwszeństwo i ustawienia z panelu przestają działać.