Każda strona internetowa prowadzi cichy dialog z robotami wyszukiwarek. Zanim Googlebot wyświetli choćby jeden wynik, sprawdza niewielki plik tekstowy w katalogu głównym domeny — robots.txt. Ten kilkulinijkowy dokument decyduje, które zasoby crawler może indeksować, a które powinien ominąć. Błędna konfiguracja robots potrafi w ciągu kilku godzin usunąć setki podstron z wyników wyszukiwania. Z kolei przemyślana struktura dyrektyw pomaga crawlerom efektywniej wykorzystywać budżet indeksowania i docierać do treści, na których naprawdę zależy właścicielowi witryny. Przy audytach spotykamy się z plikami, które albo blokują za dużo, albo nie blokują niczego — oba skrajne podejścia generują problemy. Poniżej omawiamy mechanikę działania, składnię, najczęstsze błędy i sprawdzone wzorce konfiguracji.
Z naszego artykułu dowiesz się:
Czym jest plik robots.txt i jak go interpretują wyszukiwarki
Robots.txt to zwykły plik tekstowy umieszczony pod adresem domena.pl/robots.txt. Roboty wyszukiwarek — Googlebot, Bingbot, YandexBot i inne — pobierają go jako pierwszy krok przed crawlowaniem witryny. Plik nie wymaga żadnego specjalnego serwera ani interpretera: to czysty tekst z dyrektywami zgodnymi ze standardem Robots Exclusion Protocol z 1994 roku, zaktualizowanym przez Google w 2019 roku jako RFC 9309.
Kolejność pobierania i cachowanie pliku przez crawlery
Crawler wysyła żądanie HTTP GET na adres /robots.txt przed rozpoczęciem indeksowania jakiejkolwiek podstrony. Jeśli serwer zwraca kod 200, robot parsuje dyrektywy i stosuje je do kolejnych żądań. Przy kodzie 404 (plik nie istnieje) crawler zakłada pełen dostęp do wszystkich zasobów. Przy kodach 5xx (błąd serwera) Googlebot wstrzymuje crawlowanie — traktuje brak odpowiedzi jako potencjalną blokadę, co może na kilka godzin zatrzymać indeksowanie całej domeny.
Google cachuje zawartość robots.txt na około 24 godziny. Oznacza to, że po wprowadzeniu zmian efekt nie jest natychmiastowy — przy dużych witrynach opóźnienie sięga czasem 48 godzin. Z naszego doświadczenia wynika, że wymuszenie ponownego pobrania przez Google Search Console (funkcja „Testuj plik robots.txt") skraca ten czas do kilku minut.
Różnica między robots.txt a meta robots i nagłówkiem X-Robots-Tag
Robots.txt kontroluje dostęp crawlerów — mówi „nie wchodź tutaj". Natomiast meta robots (tag w HTML) i nagłówek X-Robots-Tag kontrolują indeksowanie — mówią „wszedłeś, ale nie dodawaj tego do indeksu". Plik robots nie gwarantuje usunięcia strony z wyników Google, bo jeśli inna witryna linkuje do zablokowanego URL-a, wyszukiwarka może wyświetlić go w wynikach (bez snippetu, ale z adresem). Dopiero kombinacja robots.txt z odpowiednimi dyrektywami noindex daje pełną kontrolę — choć tu pojawia się paradoks: jeśli zablokujesz crawlowanie, robot nie przeczyta tagu noindex. Dlatego przy stronach wymagających usunięcia z indeksu lepiej stosować noindex bez blokady w robots.txt.
Składnia dyrektyw — User-agent, Disallow i Allow w praktyce
Plik robots.txt składa się z bloków dyrektyw. Każdy blok zaczyna się od User-agent, po którym następują reguły Disallow i Allow. Składnia jest prosta, ale nieintuicyjna w kilku miejscach — i właśnie tam pojawiają się błędy.
Podstawowa struktura wygląda tak:
Ważny niuans dotyczy ukośnika na końcu ścieżki. Dyrektywa Disallow: /admin blokuje zarówno /admin/, jak i /administrator/ czy /admin-panel/, bo dopasowanie działa na zasadzie prefiksu. Natomiast Disallow: /admin/ blokuje tylko adresy zaczynające się od /admin/. Przy witrynach z wieloma katalogami o podobnych nazwach ta różnica jednego znaku potrafi zablokować lub odblokować dziesiątki podstron.
Google obsługuje też wzorce z symbolami wieloznacznymi: * zastępuje dowolny ciąg znaków, a $ oznacza koniec URL-a. Przykładowo Disallow: /*.pdf$ blokuje wszystkie pliki PDF na stronie, nie wpływając na inne zasoby.
Blokowanie crawlerów — co ukrywać przed robotami, a czego nie ruszać
Decyzja o tym, co zablokować w robots.txt, powinna wynikać z analizy budżetu crawlowania i struktury witryny, nie z domysłów. Blokowanie niewłaściwych zasobów potrafi obniżyć widoczność w wyszukiwarkach, a zbyt liberalne podejście marnuje budżet crawlowania na strony bez wartości SEO.
| Zasób | Blokować? | Uzasadnienie | |
| Panel administracyjny (/wp-admin/, /admin/) | Tak | Brak wartości SEO, wrażliwe dane | |
| Wyniki wyszukiwania wewnętrznego (/search/, /?s=) | Tak | Duplikaty treści, nieskończona liczba kombinacji | |
| Strony filtrowania i sortowania | Tak (z wyjątkami) | Generują tysiące thin content URL-i | |
| Koszyk i proces zamówienia (/cart/, /checkout/) | Tak | Brak wartości SEO, dane sesyjne | |
| Pliki CSS i JavaScript | Nie | Googlebot wymaga ich do renderowania strony | |
| Obrazy (/wp-content/uploads/) | Nie (zwykle) | Indeksowane w Google Images, generują ruch | |
| Strony kategorii i tagów (blog) | Zależy | Blokuj tylko jeśli generują duplikaty |
Przy sklepach internetowych z tysiącami wariantów filtrowania (kolor + rozmiar + cena + marka) robots.txt staje się narzędziem do odcięcia kombinatorycznej eksplozji URL-i. Witryna z 500 produktami i 10 filtrami może teoretycznie wygenerować setki tysięcy unikalnych adresów — większość z nich to thin content bez wartości dla użytkownika. Blokowanie parametrów filtrów dyrektywą Disallow: /*?filtr= ratuje budżet crawlowania.
Jednocześnie ostrożność obowiązuje przy blokadzie zasobów renderujących. W 2014 roku Google oficjalnie ostrzegło, że blokowanie CSS i JS w robots.txt utrudnia ocenę strony i może negatywnie wpłynąć na pozycje. Od tamtej pory konsekwentnie powtarzają: pozwólcie Googlebotowi renderować stronę tak, jak widzi ją użytkownik.
Typowe błędy konfiguracji robots.txt i ich konsekwencje SEO
Audytując witryny, regularnie trafiamy na te same kategorie błędów — od literówek po fundamentalne nieporozumienia dotyczące działania dyrektyw. Oto problemy, które napotykamy najczęściej.
Pusta dyrektywa Disallow i przypadkowa blokada całej witryny
Dyrektywa Disallow: / (z ukośnikiem) blokuje całą witrynę. Dyrektywa Disallow: (bez wartości) nie blokuje niczego — jest równoważna brakowi dyrektywy. Pomyłka między tymi dwoma wariantami zdarza się zaskakująco często. Na jednej z analizowanych witryn e-commerce ktoś dodał Disallow: / pod User-agent: * „tymczasowo" podczas przebudowy — i zapomniał usunąć przez trzy tygodnie. Witryna straciła 94% ruchu organicznego. Odzyskanie pozycji po odblokowaniu zajęło ponad dwa miesiące.
Konflikt między robots.txt a canonical i noindex
Kolejny częsty błąd to blokowanie URL-i, na których ustawiono tag canonical lub noindex. Jeśli robot nie ma dostępu do strony, nie przeczyta żadnej dyrektywy w kodzie HTML — ani canonical, ani noindex. Strona pozostaje w indeksie jako „znana, ale niezaindeksowana", a Google może ją wyświetlać na podstawie anchor textów z linków zewnętrznych. Rozwiązanie? Jeśli celem jest usunięcie z indeksu — stosuj noindex bez blokady w robots.txt. Jeśli celem jest oszczędność budżetu crawlowania przy stronach już nieindeksowanych — wtedy blokada w robots ma sens.
Dodatkowy problem pojawia się przy migracjach. Nowy robots.txt wgrany na serwer stagingowy (z Disallow: / blokującym indeksowanie środowiska testowego) trafia na produkcję razem z resztą kodu. Takie sytuacje zdarzają się co najmniej raz na kilkadziesiąt audytów i potrafią pozostać niezauważone przez dni, zanim ktoś sprawdzi Google Search Console.
Wzorcowa konfiguracja robots.txt — szablony dla różnych typów witryn
Nie istnieje jeden uniwersalny plik robots.txt — konfiguracja zależy od CMS-a, typu witryny i strategii SEO. Przedstawiamy trzy wzorce, które sprawdzają się w praktyce.
Dla typowego bloga na WordPressie sprawdza się minimalistyczne podejście: blokada panelu administracyjnego i wewnętrznej wyszukiwarki, otwarcie reszty. Dyrektywy Disallow: /wp-admin/ i Allow: /wp-admin/admin-ajax.php (potrzebny do działania wielu wtyczek) plus Disallow: /?s= dla wyników wyszukiwania. Reszta pozostaje otwarta, a na końcu pliku dodajemy dyrektywę Sitemap.
Sklepy internetowe wymagają rozbudowanej konfiguracji. Blokada filtrów (Disallow: /*?filtr), koszyka (Disallow: /cart/), konta użytkownika (Disallow: /my-account/) i stron sortowania (Disallow: /*?orderby=). Strony kategorii i produktów pozostają otwarte — to rdzeń widoczności organicznej.
Serwisy wielojęzyczne powinny unikać blokowania alternatywnych wersji językowych. Każda wersja językowa generuje ruch z odpowiedniego rynku i potrzebuje indeksowania. Blokowanie np. /en/ lub /de/ to rezygnacja z ruchu międzynarodowego.
Niezależnie od typu witryny, po każdej zmianie warto zweryfikować plik w Google Search Console (Tester pliku robots.txt) oraz monitorować raport pokrycia indeksowania przez kolejne 7-14 dni. Wszelkie anomalie w liczbie zaindeksowanych stron sygnalizują problem z konfiguracją. Regularna weryfikacja — choćby raz na kwartał — pozwala wyłapać regresje wprowadzone przez aktualizacje CMS-a, wtyczek czy zmiany w infrastrukturze serwerowej, zanim wpłyną na widoczność organiczną.
