Źle ustawiony plik robots.txt potrafi zablokować Google dostęp do ważnych podstron, a dobrze skonfigurowany pomaga ograniczyć niepotrzebne skanowanie serwisu. Wyjaśniam, jak działa to narzędzie, czym różni się crawlowanie od indeksowania, jakie reguły stosować oraz jak sprawdzić konfigurację bez ryzyka utraty widoczności.
Najważniejsze zasady konfiguracji pliku robots.txt
- robots.txt steruje dostępem robotów do wybranych ścieżek witryny.
- Nie usuwa strony z indeksu i nie zastępuje dyrektywy noindex.
- Plik musi znajdować się w głównym katalogu właściwej domeny.
- Największe ryzyko stanowi przypadkowe użycie reguły Disallow: /.
- Po każdej zmianie trzeba sprawdzić status HTTP, składnię i kluczowe adresy.
Czym właściwie jest plik robots.txt i co robi w SEO
Potoczne określenie robot txt odnosi się zwykle do pliku robots.txt, czyli zwykłego dokumentu tekstowego odczytywanego przez crawlery. Crawler to automatyczny program, który odwiedza strony, podąża za linkami i pobiera dane potrzebne wyszukiwarce do dalszej analizy.
Plik nie służy do sterowania pozycją strony. Jego zadaniem jest przede wszystkim wskazanie, które adresy robot może odwiedzać, a których powinien unikać. Ma to znaczenie między innymi przy dużych sklepach, rozbudowanych filtrach, wynikach wyszukiwania wewnętrznego i zapleczu technicznym serwisu.
Crawlowanie a indeksowanie
To rozróżnienie powoduje najwięcej nieporozumień. Crawlowanie oznacza odwiedzenie i pobranie adresu przez robota, natomiast indeksowanie to decyzja wyszukiwarki o zapisaniu strony w bazie i pokazaniu jej w wynikach.
Zablokowanie adresu w pliku może ograniczyć jego pobieranie, ale nie daje pełnej gwarancji, że adres nigdy nie pojawi się w Google. Jeśli inne strony prowadzą do zablokowanej podstrony, wyszukiwarka może znać sam adres, a czasem także wyświetlić go bez pełnego opisu.
Gdzie umieścić plik
Dokument powinien być dostępny pod ścieżką /robots.txt w głównym katalogu konkretnego hosta. Reguły zapisane dla domeny głównej nie obejmują automatycznie subdomeny, innego portu ani innego protokołu.
Nazwa pliku powinna być zapisana małymi literami, a dokument najlepiej kodować w UTF-8 i serwować jako zwykły tekst. Brak pliku nie oznacza automatycznej blokady. W większości przypadków robot przyjmuje wtedy, że nie ma dodatkowych ograniczeń.
Jak czytać i pisać reguły bez zgadywania
Każda grupa reguł zaczyna się od User-agent. Ten wpis wskazuje, którego robota dotyczą kolejne instrukcje. Gwiazdka oznacza wszystkie crawlery, chyba że dany robot ma własną, bardziej szczegółową grupę.
User-agent: *
Disallow: /panel/
Disallow: /koszyk/
Disallow: /szukaj?
Allow: /panel/public/
Sitemap: pełny-adres-HTTPS-do-sitemap.xmlW tym przykładzie większość robotów nie powinna odwiedzać panelu administracyjnego, koszyka ani adresów wyników wyszukiwania. Jednocześnie ścieżka /panel/public/ zostaje dopuszczona, jeśli robot interpretuje reguły zgodnie z zasadą bardziej szczegółowego dopasowania.
| Dyrektywa | Znaczenie | Przykładowe zastosowanie |
|---|---|---|
User-agent |
Wskazuje robota, którego dotyczą reguły. | Wszystkie crawlery albo konkretny bot. |
Disallow |
Ogranicza dostęp do ścieżki lub adresu. | Panel, koszyk, parametry techniczne. |
Allow |
Ponownie dopuszcza bardziej szczegółową ścieżkę. | Wyjątek w zablokowanym katalogu. |
Sitemap |
Wskazuje mapę witryny XML. | Pomaga znaleźć adresy przeznaczone do crawlowania. |
Najważniejsze znaczenie pustych wartości
Reguła Disallow: bez ścieżki oznacza brak blokady. Z kolei Disallow: / blokuje całą witrynę dla robota objętego daną grupą. To jedna z najczęstszych przyczyn nagłego zniknięcia nowych stron z crawlowania.
Ścieżki są wrażliwe na wielkość liter. Reguła dotycząca /blog/ nie musi obejmować /Blog/. Podobnie trzeba uważać na końcowe ukośniki, parametry URL i znaki specjalne.
Jak działają grupy dla różnych robotów
Możesz przygotować osobne zasady dla wszystkich crawlerów i bardziej szczegółowe reguły dla wybranego robota. Trzeba jednak czytać cały plik, bo pozornie drobna zmiana w nazwie klienta może sprawić, że instrukcja nie zadziała tak, jak zakładasz.
Nie kopiuję gotowych konfiguracji bez sprawdzenia architektury strony. Reguła dobra dla sklepu może zaszkodzić blogowi, a ustawienia przygotowane dla wersji testowej mogą odciąć produkcyjną domenę.
Kiedy blokada pomaga, a kiedy szkodzi widoczności
Najlepszym zastosowaniem tego pliku jest ograniczenie crawlowania adresów, które nie mają wartości dla wyszukiwarki. Mogą to być wyniki wyszukiwania wewnętrznego, wielokrotne warianty sortowania, koszyk, konto klienta albo techniczne endpointy.
Nie blokowałbym jednak automatycznie wszystkich plików CSS, JavaScriptu i obrazów. Robot powinien móc zobaczyć stronę w sposób zbliżony do użytkownika, a brak zasobów może utrudnić ocenę wyglądu i działania witryny.
Robots.txt a noindex
Jeśli celem jest usunięcie strony z wyników wyszukiwania, właściwszym narzędziem będzie meta robots z wartością noindex albo nagłówek X-Robots-Tag. Robot musi mieć dostęp do strony, aby odczytać taką instrukcję.
Zablokowanie adresu i jednoczesne oczekiwanie, że Google zobaczy na nim noindex, prowadzi do sprzecznego ustawienia. W takiej sytuacji wyszukiwarka nie może pobrać strony i nie odczyta jej nagłówków.
Robots.txt a bezpieczeństwo
Plik nie chroni danych przed użytkownikiem ani nie zastępuje logowania. Co więcej, lista zablokowanych katalogów może podpowiedzieć osobie postronnej, gdzie znajduje się panel, wersja robocza albo zaplecze aplikacji.
Prywatne materiały powinny być zabezpieczone hasłem, autoryzacją serwera lub usunięte z publicznego środowiska. Disallow nie jest zaporą bezpieczeństwa, tylko prośbą skierowaną do respektujących ją crawlerów.
Praktyczne konfiguracje dla bloga, sklepu i wersji testowej
Blog firmowy lub serwis informacyjny
W prostym blogu często wystarczy dopuścić większość witryny i zablokować wyłącznie techniczne ścieżki. Nie ma sensu ukrywać artykułów, kategorii ani stron autorów, jeśli są wartościowe i przeznaczone do indeksowania.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Sitemap: pełny-adres-HTTPS-do-sitemap.xmlW przypadku WordPressa dokładne reguły zależą od wtyczek, motywu i sposobu generowania adresów. Po aktualizacji systemu sprawdzam plik ponownie, bo ustawienia wtyczki SEO lub hostingu mogą go zmienić.
Sklep internetowy
Sklep zwykle potrzebuje większej kontroli, ponieważ generuje adresy z filtrami, sortowaniem, sesjami i parametrami marketingowymi. Nie oznacza to, że wszystkie parametry należy blokować bez analizy. Czasem filtr tworzy wartościową, indeksowalną stronę kategorii.
User-agent: *
Disallow: /koszyk/
Disallow: /logowanie/
Disallow: /konto/
Disallow: /checkout/
Disallow: /*?sort=
Disallow: /*?session=Przed dodaniem reguły sprawdzam, czy dana ścieżka nie prowadzi do produktów albo kategorii generujących ruch organiczny. Najdroższy błąd w sklepie to zablokowanie całego katalogu tylko dlatego, że część jego adresów jest techniczna.
Przeczytaj również: Meta title w SEO - jak pisać tytuły, które przyciągają kliknięcia?
Wersja testowa i środowisko deweloperskie
Na środowisku testowym często spotyka się regułę blokującą wszystkie crawlery:
User-agent: *
Disallow: /Takie ustawienie może być uzasadnione podczas prac, ale powinno zostać usunięte przed publikacją. Nie traktowałbym go jako jedynej ochrony wersji testowej. Dostęp do niej powinien ograniczać login, autoryzacja serwera albo zapora sieciowa.
Jak wdrożyć i przetestować plik po zmianach
Samo zapisanie reguł to dopiero połowa pracy. Ja sprawdzam konfigurację w kilku prostych krokach, ponieważ błąd może wynikać zarówno z treści pliku, jak i z serwera, przekierowania albo cache.
- Otwórz plik w przeglądarce i sprawdź, czy odpowiada kodem 200 OK.
- Upewnij się, że widzisz zwykły tekst, a nie stronę błędu, formularz logowania lub HTML motywu.
- Sprawdź, czy nazwa brzmi dokładnie
robots.txti znajduje się w głównym katalogu właściwego hosta. - Przetestuj kilka ważnych adresów, w tym stronę główną, artykuł, kategorię i plik zasobów.
- Zweryfikuj raporty indeksowania w Google Search Console po wdrożeniu zmian.
- Przejrzyj logi serwera, jeśli problem dotyczy dużej witryny albo crawler nie zachowuje się zgodnie z oczekiwaniem.
Reguły nie zawsze są odczytywane natychmiast. Robot może korzystać z wersji zapisanej w pamięci podręcznej, dlatego pojedyncza obserwacja tuż po publikacji nie powinna być podstawą do kolejnej gwałtownej zmiany.
Trzeba też uważać na błędy serwera. Odpowiedź z grupy 5xx może oznaczać problem z dostępnością pliku, a błędne przekierowania utrudnią robotowi odczytanie zasad. Przy większych serwisach warto testować plik na kopii środowiska i wdrażać zmiany razem z dokumentacją.
Najbezpieczniejsza zasada dla robots.txt
Jeśli nie masz pewności, czy dana ścieżka powinna być zablokowana, najpierw sprawdź jej rolę w architekturze witryny. Zadaj sobie proste pytanie: czy ograniczam niepotrzebne crawlowanie, czy próbuję ukryć stronę przed wynikami wyszukiwania?
W pierwszym przypadku plik robots.txt może być dobrym rozwiązaniem. W drugim lepiej użyć noindex, autoryzacji lub usunięcia zasobu. Najwięcej korzyści daje nie rozbudowany dokument, lecz kilka precyzyjnych reguł, które zostały przetestowane na rzeczywistych adresach.
