Jak skonfigurować robots.txt i uniknąć typowych błędów

Zasady, które warto znać, zanim cokolwiek zmienisz

Kilka reguł działania pliku decyduje o tym, czy konfiguracja zrobi to, co zamierzasz:

• Jeden plik na host. Plik musi leżeć w katalogu głównym, pod adresem https://twojadomena.pl/robots.txt. Subdomena, np. sklep.twojadomena.pl, ma własny plik i nie dziedziczy reguł z domeny głównej.
• Plik musi zwracać kod 200. Gdy serwer odpowiada błędem 404, Google uznaje, że nie ma żadnych ograniczeń. Gdy odpowiada błędem 5xx, może wstrzymać skanowanie całej witryny, dopóki plik nie zacznie działać.
• Ścieżki rozróżniają wielkość liter. Disallow: /Admin/ nie zablokuje katalogu /admin/.
• Reguła to początek ścieżki. Disallow: /blog blokuje także /blog-firmowy i /blogowanie.html. Jeśli chodzi o sam katalog, pisz /blog/.
• Wygrywa najdokładniejsza reguła. Google wybiera regułę z najdłuższą pasującą ścieżką, a przy remisie tę mniej restrykcyjną, czyli Allow.

Plik ma też limit rozmiaru (Google czyta pierwsze 500 KiB), ale w praktyce problemem nie jest długość, tylko reguły, których nikt nie rozumie. Każdą linijkę, której przeznaczenia nie potrafię wyjaśnić, traktuję jako kandydatkę do usunięcia.

Dyrektywy i symbole, których używam

W codziennej pracy wystarcza mi kilka elementów:

• User-agent – do którego robota odnosi się grupa reguł. Gwiazdka * oznacza wszystkie roboty, które nie mają własnej grupy.
• Disallow – ścieżka, której robot nie powinien skanować.
• Allow – wyjątek od blokady, np. jeden plik w zablokowanym katalogu.
• * w ścieżce – dowolny ciąg znaków, a $ – koniec adresu.
• Sitemap – pełny adres mapy witryny. Ta linia nie należy do żadnej grupy i może stać w dowolnym miejscu pliku.

Warto pamiętać, czego Google nie obsługuje. Dyrektywa Crawl-delay jest przez Googlebota ignorowana, a Noindex wpisane w robots.txt nie działa od 2019 roku. Jeśli widzę je w pliku, to znak, że ktoś liczył na efekt, którego nie ma.

Przykładowe konfiguracje

Strona na WordPressie. Tu zwykle wystarczy zablokować panel administracyjny z wyjątkiem pliku, z którego korzystają funkcje na stronie, oraz wewnętrzną wyszukiwarkę:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/

Sitemap: https://twojadomena.pl/sitemap.xml

Sklep internetowy. W sklepach najwięcej zbędnych adresów generują koszyk, konto klienta, sortowanie i kombinacje filtrów. Przykład dla sklepu, w którym sortowanie i filtry są przekazywane w parametrach adresu:

User-agent: *
Disallow: /koszyk/
Disallow: /zamowienie/
Disallow: /moje-konto/
Disallow: /*?*sort=
Disallow: /*?*filter=

Sitemap: https://twojadomena.pl/sitemap.xml

Zanim zablokuję parametry, sprawdzam, czy któryś z nich nie tworzy stron, które mają sens w wyszukiwarce, np. kategorii z jednym popularnym filtrem. Takiego adresu nie blokuję, tylko robię z niego pełnoprawną podstronę. W dużych serwisach to jeden z pierwszych kroków, od których zaczynam optymalizację crawl budgetu.

Blokada w robots.txt to nie usunięcie z Google

To błąd, który widzę najczęściej. Disallow blokuje tylko skanowanie. Jeśli do zablokowanej podstrony prowadzą linki, Google może ją zaindeksować bez znajomości treści i pokazać w wynikach sam adres, bez opisu.

Gdy strona ma zniknąć z wyników, robię odwrotnie, niż podpowiada intuicja: zostawiam ją dostępną dla robotów i dodaję w kodzie <meta name="robots" content="noindex">. Robot musi wejść na stronę, żeby zobaczyć tę instrukcję. Blokada w robots.txt i noindex na tej samej stronie wykluczają się wzajemnie, bo noindex nigdy nie zostanie odczytany. Dla plików, w których nie da się dodać metatagu, np. PDF-ów, używam nagłówka X-Robots-Tag: noindex, który na serwerze Apache ustawisz jedną regułą w pliku .htaccess.

Najczęstsze błędy, które znajduję w audytach

• Blokada całego serwisu po wdrożeniu. Na serwerze testowym stoi Disallow: /, a przy przenoszeniu na produkcję plik idzie razem z resztą. Dlatego robots.txt jest stałym punktem mojej listy przy każdej migracji strony.
• Zablokowane pliki CSS i JavaScript. Google renderuje stronę tak jak przeglądarka. Jeśli nie ma dostępu do stylów i skryptów, może źle ocenić jej wygląd i treść, zwłaszcza na stronach budowanych w JavaScripcie.
• Ukrywanie poufnych katalogów. Plik jest publiczny i każdy może go odczytać. Wpisanie w nim ścieżki do panelu czy kopii zapasowych to wskazówka dla atakującego, a nie zabezpieczenie. Takie miejsca chroni się hasłem i uprawnieniami na serwerze.
• Zbyt szeroki wzorzec. Reguła Disallow: /*? blokuje wszystkie adresy z parametrami, także paginację i strony, które powinny być w indeksie.
• Nieaktualna mapa witryny. Linia Sitemap wskazuje adres starej mapy, wersję bez HTTPS albo plik, który zwraca błąd. Po każdej zmianie mapy strony XML sprawdzam, czy adres w robots.txt nadal jest aktualny.

Roboty AI w robots.txt

Coraz częściej klienci pytają, czy da się zablokować modele językowe. Częściowo tak: większość dużych firm ma własne nazwy robotów, które respektują robots.txt, np. GPTBot (OpenAI), ClaudeBot (Anthropic) czy CCBot (Common Crawl). Osobnym przypadkiem jest Google-Extended: to nie robot, tylko znacznik, którym możesz odmówić wykorzystania treści do trenowania modeli Google bez wpływu na widoczność w wyszukiwarce.

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Zanim dodam taką blokadę, ustalam z klientem cel. Blokowanie robotów AI może ograniczyć obecność marki w odpowiedziach asystentów, a roboty, które nie respektują pliku, i tak trzeba zatrzymywać na poziomie serwera. To, które roboty faktycznie odwiedzają stronę, najlepiej pokazuje analiza logów serwera.

Jak testuję zmiany przed i po wdrożeniu

Każdą zmianę w robots.txt sprawdzam w kilku krokach:

• Sprawdzam, czy plik zwraca kod 200, np. poleceniem curl -I https://twojadomena.pl/robots.txt.
• Przed wdrożeniem testuję reguły na liście ważnych adresów: stron głównych kategorii, produktów, wpisów, plików CSS i JS. Każdy z nich musi pozostać dostępny.
• Po wdrożeniu zaglądam do raportu robots.txt w Google Search Console (Ustawienia), który pokazuje, kiedy Google pobrał plik i czy napotkał błędy. Pojedyncze adresy sprawdzam narzędziem do sprawdzania adresów URL.
• Przez kolejne dni obserwuję raport stron w Search Console. Nagły wzrost adresów „zablokowanych przez plik robots.txt” to sygnał, że reguła objęła więcej, niż zakładałem.

Robots.txt to plik, który zmieniam rzadko, ale zawsze świadomie. Jeśli po każdej zmianie potrafię powiedzieć, które adresy przestały być skanowane i dlaczego, konfiguracja robi to, czego od niej oczekuję.