Co to jest robots.txt i jak wpływa na indeksowanie strony?

Robots.txt to plik tekstowy umieszczany w głównym katalogu serwisu internetowego. Służy do przekazywania automatycznym robotom informacji o tym, które części witryny mogą być przez nie odwiedzane, a których nie powinny skanować.

Najczęściej mówi się o nim w kontekście Google i SEO, ale z robots.txt mogą korzystać również roboty innych wyszukiwarek oraz inne automatyczne systemy odwiedzające strony internetowe.

Plik wygląda niepozornie. Może zawierać zaledwie kilka linijek tekstu.

Jednocześnie jedna nieprawidłowa reguła może spowodować, że Google przestanie pobierać ogromną część strony albo nawet cały serwis.

Dlatego robots.txt jest jednym z tych elementów technicznych, które warto rozumieć przed rozpoczęciem ich modyfikowania.

Co to jest robots.txt?

Robots.txt jest plikiem zawierającym instrukcje dla robotów internetowych.

Jego nazwa składa się z dwóch części:

• robots – roboty,
• txt – zwykły plik tekstowy.

Standard umożliwiający takie komunikowanie się z crawlerami jest określany jako Robots Exclusion Protocol.

Robot odwiedzający witrynę może najpierw sprawdzić plik robots.txt, a następnie na jego podstawie zdecydować, które adresy powinien pobierać.

Typowy adres pliku wygląda tak:

https://domena.pl/robots.txt

Plik musi znajdować się właśnie w głównym katalogu hosta.

Adres:

https://domena.pl/jakis-katalog/robots.txt

nie pełni tej samej funkcji.

Do czego służy robots.txt?

Podstawowym zadaniem pliku jest zarządzanie crawlingiem, czyli skanowaniem strony przez roboty.

Można za jego pomocą poinformować crawlera, że nie powinien odwiedzać na przykład:

• określonego katalogu,
• stron technicznych,
• niepotrzebnych wyników wyszukiwania,
• wybranych parametrów,
• zaplecza administracyjnego,
• obszarów generujących ogromną liczbę nieprzydatnych adresów.

Robots.txt może być szczególnie przydatny w dużych serwisach i sklepach internetowych, gdzie liczba technicznych adresów URL potrafi być wielokrotnie większa od liczby rzeczywistych produktów i kategorii.

Robots.txt steruje crawlingiem, a nie indeksowaniem

To najważniejsza rzecz, którą trzeba zrozumieć.

Robots.txt nie jest narzędziem służącym bezpośrednio do usuwania stron z indeksu Google.

Plik mówi robotowi przede wszystkim:

„nie pobieraj tego adresu”.

Nie mówi:

„usuń ten adres z wyników wyszukiwania”.

Crawling i indeksowanie to dwa różne procesy.

Co to jest crawling?

Crawling, czyli skanowanie, polega na odwiedzaniu adresów przez robota wyszukiwarki.

Robot pobiera dokument, analizuje jego treść i odnajduje znajdujące się w nim linki.

Może dzięki temu odkrywać kolejne strony.

Jeżeli robots.txt zabrania pobrania danego adresu, robot może zrezygnować z wejścia na niego.

Co to jest indeksowanie?

Indeksowanie jest kolejnym etapem.

Wyszukiwarka analizuje pobraną treść i może zdecydować, czy chce przechowywać informacje o stronie w swoim indeksie oraz prezentować ją w wynikach wyszukiwania.

Strona może więc być:

• dozwolona do crawlowania i zaindeksowana,
• dozwolona do crawlowania, ale niezaindeksowana,
• zablokowana dla crawlera, ale jej adres nadal może być znany wyszukiwarce.

Właśnie ten trzeci przypadek powoduje wiele nieporozumień.

Czy zablokowana strona może pojawić się w Google?

Tak.

Jeżeli Google zna adres URL z innych źródeł, może wiedzieć o jego istnieniu nawet wtedy, gdy robots.txt nie pozwala pobrać zawartości.

Adres może zostać odkryty między innymi przez:

• link z innej strony,
• link zewnętrzny,
• wcześniejsze crawlowanie,
• inne źródła informacji o adresach.

Jeżeli robot nie może wejść na stronę, nie widzi jej treści ani znajdujących się w dokumencie instrukcji dotyczących indeksowania.

Dlatego blokada w robots.txt nie powinna być używana jako zamiennik noindex.

Robots.txt a noindex

Noindex jest instrukcją dotyczącą indeksowania.

Może zostać przekazany między innymi poprzez odpowiedni meta robots albo nagłówek HTTP.

Jego znaczenie jest zasadniczo inne niż Disallow w robots.txt.

Disallow oznacza:

„nie skanuj tego adresu”.

Noindex oznacza:

„możesz pobrać stronę, ale nie umieszczaj jej w indeksie”.

Jeżeli jednocześnie zablokuje się adres w robots.txt i umieści na nim noindex, powstaje problem.

Robot może nie wejść na stronę, a więc nie zobaczy instrukcji noindex.

Czy można wpisać noindex do robots.txt?

Nie należy tego robić.

Dyrektywa noindex umieszczona bezpośrednio w robots.txt nie jest standardowym sposobem sterowania indeksowaniem i nie powinna być traktowana jako rozwiązanie SEO.

Jeżeli strona ma nie pojawiać się w wynikach wyszukiwania, należy zastosować mechanizm przeznaczony właśnie do tego celu.

Jak wygląda plik robots.txt?

Najprostszy możliwy plik może wyglądać logicznie tak:

User-agent: *

Disallow:

Oznacza to, że reguła dotyczy wszystkich robotów i nie blokuje żadnej ścieżki.

Można również zablokować określony katalog:

User-agent: *

Disallow: /prywatny-katalog/

Robot respektujący tę regułę nie powinien pobierać adresów znajdujących się pod wskazaną ścieżką.

Co oznacza User-agent?

User-agent wskazuje robota, którego dotyczą znajdujące się dalej reguły.

Gwiazdka oznacza wszystkie roboty respektujące standard.

Przykład:

User-agent: *

oznacza:

„poniższe reguły dotyczą wszystkich robotów”.

Możliwe jest również przygotowanie osobnych zasad dla określonego crawlera.

Co oznacza Disallow?

Disallow wskazuje ścieżkę, której robot nie powinien skanować.

Przykład:

Disallow: /panel/

oznacza blokadę adresów rozpoczynających się od wskazanej ścieżki.

Trzeba bardzo uważać na zakres reguły.

Inny zapis:

Disallow: /

ma zupełnie inne znaczenie.

Co robi Disallow: /?

Ta jedna linijka może zablokować crawlowanie całego serwisu dla wskazanego robota.

Przykład:

User-agent: *

Disallow: /

oznacza w praktyce:

„żaden robot objęty tą regułą nie powinien skanować żadnego adresu w tym serwisie”.

To jedna z pierwszych rzeczy, które warto sprawdzić, jeżeli po uruchomieniu nowej strony Google nie zaczyna jej prawidłowo skanować.

Jak wygląda całkowicie otwarty robots.txt?

Można zastosować:

User-agent: *

Disallow:

Pusta wartość po Disallow oznacza brak blokady.

Możliwe jest również niewprowadzanie reguł blokujących.

Co oznacza Allow?

Dyrektywa Allow może pozwolić na crawlowanie określonej ścieżki znajdującej się wewnątrz szerszego obszaru objętego blokadą.

Przykładowo można zablokować katalog, ale dopuścić znajdujący się w nim konkretny zasób.

Takie reguły wymagają już większej ostrożności, ponieważ znaczenie może zależeć od stopnia dopasowania ścieżek.

Nie warto budować skomplikowanych kombinacji Allow i Disallow, jeżeli problem można rozwiązać prostszą architekturą.

Dyrektywa Sitemap

W robots.txt można również wskazać adres mapy XML.

Przykład:

Sitemap: https://domena.pl/sitemap.xml

Nie jest to reguła blokująca.

Informuje robota, gdzie znajduje się mapa witryny zawierająca adresy, które właściciel serwisu chce mu wskazać.

W dużym serwisie mapa może być również indeksem prowadzącym do kilku osobnych sitemap.

Czy sitemap musi być wpisana w robots.txt?

Nie.

Mapa XML może zostać wykryta lub przekazana wyszukiwarce także innymi metodami, na przykład przez Google Search Console.

Wpis w robots.txt jest jednak prostym i czytelnym sposobem wskazania jej lokalizacji crawlerom.

Komentarze w robots.txt

W pliku można dodawać komentarze rozpoczynające się znakiem #.

Mogą pomagać administratorowi zrozumieć, dlaczego konkretna reguła istnieje.

Przy bardziej rozbudowanym pliku ma to znaczenie, ponieważ po kilku miesiącach trudno czasami pamiętać, z jakiego powodu określona ścieżka została zablokowana.

Robots.txt w WordPressie

WordPress może udostępniać wirtualny robots.txt nawet wtedy, gdy fizycznego pliku nie ma na serwerze.

Jego zawartość może być również modyfikowana przez:

• wtyczki SEO,
• hosting,
• system bezpieczeństwa,
• indywidualny kod.

Dlatego przy diagnozowaniu problemów liczy się zawartość rzeczywiście zwracana pod adresem /robots.txt, a nie tylko plik znaleziony przez FTP.

Opcja widoczności dla wyszukiwarek w WordPressie

WordPress posiada ustawienie dotyczące widoczności dla wyszukiwarek.

Jest ono często używane na stronach testowych.

Nie powinno być jednak traktowane jako zabezpieczenie prywatności.

To mechanizm przekazujący wyszukiwarkom określone sygnały, a nie system kontroli dostępu.

Po przeniesieniu strony ze środowiska testowego na produkcję trzeba zawsze sprawdzić, czy ograniczenia indeksowania zostały usunięte.

Robots.txt na stronie testowej

To bardzo częsty scenariusz.

Powstaje staging, na którym wprowadzane są zmiany przed publikacją.

Administrator blokuje go w robots.txt:

User-agent: *

Disallow: /

Następnie pliki zostają skopiowane na domenę produkcyjną razem z konfiguracją.

Nowa strona działa, ale robots.txt nadal blokuje cały serwis.

Taki błąd może pozostać niezauważony, ponieważ dla zwykłego użytkownika wszystko wygląda prawidłowo.

Dlaczego robots.txt nie zabezpiecza stagingu?

Jeżeli serwis testowy zawiera dane, których użytkownicy nie powinni oglądać, robots.txt nie jest wystarczającym zabezpieczeniem.

Plik jedynie prosi określone roboty o nieodwiedzanie adresów.

Nie blokuje użytkownika, który zna URL.

Nie blokuje również złośliwego bota, który po prostu ignoruje standard.

Środowisko testowe powinno być chronione mechanizmem dostępu, na przykład uwierzytelnieniem na poziomie serwera lub innym rzeczywistym zabezpieczeniem.

Robots.txt nie jest narzędziem bezpieczeństwa

To kolejna krytyczna zasada.

Nie należy umieszczać w robots.txt poufnych katalogów w przekonaniu, że w ten sposób stają się niewidoczne.

Plik robots.txt sam jest publiczny.

Każdy może otworzyć:

https://domena.pl/robots.txt

i zobaczyć wpisane tam ścieżki.

Jeżeli katalog zawiera dane wymagające ochrony, trzeba zastosować prawdziwą kontrolę dostępu.

Dobry bot i złośliwy bot

Robots.txt działa na zasadzie współpracy.

Robot wyszukiwarki może respektować zawarte w nim instrukcje.

Złośliwy scraper, skaner bezpieczeństwa lub inny automat nie musi tego robić.

Nie istnieje mechanizm techniczny zmuszający każdy program na świecie do przestrzegania robots.txt.

Dlatego plik nie zastępuje:

• logowania,
• autoryzacji,
• firewalla,
• ograniczeń serwera,
• ochrony danych.

Robots.txt w WooCommerce

W sklepie internetowym plik może mieć szczególnie duże znaczenie ze względu na liczbę generowanych adresów.

WooCommerce i używane rozszerzenia mogą tworzyć strony związane między innymi z:

• koszykiem,
• kontem klienta,
• checkoutem,
• wyszukiwarką,
• filtrami,
• sortowaniem,
• parametrami URL.

Nie oznacza to jednak, że wszystkie takie adresy należy mechanicznie wrzucić do robots.txt.

Każda grupa URL powinna zostać oceniona osobno.

Czy blokować koszyk i checkout?

Strony koszyka, konta i checkoutu zazwyczaj nie są wartościowymi landing pages dla wyszukiwarki.

Sposób ograniczenia ich indeksowania powinien jednak wynikać z całej konfiguracji strony.

Nie należy zakładać, że Disallow automatycznie rozwiązuje problem indeksacji.

Jeżeli celem jest brak takich stron w indeksie, trzeba kontrolować również dyrektywy indeksowania oraz sposób linkowania.

Robots.txt a filtry produktów

Filtry są jednym z najbardziej skomplikowanych obszarów dużych sklepów.

System może generować adresy odpowiadające kombinacjom:

• marki,
• koloru,
• rozmiaru,
• ceny,
• materiału,
• innych atrybutów.

Jeżeli każda kombinacja tworzy osobny URL, liczba adresów może rosnąć lawinowo.

Niektóre z nich mogą być wartościowe SEO, a inne całkowicie techniczne.

Dlatego nie stosuję zasady „zablokuj wszystkie filtry”. Najpierw analizuję, które adresy mają mieć wartość jako strony docelowe, a które są wyłącznie technicznym efektem działania interfejsu.

Robots.txt a sortowanie

Sortowanie może tworzyć warianty tej samej listy produktów:

• od najtańszych,
• od najdroższych,
• według popularności,
• według daty.

Jeżeli każdy wariant posiada osobny adres, wyszukiwarka może odkrywać wiele URL prowadzących do bardzo podobnej treści.

Robots.txt jest jednym z narzędzi, które czasami wykorzystuje się przy zarządzaniu takim crawlingiem, ale trzeba uwzględnić również canonical, indeksowanie i linkowanie wewnętrzne.

Robots.txt a paginacja

Strony paginacji bardzo często powinny pozostać dostępne dla crawlera, ponieważ znajdują się na nich linki do dalszych produktów lub artykułów.

Automatyczna reguła:

Disallow: /page/

może więc być bardzo niebezpieczna.

Jeżeli produkt znajduje się na stronie 15 kategorii, zablokowanie paginacji może ograniczyć jedną z dróg, którą crawler do niego dociera.

Robots.txt a wewnętrzna wyszukiwarka

Wewnętrzne wyniki wyszukiwania mogą generować praktycznie nieskończoną liczbę adresów.

Użytkownik wpisuje dowolne słowo, a system tworzy stronę wyników.

Takie adresy często nie powinny stanowić dużej części indeksu wyszukiwarki.

Przy dużych serwisach ich crawling również może być niepotrzebny.

To przykład obszaru, który warto przeanalizować podczas projektowania robots.txt.

Robots.txt a parametry URL

Adres może zawierać parametry, na przykład:

?sort=price

?color=black

?utm_source=...

Nie każdy parametr powinien być obsługiwany w ten sam sposób.

Parametr kampanii marketingowej jest innym przypadkiem niż filtr definiujący wartościowy zestaw produktów.

Próba zablokowania wszystkich znaków zapytania jedną szeroką regułą może spowodować nieprzewidziane problemy.

Robots.txt a crawl budget

Crawl budget ma największe znaczenie w dużych serwisach posiadających bardzo dużą liczbę adresów.

Robot wyszukiwarki nie posiada nieskończonych zasobów.

Jeżeli ogromną część czasu poświęca na odwiedzanie bezwartościowych kombinacji filtrów i parametrów, może mniej efektywnie skanować istotne części serwisu.

Robots.txt może pomóc ograniczyć dostęp do wybranych technicznych przestrzeni URL.

Nie oznacza to jednak, że niewielka strona firmowa potrzebuje skomplikowanej optymalizacji crawl budget.

Czy każda strona potrzebuje rozbudowanego robots.txt?

Nie.

W przypadku niewielkiego serwisu bardzo prosty plik jest często najlepszym rozwiązaniem.

Im więcej skomplikowanych reguł, tym większe ryzyko przypadkowej blokady.

Robots.txt powinien rozwiązywać konkretny problem.

Nie warto dodawać kilkudziesięciu dyrektyw tylko dlatego, że podobny plik został znaleziony na innej stronie.

Kopiowanie robots.txt z innego serwisu

To zły pomysł.

Każda strona może posiadać inną:

• strukturę katalogów,
• platformę,
• architekturę URL,
• konfigurację filtrów,
• strategię indeksowania.

Reguła poprawna dla jednego sklepu może zablokować ważną sekcję w drugim.

Plik powinien odpowiadać rzeczywistej strukturze konkretnego serwisu.

Robots.txt a CSS i JavaScript

W przeszłości można było spotkać bardzo szerokie blokady katalogów zawierających zasoby techniczne strony.

Dzisiaj trzeba uważać z blokowaniem plików CSS i JavaScript wymaganych do prawidłowego renderowania serwisu.

Wyszukiwarka może potrzebować tych zasobów, aby zobaczyć stronę podobnie do użytkownika.

Jeżeli robot nie może pobrać kluczowych arkuszy stylów lub skryptów, ocena strony może być utrudniona.

Robots.txt a obrazy

Możliwe jest również ograniczanie dostępu robotów do określonych zasobów graficznych.

Nie powinno się jednak robić tego automatycznie.

Zdjęcia produktów i grafiki mogą być wartościowym źródłem ruchu z wyszukiwania obrazów.

Jeżeli obrazy mają być widoczne w Google Grafika, robot powinien posiadać możliwość ich pobrania.

Robots.txt a pliki PDF

Pliki PDF również mogą być crawlowane i indeksowane.

Jeżeli dokument jest publiczny i ma pojawiać się w wyszukiwarce, blokowanie dostępu nie ma sensu.

Jeżeli dokument zawiera poufne informacje, robots.txt również nie jest odpowiednim zabezpieczeniem.

Plik trzeba chronić dostępem albo usunąć z publicznie dostępnego obszaru.

Robots.txt a subdomeny

Plik dotyczy hosta, na którym został udostępniony.

Jeżeli firma posiada:

www.domena.pl

oraz:

sklep.domena.pl

subdomena może wymagać własnej konfiguracji robots.txt.

Nie należy zakładać, że plik głównej domeny automatycznie kontroluje wszystkie subdomeny.

Robots.txt w środowisku wielodomenowym

Podobny problem występuje, gdy ten sam system odpowiada na kilka różnych domen.

Każda z nich może posiadać inną rolę.

Jedna może być produkcyjna, druga testowa, a trzecia używana tylko technicznie.

Trzeba upewnić się, że właściwy robots.txt jest zwracany dla każdego hosta.

Wielkość liter w ścieżkach

Przy tworzeniu reguł warto traktować ścieżki precyzyjnie.

Adresy:

/Sklep/

i:

/sklep/

mogą być technicznie różnymi ścieżkami.

Nie należy zakładać, że jedna reguła zawsze obejmie oba warianty.

Znaki specjalne w regułach

Niektóre popularne roboty obsługują dodatkowe mechanizmy dopasowania, takie jak gwiazdka reprezentująca ciąg znaków czy znak końca adresu.

Pozwala to tworzyć bardziej elastyczne reguły.

Im bardziej skomplikowany wzorzec, tym łatwiej jednak zablokować więcej adresów, niż było zamierzone.

Przy ważnej witrynie każdą taką regułę warto przetestować na rzeczywistych URL.

Crawl-delay

W niektórych plikach można spotkać dyrektywę Crawl-delay określającą opóźnienie pomiędzy kolejnymi żądaniami robota.

Nie jest ona jednak obsługiwana jednakowo przez wszystkie wyszukiwarki.

Google nie wykorzystuje jej jako standardowego sposobu sterowania szybkością crawlowania.

Nie należy więc zakładać, że wpisanie Crawl-delay rozwiąże problem przeciążenia serwera przez każdego crawlera.

Jak robot wybiera regułę?

Plik może zawierać różne grupy przeznaczone dla różnych User-agentów.

Robot wyszukuje reguły dotyczące własnej nazwy i interpretuje odpowiednie dopasowania ścieżek.

W praktyce przy podstawowym serwisie warto utrzymywać konfigurację możliwie prostą.

Skomplikowane rozdzielanie zasad dla wielu botów powinno mieć konkretny powód.

Czy wszystkie roboty respektują te same zasady?

Nie.

Istnieje standard określający podstawowe zachowanie, ale poszczególne crawlery mogą różnić się obsługą dodatkowych elementów.

Przed zastosowaniem nietypowej dyrektywy warto sprawdzić dokumentację konkretnego robota.

Co się stanie, jeśli robots.txt nie istnieje?

Brak pliku nie oznacza automatycznie problemu.

Jeżeli serwer informuje robota, że robots.txt nie istnieje, crawler może potraktować to jako brak szczególnych ograniczeń.

Nie każda strona musi więc posiadać rozbudowany fizyczny plik.

Co się stanie, gdy robots.txt zwraca błąd?

Znaczenie ma rodzaj odpowiedzi serwera.

Brak pliku jest inną sytuacją niż awaria serwera uniemożliwiająca jego pobranie.

Jeżeli crawler nie może ustalić reguł z powodu problemu technicznego po stronie serwera, może zachować się ostrożniej niż przy zwykłym braku pliku.

Dlatego podczas audytu sprawdzam nie tylko jego treść, ale również status HTTP i sposób odpowiedzi serwera.

Robots.txt i przekierowania

Adres /robots.txt powinien być dostępny w przewidywalny sposób.

Nie warto tworzyć długiego łańcucha przekierowań albo kierować go na przypadkową stronę HTML.

Robot oczekuje pliku tekstowego zawierającego reguły.

Typ MIME robots.txt

Plik powinien być zwracany jako zwykła treść tekstowa.

Nie powinien prowadzić do strony błędu zaprojektowanej jako normalny dokument HTML albo do formularza logowania.

Podczas diagnostyki zawsze warto zobaczyć rzeczywistą odpowiedź otrzymywaną przez klienta.

Robots.txt a błędny status 200

Serwer może zwrócić kod 200, ale zamiast prawidłowego pliku wyświetlić na przykład stronę błędu.

Dlatego sam status nie wystarcza.

Trzeba sprawdzić również treść odpowiedzi.

Jak sprawdzić robots.txt ręcznie?

Najprostszy sposób to otworzyć w przeglądarce:

https://twojadomena.pl/robots.txt

Następnie warto sprawdzić:

• czy plik istnieje,
• czy wyświetla się jako tekst,
• czy nie ma Disallow: / dla wszystkich robotów,
• czy ważne katalogi nie są zablokowane,
• czy wskazana sitemap rzeczywiście działa.

To podstawowa kontrola, którą można wykonać w kilkanaście sekund.

Jak analizować konkretną regułę?

Nie wystarczy przeczytać:

Disallow: /abc/

Trzeba ustalić, jakie realne adresy rozpoczynają się od tej ścieżki.

Jedna reguła może obejmować setki tysięcy URL.

Przed wdrożeniem warto więc przygotować przykłady:

• adres, który ma być zablokowany,
• adres podobny, który ma pozostać dostępny,
• adres z parametrem,
• adres głębiej w strukturze.

Robots.txt i Google Search Console

Google Search Console pomaga diagnozować problemy z dostępnością i indeksowaniem adresów.

Jeżeli Google informuje, że strona została zablokowana przez robots.txt, warto sprawdzić rzeczywistą regułę zamiast usuwać ją w ciemno.

Czasami blokada jest błędem.

Innym razem adres rzeczywiście jest techniczny i ograniczenie jest zamierzone.

„Zablokowano przez robots.txt” nie zawsze oznacza awarię

Raport może zawierać adresy, których świadomie nie chcemy crawlowania.

Sam komunikat nie oznacza więc automatycznie, że serwis wymaga naprawy.

Najpierw trzeba odpowiedzieć:

Czy ten konkretny adres powinien być dostępny dla robota?

Dopiero wtedy wiadomo, czy blokada jest prawidłowa.

Robots.txt po migracji strony

Po zmianie domeny, hostingu albo technologii plik powinien zostać ponownie sprawdzony.

Mogły zmienić się:

• katalogi,
• adresy URL,
• lokalizacja mapy XML,
• system filtrowania,
• mechanizm wyszukiwania.

Stare reguły mogą już nie mieć sensu albo, co gorsza, zacząć pasować do nowych ważnych adresów.

Robots.txt po zmianie CMS

Reguły przygotowane dla WordPressa nie muszą mieć sensu po migracji do systemu statycznego, dedykowanego CMS albo innej platformy.

Nie warto więc traktować robots.txt jako pliku, który można bezrefleksyjnie przenosić pomiędzy kolejnymi wersjami strony.

Robots.txt w stronie statycznej

Strona statyczna również może posiadać robots.txt.

Brak WordPressa czy bazy danych nie zmienia funkcji tego pliku.

Może wskazywać sitemap oraz określać obszary, do których crawler nie powinien wchodzić.

W przypadku dobrze zaprojektowanej statycznej witryny struktura jest często prostsza, więc sam robots.txt również może być bardzo krótki.

Czy warto blokować panel administracyjny?

Można ograniczać crawling technicznych adresów panelu, ale nie należy mylić tego z jego zabezpieczeniem.

Panel powinien być chroniony przede wszystkim poprzez uwierzytelnianie, odpowiednie uprawnienia i zabezpieczenia systemowe.

Wpisanie jego adresu do robots.txt nie powstrzymuje osoby, która zna URL i chce spróbować się z nim połączyć.

Czy robots.txt ukrywa adres strony?

Nie.

Wręcz przeciwnie: sam plik może publicznie wymieniać nazwy blokowanych katalogów.

Dlatego nigdy nie należy wpisywać tam ścieżki tylko po to, aby była tajna.

Robots.txt a canonical

Canonical i robots.txt rozwiązują różne problemy.

Canonical pomaga wskazać preferowaną wersję dokumentu, gdy podobna treść istnieje pod kilkoma adresami.

Robots.txt kontroluje możliwość crawlowania.

Jeżeli zablokuje się stronę w robots.txt, robot może nie zobaczyć znajdującego się w niej canonicala.

Dlatego nie należy projektować strategii polegającej jednocześnie na blokowaniu strony i oczekiwaniu, że Google odczyta jej elementy HTML.

Robots.txt a przekierowanie 301

Jeżeli stary adres został trwale przeniesiony na nowy, zazwyczaj najlepszym mechanizmem jest odpowiednie przekierowanie HTTP.

Blokowanie starego adresu w robots.txt może utrudnić crawlerowi zobaczenie przekierowania.

Nie warto więc stosować Disallow jako zamiennika prawidłowej migracji adresów.

Robots.txt a błędy 404

Nie trzeba blokować każdego nieistniejącego adresu.

Jeżeli URL rzeczywiście nie istnieje, serwer powinien prawidłowo poinformować o tym kodem odpowiedzi.

Robots.txt nie służy do ukrywania błędów 404.

Robots.txt a spamerskie adresy

Po ataku lub błędnej konfiguracji w indeksie mogą pojawić się tysiące niechcianych URL.

Naturalnym odruchem bywa dodanie ich do robots.txt.

Może to jednak utrudnić wyszukiwarce zobaczenie, że strony zostały usunięte albo otrzymały odpowiednią instrukcję indeksowania.

Najpierw trzeba ustalić, w jaki sposób Google ma dowiedzieć się o docelowym stanie adresu.

Robots.txt a JavaScript rendering

Jeżeli strona potrzebuje plików JavaScript do wygenerowania głównej treści, ich zablokowanie może ograniczyć możliwość prawidłowego renderowania.

Dotyczy to szczególnie aplikacji, w których znaczna część interfejsu powstaje po stronie klienta.

Robot powinien mieć dostęp do zasobów potrzebnych do zrozumienia strony.

Robots.txt a Core Web Vitals

Sam plik nie poprawia bezpośrednio wskaźników wydajności strony.

Nie należy blokować ciężkich zasobów tylko po to, aby robot ich nie pobierał.

Jeżeli skrypt albo arkusz CSS powoduje problemy wydajnościowe dla użytkownika, trzeba zoptymalizować samą stronę.

Najczęstsze błędy w robots.txt

Przypadkowe Disallow: /

Cała strona pozostaje zablokowana po przeniesieniu ze stagingu na produkcję.

Blokowanie stron z noindex

Robot nie może wejść na stronę i zobaczyć instrukcji noindex.

Blokowanie paginacji

Crawler traci naturalną ścieżkę prowadzącą do produktów znajdujących się głębiej w katalogu.

Blokowanie CSS i JavaScript

Robot może mieć problem z prawidłowym renderowaniem strony.

Traktowanie robots.txt jako zabezpieczenia

Poufny katalog pozostaje publicznie dostępny mimo wpisania go w Disallow.

Kopiowanie pliku z innej strony

Reguły nie odpowiadają rzeczywistej strukturze serwisu.

Zbyt szerokie wzorce

Reguła miała blokować jeden typ adresów, ale pasuje również do wartościowych podstron.

Brak aktualizacji po migracji

Stare ścieżki nie istnieją, a nowe nie są objęte prawidłową konfiguracją.

Jak podejść do tworzenia robots.txt?

Najpierw warto określić, czy rzeczywiście istnieje coś, czego robot nie powinien crawlowania.

Nie zaczynam od listy gotowych reguł znalezionych w internecie.

Analizuję strukturę konkretnej strony:

1. jakie typy adresów istnieją,
2. które są wartościowymi landing pages,
3. które powinny być indeksowane,
4. które są wyłącznie techniczne,
5. jak crawler dociera do produktów i treści,
6. jak działają filtry i parametry.

Dopiero wtedy można zdecydować, czy robots.txt powinien coś blokować.

Najpierw cel, potem reguła

Przed dodaniem każdej dyrektywy warto odpowiedzieć:

Jaki konkretny problem rozwiązuję?

Jeżeli odpowiedź brzmi:

„bo znalazłem taką regułę w poradniku”,

nie jest to wystarczający powód.

Poprawna konfiguracja techniczna wynika z rzeczywistego działania serwisu.

Jak testować zmianę robots.txt?

Przed publikacją warto przygotować zestaw przykładowych adresów.

Dla każdej reguły sprawdzam przynajmniej:

• URL, który ma być blokowany,
• podobny URL, który ma pozostać dostępny,
• adres kategorii,
• adres produktu,
• adres z parametrem, jeśli reguła dotyczy parametrów.

To znacznie bezpieczniejsze niż wdrożenie szerokiego wzorca bez kontroli jego rzeczywistego zasięgu.

Po zmianie trzeba obserwować efekty

Publikacja pliku nie kończy pracy.

Przy istotnej zmianie warto później sprawdzić między innymi:

• Google Search Console,
• logi serwera,
• crawl serwisu,
• indeksację ważnych stron,
• zachowanie filtrów i paginacji.

Jeżeli przypadkowo zablokowano istotny obszar, najlepiej wykryć to szybko.

Robots.txt w audycie technicznym SEO

Plik jest jednym z pierwszych elementów, które sprawdzam podczas analizy technicznej strony.

Nie wystarczy jednak przeczytać kilku linijek.

Trzeba zestawić je z rzeczywistą architekturą witryny.

Sprawdzam między innymi:

• czy ważne strony są dostępne dla crawlerów,
• czy blokady odpowiadają rzeczywistym typom URL,
• czy paginacja nie została odcięta,
• czy zasoby potrzebne do renderowania są dostępne,
• czy sitemap wskazuje właściwe adresy,
• czy robots.txt nie próbuje zastępować noindex albo zabezpieczeń.

To jeden z elementów analizowanych przeze mnie w ramach SEO technicznego, ponieważ błędy w tym obszarze potrafią wpływać na ogromną część serwisu jednocześnie.

Czy robots.txt może poprawić SEO?

Sam fakt posiadania pliku nie daje dodatkowych punktów rankingowych.

Nie jest to element, który automatycznie przesuwa stronę wyżej w Google.

Może jednak pomóc wyszukiwarce efektywniej korzystać z dużego serwisu i ograniczać crawling niepotrzebnych przestrzeni URL.

Najważniejszą wartością jest jednak unikanie błędów.

Źle skonfigurowany plik może zaszkodzić znacznie bardziej, niż poprawnie skonfigurowany może samodzielnie pomóc.

Czy mała strona firmowa potrzebuje optymalizacji robots.txt?

Zazwyczaj nie wymaga skomplikowanych reguł.

Jeżeli serwis posiada kilkanaście publicznych podstron i nie generuje ogromnej liczby parametrów, bardzo prosty robots.txt jest zwykle wystarczający.

W takim przypadku większe znaczenie będą miały:

• poprawne linkowanie,
• indeksowanie,
• sitemap XML,
• canonical,
• statusy HTTP,
• wydajność strony.

Kiedy robots.txt staje się szczególnie ważny?

Znaczenie rośnie wraz ze złożonością serwisu.

Szczególnie warto się nim zainteresować przy:

• dużych sklepach internetowych,
• rozbudowanych filtrach,
• wielu parametrach URL,
• wewnętrznych wynikach wyszukiwania,
• serwisach posiadających miliony możliwych kombinacji adresów,
• migracjach,
• środowiskach produkcyjnych i testowych.

Minimalizm jest zaletą

Dobry robots.txt nie musi być długi.

Wręcz przeciwnie.

Jeżeli ten sam rezultat można osiągnąć trzema czytelnymi regułami zamiast trzydziestu skomplikowanych wzorców, prostsze rozwiązanie jest zazwyczaj bezpieczniejsze.

Każda dodatkowa reguła jest kolejnym miejscem, w którym można popełnić błąd.

Najważniejsze zasady korzystania z robots.txt

• używaj robots.txt do sterowania crawlingiem, a nie jako zamiennika noindex,
• nie używaj go do zabezpieczania poufnych danych,
• uważaj szczególnie na Disallow: /,
• nie blokuj ważnych plików CSS i JavaScript bez powodu,
• nie blokuj paginacji automatycznie,
• analizuj filtry i parametry zamiast stosować jedną regułę dla wszystkiego,
• sprawdzaj plik po migracjach i uruchomieniu nowej strony,
• nie kopiuj konfiguracji z przypadkowego serwisu,
• testuj zakres każdej szerszej reguły,
• pamiętaj, że robot może znać adres mimo zakazu crawlowania.

Co warto zapamiętać o robots.txt?

Robots.txt jest prostym plikiem tekstowym służącym do komunikacji z robotami odwiedzającymi stronę.

Jego głównym zadaniem jest określenie, które adresy mogą być crawlowane, a które robot powinien pominąć.

Najważniejsze jest rozróżnienie crawlowania od indeksowania. Zablokowanie URL w robots.txt nie oznacza automatycznie usunięcia go z Google, a w niektórych sytuacjach może wręcz uniemożliwić robotowi zobaczenie instrukcji noindex.

Plik nie jest również zabezpieczeniem. Każdy może przeczytać jego zawartość, a złośliwe roboty mogą całkowicie ignorować znajdujące się w nim instrukcje.

W małych serwisach robots.txt powinien być zazwyczaj prosty. W dużych sklepach może stać się ważnym elementem zarządzania crawlingiem filtrów, parametrów i technicznych obszarów strony.

Najbezpieczniejsza zasada brzmi: nie dodawać żadnej blokady bez dokładnego zrozumienia, jakie rzeczywiste adresy zostaną nią objęte. W przypadku robots.txt kilka znaków może decydować o dostępności dla wyszukiwarki tysięcy lub milionów podstron.