Спецификации файла robots.txt

О чем этот документ

Здесь описано, как Google обрабатывает файл robots.txt, с помощью которого можно контролировать сканирование и индексацию общедоступных сайтов поисковыми роботами Google.

Язык требований

Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL следует понимать так, как описано в документе RFC 2119.

Основные определения

  • Поисковый робот – это служба или агент, которые сканируют веб-сайты. Поисковый робот автоматически осуществляет рекурсивный доступ к известным URL хостов. Это должны быть страницы, доступные в обычном браузере. При обнаружении новых URL (например, с помощью ссылок на просканированных страницах или файлов Sitemap) их сканирование выполняется таким же образом.
  • Агент пользователя – средство идентификации отдельного поискового робота или целой группы.
  • Директивыв файле robots.txt– список действующих инструкций в файле robots.txt для одного или нескольких поисковых роботов.
  • URL – унифицированные адреса ресурсов, по стандарту RFC 1738.
  • Только для Google. Указанная информация касается особенностей обработки файла robots.txt поисковыми роботами Google. Она может быть неактуальна в других случаях.

Область применения

Инструкции, описанные в данном документе, выполняются всеми автоматическими поисковыми роботами Google. Они не учитываются в тех случаях, когда агент обращается к URL от имени пользователя (для перевода, при получении фидов, на которые была оформлена подписка, а также при анализе вредоносного ПО и т. д.).

Местоположение файла и диапазон действия

Файл robots.txt должен находиться в каталоге верхнего уровня хоста, доступного при указании соответствующего протокола и номера порта. Общепринятые протоколы для доступа к файлу robots.txt (и для сканирования веб-сайтов) – http и https. Получение файла robots.txt по этим протоколам осуществляется с помощью безусловного HTTP-запроса GET.

Только для Google. Google также принимает файлы robots.txt для FTP-серверов и выполняет указанные в них инструкции. Доступ к таким файлам robots.txt осуществляется через FTP-протокол с использованием анонимного способа входа.

Директивы, перечисленные в файле robots.txt, действительны только в отношении того хоста, протокола и номера порта, где расположен файл.

Примечание. URL файла robots.txt (как и другие URL) чувствителен к регистру.

Примеры действительных URL файла robots.txt:

URL файла robots.txtДействителен для Не действителен дляКомментарии
http://example.com/robots.txt http://example.com/
http://example.com/folder/file
http://other.example.com/
https://example.com/
http://example.com:8181/
Общий пример. Не действителен для других субдоменов, протоколов или номеров портов. Действителен для всех файлов во всех подкаталогах, относящихся к этому хосту, протоколу и номеру порта.
http://www.example.com/robots.txt http://www.example.com/ http://example.com/
http://shop.www.example.com/
http://www.shop.example.com/
Файл robots.txt, размещенный в определенном субдомене, действителен только для него.
http://example.com/folder/robots.txt Недействительный файл robots.txt   Поисковые роботы не осуществляют поиск файлов robots.txt в подкаталогах.
http://www.müller.eu/robots.txt http://www.müller.eu/
http://www.xn--mller-kva.eu/
http://www.muller.eu/ Эквивалентами IDN являются их варианты в пуникоде. См. также RFC 3492.
ftp://example.com/robots.txt ftp://example.com/ http://example.com/ Только для Google. Google использует файлы robots.txt для FTP-ресурсов.
http://212.96.82.21/robots.txt http://212.96.82.21/ http://example.com/ (даже при размещении на 212.96.82.21) Файл robots.txt, для которого в качестве имени хоста указан IP-адрес, действителен только при сканировании с указанием данного IP-адреса в качестве имени хоста. Он не будет автоматически применяться для всех веб-сайтов, размещенных по этому IP-адресу (хотя этот файл robots.txt может быть общим, и тогда он будет доступен также и по общему имени хоста).
http://example.com:80/robots.txt http://example.com:80/
http://example.com/
http://example.com:81/ Стандартные номера портов (80 для http, 443 для https, 21 для ftp) являются эквивалентами собственных имен хостов по умолчанию. См. также [номера портов].
http://example.com:8181/robots.txt http://example.com:8181/ http://example.com/ Файлы robots.txt, размещенные вне стандартных номеров портов, действительны только для контента, доступного по этим номерам портов.

Обработка кодов ответа HTTP

После чтения файла robots.txt поисковый робот получает одну из этих общих инструкций:

  • полный доступ – разрешение на сканирование всего содержания;
  • полный запрет – запрет на сканирование всего содержания;
  • частичный доступ – определение возможности сканирования содержания директивами в файле robots.txt.
2xx (успешно)
Коды ответов HTTP, свидетельствующие об успешном результате при сканировании с частичным доступом.
3xx (переадресация)
Обычно поисковый робот следует переадресации до тех пор, пока не будет получен действительный результат (или обнаружен цикл). Выполняется определенное количество повторений (RFC 1945 для HTTP/1.0 допускает до 5 повторений), затем цикл прекращается и регистрируется ошибка 404. Переадресации к заблокированным URL в robots.txt не выполняются. Обработка логических переадресаций к файлу robots.txt на основе HTML-содержания, возвращающего коды 2xx (переадресации на основе фреймов, JavaScript или метатегов обновления) не рассматривается. Этот метод не рекомендуется к использованию.
4xx (ошибки клиента)
Google расценивает все ошибки 4xx аналогично и предполагает, что действительный файл robots.txt отсутствует. При этом также предполагается, что ограничений в отношении содержания сайта нет, то есть разрешен полный доступ для сканирования. Учтите, что к этому разделу относятся коды ответа HTTP 401 "Требуется авторизация" и 403 "Доступ запрещен".
5xx (ошибка сервера)
Ошибки сервера расцениваются как временные, сканирование полностью запрещаетс. Запрос отправляется повторно до тех пор, пока не будет получен другой код ответа. При появлении ошибки 503 (недоступно) попытки будут повторяться достаточно часто. Для временной приостановки сканирования рекомендуется предоставлять код ответа HTTP 503. Обработка постоянной ошибки сервера не описана.

Только для Google. Если Google удается определить, что сайт настроен неправильно и отображает для отсутствующих страниц ошибку 5xx вместо 404, для этого сайта она будет обрабатываться как ошибка 404.
Неудачные запросы и неполные данные
Обработка файла robots.txt, который недоступен из-за проблем с DNS или сетью (тайм-аутов, неверных запросов, обрыва соединения, ошибок HTTP) не определена.
Кеширование
Ответ, полученный в результате запроса файла robots.txt, обычно хранится в кеше не более суток, но может быть доступен и дольше в тех случаях, когда обновить имеющуюся в кеше версию невозможно (например из-за истечения времени ожидания или ошибок 5xx). Сохраненный в кеше ответ может передаваться другим поисковым роботам. Google может увеличить или уменьшить срок действия кеша с учетом соответствующих HTTP-заголовков.

Формат файла

Файл должен содержать обычный текст в кодировке UTF-8, состоящий из записей (строк), разделенных символами возврата каретки, возврата каретки/перевода строки или перевода строки.

Выполняются только действительные записи, остальное содержание игнорируется. Например, при получении страницы HTML будут учитываться только действительные строки, а остальное содержание – игнорироваться без предупреждения или сообщения об ошибке.

При использовании кодировки, в которой присутствуют символы, не входящие в таблицу UTF-8, синтаксический анализ содержания файла может быть выполнен неправильно.

Отметка последовательности байтов (BOM) в начале файла robots.txt игнорируется. Добавлять ее не обязательно.

Каждая запись состоит из поля, двоеточия и значения. Использование пробелов не обязательно, но рекомендуется для удобства чтения. Комментарии могут размещаться в любом месте файла и должны обозначаться символом #. Все содержание, расположенное после этого знака до конца записи, расценивается как комментарий и игнорируется. Общий формат: "<поле>:<значение><#комментарий (не обязательно)>". Пробелы в начале и конце записи игнорируются.

Для элемента <поле> регистр не учитывается. Элемент <значение> может быть чувствительным к регистру (в зависимости от элемента <поле>).

Обработка элементов <поле> с простыми ошибками или опечатками (useragent вместо user-agent и т. п.) не описана. Некоторые агенты пользователя обрабатывают такие ошибки правильно.

Иногда поисковый робот не рассматривает файлы больше определенного размера. Не исключено, что контент, превышающий заданное значение, при сканировании будет пропущен. В настоящее время максимальный размер файла, установленный Google, составляет 500 КБ.

Формальный синтаксис и определение

Это описание в форме Бэкуса-Наура (BNF). В нем используются правила RFC 822. Единственное исключение: символ | применяется для обозначения альтернатив. Литералы заключаются в кавычки; круглые скобки ( и ) используются для группировки элементов, а [квадратные скобки] – для дополнительных элементов. Перед элементами может находиться <n>* для обозначения n или более повторов следующего элемента; значение n по умолчанию – 0.

robotstxt = *entries
entries = *( ( <1>*startgroupline
  *(groupmemberline | nongroupline | comment)
  | nongroupline
  | comment) )
startgroupline = [LWS] "user-agent" [LWS] ":" [LWS] agentvalue [comment] EOL
groupmemberline = [LWS] (
  pathmemberfield [LWS] ":" [LWS] pathvalue
  | othermemberfield [LWS] ":" [LWS] textvalue) [comment] EOL
nongroupline = [LWS] (
  urlnongroupfield [LWS] ":" [LWS] urlvalue
  | othernongroupfield [LWS] ":" [LWS] textvalue) [comment] EOL
comment = [LWS] "#" *anychar
agentvalue = textvalue

pathmemberfield = "disallow" | "allow"
othermemberfield = ()
urlnongroupfield = "sitemap"
othernongroupfield = ()

pathvalue = "/" path
urlvalue = absoluteURI
textvalue = *(valuechar | SP)
valuechar = <any UTF-8 character except ("#" CTL)>
anychar = <any UTF-8 character except CTL>
EOL = CR | LF | (CR LF)

Синтаксис для "absoluteURI", "CTL", "CR", "LF" и "LWS" определен в RFC 1945. Синтаксис для "path" – в RFC 1808.

Группировка записей

Существуют различные типы записей в зависимости от элемента <field>:

    • "начало группы";
    • "член группы";
    • "вне группы".

Все записи "член группы", расположенные между двумя записями "начало группы", обрабатываются совместно. Единственный элемент "начало группы" – user-agent. После записей "член группы" будет идти несколько строк "начало группы" подряд. Записи "член группы", перед которыми отсутствует "начало группы", будут проигнорированы. Все записи "вне группы" действительны и независимы.

Допустимые элементы <field>, которые будут рассмотрены далее в этом документе:

  • user-agent ("начало группы");
  • disallow (действительно только как "член группы");
  • allow (действительно только как "член группы");
  • sitemap ("вне группы").

Все остальные элементы <field> могут быть проигнорированы.

В элементе user-agent (начало группы) указывается, для какого поискового робота действительна эта группа. Для отдельного поискового робота действительна только одна группа записей. Их приоритет будет рассмотрен ниже в данном документе.

Примеры групп:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

user-agent: e
user-agent: f
disallow: /g

Определены три отдельные группы: первая для a, вторая для b, а третья для e и f. В каждой из них имеется запись "член группы". Обратите внимание, как использование дополнительных пробелов (пустых строк) упрощает чтение.

Приоритет для агентов пользователей

Для отдельного поискового робота действительна только одна группа записей "член группы". Чтобы определить ее, он должен найти группу, для которой указан наиболее строгий, но подходящий агент пользователя. Все остальные группы записей будут проигнорированы. В обозначении агента пользователя не учитывается регистр. Весь неподходящий текст игнорируется. Например, googlebot/1.2 и googlebot* аналогичны googlebot. Порядок групп в файле robots.txt не учитывается.

Пример.

Предположим, что есть следующий файл robots.txt:

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

Поисковый робот выберет нужную группу следующим образом:

Название поискового роботаВыполняемая группа записей Комментарии
Googlebot News (group 1) Выполняется только наиболее строгая группа записей, все остальные игнорируются.
Робот Googlebot (веб-поиск) (group 3) 
Googlebot Images (group 3) Отдельной группы googlebot-images нет, будет выбран более общий вариант.
Робот Googlebot для новостей (при сканировании изображений) (group 1) Будет учитываться только соответствующая группа.
Otherbot (веб-поиск)(group 2) 
Otherbot (для новостей)(group 2) Даже если имеется запись для этого робота, она действительна только при точном соответствии.

Также см. эту статью.

Записи "член группы"

В этом разделе рассматриваются только общие и созданные для Google типы записей. Они также называются директивами для поисковых роботов. Для таких записей используется формат "директива: [путь]", где [путь] указывать не обязательно. По умолчанию нет никаких ограничений по сканированию для обозначенных поисковых роботов. Директивы без элемента [путь] игнорируются.

Значение [путь], если оно указано, рассматривается в соответствии с веб-сайтом, для которого был получен файл robots.txt (используется тот же протокол, номер порта, хост и имена доменов). Значение пути должно начинаться с символа / для обозначения корневого каталога. Путь чувствителен к регистру. Подробнее читайте в разделе "Подбор URL с учетом значений пути" ниже.

disallow

Директива disallow определяет конкретные пути, которые должны быть недоступны указанным поисковым роботам. Если путь не указан, она игнорируется.

Использование:

disallow: [path]

allow

Директива allow определяет пути, которые должны быть доступны указанным поисковым роботам. Если путь не указан, она игнорируется.

Использование:

allow: [path]

Подбор URL с учетом значений пути

Значение пути используется для определения того, должно ли правило применяться к конкретному URL на сайте. За исключением подстановочных знаков путь должен совпадать с началом любого действующего и подходящего URL. Не 7-битные символы ASCII в пути могут быть добавлены как символы UTF-8 или как экранированные значения в кодировке UTF-8 (см. RFC 3986).

Примечание. Для URL, использующих схему сканирования AJAX, указывайте просканированные версии.

Google, Bing, Yahoo и Ask поддерживают определенные подстановочные знаки для значений путей. Вот их полный список:

  1. * обозначает 0 или более экземпляров любого действительного символа.
  2. $ обозначает конец URL.

Примеры

ПутьСоответствует Не соответствуетКомментарии
/любой действительный URL  Соответствует корневому каталогу и всем URL более низкого уровня.
/*эквивалент / эквивалент / Эквивалент символа /, завершающий подстановочный знак игнорируется.
/fish/fish
/fish.html
/fish/salmon.html
/fishheads
/fishheads/yummy.html
/fish.php?id=anything
/Fish.asp
/catfish
/?id=fish
Обратите внимание на то, что регистр учитывается.
/fish*/fish
/fish.html
/fish/salmon.html
/fishheads
/fishheads/yummy.html
/fish.php?id=anything
/Fish.asp
/catfish
/?id=fish
Эквивалент "/fish", завершающий подстановочный знак игнорируется.
/fish//fish/
/fish/?id=anything
/fish/salmon.htm
/fish
/fish.html
/Fish/Salmon.asp
Начальная косая черта означает, что соответствуют все элементы в этой папке.
/*.php/filename.php
/folder/filename.php
/folder/filename.php?parameters
/folder/any.php.file.html
/filename.php/
/ (даже если это /index.php)
/windows.PHP
 
/*.php$/filename.php
/folder/filename.php
/filename.php?parameters
/filename.php/
/filename.php5
/windows.PHP
 
/fish*.php/fish.php
/fishheads/catfish.php?parameters
/Fish.PHP  

Записи вне групп, поддерживаемые Google

sitemap

Поддерживается Google, Ask, Bing и Yahoo. Описание см. на сайте sitemaps.org.

Использование:

sitemap: [absoluteURL]

[absoluteURL] указывает на карту сайта, ее указатель или другой соответствующий URL, хост которого не обязательно должен быть тем же, что и у файла robots.txt. Записей sitemap может быть несколько. Поскольку записи не входят в группы, они не связаны с определенными агентами пользователя и доступны для всех поисковых роботов, которые не заблокированы.

Порядок приоритетности для записей вне групп

На уровне группы, в частности для директив allow и disallow, самое строгое правило, учитывающее длину записи [путь], будет важнее менее строгого и более короткого правила. Порядок очередности правил с подстановочными знаками не определен.

Примеры ситуаций:

URLallow:disallow:Вердикт Комментарии
http://example.com/page /p /allow 
http://example.com/folder/page /folder/ /folderallow 
http://example.com/page.htm /page /*.htmundefined 
http://example.com/ /$ /allow 
http://example.com/page.htm /$ /disallow 

Оставить отзыв о...

Текущей странице