Piątek, 28 marca 2025 roku
W poprzednich wpisach na temat protokołu Robots Exclusion Protocol (REP) omawialiśmy, co możesz już zrobić za pomocą jego różnych elementów, czyli pliku robots.txt i ustawień na poziomie identyfikatora URI. W tym poście omówimy, jak REP może wspierać ciągle zmieniające się relacje między klientami automatycznymi a ludźmi w internecie.
Protokół REP, a w szczególności plik robots.txt, stał się standardem w 2022 roku jako RFC9309.
Jednak ciężka praca została wykonana przed standaryzacją: próba czasu w latach 1994–2022 sprawiła, że roboty te stały się na tyle popularne, że zostały zastosowane przez miliardy hostów i prawie wszystkich głównych operatorów robotów (z wyjątkiem robotów wrogich, takich jak skanery złośliwego oprogramowania). Jest to proste i eleganckie rozwiązanie umożliwiające wyrażanie preferencji za pomocą prostej, ale wszechstronnej składni.
W ciągu 25 lat istnienia ta technologia prawie wcale nie ewoluowała od swojej pierwotnej formy. Dodano tylko regułę allow, jeśli weźmiemy pod uwagę tylko reguły obsługiwane powszechnie przez roboty.
Nie oznacza to, że nie ma innych reguł. Każdy operator robota może stosować własne reguły. Na przykład reguły „clean-param” i „crawl-delay” nie są częścią RFC9309, ale są obsługiwane przez niektóre wyszukiwarki, choć nie przez wyszukiwarkę Google.
Reguła „sitemap”, która nie jest częścią RFC9309, jest obsługiwana przez wszystkie główne wyszukiwarki. Jeśli uzyska wystarczające poparcie, może stać się oficjalną regułą w REP.
Ponieważ REP może otrzymywać „aktualizacje”. Jest to powszechnie obsługiwany protokół, który powinien się rozwijać wraz z internetem. Wprowadzanie w nim zmian nie jest niemożliwe, ale nie jest łatwe. Nie powinno być łatwe, ponieważ REP jest szeroko obsługiwany. Podobnie jak w przypadku każdej zmiany w standardzie, musi istnieć konsensus, że zmiany są korzystne dla większości użytkowników protokołu, zarówno po stronie wydawców, jak i operatorów robotów.
Ze względu na swoją prostotę i szerokie zastosowanie REP jest doskonałym rozwiązaniem do przechowywania nowych preferencji indeksowania: miliardy wydawców znają już plik robots.txt i jego składnię, więc wprowadzanie w nimzmian przychodzi im łatwiej. Z drugiej strony operatorzy robotów mają już niezawodne, dobrze przetestowane parsery i dopasowywacze (a Google udostępnił też swój własny parser pliku robots.txt w wersji open source). Oznacza to, że z dużą dozą prawdopodobieństwa nie wystąpią problemy z analizowaniem nowych reguł.
To samo dotyczy rozszerzeń do REP na poziomie identyfikatora URI, nagłówka HTTP X-robots-tag i jego odpowiednika w postaci metatagu. Jeśli potrzebujesz nowej reguły, która będzie zawierać preferencje dotyczące rezygnacji, możesz ją łatwo rozszerzyć. Ale jak?
Najważniejsze, co możesz zrobić, to mówić publicznie o swoim pomyśle i zbierać poparcie dla niego. Ponieważ REP jest standardem publicznym, żadna organizacja nie może wprowadzać w nim zmian jednostronnych. Oczywiście może wdrożyć obsługę czegoś nowego po swojej stronie, ale nie stanie się to standardem. Jednak omawianie tej zmiany i uświadamianie ekosystemowi – zarówno operatorom robotów, jak i ekosystemowi wydawniczemu – że przynosi ona korzyści wszystkim, pozwoli osiągnąć konsensus i utoruje drogę do aktualizacji standardu.
Podobnie, jeśli w protokole czegoś brakuje, powiedz o tym publicznie. sitemap
stało się powszechnie obsługiwaną regułą w pliku robots.txt, ponieważ było przydatne zarówno dla twórców treści, jak i wyszukiwarek. To otworzyło drogę do przyjęcia rozszerzenia. Jeśli masz nowy pomysł na regułę, zapytaj użytkowników pliku robots.txt i jego twórców, co sądzą o tym pomyśle, i wspólnie z nimi rozpatrzcie potencjalne (i prawdopodobne) problemy oraz opracuj propozycję.
Jeśli Twój sterownik ma służyć wspólnemu dobru, warto to zrobić.