„URL zablokowany przez plik robots.txt”. Jak znaleźć regułę, która blokuje?

W raporcie Google Search Console pojawia się wiersz z informacją, że adres został zablokowany przez plik robots.txt, a obok niego liczba stron, czasem kilka, czasem kilka tysięcy. Sam komunikat nie mówi jednak najważniejszego: który wiersz pliku odpowiada za blokadę i czy ta blokada jest zamierzona, czy przypadkowa. Właściciel firmy widzi tylko, że części serwisu Google nie czyta.

Ten tekst jest dla osób, które prowadzą stronę firmową lub sklep i chcą samodzielnie ustalić, skąd wzięła się blokada. Nie trzeba być programistą. Wystarczy dostęp do Search Console i możliwość zmiany pliku na serwerze albo w panelu strony.

Po lekturze czytelnik będzie umiał odnaleźć zablokowane adresy, wskazać dokładną regułę, która je zatrzymuje, zdecydować, czy należy ją zmienić, poprawić plik bez szkody dla reszty serwisu i sprawdzić, czy Google przyjął poprawkę.

Co dokładnie oznacza komunikat o blokadzie przez robots.txt?

Plik robots.txt to zwykły plik tekstowy w katalogu głównym witryny. Zawiera reguły, które mówią robotom wyszukiwarek, do jakich adresów mogą zaglądać, a do jakich nie. Robot Google przed wizytą na stronie pobiera ten plik i stosuje się do niego.

Komunikat w raporcie oznacza więc jedno: Google zna dany adres, ale nie pobrał jego treści, ponieważ zabrania mu tego reguła w pliku. W dokumentacji pomocy Search Console ten stan nosi nazwę „URL zablokowany przez plik robots.txt”. W panelu brzmienie może się nieznacznie różnić, na przykład zaczynać się od słowa „Strona”, ale chodzi o tę samą przyczynę.

Dwa podobne komunikaty, dwie różne sytuacje

W raporcie występują dwa wpisy związane z plikiem robots.txt i łatwo je pomylić. Pierwszy, opisany wyżej, dotyczy adresów zablokowanych i nieobecnych w indeksie. Drugi to ostrzeżenie „Strona zindeksowana, ale zablokowana przez plik robots.txt”.

Drugi przypadek zdarza się wtedy, gdy do zablokowanej strony prowadzą linki z innych miejsc. Google nie pobiera jej treści, ale może umieścić sam adres w wynikach wyszukiwania, zwykle bez opisu. Dokumentacja Google mówi o tym wprost: plik robots.txt nie jest mechanizmem służącym do ukrywania strony przed wyszukiwarką.

Kiedy blokada jest w porządku, a kiedy wymaga naprawy?

Nie każdy adres z tego wiersza jest błędem. Pomoc Search Console zaznacza, że adresy zablokowane przez plik robots.txt są często blokowane celowo i nie zawsze jest co naprawiać. Koszyk, panel logowania, wyniki wewnętrznej wyszukiwarki czy adresy z parametrami sortowania zwykle słusznie pozostają poza zasięgiem robota.

Naprawy wymagają trzy sytuacje. Pierwsza: na liście są strony, które mają sprzedawać i przyciągać klientów, czyli oferta, wpisy, kategorie sklepu, strona kontaktowa. Druga: zablokowane są pliki potrzebne do wyświetlenia strony, na przykład arkusze stylów i skrypty, przez co Google widzi stronę inaczej niż klient. Trzecia: stronę celowo wyłączono z wyników tagiem noindex, a blokada w pliku sprawia, że Google tego tagu nie może odczytać.

Gdzie w Search Console widać zablokowane adresy?

Pełna lista adresów znajduje się w raporcie „Indeksowanie stron”. Od niej należy zacząć, bo dopiero przegląd adresów pokazuje, czy problem dotyczy pojedynczych podstron, czy całego działu serwisu.

1. Po zalogowaniu do Search Console należy wybrać właściwą usługę, czyli witrynę, której dotyczy komunikat.
2. W menu po lewej stronie, w grupie „Indeksowanie”, trzeba kliknąć „Strony”. Otworzy się raport „Indeksowanie stron”.
3. Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Należy odszukać w niej wiersz mówiący o blokadzie przez plik robots.txt i kliknąć go.
4. Otworzy się strona ze szczegółowymi informacjami: wykres pokazujący, od kiedy liczba adresów rośnie, oraz lista przykładowych adresów.
5. Listę najwygodniej wyeksportować przyciskiem eksportu w prawym górnym rogu raportu i przejrzeć w arkuszu, sortując adresy alfabetycznie.

U góry raportu działa filtr z wartościami „Wszystkie znane strony”, „Wszystkie przesłane strony” i „Tylko strony nieprzesłane”. Radzę przełączyć go na „Wszystkie przesłane strony”. Wtedy zostają tylko adresy zgłoszone w mapie witryny, a więc te, które właściciel sam wskazał jako ważne. Jeśli po tej zmianie lista nie jest pusta, sytuacja jest sprzeczna: witryna jednocześnie prosi Google o odwiedzenie adresu i tego zabrania.

Posortowana lista zwykle od razu zdradza wzór. Adresy zaczynają się od tego samego katalogu, kończą tym samym rozszerzeniem albo zawierają ten sam parametr po znaku zapytania. Ten wspólny fragment należy zanotować, bo właśnie jego trzeba będzie szukać w pliku.

Lista w raporcie pokazuje przykłady, a nie zawsze komplet adresów. Dlatego ważniejszy od liczenia pozycji jest wzór, który je łączy. Jedna reguła potrafi zatrzymać tysiące podstron, a jej poprawienie odblokowuje wszystkie naraz.

Jak potwierdzić blokadę dla konkretnego adresu?

Raport bywa opóźniony o kilka dni, a plik mógł się w tym czasie zmienić. Zanim zacznie się cokolwiek poprawiać, trzeba sprawdzić stan obecny. Służy do tego narzędzie do sprawdzania adresów URL, czyli pole wyszukiwania na samej górze Search Console.

1. W polu na górze panelu wpisuje się pełny adres jednej z zablokowanych stron, razem z początkiem https, i zatwierdza klawiszem Enter.
2. W wynikach należy rozwinąć sekcję „Indeksowanie stron”.
3. Pole „Czy skanowanie jest dozwolone” pokazuje, czy reguła w pliku robots.txt zatrzymała robota. Wartość „Nie” potwierdza blokadę.
4. Pole „Pobranie strony” przy blokadzie wskazuje niepowodzenie, ponieważ robot nie pobrał treści.
5. Następnie trzeba kliknąć „Sprawdź URL wersji opublikowanej”. Narzędzie odwiedzi stronę w tej chwili i pokaże, czy blokada nadal działa.

Wynik dla wersji zindeksowanej opisuje ostatnią wizytę robota, która mogła odbyć się dawno. Test wersji opublikowanej opisuje stan bieżący. Jeśli pierwszy wynik pokazuje blokadę, a drugi już nie, plik został wcześniej poprawiony i wystarczy poczekać na ponowne odwiedziny Google albo je przyspieszyć w sposób opisany niżej.

Jest tu jedna pułapka. Przy stronie zablokowanej w pliku robots.txt pole „Czy indeksowanie jest dozwolone” zawsze ma wartość „Tak”. Nie oznacza to, że wszystko jest w porządku. Robot nie wszedł na stronę, więc nie mógł odczytać z niej żadnych poleceń, w tym tagu noindex.

Który plik robots.txt obowiązuje dla danego adresu?

Częsty powód bezowocnych poszukiwań: sprawdzany jest nie ten plik. Reguły obowiązują tylko dla tego protokołu, hosta i portu, pod którym plik jest dostępny. Plik pod adresem z https nie dotyczy adresu z http, plik domeny głównej nie dotyczy subdomeny, a wersja z www i bez www to dla robota dwa osobne miejsca.

Właściwy adres pliku ustala się prosto. Z adresu zablokowanej strony usuwa się wszystko, co następuje po nazwie hosta, i dopisuje /robots.txt. Dla strony https://sklep.example.com/buty/czarne obowiązuje więc plik https://sklep.example.com/robots.txt, a nie plik domeny example.com. Plik umieszczony w podkatalogu jest przez roboty pomijany.

Raport dotyczący pliku robots.txt

Search Console pokazuje, które pliki Google faktycznie znalazł i co w nich przeczytał. W menu po lewej stronie należy otworzyć „Ustawienia” i odszukać pozycję dotyczącą pliku robots.txt, a następnie otworzyć raport. Jest on dostępny dla usługi domeny oraz dla usługi z adresem bez ścieżki.

W tabeli widać kolumny „Ścieżka pliku”, „Stan pobierania”, „Sprawdzono”, „Rozmiar” i „Problemy”. Kliknięcie pliku na liście wyświetla ostatnio pobraną wersję, czyli dokładnie tę treść, według której Google obecnie działa. To ważne, bo może się ona różnić od pliku widocznego w przeglądarce, jeśli zmiana została wprowadzona niedawno. Po wybraniu „Wersje” widać wcześniejsze pobrania z ostatnich 30 dni, co pozwala ustalić, kiedy blokująca reguła się pojawiła.

Plik, którego nie ma na serwerze

W WordPressie plik robots.txt często nie istnieje fizycznie. System tworzy go w locie, gdy ktoś otwiera jego adres, a wtyczki do pozycjonowania dopisują do niego własne wiersze. Dlatego na serwerze pliku nie widać, a w przeglądarce jest. Jeśli w katalogu głównym pojawi się prawdziwy plik o tej nazwie, serwer poda właśnie jego, a ustawienia z panelu przestaną być widoczne dla robotów.

W praktyce trzeba więc ustalić źródło treści: fizyczny plik na serwerze, edytor we wtyczce albo ustawienia platformy sklepowej. W gotowych kreatorach stron bezpośrednia edycja bywa niedostępna i reguły zmienia się w ustawieniach widoczności witryny u dostawcy. Jak zbudować ten plik poprawnie od podstaw, opisałem osobno we wpisie o ustawianiu pliku robots.txt.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: wskażę regułę, która blokuje stronę, przygotuję poprawiony plik i dopilnuję, żeby Google go odczytał.

Jak czytać plik, żeby znaleźć regułę, która blokuje?

Plik składa się z grup. Każda grupa zaczyna się od wiersza User-agent, który wskazuje, jakiego robota dotyczy, a pod nim znajdują się wiersze Disallow (zakaz) i Allow (zezwolenie). Gwiazdka w wierszu User-agent: * oznacza wszystkie roboty. Wiersze zaczynające się od znaku # to komentarze i robot je pomija.

Najpierw właściwa grupa

Robot Google nie czyta całego pliku jako jednej listy zakazów. Wybiera jedną grupę: tę, której nazwa najdokładniej do niego pasuje. Jeśli w pliku jest grupa User-agent: Googlebot, robot stosuje wyłącznie ją i pomija grupę z gwiazdką. Dokumentacja Google zaznacza, że grupy dla konkretnego robota i grupa ogólna nie są łączone.

Wynikają z tego dwa wnioski. Jeżeli w pliku istnieje grupa dla Googlebota, blokującej reguły należy szukać w niej, a nie w grupie ogólnej. Jeżeli takiej grupy nie ma, obowiązuje grupa z gwiazdką. Kolejność grup w pliku nie ma znaczenia.

Potem dopasowanie ścieżki

Reguła porównywana jest ze ścieżką adresu, czyli z tym, co następuje po nazwie hosta, razem z parametrami po znaku zapytania. Dopasowanie działa od początku ścieżki. Reguła Disallow: /oferta zatrzymuje więc nie tylko stronę /oferta, ale też /oferta/strony-www, /oferta.html i /oferta-specjalna. Każdy adres, który zaczyna się od tych znaków, jest objęty zakazem.

Obowiązują przy tym trzy zasady, które warto mieć przed oczami podczas czytania pliku:

• gwiazdka * wewnątrz reguły zastępuje dowolny ciąg znaków, więc Disallow: /*? blokuje każdy adres zawierający znak zapytania;
• znak dolara $ oznacza koniec adresu, więc Disallow: /*.pdf$ blokuje adresy kończące się na .pdf, ale nie te, po których następują jeszcze parametry;
• wielkość liter ma znaczenie, więc reguła dla /Oferta nie obejmuje adresu /oferta.

Na końcu pierwszeństwo reguł

Do jednego adresu może pasować kilka reguł naraz. Google stosuje wtedy tę najbardziej szczegółową, czyli o najdłuższej ścieżce. Gdy zakaz i zezwolenie są równie szczegółowe, wygrywa reguła mniej restrykcyjna, czyli zezwolenie. Kolejność wierszy w grupie nie rozstrzyga niczego.

Przykład z dokumentacji dobrze to pokazuje. Przy parze Allow: /p i Disallow: / adres /page pozostaje dostępny, ponieważ zezwolenie ma dłuższą ścieżkę niż zakaz. Dlatego sama obecność wiersza Disallow: / nie przesądza jeszcze o blokadzie konkretnej strony, trzeba sprawdzić, czy nie istnieje dłuższe zezwolenie.

Ręczne wskazanie winnego wiersza

Search Console nie podaje numeru wiersza, który zatrzymał robota, więc regułę wskazuje się samodzielnie. Należy otworzyć w raporcie ostatnio pobraną wersję pliku, wybrać właściwą grupę, a następnie przejść przez jej zakazy jeden po drugim i przy każdym zadać jedno pytanie: czy ścieżka zablokowanej strony zaczyna się od tego ciągu znaków albo pasuje do wzoru z gwiazdką. Pasujące zakazy trzeba wypisać, potem wypisać pasujące zezwolenia i porównać długość ścieżek.

Wiersz, który po tym porównaniu wygrywa, jest szukaną regułą. Wspólny fragment adresów zanotowany wcześniej z raportu zwykle prowadzi do niego w kilka minut.

Jakie reguły najczęściej blokują więcej, niż powinny?

Większość przypadkowych blokad powtarza kilka tych samych schematów. Przy przeglądzie pliku radzę sprawdzić je w pierwszej kolejności.

• Disallow: / w grupie ogólnej. Blokuje całą witrynę. Najczęściej zostaje po wersji roboczej strony, którą celowo zamknięto przed robotami, a potem przeniesiono na właściwy adres razem z plikiem.
• Brak ukośnika na końcu. Reguła Disallow: /blog miała zamknąć jeden katalog, a zamyka każdy adres zaczynający się od tych liter. Katalog wskazuje się z ukośnikiem na końcu: Disallow: /blog/.
• Zbyt szeroki wzór z gwiazdką. Reguła Disallow: /*? miała wyłączyć sortowanie i filtry, a zatrzymuje także stronicowanie kategorii i wszystkie inne adresy z parametrami.
• Zablokowane zasoby. Zakaz dla katalogów ze stylami, skryptami lub obrazami utrudnia Google zrozumienie strony. Dokumentacja zaleca nie blokować zasobów, bez których strona nie wyświetla się poprawnie.
• Osobna grupa dla Googlebota. Ktoś dopisał ją dla jednej reguły, a robot przestał stosować zezwolenia z grupy ogólnej, bo grupy nie są łączone.
• Zakaz razem z tagiem noindex. Strona miała zniknąć z wyników, więc dodano i tag, i blokadę. Blokada uniemożliwia odczytanie tagu, dlatego adres może nadal pojawiać się w Google.

Osobną grupą są pliki zmienione przez aktualizację wtyczki, przez wdrożenie nowej wersji strony albo przez przywrócenie starej kopii serwisu. Jeśli wykres w raporcie pokazuje nagły skok liczby zablokowanych adresów, warto zestawić jego początek z historią wersji pliku w raporcie dotyczącym robots.txt oraz z terminem ostatnich prac na stronie. Podobnie postępuje się po przenosinach serwisu, o czym piszę we wpisie o stronie, która zniknęła z Google.

Jak bezpiecznie poprawić regułę i wgrać plik?

Plik robots.txt jest krótki, ale pomyłka w nim działa na cały serwis. Zmianę należy wprowadzać spokojnie, na kopii, i tylko w tym wierszu, który faktycznie blokuje. Usuwanie całej zawartości pliku „na wszelki wypadek” otwiera robotom miejsca, które słusznie były zamknięte.

1. Zapisanie kopii obecnego pliku. Wystarczy otworzyć jego adres w przeglądarce, skopiować treść do nowego pliku tekstowego na komputerze i zachować ją pod inną nazwą.
2. Otwarcie pliku w zwykłym edytorze tekstu, takim jak Notatnik. Dokumentacja Google odradza procesory tekstu, ponieważ potrafią zapisać plik w nieodpowiednim formacie i podmienić znaki.
3. Poprawienie wyłącznie wskazanej reguły: zawężenie jej, na przykład przez dodanie ukośnika na końcu katalogu, zastąpienie precyzyjniejszym wzorem albo usunięcie całego wiersza, jeśli zakaz nie jest potrzebny.
4. Jeżeli szeroki zakaz ma pozostać, a dostępna ma być tylko część katalogu, pod zakazem dopisuje się dłuższe zezwolenie, na przykład Allow: /oferta/pozycjonowanie/ pod wierszem Disallow: /oferta/.
5. Zapisanie pliku jako zwykłego tekstu w kodowaniu UTF-8, pod nazwą robots.txt.
6. Wgranie pliku do katalogu głównego witryny albo wklejenie treści w edytorze wtyczki lub platformy, zależnie od tego, skąd plik pochodzi.
7. Otwarcie adresu pliku w przeglądarce, najlepiej w oknie prywatnym, i sprawdzenie, czy widać nową treść.

Poprawiona grupa ogólna w prostym serwisie firmowym na WordPressie może wyglądać następująco:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.example.com/sitemap.xml

To tylko przykład układu, a nie wzór do skopiowania. Adres mapy witryny musi być pełny i prawdziwy, a lista zakazów zależy od budowy konkretnego serwisu. Sklep będzie miał ich więcej niż strona z kilkoma podstronami.

Jeżeli po wgraniu w przeglądarce nadal widać starą treść, przyczyną jest zwykle pamięć podręczna: wtyczki, serwera albo sieci dostarczania treści. Trzeba ją wyczyścić i otworzyć plik ponownie. Dopóki pod adresem pliku nie widać nowej wersji, nie ma sensu prosić Google o cokolwiek.

Gdy strona ma pozostać poza wynikami

Bywa, że po analizie okazuje się, iż zablokowana strona rzeczywiście nie powinna być w Google, a mimo to jej adres pojawia się w wynikach. Wtedy droga jest odwrotna, niż podpowiada intuicja. Zgodnie z dokumentacją należy usunąć blokadę z pliku robots.txt i oznaczyć stronę tagiem noindex albo zabezpieczyć ją logowaniem. Dopiero gdy robot wejdzie na stronę i odczyta tag, adres zniknie z wyników.

Jak przyspieszyć odczytanie zmiany przez Google?

Google nie pobiera pliku robots.txt przy każdej wizycie. Przechowuje jego kopię i odświeża ją zwykle w ciągu 24 godzin. Przez ten czas robot może nadal działać według starej wersji, dlatego test wykonany kilka minut po zmianie bywa mylący.

Odświeżenie można przyspieszyć w raporcie dotyczącym pliku robots.txt. Pomoc Search Console wskazuje, że warto to zrobić właśnie wtedy, gdy reguły zmieniono po to, aby odblokować ważne adresy.

1. W Search Console należy otworzyć „Ustawienia”, a w nich raport dotyczący pliku robots.txt.
2. Na liście plików trzeba odszukać ten, który został poprawiony, zwracając uwagę na protokół i host w kolumnie „Ścieżka pliku”.
3. Obok pliku znajduje się ikona „Więcej ustawień” w postaci trzech kropek. Po jej kliknięciu należy wybrać „Poproś o ponowne zindeksowanie”.
4. Po pewnym czasie w kolumnie „Sprawdzono” pojawi się nowa godzina, a w kolumnie „Stan pobierania” wartość „Pobrano”. Kliknięcie pliku pokaże, czy Google ma już poprawioną treść.
5. Dopiero wtedy należy wrócić do narzędzia do sprawdzania adresów URL, wpisać odblokowany adres i kliknąć „Sprawdź URL wersji opublikowanej”.
6. Jeśli pole „Czy skanowanie jest dozwolone” ma teraz wartość „Tak”, można kliknąć „Poproś o zindeksowanie”.

Prośba o zindeksowanie dotyczy jednego adresu i obowiązuje dla niej dzienny limit, dlatego warto przeznaczyć ją na najważniejsze strony: główną, ofertę, kategorie sklepu. Pozostałe adresy Google odwiedzi sam przy kolejnych wizytach. Pomaga w tym aktualna mapa witryny, a sposób jej przesłania opisuję we wpisie o zgłaszaniu mapy witryny w Search Console.

Zgłoszenie poprawki w raporcie

Ostatnią czynnością jest powrót do raportu „Indeksowanie stron”, otwarcie wiersza z blokadą i kliknięcie „Sprawdź poprawkę”. Search Console najpierw sprawdza kilka przykładowych adresów. Jeśli blokada nadal na nich występuje, weryfikacja od razu kończy się niepowodzeniem. Jeśli nie, zaczyna się sprawdzanie pozostałych znanych adresów.

Według pomocy Search Console weryfikacja trwa zazwyczaj do dwóch tygodni, a czasem dłużej. Nie jest ona obowiązkowa. Google aktualizuje liczby w raporcie także bez niej, przy każdej kolejnej wizycie na danym adresie. Zgłoszenie poprawki daje jednak wygodny podgląd postępu.

Po czym poznać, że naprawa zadziałała, i co robić, gdy blokada nie znika?

Skuteczną naprawę potwierdzają trzy sygnały, pojawiające się w różnym tempie. Najszybciej widać zmianę w teście wersji opublikowanej: pole „Czy skanowanie jest dozwolone” ma wartość „Tak”, a „Pobranie strony” kończy się powodzeniem. To dowód, że reguła przestała blokować.

Drugi sygnał to wynik sprawdzania poprawki. Na stronie szczegółów widać stan weryfikacji oraz stany poszczególnych adresów: „Oczekuje”, „Powodzenie” albo „Niepowodzenie”. Trzeci sygnał to wykres: liczba adresów w wierszu z blokadą zaczyna spadać, a odblokowane strony przechodzą do grupy zindeksowanych albo do innego wiersza z przyczyną.

Ten ostatni punkt wymaga komentarza. Odblokowanie strony nie oznacza automatycznie jej obecności w wynikach. Oznacza tylko, że Google może ją wreszcie przeczytać i ocenić. Jeśli strona trafi potem do innego wiersza raportu, jest to już osobny temat. Stan indeksu dla pojedynczych adresów można kontrolować sposobami opisanymi we wpisie o sprawdzaniu, czy Google zaindeksował stronę.

Gdy blokada nie znika

Jeżeli po kilku dniach test wersji opublikowanej nadal pokazuje blokadę, przyczyna leży w jednym z kilku miejsc. Radzę sprawdzać je po kolei, zamiast ponownie przerabiać cały plik.

• Poprawiono nie ten plik. Zablokowany adres należy do innego hosta lub protokołu, na przykład do subdomeny sklepu albo wersji z www, która ma własny plik.
• Google nadal ma starą kopię. W raporcie dotyczącym pliku robots.txt kolumna „Sprawdzono” pokazuje czas sprzed zmiany, a treść po kliknięciu pliku jest dawna.
• Serwer podaje starą treść z pamięci podręcznej albo fizyczny plik w katalogu głównym przesłania ustawienia wprowadzone we wtyczce.
• Adres blokuje inna reguła niż poprawiona. Do ścieżki pasowały dwa zakazy, a usunięto tylko jeden.
• W pliku istnieje osobna grupa dla Googlebota, a zmianę wprowadzono w grupie z gwiazdką.
• Kolumna „Problemy” w raporcie pokazuje błędy składni. Google pomija wiersze, których nie potrafi odczytać, więc dopisane zezwolenie z literówką po prostu nie działa.

Warto też spojrzeć na „Stan pobierania”. Wartość „Nie pobrano – nie znaleziono (404)” oznacza brak pliku, co jest sytuacją prawidłową: Google może wtedy odwiedzać wszystkie adresy witryny. Inaczej jest przy błędach serwera. Gdy plik robots.txt zwraca błąd z grupy 5xx, Google na pewien czas wstrzymuje odwiedzanie witryny, a potem przez ograniczony czas korzysta z ostatniej poprawnej kopii pliku. Taki stan wymaga pilnego kontaktu z firmą hostingową, bo problemem jest serwer, a nie reguły.

Jakich błędów unikać przy pracy z plikiem robots.txt?

Najpoważniejszy błąd to usunięcie wszystkich zakazów w odruchu obronnym. Roboty zaczynają wtedy odwiedzać koszyki, wyniki wyszukiwania i niekończące się kombinacje filtrów, co obciąża serwer i odciąga je od stron ważnych. Poprawia się jedną regułę, a nie cały plik.

Drugi błąd to traktowanie pliku robots.txt jako zabezpieczenia. Plik jest publiczny, każdy może go przeczytać, a reguły są prośbą skierowaną do robotów, nie zamkiem. Treści poufne chroni się hasłem, a nie wierszem zakazu. Co więcej, lista zakazanych katalogów podpowiada ciekawskim, gdzie szukać.

Trzeci błąd to praca bez kopii i bez sprawdzenia. Każdą zmianę należy poprzedzić zapisaniem starej wersji, a zakończyć testem dwóch adresów: jednego, który miał zostać odblokowany, i jednego, który ma pozostać zamknięty. Czwarty błąd to pośpiech w ocenie. Raport „Indeksowanie stron” odświeża się z opóźnieniem, więc brak zmiany na wykresie następnego dnia niczego jeszcze nie dowodzi. Miarodajny jest test wersji opublikowanej.

Piąty błąd dotyczy wersji roboczych serwisu. Zamykanie ich wierszem Disallow: / jest ryzykowne, ponieważ plik łatwo przenieść na właściwą domenę razem z resztą strony. Bezpieczniej zabezpieczyć wersję roboczą hasłem, a po każdym wdrożeniu otworzyć adres pliku na docelowej domenie i przeczytać go od początku do końca.

Najczęstsze pytania

Czy komunikat o blokadzie przez robots.txt obniża pozycje całej strony?

Sam wpis w raporcie nie jest karą ani oceną witryny. Skutki zależą od tego, co zostało zablokowane. Zatrzymanie koszyka czy panelu logowania niczego nie psuje, natomiast zablokowanie oferty, kategorii albo plików potrzebnych do wyświetlenia strony odbiera tym stronom szansę na widoczność, bo Google nie zna ich treści.

Ile trwa, zanim odblokowane strony wrócą do Google?

Nową wersję pliku Google odczytuje zwykle w ciągu 24 godzin, a szybciej po prośbie w raporcie dotyczącym pliku robots.txt. Ponowne odwiedzenie i zindeksowanie samych stron trwa dłużej, od kilku dni do kilku tygodni, zależnie od wielkości serwisu. Nikt rzetelny nie poda tu gwarantowanego terminu.

Czy można po prostu usunąć plik robots.txt?

Technicznie tak. Brak pliku jest dla Google sytuacją prawidłową i oznacza zgodę na odwiedzanie wszystkich adresów. W małej witrynie firmowej zwykle nic złego się nie stanie. W sklepie lub dużym serwisie roboty zaczną jednak odwiedzać adresy techniczne, dlatego lepiej poprawić jedną regułę, niż rezygnować z całego pliku.

Dlaczego adres jest w wynikach Google, skoro plik go blokuje?

Plik robots.txt zabrania pobierania treści, a nie umieszczania adresu w indeksie. Jeśli do strony prowadzą linki, Google może pokazać sam adres, zwykle bez opisu. Aby adres zniknął, trzeba zdjąć blokadę i oznaczyć stronę tagiem noindex, tak aby robot mógł ten tag odczytać.

W WordPressie nie ma pliku robots.txt na serwerze. Skąd biorą się reguły?

WordPress tworzy ten plik w locie, a wtyczki do pozycjonowania mogą zmieniać jego treść. Reguł należy więc szukać w ustawieniach wtyczki, zwykle w części z narzędziami lub edytorem plików. Jeżeli w katalogu głównym leży fizyczny plik, to on ma pierwszeństwo przed wersją tworzoną przez system.

Czy reguły dla Googlebota dotyczą też innych wyszukiwarek?

Nie. Każdy robot wybiera grupę, która najlepiej pasuje do jego nazwy, a gdy takiej nie ma, stosuje grupę z gwiazdką. Dokumentacja Google zaznacza ponadto, że roboty różnych firm mogą nieco inaczej rozumieć składnię, dlatego reguły warto pisać prosto i bez wyszukanych wzorów.

Jak sprawdzić regułę, zanim plik trafi na serwer?

Raport w Search Console działa tylko na plikach już opublikowanych. Przed wgraniem pozostaje ręczne porównanie ścieżek według opisanych zasad: właściwa grupa, dopasowanie od początku ścieżki, najdłuższa reguła wygrywa. Po wgraniu rozstrzygający jest test wersji opublikowanej dla adresu, który miał zostać odblokowany, i dla adresu, który ma pozostać zamknięty.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Plik robots.txt ma kilka wierszy, ale jedna pomyłka potrafi zamknąć przed Google cały serwis, więc nie każdy chce brać to na siebie. Chętnie zajmę się tym od początku do końca: przejrzę raport w Search Console, wskażę regułę, która blokuje strony, oddzielę blokady potrzebne od przypadkowych, przygotuję poprawiony plik, wgram go, poproszę Google o ponowne odczytanie i sprawdzę, czy odblokowane adresy wracają do indeksu.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę i co należy zrobić.