Формализация спецификации протокола исключения роботов

Понедельник, 1 июля 2019 г.

В течение 25 лет протокол исключения роботов (REP) был одним из самых базовых и критически важных компонентов сети. Он позволяет владельцам веб-сайтов запрещать автоматизированным клиентам, например
веб-краулерам, доступ к своим сайтам — частично или полностью.

В 1994 году Martijn Koster
(сам веб-мастер) создал первоначальный стандарт после того, как краулеры стали перегружать его сайт. Благодаря дополнительным отзывам от других веб-мастеров появился REP, который был принят поисковыми системами, чтобы помочь владельцам сайтов проще управлять своими серверными ресурсами.

Однако REP так и не был превращен в официальный
интернет-стандарт, что означает,
что разработчики с годами интерпретировали протокол несколько по-разному. И с момента своего
появления REP не обновлялся для учета современных крайних случаев. Это сложная
проблема для владельцев сайтов, потому что двусмысленный де-факто стандарт затруднял правильное написание
правил.

Мы хотели помочь владельцам сайтов и разработчикам создавать потрясающие возможности в интернете вместо
того, чтобы беспокоиться о том, как управлять краулерами. Вместе с первоначальным автором протокола,
веб-мастерами и другими поисковыми системами мы задокументировали то, как REP используется в современном интернете, и
передали его в IETF.

Предложенный проект REP отражает более чем 20-летний практический опыт использования правил robots.txt, применяемых как Googlebot, так и другими крупными краулерами, а также примерно полумиллиардом веб-сайтов, которые полагаются на REP. Эти детализированные элементы управления дают издателю возможность решать, что именно на его сайте должно сканироваться и потенциально показываться заинтересованным пользователям. Он не изменяет
правила, созданные в 1994 году, а скорее определяет практически все неопределенные сценарии для синтаксического анализа и сопоставления robots.txt, а также расширяет его для современного веба. В частности:

1. Любой
   протокол передачи на основе URI
   может использовать robots.txt. Например, он больше не ограничивается HTTP и может использоваться также для FTP или
   CoAP
   .
2. Разработчики должны обрабатывать как минимум первые 500
   кибибайт файла robots.txt.
   Определение максимального размера файла гарантирует, что соединения не остаются открытыми слишком долго, уменьшая
   ненужную нагрузку на серверы.
3. Новое максимальное время кэширования в 24 часа или значение директивы кэша, если оно доступно, дает владельцам сайтов гибкость в обновлении robots.txt в любое время, при этом краулеры не перегружают веб-сайты запросами robots.txt. Например, в случае с HTTP для определения времени кэширования могут использоваться заголовок Cache-Control.
4. Теперь спецификация предусматривает, что если ранее доступный файл robots.txt становится недоступным из-за сбоев сервера, известные запрещенные страницы не сканируются в течение разумно длительного периода времени.

Кроме того, мы обновили
расширенную форму Бэкуса-Наура
в интернет-черновике, чтобы лучше определить синтаксис robots.txt, что крайне важно для разработчиков при разборе строк.

RFC означает Request for Comments (запрос комментариев), и мы действительно так считаем: мы загрузили черновик в IETF, чтобы получить отзывы от разработчиков, которым важны базовые строительные блоки интернета. Поскольку мы работаем над тем, чтобы предоставить создателям веб-сайтов элементы управления, необходимые для того, чтобы сообщать нам, какой объем информации они хотят сделать доступным для Googlebot и, как следствие, иметь право появляться в Поиске, мы должны убедиться, что делаем все правильно.

Если вы хотите оставить нам комментарий, задать вопросы или просто поздороваться, вы можете найти нас в
Twitter и в нашем
сообществе веб-мастеров, как офлайн , так и онлайн.

Опубликовано Henner Zeller,
Lizzi Sassman, и
Gary Illyes