Jak sprawdzić robots.txt pod kątem zablokowanych stron

Gdzie musi znajdować się robots.txt

Musi siedzieć w katalogu głównym hosta, jako /robots.txt, w zwykłym tekście UTF-8. Dotyczy dokładnie jednego schematu, hosta i portu, więc https://example.com/robots.txt nie reguluje niczego na https://shop.example.com ani niczego w wersji http tego samego hosta. Każda subdomena, którą chcesz kontrolować, potrzebuje własnego pliku.

Kod statusu zwracany przez ten plik ma tak samo duże znaczenie, jak jego treść. 404 jest odczytywane jako "brak ograniczeń, przeszukuj wszystko", co jest całkowicie prawidłowym stanem. Powtarzające się 5xx jest odczytywane jako awaria tymczasowa, i Google może wstrzymać przeszukiwanie hosta, zamiast zakładać, że wolno mu kontynuować. 403 zachowuje się w tym kontekście jak błąd serwera. Jeśli robots.txt jest niestabilny, przeszukiwanie staje się niestabilne razem z nim.

Składnia w pięciu liniach

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent otwiera grupę. Disallow blokuje prefiks ścieżki, Allow wykrawa wyjątek z blokady, * dopasowuje dowolny ciąg znaków, a $ kotwiczy koniec adresu URL. Sitemap jest niezależny od jakiejkolwiek grupy i przyjmuje bezwzględny adres URL. Format jest ustandaryzowany jako RFC 9309, więc opisane tu zachowanie nie jest specyficzne dla żadnego dostawcy.

To, co faktycznie się dzieje, decydują dwie reguły rozstrzygania. Robot używa tylko najbardziej konkretnej grupy, która go wymienia, i całkowicie ignoruje grupę *, gdy tylko jakaś grupa wymienia go bezpośrednio. W ramach tej grupy wygrywa najdłużej dopasowana reguła, a remis rozstrzyga na korzyść Allow.

Błędy, które blokują całą witrynę

• Disallow: / pozostawione po wdrożeniu ze środowiska testowego. Jeden znak, a zablokowana cała witryna. Trafia do produkcji dokładnie tak samo, jak trafia tam noindex ze środowiska testowego: plik konfiguracyjny wypromowany razem z wydaniem.
• Blokowanie CSS i JavaScript. Google renderuje strony, więc zablokowany katalog zasobów może sprawić, że strona wygląda dla robota na zepsutą, mimo że dla Ciebie wygląda dobrze.
• Oczekiwanie, że robots.txt usunie stronę z wyszukiwania. Nie może. Zablokowany URL wciąż może być wylistowany z linków zewnętrznych, zwykle bez fragmentu opisu, a ponieważ robot nie może go pobrać, noindex na tej stronie nigdy nie zostaje zobaczony. Żeby usunąć stronę, zezwól na przeszukanie i serwuj noindex.
• Używanie noindex: jako dyrektywy wewnątrz robots.txt. Nigdy nie było to częścią standardu, a Google przestał to honorować 1 września 2019 roku. Dziś jest po cichu ignorowane.
• Dodanie grupy dla nazwanego bota i oczekiwanie, że reguły z wieloznacznikiem wciąż będą obowiązywać. Nie będą. Gdy tylko istnieje User-agent: Googlebot, Googlebot czyta tę grupę i nic więcej, więc każda wspólna reguła musi zostać w niej powtórzona.
• Pusta linia wewnątrz grupy. Pusta linia kończy grupę, więc reguły po niej nie należą do niczego, dopóki nie pojawi się kolejna linia User-agent.
• Wypisywanie prywatnych ścieżek. Ten plik jest publiczny. Wymienienie w nim /internal-admin/ publikuje lokalizację rzeczy, którą próbujesz ukryć.

Jak przetestować pojedynczą ścieżkę

Pobierz plik i najpierw przeczytaj grupę, która Cię dotyczy:

curl -s https://example.com/robots.txt

Potem zastosuj ręcznie regułę najdłuższego dopasowania do badanej ścieżki. Przy Disallow: /blog/ i Allow: /blog/public/, URL /blog/public/post jest dozwolony, bo pasująca reguła Allow jest dłuższa. Dla usługi, którą posiadasz, raport robots.txt w Search Console pokazuje pobrany plik, kiedy został ostatnio odczytany i wszelkie błędy parsowania, co jest najszybszym sposobem na potwierdzenie, że robot czyta to, co Ty myślisz, że czyta.

Potwierdź, że jest osiągalny z każdego miejsca

Plik robots.txt, który wczytuje się z Twojego biurka, wciąż może zawodzić dla robota. Reguły ochrony przed botami, limity częstotliwości i blokady geograficzne rutynowo zwracają 403 dla zakresów adresów centrów danych, jednocześnie obsługując normalnie odwiedzających domowych, a wynikiem jest host, który Google spowalnia albo przestaje przeszukiwać z powodów, których nic w Twoich logach nie nazywa błędem.

Sposobem, żeby to zobaczyć, jest zażądanie pliku z miejsca, które nie jest Twoim biurem. Skieruj darmowe narzędzie do sprawdzania HTTP na https://example.com/robots.txt i odczytaj kod statusu zwrócony z punktów kontrolnych w różnych krajach. 200 wszędzie to zdrowa odpowiedź; 200 w domu i 403 z trzech regionów to odkrycie. Żeby przetestować, czy reguły blokują konkretną stronę, darmowy tester robots.txt sprawdza URL względem grupy dla wszystkich robotów i zgłasza, czy jest wymieniony w mapie witryny. Robots.txt istnieje poza stroną, więc opcja Indeksowalność w monitorze HTTP HostTracker go nie czyta: obserwuje ona tagi noindex i canonical na samej stronie, podczas gdy zaplanowane przeszukiwanie, w wersji beta, krzyżowo sprawdza każdą przeszukaną stronę względem robots.txt. Monitoring SEO wyjaśnia, co pokrywa które z nich.