Plik robots.txt to jeden z pierwszych elementów, z jakimi styka się robot wyszukiwarki podczas odwiedzin serwisu. Zanim Googlebot czy Bingbot zacznie indeksować strony, zagląda właśnie tu — do prostego pliku tekstowego znajdującego się w katalogu głównym domeny. Robots txt wprowadzenie do tego tematu warto zacząć od zrozumienia, czym ten mechanizm jest w praktyce, a czym zdecydowanie nie jest.
Plik robots.txt nie jest barierą bezpieczeństwa. Nie chroni danych, nie szyfruje treści, nie blokuje dostępu złośliwym botom. Jego jedyną funkcją jest komunikacja z botami, które respektują standard Robots Exclusion Protocol — a te „grzeczne” roboty faktycznie stosują się do jego wskazówek. Tym niemniej zrozumienie jego budowy i składni jest niezbędne dla każdego, kto zarządza widocznością serwisu w wynikach wyszukiwania.
Z naszego artykułu dowiesz się:
Jak wygląda struktura pliku robots.txt
Plik robots.txt składa się z bloków zwanych rekordami. Każdy rekord opisuje zasady dla konkretnego robota (user-agenta) i zawiera dyrektywy określające, co jest dla niego dostępne, a co nie. Budowa jest prosta, ale precyzja zapisu ma ogromne znaczenie — jeden błąd może nieumyślnie zablokować indeksowanie całego serwisu.
Typowy plik wygląda mniej więcej tak:
` User-agent: * Disallow: /admin/ Allow: /publiczny-katalog/ Sitemap: https://example.com/sitemap.xml `
Każda linia to osobna dyrektywa. Puste linie oddzielają kolejne rekordy. Znaki # oznaczają komentarze, które roboty ignorują — przydatne do dokumentowania pliku dla zespołu.
User-agent — do kogo mówimy
Dyrektywa User-agent określa, którego robota dotyczą zasady w danym bloku. Gwiazdka (*) oznacza wszystkie roboty — to tzw. wildcard, najczęściej stosowany zapis. Można jednak tworzyć reguły dedykowane dla konkretnych botów, na przykład:
` User-agent: Googlebot Disallow: /wersja-testowa/
User-agent: Bingbot Disallow: / `
W powyższym przykładzie Googlebot ma zablokowany dostęp tylko do jednego katalogu, podczas gdy Bingbot nie może wejść nigdzie. Ważna zasada: każdy rekord musi zaczynać się od User-agent. Jeśli piszemy reguły dla kilku różnych botów z tymi samymi ograniczeniami, każdy z nich wymaga osobnej linii z tą dyrektywą przed blokiem reguł.
Jak roboty parsują kolejność rekordów
Roboty Google stosują zawsze najdokładniej dopasowany rekord — czyli jeśli istnieje blok dedykowany dla Googlebot, Googlebot zastosuje właśnie te reguły, ignorując blok z gwiazdką. Kolejność bloków w pliku ma znaczenie jedynie dla czytelności; parsowanie opiera się na dopasowaniu, nie na sekwencji.
Dyrektywa Disallow — blokowanie dostępu robotów
Disallow to dyrektywa, którą spotykamy w plikach robots.txt najczęściej. Informuje robota, że nie powinien odwiedzać wskazanej ścieżki. Warto pamiętać o kilku szczegółach, które często umykają podczas konfiguracji.
Pusta wartość po Disallow: oznacza brak blokad — robot może odwiedzać wszystko. Z kolei samo Disallow: / blokuje dostęp do całego serwisu. To rozróżnienie ma ogromne znaczenie praktyczne:
Disallow:(puste) — brak ograniczeń dla danego user-agentaDisallow: /— blokada całego serwisuDisallow: /koszyk/— blokada konkretnego kataloguDisallow: /produkt-.html— blokada z użyciem wzorca (wildcard)Disallow: /*.pdf$— blokada plików PDF (znak$oznacza koniec URL)
Dyrektywa disallow nie gwarantuje, że zablokowane strony znikną z indeksu. Jeśli robot znajdzie linki prowadzące do zablokowanej strony na innych, indeksowanych podstronach — może mimo wszystko pokazać ten URL w wynikach wyszukiwania, tyle że bez opisu strony. Aby trwale usunąć stronę z indeksu, potrzebne są dodatkowe działania: tag noindex lub narzędzie do usuwania URL w Search Console.
Dyrektywa Allow — zezwolenia w blokowanych katalogach
Allow działa jako wyjątek od reguły disallow. Używamy jej, gdy chcemy zablokować cały katalog, ale udostępnić konkretne zasoby wewnątrz niego. To szczególnie przydatne w przypadku katalogów z zasobami statycznymi.
Klasyczny przykład dotyczy CSS i JavaScript. Dawniej powszechnie blokowano katalog /wp-content/ czy /assets/, nie zdając sobie sprawy, że roboty nie mogą wtedy poprawnie wyrenderować strony. Dziś Google wyraźnie zaleca, by pliki stylów i skryptów były dostępne dla Googlebota — inaczej ocena jakości renderowania strony jest niepełna. Dyrektywa allow pozwala to rozwiązać elegancko:
` User-agent: Googlebot Disallow: /assets/ Allow: /assets/css/ Allow: /assets/js/ `
Gdy reguły allow i disallow nakładają się, wygrywa ta, która jest bardziej szczegółowa. Jeśli długość ścieżek jest identyczna, pierwszeństwo ma allow — to specyfika parsowania przez Googlebot, inne roboty mogą zachowywać się inaczej.
Dyrektywa Sitemap — wskazanie mapy serwisu
Sitemap directive to często pomijany, a bardzo użyteczny element pliku robots.txt. Pozwala wskazać botom lokalizację mapy XML serwisu, co przyspiesza odkrywanie nowych i zmienionych URL-i.
Zapis jest prosty i nie wymaga przypisania do konkretnego user-agenta — sitemap directive działa globalnie dla wszystkich robotów, które ją obsługują:
` Sitemap: https://example.com/sitemap.xml Sitemap: https://example.com/sitemap-obrazy.xml `
W jednym pliku robots.txt można podać wiele adresów sitemap — każda w osobnej linii. Warto jednak pamiętać, że wskazanie sitemap w robots.txt nie zastępuje jej zgłoszenia w Google Search Console. Oba kanały warto stosować jednocześnie: Search Console daje wgląd w status indeksowania, natomiast dyrektywa w robots.txt pomaga botom nawet wtedy, gdy nie mamy dostępu do panelu administracyjnego serwisu.
Adres w dyrektywie sitemap musi być bezwzględny (z protokołem i domeną), nie względny. Zapis /sitemap.xml bez domeny jest nieprawidłowy i zostanie zignorowany przez większość robotów.
Najczęstsze błędy w konfiguracji pliku robots.txt
Teoria jest prosta, praktyka bywa zaskakująco zdradliwa. Poniżej zebraliśmy błędy, które powtarzają się regularnie — nawet w serwisach obsługiwanych przez doświadczone zespoły.
Zablokowanie zasobów CSS i JS to błąd, o którym już wspomnieliśmy, ale warto go wyróżnić osobno — jego skutki są poważne. Google od lat ocenia strony na podstawie wyrenderowanego wyglądu, a bez dostępu do arkuszy stylów Googlebot widzi zupełnie inną stronę niż użytkownik.
Inne częste problemy to:
- Brak ukośnika na końcu ścieżki do katalogu:
Disallow: /adminzablokuje zarówno/admin/panel, jak i hipotetyczny URL/administrator— co może być niezamierzone. Poprawnie:Disallow: /admin/ - Wielkie litery w ścieżkach: robots.txt rozróżnia wielkość liter w ścieżkach URL.
Disallow: /Admin/nie zablokuje/admin/ - Spacje na początku linii: niektóre parsery traktują wcięcia jako część dyrektywy, co może powodować błędy
- Plik w złej lokalizacji: robots.txt musi znajdować się dokładnie pod adresem
domena.pl/robots.txt— nie w podkatalogu, nie na subdomenie (chyba że chcemy go zdefiniować osobno dla subdomeny) - Brak pliku w ogóle: brak robots.txt to nie tragedia — robot wejdzie wszędzie — ale jego obecność pozwala świadomie zarządzać crawl budgetem
Crawl budget, czyli dzienny limit stron, które Googlebot jest gotowy odwiedzić w serwisie, to temat bezpośrednio powiązany z robots.txt. W dużych serwisach z tysiącami lub milionami URL-i świadome blokowanie stron technicznych, zduplikowanych i niskiej wartości pozwala skierować ten limit na strony, które faktycznie chcemy mieć zaindeksowane. W małych serwisach crawl budget rzadko stanowi problem, ale zrozumienie mechanizmu procentowo zawsze się opłaca.
Testowanie pliku to ostatni krok, który bywa pomijany. Google Search Console udostępnia narzędzie do testowania reguł robots.txt — pozwala sprawdzić, czy konkretny URL jest zablokowany czy dostępny dla wybranego bota. Zanim wdrożymy zmiany w produkcji, warto przepuścić przez nie krytyczne ścieżki serwisu. Jeden przeooczony ukośnik potrafi zablokować indeksowanie sklepu na kilka tygodni, zanim ktokolwiek zauważy problem w raportach Search Console.
