Nieprawidłowa konfiguracja pliku robots.txt potrafi ograniczyć widoczność całej witryny albo skierować roboty na mało istotne adresy. Określenie robot txt zwykle dotyczy właśnie tego prostego pliku tekstowego, który pomaga zarządzać indeksowaniem, budżetem crawlowania i dostępem botów do wybranych części serwisu. Wyjaśniam, jak działa, jak go napisać, czego nie blokować i kiedy zamiast niego użyć dyrektywy noindex.
Najważniejsze zasady konfiguracji pliku dla robotów
- robots.txt steruje crawlowaniem, ale sam nie gwarantuje usunięcia strony z wyników wyszukiwania.
- Plik powinien znajdować się w głównym katalogu domeny i być dostępny pod ścieżką /robots.txt.
- Dyrektywa Disallow blokuje odwiedziny robota, a nie jest zabezpieczeniem przed dostępem ludzi ani nieuczciwymi botami.
- Do wykluczania strony z indeksu służy przede wszystkim noindex albo uwierzytelnianie.
- Najgroźniejszy błąd to przypadkowe użycie Disallow: / na działającej witrynie.
Czym jest robots.txt i co naprawdę kontroluje
Robots.txt to zwykły plik tekstowy zapisany w katalogu głównym serwisu. Robot wyszukiwarki, zanim zacznie odwiedzać kolejne adresy, może odczytać zawarte w nim reguły i sprawdzić, które ścieżki właściciel witryny pozwala crawlować. Standard opisany między innymi w dokumencie RFC 9309 dotyczy automatycznych klientów, ale nie jest mechanizmem bezpieczeństwa.
Najprościej traktować ten plik jak instrukcję ruchu dla botów. Można wskazać, że nie powinny odwiedzać panelu administracyjnego, wyników wyszukiwania wewnętrznego, koszyka czy technicznych wariantów adresów. Nie oznacza to jednak, że człowiek zostanie zablokowany albo że każdy bot zastosuje się do poleceń.
W SEO plik służy głównie do ograniczania zbędnego crawlowania. Ma to znaczenie szczególnie w dużych sklepach, serwisach informacyjnych i platformach, które generują tysiące adresów z filtrami, parametrami lub sortowaniem. W małej stronie firmowej korzyść może być mniejsza, a źle wpisana reguła może przynieść znacznie więcej szkody niż pożytku.
Google Search Central wyraźnie rozdziela crawlowanie od indeksowania. Robot może nie odwiedzić strony zablokowanej w pliku, ale adres nadal może zostać znaleziony na podstawie linków prowadzących z innych miejsc. Dlatego robots.txt nie powinien być jedynym sposobem ukrywania poufnych treści.
Jak czytać składnię i budować poprawne reguły
Każda grupa reguł zaczyna się od wskazania robota, którego dotyczy. Najczęściej używa się gwiazdki, czyli znaku oznaczającego wszystkie boty. Poniższy przykład blokuje katalog techniczny i adresy wyszukiwania wewnętrznego, ale pozostawia resztę serwisu dostępną.
User-agent: *
Disallow: /panel/
Disallow: /szukaj/
Allow: /szukaj/oferta-wzorcowa/
Sitemap: [adres mapy witryny]
User-agent określa odbiorcę reguły. Wpis User-agent: * dotyczy wszystkich zgodnych ze standardem robotów, natomiast osobna nazwa może odnosić się do konkretnego crawlera. Trzeba uważać na rozdzielanie grup, ponieważ reguły przypisane do konkretnego robota nie zawsze łączą się automatycznie z grupą ogólną.
Disallow wskazuje ścieżkę, której robot nie powinien odwiedzać. Pusta wartość po tej dyrektywie oznacza brak blokady, a zapis Disallow: / obejmuje cały serwis. Allow może otworzyć konkretną ścieżkę w obrębie szerzej zablokowanego katalogu, choć sposób rozstrzygania konfliktów warto sprawdzić w narzędziu konkretnej wyszukiwarki.
Dyrektywa Sitemap wskazuje lokalizację mapy witryny. Nie zastępuje ona zgłoszenia mapy w narzędziach dla webmasterów, ale ułatwia robotom znalezienie listy najważniejszych adresów. Nazwa pliku powinna być zapisana małymi literami, w kodowaniu UTF-8 i jako zwykły tekst.
| Dyrektywa | Do czego służy | Przykładowe zastosowanie |
|---|---|---|
User-agent |
Wybiera robota, którego dotyczą kolejne reguły | Wszyscy crawlerzy albo konkretny bot |
Disallow |
Ogranicza crawlowanie wskazanej ścieżki |
/koszyk/ lub /filtry/
|
Allow |
Pozwala odwiedzić wyjątek w zablokowanym obszarze | Plik graficzny potrzebny do renderowania |
Sitemap |
Wskazuje mapę witryny | Mapa stron, produktów lub wpisów |
Nie kopiowałbym bez zastanowienia dyrektywy Crawl-delay z gotowych poradników. Jej obsługa zależy od robota, a Google nie traktuje jej jako standardowego polecenia. Jeśli serwer jest przeciążony, lepsze efekty zwykle daje analiza logów, poprawa wydajności i ograniczenie niepotrzebnych adresów.
Robots.txt a noindex to nie jest to samo
To rozróżnienie jest źródłem wielu problemów. Robots.txt mówi przede wszystkim, czy robot może wejść pod dany adres, natomiast noindex przekazuje informację, że strona nie powinna trafić do indeksu. Aby robot odczytał noindex, musi mieć możliwość pobrania strony, więc blokowanie jej w robots.txt może uniemożliwić odczyt tej instrukcji.
| Cel | Najlepsze rozwiązanie | Dlaczego |
|---|---|---|
| Ograniczenie wejść do technicznych adresów |
Disallow w robots.txt |
Zmniejsza liczbę niepotrzebnych wizyt botów |
| Usunięcie publicznej strony z indeksu |
noindex w meta robots lub nagłówku |
Robot może odczytać jasną instrukcję indeksowania |
| Ukrycie danych poufnych | Logowanie, autoryzacja lub ograniczenie dostępu na serwerze | Robots.txt nie chroni treści przed użytkownikami |
| Wskazanie preferowanego duplikatu | Link kanoniczny | Pomaga wskazać główną wersję podobnych adresów |
Przykład praktyczny jest prosty. Strona testowa dostępna publicznie, ale nieprzeznaczona do wyników wyszukiwania, powinna otrzymać noindex albo zostać zabezpieczona logowaniem. Sama reguła Disallow: /testy/ może ograniczyć crawlowanie, ale nie daje pewności, że adres nie będzie znany wyszukiwarce.
Podobnie nie blokowałbym w ciemno plików CSS i JavaScript. Roboty potrzebują części zasobów, aby poprawnie ocenić wygląd i działanie strony na urządzeniach mobilnych. Blokada zasobów może utrudnić renderowanie, a przez to pogorszyć ocenę strony lub utrudnić zrozumienie jej zawartości.
Jak stworzyć, wdrożyć i sprawdzić plik bez ryzyka
Najpierw ustalam, co faktycznie powinno zostać ograniczone. Nie zaczynam od gotowej listy znalezionej w internecie, ponieważ różne CMS-y, sklepy i aplikacje mają zupełnie inne ścieżki techniczne. Pomocne są logi serwera, raporty crawlowania i lista adresów generowanych przez wyszukiwarkę.
- Utwórz zwykły plik tekstowy o nazwie
robots.txt. - Zapisz go w katalogu głównym domeny, a nie w folderze motywu lub podstronie CMS-a.
- Dodaj tylko reguły, których działanie rozumiesz i potrafisz uzasadnić.
- Sprawdź, czy serwer zwraca plik bez błędu i czy jego typ to zwykły tekst.
- Przetestuj kilka ważnych adresów w narzędziach dla webmasterów.
- Po wdrożeniu obserwuj raporty indeksowania i logi przez kilka dni.
W systemach takich jak WordPress plik może być generowany przez CMS, wtyczkę SEO albo konfigurację serwera. Zdarza się, że ręczna edycja jednego miejsca nie daje efektu, bo aplikacja nadpisuje zmiany przy aktualizacji. Przed publikacją sprawdź rzeczywistą wersję dostępną dla robota, a nie tylko plik zapisany lokalnie.
Test powinien obejmować zarówno adres, który ma być zablokowany, jak i taki, który musi pozostać dostępny. Szczególną uwagę zwracam na stronę główną, kategorie, produkty, artykuły oraz zasoby potrzebne do renderowania. Jedna pomyłka w ścieżce może objąć znacznie większy obszar, niż wynika to z samego wyglądu reguły.
Zmiany nie zawsze są widoczne natychmiast, ponieważ roboty mogą przechowywać wcześniejszą wersję pliku przez pewien czas. Nie oznacza to jednak, że warto wielokrotnie zmieniać konfigurację bez kontroli. Lepiej wprowadzić jedną przemyślaną wersję, zweryfikować ją i obserwować skutki.
Przykłady zastosowania w sklepie i serwisie treściowym
Sklep internetowy
Sklep często tworzy wiele adresów dla filtrów, sortowania, sesji i wyszukiwania. Nie każdy taki wariant ma wartość dla SEO, dlatego można ograniczyć crawlowanie części adresów technicznych, ale nie wolno blokować kategorii, kart produktów ani stron, które mają zdobywać ruch.
User-agent: *
Disallow: /koszyk/
Disallow: /logowanie/
Disallow: /konto/
Disallow: /szukaj/
Disallow: /*?sort=
Disallow: /*?filtr=
Ten przykład jest tylko punktem wyjścia, a nie uniwersalnym szablonem. Jeśli parametry są wykorzystywane do tworzenia wartościowych landing page’y, ich blokada może odciąć ważne adresy. W sklepie najpierw sprawdzam, czy dana wersja ma własną treść, linkowanie i potencjał wejść z wyszukiwarki.
Portal informacyjny lub blog
Serwis publikujący treści powinien zostawić dostęp do wpisów, kategorii, tagów używanych w nawigacji oraz obrazów. Sensownie jest ograniczyć zaplecze, wewnętrzne wyniki wyszukiwania i techniczne kanały, jeśli generują dużą liczbę podobnych adresów.
User-agent: *
Disallow: /admin/
Disallow: /logowanie/
Disallow: /szukaj/
Disallow: /preview/
Sitemap: [adres mapy witryny]
Nie blokowałbym całego katalogu z obrazami tylko dlatego, że nie wszystkie pliki mają osobne strony docelowe. Obrazy mogą wspierać widoczność w wyszukiwaniu grafik, a także pomagać robotowi zrozumieć publikowaną treść.
Przeczytaj również: Parametry UTM - Jak mierzyć skuteczność kampanii bez zgadywania?
Wersja deweloperska
Środowisko testowe powinno być zabezpieczone przede wszystkim na poziomie serwera lub dostępu użytkownika. Tymczasowa reguła Disallow: / może być dodatkową ostrożnością, ale po uruchomieniu produkcji trzeba ją usunąć i wykonać test ponownie.
Najczęstsze błędy widzę przy migracjach. Zespół kopiuje konfigurację z wersji testowej, zapomina zmienić reguły po wdrożeniu albo blokuje katalog, w którym znajdują się publikowane materiały. Właśnie dlatego robots.txt powinien być częścią checklisty wdrożeniowej, a nie jednorazową poprawką wykonywaną po spadku ruchu.
Co sprawdzić, zanim uznasz konfigurację za gotową
- Czy plik jest dostępny w katalogu głównym i ma dokładną nazwę
robots.txt? - Czy nie zawiera przypadkowej reguły
Disallow: /? - Czy ważne podstrony, obrazy, arkusze stylów i skrypty mogą być pobierane?
- Czy adresy przeznaczone do usunięcia z indeksu mają noindex, zamiast samej blokady?
- Czy mapa witryny wskazuje wyłącznie kanoniczne i dostępne adresy?
- Czy reguły odpowiadają rzeczywistym ścieżkom używanym przez CMS?
- Czy po wdrożeniu sprawdzono raporty crawlowania oraz indeksowania?
Nie traktuję liczby wpisów w robots.txt jako oznaki profesjonalizmu. Dobrze skonfigurowany plik może mieć zaledwie kilka prostych reguł, jeśli architektura strony jest uporządkowana. Rozbudowana lista wyjątków często sygnalizuje, że problem leży głębiej, na przykład w filtrach, duplikacji adresów albo sposobie generowania linków.
Robots.txt jest narzędziem kontroli ruchu robotów, a nie magicznym przełącznikiem SEO. Największą wartość daje wtedy, gdy łączy się go z logiczną strukturą serwisu, mapą witryny, poprawnymi nagłówkami noindex i analizą realnych zachowań crawlerów. W takim układzie pomaga wyszukiwarkom skupić uwagę na stronach, które faktycznie mają znaczenie dla użytkowników i biznesu.