Robots.txt: co robi, czego nie robi i jak go sprawdzić

Plik robots.txt mówi robotom wyszukiwarek, które obszary witryny mogą pobierać. Nie usuwa strony z indeksu, nie chroni poufnych danych i nie zastępuje dyrektywy noindex. Najbezpieczniej traktować go jak regulację ruchu crawlerów: najpierw sprawdzić konkretny adres, potem regułę, która do niego pasuje, a na końcu rzeczywistą odpowiedź serwera.

Co robots.txt kontroluje, a czego nie potrafi zrobić

Plik znajduje się w katalogu głównym hosta. Dla adresu https://example.pl/oferta/ właściwy plik to https://example.pl/robots.txt. Subdomena ma własny plik, podobnie jak inny protokół lub port. Reguła umieszczona na www.example.pl nie zarządza automatycznie adresem sklep.example.pl. To ważne przy stronach, które mają blog, sklep albo panel na osobnych hostach.

Robot przed pobraniem zasobu może sprawdzić, czy jego identyfikator i ścieżka są dozwolone. Reguła Disallow: /panel/ oznacza zakaz pobierania ścieżek rozpoczynających się od /panel/ dla wskazanego user-agenta. Nie powoduje jednak zniknięcia samego adresu z internetu. Jeżeli inne strony do niego linkują, wyszukiwarka może znać URL i w pewnych sytuacjach pokazać go bez odczytanej treści.

Najczęstsze nieporozumienie polega na jednoczesnym zablokowaniu adresu i dodaniu na nim noindex. Robot nie pobiera strony, więc nie widzi dyrektywy. Jeśli URL był wcześniej w indeksie, efekt może być odwrotny od oczekiwanego: treść przestaje być odczytywana, ale sam adres nie znika od razu. Zależność między tymi mechanizmami szerzej wyjaśnia poradnik o dyrektywie noindex i bezpiecznym przywracaniu indeksacji.

Robots nie jest również narzędziem do oszczędzania każdej pojedynczej wizyty Googlebota. Na małej witrynie kilka poprawnych stron, arkuszy stylów i skryptów nie stanowi problemu. Blokowanie zasobów potrzebnych do renderowania może natomiast sprawić, że wyszukiwarka zobaczy stronę inaczej niż użytkownik. Interweniuj tam, gdzie istnieje realna grupa powtarzalnych URL-i technicznych, filtrów, wyników wewnętrznych lub środowisk, a nie dla samego posiadania rozbudowanego pliku.

Jak czytać sekcje User-agent, Disallow i Allow

Plik jest tekstowy i składa się z grup. Grupa zaczyna się od jednego albo kilku wierszy User-agent, a pod nimi znajdują się reguły. Pusta wartość Disallow: niczego nie blokuje. Zapis Disallow: / odcina wskazanego robota od całego hosta. Jedna pomylona kreska potrafi więc zmienić znaczenie z neutralnego na krytyczne.

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

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

Ten przykład zabrania pobierania większości zaplecza WordPressa, ale pozostawia dostęp do pliku używanego przez część funkcji frontendu. Wiersz Sitemap nie jest regułą blokującą. Wskazuje lokalizację mapy i może występować niezależnie od grup user-agentów. Jeżeli witryna korzysta z Yoasta, właściwym adresem jest zwykle indeks map. Samo dodanie wpisu nie naprawi mapy zawierającej 404, przekierowania albo URL-e noindex; jej zawartość trzeba ocenić osobno według procedury z poradnika o mapie strony WordPress.

Ścieżki są rozpatrywane od pierwszego znaku po nazwie hosta. Disallow: /koszyk/ dotyczy https://example.pl/koszyk/, ale nie adresu na innym subdomenowym hoście. Wielkość liter może mieć znaczenie, ponieważ serwer może rozróżniać /Pliki/ i /pliki/. Nie zakładaj, że reguła zadziała na podobnie wyglądające warianty. Wypisz kilka reprezentatywnych URL-i i testuj je pojedynczo.

Symbol * może reprezentować ciąg znaków, a znak $ koniec adresu. Reguła Disallow: /*?sort= bywa używana do ograniczenia wariantów sortowania, ale wymaga znajomości sposobu budowy parametrów w danym serwisie. Zbyt szeroki wzorzec może objąć linki kampanii, paginację albo adresy, które mają samodzielną wartość. W małej stronie czytelna lista kilku ścieżek bywa bezpieczniejsza niż krótka, lecz nieprzewidywalna reguła z wieloma wildcardami.

Skąd bierze się robots.txt w WordPressie

WordPress może generować wirtualny plik, nawet gdy fizycznego robots.txt nie ma w katalogu instalacji. Wtyczka SEO, warstwa cache, serwer albo CDN mogą go następnie zmieniać. Dlatego odczyt publicznego adresu jest ważniejszy niż samo sprawdzenie plików na hostingu. Liczy się odpowiedź, którą otrzymuje niezalogowany użytkownik i crawler.

Ustawienie „Proś wyszukiwarki o nieindeksowanie tej witryny” nie jest subtelnym przełącznikiem stagingu. W środowisku testowym może być zasadne, ale po migracji trzeba sprawdzić, czy zostało wyłączone. Sama zmiana opcji nie daje jeszcze pełnej pewności, bo wtyczka lub serwer mogą nadal emitować noindex, a plik robots może zawierać blokadę. Kontroluj oba mechanizmy na rzeczywistym froncie.

W instalacji z Yoast SEO mapa powinna być wskazana jednym aktualnym adresem. Nie ma potrzeby utrzymywania listy wszystkich map podrzędnych w robots. Gdy zmieniasz system map, sprawdź, czy stary adres przekierowuje do nowego albo zwraca uczciwy brak, a nie pustą mapę. W Google Search Console usuń zgłoszenie, które przestało odpowiadać aktywnej konfiguracji, i prześlij indeks używany obecnie.

Jeżeli kilka narzędzi próbuje zarządzać tym samym plikiem, ustal jedno źródło prawdy. Ręczny plik na serwerze może mieć pierwszeństwo przed wirtualną odpowiedzią WordPressa. Cache może z kolei podawać starą wersję po edycji. Zapisz oczekiwaną treść, wyczyść właściwą warstwę pamięci podręcznej i pobierz plik ponownie w oknie prywatnym. Przy serwisie utrzymywanym przez kilka osób przydaje się stała opieka techniczna nad WordPressem, jeżeli reguły, aktualizacje i monitoring mają mieć jednego odpowiedzialnego wykonawcę.

Jak sprawdzić, czy konkretny URL jest zablokowany

Zacznij od pełnego adresu końcowego. Jeśli wpisujesz stary URL, który przekierowuje, diagnozujesz inną ścieżkę niż dokument docelowy. Otwórz stronę, zanotuj kod odpowiedzi, canonical i wariant hosta. Dopiero potem porównuj ścieżkę z robots. Taka kolejność zapobiega poprawianiu pliku dla adresu, którego witryna już nie używa.

1. Pobierz publiczny plik. Sprawdź status 200, typ treści i to, czy nie oglądasz komunikatu błędu udającego plik tekstowy.
2. Ustal crawlera. Reguła dla konkretnego user-agenta może mieć inne znaczenie niż grupa ogólna.
3. Dopasuj ścieżkę. Porównaj cały fragment od pierwszego ukośnika, włącznie z parametrami, jeżeli występują w regule.
4. Sprawdź zasoby strony. HTML może być dozwolony, podczas gdy krytyczny CSS, JavaScript albo obraz LCP jest zablokowany.
5. Użyj inspekcji URL. Odczytaj stan ostatnio znany Google i wynik bieżącego testu. Nie mieszaj tych dwóch widoków.
6. Porównaj z intencją. Zablokowana strona konta może być prawidłowym wynikiem; zablokowany poradnik przeznaczony do Google zwykle nie.

Komunikat o blokadzie nie mówi automatycznie, że cała witryna ma problem. Raporty często pokazują adresy techniczne, które świadomie nie powinny być crawlowane. Klasyfikuj grupy według wzorca. Jeśli blokada obejmuje jeden katalog roboczy, naprawa nie może przy okazji otworzyć koszyka, panelu albo setek parametrów. Zmiana powinna być najmniejsza, która udostępnia potrzebną treść.

Po poprawce testuj pary adresów: jeden, który powinien być dozwolony, i jeden, który nadal ma pozostać zablokowany. Następnie sprawdź stronę w inspekcji. Jeśli celem jest indeksacja, kontrola nie kończy się na „dozwolono pobieranie”. URL musi zwracać 200, nie mieć noindex, wskazywać właściwy canonical i posiadać drogę odkrycia. Procedurę końcową opisuje poradnik jak sprawdzić indeksację konkretnej strony.

Błędy, które najczęściej powodują szkody

Najbardziej kosztowna jest publikacja wersji stagingowej na produkcji razem z Disallow: /. Strona działa dla ludzi, więc zespół uznaje start za udany, ale crawler nie może pobrać żadnego dokumentu. Dlatego kontrola robots powinna znaleźć się na krótkiej checkliście publikacyjnej obok HTTPS, canonicali, mapy i formularzy.

Drugi błąd to blokowanie CSS i JavaScript na podstawie przekonania, że robot potrzebuje tylko tekstu. Wyszukiwarka renderuje strony, a zablokowane zasoby mogą utrudnić ocenę wersji mobilnej, układu lub treści ładowanej przez skrypt. Nie otwieraj całego zaplecza w ciemno, lecz nie odcinaj plików publicznego motywu wyłącznie dlatego, że znajdują się w katalogu technicznym.

Trzeci problem powstaje przy parametrach. Blokada wszystkich URL-i zawierających znak zapytania może objąć adresy kampanii, filtry potrzebne użytkownikom albo zasoby z wersjonowaniem. Parametr sam w sobie nie oznacza śmieciowej strony. Najpierw ustal, jakie kombinacje generuje witryna, czy zwracają tę samą treść, jaki mają canonical i czy występują w linkach. Dopiero na tej podstawie wybierz crawling, canonical albo zmianę sposobu generowania adresów.

Czwarty błąd to edycja bez kontroli odpowiedzi po wdrożeniu. Poprawny plik zapisany lokalnie nie ma znaczenia, jeśli serwer nadal podaje starą wersję. Sprawdź wynik przez HTTP, najlepiej z innej sesji, i zanotuj datę. Jeśli widzisz rozbieżność między treścią oczekiwaną a publiczną, przejrzyj cache serwera, CDN oraz fizyczny plik w katalogu głównym.

Ostatnia pułapka polega na traktowaniu każdego raportowanego zablokowanego URL-a jak usterki. Koszyk, wyniki wyszukiwania, panel logowania lub nieskończone kombinacje filtrów mogą być świadomie wyłączone. Naprawiaj ważne adresy kanoniczne, a nie samą liczbę komunikatów. Powiązania między mapą, canonicalem i linkami wewnętrznymi pomagają ustalić, które strony portal naprawdę uznaje za publiczne.

Najczęstsze pytania o robots.txt

Po każdej zmianie zachowaj kopię poprzedniego pliku, listę testowanych URL-i i oczekiwany wynik. Jedna reguła obejmuje często setki adresów, dlatego kontrola reprezentatywnych przykładów jest ważniejsza niż samo stwierdzenie, że plik ma poprawną składnię.