Plik robots.txt porządkuje komunikację między stroną a robotami wyszukiwarek: mówi, co wolno im odwiedzać, a czego lepiej nie pobierać. W SEO ma to znaczenie większe, niż wielu właścicieli stron zakłada na początku, bo od poprawnej konfiguracji zależy nie tylko oszczędność crawl budgetu, ale też to, czy wyszukiwarka w ogóle zobaczy ważne podstrony. Poniżej rozkładam temat na praktyczne elementy: od działania pliku, przez błędy, po sytuacje, w których lepsze będzie noindex lub blokada nagłówkiem HTTP.
Najważniejsze rzeczy o robots.txt w praktyce
- Robots.txt steruje crawlingiem, ale nie usuwa sam z siebie strony z indeksu.
- Plik musi leżeć w katalogu głównym danego hosta i mieć nazwę robots.txt.
- Najczęściej używa się dyrektyw User-agent, Disallow, Allow i czasem wskazania mapy witryny.
- To narzędzie do porządkowania budżetu indeksowania, a nie do ukrywania poufnych treści.
- Jeśli strona ma zniknąć z wyników, zwykle lepiej sprawdza się noindex albo blokada dostępu.
- Najgroźniejszy błąd to zablokowanie zasobów, które są potrzebne do prawidłowego renderowania strony.
Co robots.txt naprawdę robi w SEO
Ten plik traktuję jak zestaw znaków drogowych dla robotów wyszukiwarek. W praktyce mówi im, które ścieżki mogą odwiedzać, a które lepiej omijać, żeby nie przeciążać serwera i nie marnować czasu na treści techniczne, duplikaty albo obszary bez wartości dla użytkownika. Jak podaje Google Search Central, robots.txt służy do sterowania crawlingiem, a nie do ukrywania strony w wynikach wyszukiwania.
To rozróżnienie jest ważne, bo wiele osób myli dwie różne rzeczy: odwiedzanie strony przez bota i pokazywanie jej w indeksie. Robot może nie wejść na daną podstronę, ale jeśli adres jest mocno linkowany z zewnątrz, nadal może się pojawić w wynikach w uproszczonej formie. Z kolei jeśli zależy Ci na wycofaniu treści z indeksu, sam robots.txt zwykle nie wystarczy.
- Najlepiej sprawdza się przy panelach administracyjnych, koszykach, wynikach wewnętrznej wyszukiwarki i stronach testowych.
- Pomaga ograniczać crawl budget na większych serwisach, zwłaszcza w e-commerce.
- Nie jest mechanizmem bezpieczeństwa, więc nie nadaje się do prywatnych danych.
Gdy już wiadomo, do czego ten plik służy, można przejść do składni. To właśnie tutaj najłatwiej o drobny błąd, który potem wpływa na całą widoczność serwisu.
Jak wygląda poprawny plik i jego składnia
Roboty czytają prosty plik tekstowy z regułami zapisanymi w formie pole: wartość. Najczęściej spotkasz grupy zaczynające się od User-agent, a pod nimi reguły określające, co wolno pobierać. Sama składnia nie jest skomplikowana, ale trzeba pilnować kolejności i precyzji ścieżek.
| Dyrektywa | Do czego służy | Kiedy ją stosuję | Przykład użycia |
|---|---|---|---|
| User-agent | Określa, którego bota dotyczą reguły | Gdy chcę ustawić osobne zasady dla konkretnego robota lub dla wszystkich | User-agent: * |
| Disallow | Blokuje crawl danej ścieżki | Dla paneli, koszyków, wyszukiwarki wewnętrznej, filtrów | Disallow: /panel/ |
| Allow | Wyjątek od reguły blokady | Gdy chcę zostawić dostęp do wybranego zasobu w zablokowanym katalogu | Allow: /panel/publiczne-zasoby/ |
| Comments | Notatki dla człowieka, ignorowane przez boty | Gdy chcę opisać powód blokady | # blokada panelu technicznego |
W praktyce lubię, kiedy plik jest krótki. Im mniej warstw i wyjątków, tym mniejsze ryzyko, że ktoś później dopisze coś przypadkiem i zablokuje ważną sekcję serwisu. Dobrą zasadą jest też to, żeby reguły były czytelne dla człowieka, bo za pół roku często wraca się do nich szybciej niż do kodu frontendu.
User-agent: *
Disallow: /panel/
Disallow: /koszyk/
Disallow: /konto/
Allow: /panel/publiczne-zasoby/To tylko ilustracja, ale dobrze pokazuje logikę: blokuję obszary techniczne i użytkowe, a zostawiam to, co może być potrzebne do działania strony. Dalej ważniejsze staje się już nie samo pisanie reguł, tylko miejsce publikacji i techniczna poprawność pliku.
Gdzie go umieścić i jak go przygotować
Plik musi znaleźć się w katalogu głównym hosta, którego dotyczy. Innymi słowy, jeśli serwis działa na kilku subdomenach albo na różnych protokołach, każda z tych wersji może potrzebować własnego pliku. To jeden z powodów, dla których problemy z robots.txt często wychodzą dopiero po wdrożeniu na produkcję.
Żeby nie wpaść w typowe pułapki, trzymam się prostego porządku:
- Tworzę zwykły plik tekstowy o nazwie robots.txt.
- Zapisuję go w kodowaniu UTF-8.
- Wgrywam go do katalogu głównego właściwego hosta.
- Sprawdzam, czy serwer zwraca poprawną wersję pliku i czy nie ma literówek w ścieżkach.
Warto pamiętać o dwóch ograniczeniach technicznych. Po pierwsze, Google obsługuje plik do 500 KiB, a nadmiar treści po tym limicie jest ignorowany. Po drugie, plik nie służy do ochrony danych wrażliwych, bo roboty, które nie respektują zasad, i tak mogą próbować pobrać zakazane zasoby.
Jeżeli korzystasz z CMS-a, sytuacja bywa prostsza albo odwrotnie: trudniejsza, bo panel nie zawsze daje pełną kontrolę nad plikiem w root. Wtedy najpierw sprawdzam możliwości systemu, a dopiero później grzebię w samym pliku. To prowadzi naturalnie do pytania, czego użyć, gdy celem nie jest samo ograniczenie crawl, tylko faktyczne wycofanie treści z wyników.
Kiedy wybrać robots.txt, a kiedy noindex
To jest jeden z najważniejszych punktów całego tematu. Robots.txt ogranicza pobieranie adresów, a noindex kontroluje indeksowanie. Te mechanizmy są podobne tylko pozornie, a ich pomylenie potrafi zepsuć widoczność strony albo odwrotnie: zostawić w indeksie to, czego miało nie być.
| Rozwiązanie | Co kontroluje | Kiedy ma sens | Największe ryzyko |
|---|---|---|---|
| robots.txt | Crawling, czyli odwiedzanie URL-i | Gdy chcesz ograniczyć pobieranie technicznych lub mało wartościowych sekcji | Strona może nadal pojawić się w wynikach, jeśli inne sygnały na to wskazują |
| meta robots noindex | Indeksowanie konkretnej strony | Gdy strona ma być dostępna dla bota, ale nie ma trafiać do indeksu | Nie zadziała, jeśli wcześniej zablokujesz crawl w robots.txt |
| X-Robots-Tag | Indeksowanie przez nagłówek HTTP | Gdy pracujesz z PDF-ami, obrazami, wideo lub innymi zasobami spoza HTML | Wymaga konfiguracji serwera i dokładnego testowania |
| Hasło lub autoryzacja | Dostęp do treści | Gdy treść ma być naprawdę prywatna | Największy próg wejścia, ale też najlepsza ochrona |
Najważniejsza zasada brzmi: jeśli chcesz, żeby wyszukiwarka przestała pokazywać daną stronę, nie blokuj jej najpierw w robots.txt, tylko pozwól botowi zobaczyć instrukcję noindex albo zabezpiecz treść innym sposobem. Gdy tego nie dopilnujesz, crawler nie przeczyta dyrektywy i problem zostanie w indeksie dłużej, niż się spodziewasz.
Skoro wiemy już, czego nie mylić, czas na część, w której najczęściej widzę realne szkody w audytach SEO: błędy konfiguracyjne, które potrafią kosztować ruch organiczny.
Najczęstsze błędy, które widzę w audytach
W teorii robots.txt jest prosty. W praktyce właśnie przez tę prostotę ludzie potrafią zrobić nim najwięcej bałaganu. Poniżej mam listę błędów, które wracają najczęściej, razem z tym, dlaczego są groźne.
-
Blokowanie całej witryny przez przypadkowe
Disallow: /na produkcji. Efekt jest oczywisty: spadek widoczności i brak nowych wejść z wyszukiwarki. - Blokowanie zasobów potrzebnych do renderowania, takich jak pliki CSS czy JavaScript. Wtedy bot widzi stronę inaczej niż użytkownik, a to utrudnia ocenę jakości strony.
- Założenie, że robots.txt usuwa adres z indeksu. To błąd strategiczny, bo reguła dotyczy crawl, nie samego indeksowania.
- Zapomnienie o subdomenach i środowiskach testowych. Dla każdej wersji hosta może obowiązywać osobny plik i osobne reguły.
- Zbyt szerokie blokady na stronach z filtrami. W sklepach internetowych łatwo przesadzić i odciąć także sensowne URL-e produktowe.
- Brak kontroli po wdrożeniu. Nawet dobry plik po zmianach w CMS-ie albo po migracji potrafi przestać działać tak, jak planowano.
Ja zwykle patrzę na te błędy przez pryzmat konsekwencji biznesowych, nie tylko technicznych. Jeden zły wpis może zablokować cały katalog, a jeden brakujący wyjątek może sprawić, że Google zacznie marnować czas na setki bezwartościowych adresów. Właśnie dlatego przy większych serwisach warto mieć gotowe wzorce, zamiast pisać wszystko od zera za każdym razem.
Przykłady konfiguracji dla bloga, sklepu i strony firmowej
Najlepsze użycie tego pliku zależy od typu serwisu. To, co działa w blogu, nie zawsze ma sens w e-commerce, a konfiguracja bezpieczna dla strony firmowej może być zbyt uboga dla dużego sklepu. Poniżej pokazuję trzy scenariusze, które najczęściej spotykam.
| Typ serwisu | Co zwykle blokuję | Po co | Na co uważam |
|---|---|---|---|
| Blog | Panel administracyjny, techniczne endpointy, podglądy robocze | Żeby nie marnować crawl budgetu na rzeczy niewidoczne dla użytkownika | Nie blokuję zasobów, które są potrzebne do poprawnego wyświetlania wpisów |
| Sklep internetowy | Koszyk, konto klienta, etap finalizacji zamówienia, techniczne strony wyszukiwania | Żeby odsiać sekcje bez wartości SEO i ograniczyć duplikację | Nie zamykam zbyt agresywnie filtrów, jeśli prowadzą do wartościowych kategorii |
| Strona firmowa | Strefy prywatne, testowe wersje, nieużywane katalogi po migracji | Żeby zachować prosty i czysty profil indeksacji | Publiczne podstrony ofertowe zostawiam otwarte bez kombinowania |
W praktyce najrozsądniejsza zasada brzmi: blokuj technikę, nie wartość. Jeśli jakaś sekcja służy tylko do działania serwisu, ma sens ją odciąć od crawl. Jeśli jednak adres może przyciągać ruch, odpowiada na intencję użytkownika albo wzmacnia topical authority, wolę go zostawić i ewentualnie zarządzić nim innym mechanizmem. To właśnie tutaj robots.txt staje się narzędziem precyzyjnym, a nie młotkiem do wszystkiego.
Na końcu i tak sprowadza się to do kontroli przed publikacją. Ostatnia sekcja pokazuje, co sam sprawdzam, zanim uznam plik za gotowy na produkcję.
Co sprawdzam przed publikacją, żeby plik pomagał, a nie szkodził
Przed wdrożeniem robię krótki, ale konsekwentny przegląd. Taki check-listowy sposób pracy oszczędza mi później cofania zmian i tłumaczenia, dlaczego ruch organiczny spadł po „niewinnej” aktualizacji.
- Sprawdzam, czy główna wersja serwisu nie ma przypadkowej blokady całej witryny.
- Patrzę, czy ważne sekcje produktowe albo treściowe nie zostały wrzucone do katalogu objętego zakazem crawl.
- Porównuję plik z aktualną strukturą serwisu po migracji, bo stare reguły często zostają po poprzedniej wersji CMS-a.
- Weryfikuję, czy środowisko testowe i produkcyjne nie dzielą tych samych zasad wbrew założeniom.
- Testuję efekt w Search Console i przeglądam logi serwera, jeśli serwis jest większy lub bardziej złożony.
Jeśli miałbym zostawić jedną praktyczną radę, byłaby prosta: używaj robots.txt do porządkowania dostępu dla robotów, ale nie licz, że rozwiąże problem indeksacji, prywatności albo duplikacji sam z siebie. Dobrze ustawiony plik wspiera SEO, źle ustawiony potrafi je wyhamować, więc traktuję go jak element infrastruktury, a nie drobiazg do odhaczenia po wdrożeniu.
