Jak sprawdzić, czy witryna ma plik robots.txt
Jak sprawdzić, czy witryna ma plik robots.txt
Plik robots.txt to niewielki plik tekstowy zawierający instrukcje dla botów, które zdecydują się ich przestrzegać. Jego sprawdzenie może pomóc ustalić, które ścieżki witryna zaleca odwiedzać lub omijać określonym robotom. Nie pokazuje jednak wszystkich ustawień witryny i nie stanowi zabezpieczenia.
Jeśli zastanawiasz się, jak sprawdzić, czy witryna ma plik robots.txt, zacznij od dokładnego adresu źródłowego witryny, a następnie sprawdź odpowiedź serwera i zawartość pliku. To ważne szczegóły: plik w jednej subdomenie może nie mieć żadnego związku z inną, a błąd w przeglądarce nie zawsze oznacza, że pliku brakuje. Warto też wiedzieć, jak sprawdzić plik robots.txt, aby odróżnić brak zasobu od pustej odpowiedzi lub problemu z serwerem.
1. Dowiedz się, co można, a czego nie można ustalić na podstawie pliku robots.txt
Plik robots.txt zawiera reguły dla robotów indeksujących. Reguła może na przykład zalecać zgodnemu z nią robotowi wyszukiwarki, by nie odwiedzał ścieżki takiej jak /private/. To prośba, a nie mechanizm kontroli dostępu: użytkownik nadal może otworzyć ten adres, a bot może zignorować prośbę.
Plik nie gwarantuje też, że zablokowana strona nie pojawi się w wynikach wyszukiwania. Wyszukiwarka może poznać adres URL z odnośników w innych miejscach i wyświetlić go bez pobierania jego zawartości. Jeśli strona ma pozostać prywatna, zastosuj rzeczywistą kontrolę dostępu, na przykład uwierzytelnianie, zamiast polegać na pliku robots.txt.
Traktuj ten plik jak publiczny zestaw wskazówek. Może pomóc wyjaśnić sposób indeksowania, ale nie potwierdzi, czy dana strona jest dostępna, prywatna lub zaindeksowana. Każdą z tych kwestii sprawdzaj osobno.
2. Znajdź plik robots.txt we właściwym adresie źródłowym witryny
W przypadku witryny pod adresem https://example.com plik zazwyczaj znajduje się pod adresem https://example.com/robots.txt. Jeśli zastanawiasz się, gdzie znaleźć robots.txt witryny, zachowaj protokół i nazwę hosta widoczne na pasku adresu, a jeśli witryna korzysta z niestandardowego portu, uwzględnij go również. Ścieżka znajduje się w katalogu głównym danego adresu źródłowego, a nie w folderze takim jak /blog/.
Zmiana protokołu lub nazwy hosta może dać inny wynik. Na przykład http://example.com/robots.txt и https://example.com/robots.txt to odrębne żądania, nawet jeśli jedno przekierowuje do drugiego. Podobnie adresy www.example.com и example.com mogą być skonfigurowane osobno.
Subdomeny mają własne adresy źródłowe. Plik pod adresem https://shop.example.com/robots.txt nie dotyczy automatycznie witryny https://example.com/ lub https://help.example.com/. Sprawdź host, który Cię interesuje — zwłaszcza gdy firma prowadzi sklep, dział pomocy i główną witrynę w osobnych subdomenach.
Na początek użyj paska adresu: wpisz pełny adres URL pliku robots.txt i sprawdź, co się wyświetli. Często zobaczysz zwykły tekst, ale sformatowany widok w przeglądarce również jest w porządku. Najważniejsze są adres URL, pod który wysłano żądanie, i odpowiedź serwera.
3. Sprawdź odpowiedź, nie tylko stronę wyświetloną w przeglądarce
Pomyślna odpowiedź zwykle oznacza, że serwer zwrócił zawartość dla tego adresu URL. Wiele witryn zwraca kod HTTP, taki jak 200, ale widoczna treść może zawierać zestaw reguł, pusty plik, a nawet nieoczekiwaną stronę. Oceniaj treść łącznie z kodem odpowiedzi — samo załadowanie strony nie dowodzi, że jest to prawidłowy plik robots.txt.
Odpowiedź informująca o nieznalezieniu zasobu, często 404, sugeruje, że pod wskazaną ścieżką w danym adresie źródłowym plik w tej chwili nie istnieje. To przydatna wskazówka, ale najpierw sprawdź nazwę hosta i przekierowania. Literówka lub inna subdomena może dać ten sam wynik.
Przekierowania wymagają uwagi. Żądany adres URL może przekierować do innego hosta lub ścieżki, a adres docelowy może zwrócić treść dotyczącą innego adresu źródłowego. Zapisz zarówno pierwotny adres URL, jak i adres docelowy, zanim zdecydujesz, których instrukcji witryny dotyczy odczytany plik.
Błędy dostępu i awarie serwera to nie to samo co brak pliku. Odpowiedź taka jak 403 może oznaczać, że serwer odmówił dostępu, a kod 5xx może wskazywać na chwilowy problem z serwerem. Sprawdzenie może uniemożliwić również przekroczenie limitu czasu połączenia lub błąd połączenia w przeglądarce. Spróbuj ponownie później albo użyj drugiej metody, zanim wyciągniesz ostateczny wniosek.
Przy okazji audytu witryny możesz też przeczytać, jak sprawdzić, czy witryna publikuje informację o linkach afiliacyjnych. To sprawdzenie dotyczy widocznej polityki, a nie instrukcji dla robotów indeksujących.
4. Sprawdź dyrektywy robots.txt dotyczące wybranego robota
Aby wiedzieć, jak odczytać reguły robots.txt, czytaj każdą grupę dyrektyw w kontekście. Wiersz User-agent wskazuje robota, a wiersze Disallow i Allow określają ścieżki, których robot nie powinien odwiedzać albo które może odwiedzać. Sposób interpretacji może zależeć od robota, dlatego w razie wątpliwości sprawdź jego dokumentację.
Na przykład grupa rozpoczynająca się od User-agent: ExampleBotmoże dotyczyć wyłącznie wymienionego robota. Osobna grupa User-agent: * jest przeznaczona dla robotów, dla których nie zdefiniowano bardziej szczegółowej grupy. Nie zakładaj, że reguła dotycząca jednego bota obowiązuje wszystkie wyszukiwarki i inne usługi automatyczne.
Znaczenie mają również ścieżki. Reguła dotycząca /images/ nie jest tym samym co reguła dla /, a reguła dla /drafts/ nie musi obejmować podobnie nazwanej ścieżki w innym miejscu. Zanim zastosujesz regułę do adresu URL, sprawdź całą ścieżkę i grupę, w której się znajduje.
Rozważmy plik zawierający Disallow: /private/w ogólnej grupie User-agent. Ta instrukcja prosi pasujące roboty o nieodwiedzanie ścieżek w tym katalogu i jego podkatalogach. Nie powstrzyma jednak nikogo przed otwarciem znanego adresu URL i nie dowodzi, że każdy bot jej przestrzega.
Niektóre pliki zawierają komentarze, puste wiersze lub reguły skierowane do konkretnych usług. Skup się na grupie User-agent odpowiadającej Twojemu pytaniu, a następnie sprawdź opublikowane zasady danego robota, by dowiedzieć się, jak interpretuje nakładające się lub nietypowe dyrektywy. Jeśli sprawdzasz konkretną wyszukiwarkę, jej dokumentacja jest najlepszym źródłem informacji o tym, jak ta wyszukiwarka interpretuje plik.
5. Odróżnij pusty plik od brakującego lub nieprawidłowego
Pusta odpowiedź i brak pliku to dwa różne wyniki. Jeśli serwer zwraca pomyślną odpowiedź, ale nie widać w niej tekstu, plik może istnieć, lecz nie zawierać żadnych dyrektyw. Jeśli serwer zwraca kod informujący o nieznalezieniu zasobu, oznacza to, że nie znalazł pliku pod wskazanym adresem URL. Zapisz zarówno kod odpowiedzi, jak i treść, aby nie pomylić tych przypadków.
Nieoczekiwana zawartość wymaga dodatkowego sprawdzenia. Strona z ogólnym komunikatem o błędzie, ekran logowania lub kod HTML mogą oznaczać, że żądanie trafiło na stronę zastępczą, a nie na zwykły plik robots.txt. Adres URL może załadować się poprawnie, mimo że zwrócona treść nie nadaje się do wykorzystania jako instrukcje dla robotów.
Nie zgaduj, co oznaczają niepoprawne lub nieznane wiersze. Zapisz dokładną odpowiedź i porównaj ją z dokumentacją sprawdzanego robota. Jeśli plik zmienia się między kolejnymi sprawdzeniami, zanotuj godzinę — późniejsza odpowiedź może odzwierciedlać poprawioną wersję, a nie tę samą treść.
6. Zweryfikuj wyniki inną metodą
Jeśli wynik w przeglądarce jest niejasny, wyślij żądanie z wiersza poleceń. Na przykład curl -i https://example.com/robots.txt pozwala w jednym żądaniu wyświetlić nagłówki odpowiedzi i zwróconą treść. Zastąp przykładowy adres dokładnym adresem źródłowym, który sprawdzasz, uwzględniając właściwą subdomenę i port, jeśli to konieczne.
Możesz też skorzystać z narzędzi deweloperskich przeglądarki. Otwórz panel Network, załaduj adres URL pliku robots.txt, a następnie wybierz żądanie, aby sprawdzić jego status, nagłówki i treść odpowiedzi. Przydaje się to, gdy przeglądarka pokazuje przekierowanie lub sformatowaną stronę, ale nie wskazuje jasno końcowego adresu docelowego.
Jeśli wyniki różnych metod się różnią, porównaj dokładny adres URL, godzinę, kod odpowiedzi, przekierowania i treść. Żądanie z wiersza poleceń i żądanie z przeglądarki mogą inaczej obsługiwać przekierowania albo trafić na chwilową awarię serwera. Jeśli korzystasz z firmowego serwera proxy, VPN-u lub rozszerzenia przeglądarki, w razie potrzeby sprawdź wynik bez tych narzędzi. Zmiana odpowiedzi może wskazywać na pośrednika, a nie samą witrynę.
Inny przykład sprawdzania witryny to jak sprawdzić, czy witrynawyświetla informację o prawach autorskich. Nie łącz tego z plikiem robots.txt: pierwsza informacja jest przeznaczona dla czytelników, a drugi plik — dla robotów indeksujących.
7. Zapisz zakres i ograniczenia sprawdzenia
Zapisz dokładny adres URL pliku robots.txt, datę i godzinę żądania, kod HTTP, adres docelowy przekierowania oraz zauważoną treść. Jeśli interpretujesz konkretną grupę dyrektyw, dodaj informację o robocie lub jego identyfikatorze User-agent. Dzięki temu będzie można powtórzyć sprawdzenie, jeśli witryna się zmieni.
Formułuj wnioski precyzyjnie. Pomyślna odpowiedź pokazuje, co serwer zwrócił dla jednego adresu źródłowego w danym momencie. Nie dowodzi, że strona jest zaindeksowana, dostępna dla wszystkich użytkowników ani zablokowana dla każdego robota. Odpowiedź o braku pliku dotyczy wskazanego adresu URL, a nie automatycznie każdej subdomeny ani wersji protokołu.
Plik robots.txt może zmienić się bez ostrzeżenia. Jeśli decyzja zależy od aktualnych reguł, ponownie sprawdź dokładny adres źródłowy i zachowaj nową odpowiedź, zamiast polegać na starszej kopii.
