Sformalizowanie specyfikacji Robots Exclusion Protocol

Poniedziałek, 1 lipca 2019 r.

Od 25 lat protokół Robots Exclusion Protocol (REP) jest jednym z najbardziej podstawowych i najważniejszych elementów internetu. Umożliwia właścicielom witryn blokowanie automatycznym klientom, na przykład robotom indeksującym dostępu do witryny – częściowo lub w całości.

Wstępną wersję standardu opracował w 1994 roku Martijn Koster (również webmaster), gdy roboty indeksujące przeciążały jego witrynę. Dzięki wkładowi pracy innych webmasterów pojawił się protokół REP, który został wdrożony przez wyszukiwarki, aby ułatwić właścicielom witryn zarządzanie zasobami serwera.

Protokół REP nigdy nie stał się oficjalnym standardem internetowym, co oznacza, że przez lata programiści interpretowali go nieco inaczej. Od momentu utworzenia protokół REP nie była aktualizowany pod kątem dzisiejszych sytuacji granicznych. Jest to trudny problem dla właścicieli witryn, ponieważ niejednoznaczny standard faktyczny utrudnia prawidłowe tworzenie reguł.

Chcieliśmy pomóc właścicielom witryn i deweloperom w tworzeniu znakomitych treści w internecie, aby nie musieli martwić się, jak kontrolować roboty. Wspólnie z pierwotnym autorem, webmasterami i innymi wyszukiwarkami udokumentowaliśmy sposób używania protokołu REP we współczesnym internecie oraz przesłaliśmy go do IETF.

Proponowana wersja robocza obejmuje 20 lat doświadczenia związanego z regułami w plikach robots.txt używanych przez Googlebota i inne główne roboty, a także ponad pół miliarda witryn korzystających z REP. Szczegółowe opcje dają wydawcy możliwość decydowania, jakie treści mają być indeksowane w witrynie i wyświetlane zainteresowanym użytkownikom. Protokół nie zmienia reguł utworzonych w 1994 roku, a jedynie precyzuje wszystkie niezdefiniowane scenariusze analizowania pliku robots.txt i dopasowywania reguł oraz rozszerza je na potrzeby nowoczesnej sieci. Ważne informacje:

  1. Każdy protokół transferu oparty na identyfikatorze URI może używać pliku robots.txt. Nie jest on już ograniczony do HTTP i może być używany także w przypadku FTP lub CoAP.
  2. Deweloperzy muszą analizować co najmniej pierwsze 500 kibibajtów pliku robots.txt. Określenie maksymalnego rozmiaru pliku daje pewność, że połączenia nie będą zbyt długo otwarte, co pozwoli ograniczyć niepotrzebne obciążenie serwerów.
  3. Nowy maksymalny czas przechowywania w pamięci podręcznej wynoszący 24 godziny lub równy wartości dyrektywy pamięci podręcznej (jeśli jest dostępna) zapewnia właścicielom witryn elastyczność aktualizowania pliku robots.txt w dowolnym momencie, a roboty nie przeciążają witryn żądaniami pliku robots.txt. Na przykład w przypadku HTTP do określenia czasu przechowywania w pamięci podręcznej można było używać nagłówków Cache-Control.
  4. Specyfikacja określa teraz, że kiedy dostępny wcześniej plik robots.txt staje się niedostępny z powodu awarii serwera, znane niedozwolone strony nie są indeksowane przez dłuższy czas.

Oprócz tego w wersji roboczej standardu internetowego zaktualizowaliśmy formularz Backusa-Naura. Ma on teraz lepszą definicję składni pliku robots.txt, co jest niezwykle ważne dla programistów podczas analizowania składniowej.

RFC to skrót od Request for Comment („prośba o komentarze”). Wersja robocza została przesłana do IETF, aby uzyskać opinie deweloperów, którzy zajmują się podstawowymi elementami internetu. Chcemy, aby twórcy stron internetowych mieli dostęp do opcji, które pozwalają określić, ile informacji ma być dostępnych dla Googlebota (i widocznych w wyszukiwarce). Dlatego zależy nam, aby wszystko działało prawidłowo.

Jeśli chcesz przekazać nam swoje uwagi, zadać pytanie lub po prostu przywitać się z nami, znajdziesz nas na Twitterze i na Forum webmasterów, zarówno offline, jak i w trybie online.