Автоматизированные
краулеры Google
поддерживаютПротокол исключения роботов (REP)
.
Это означает, что перед сканированием сайта краулеры Google загружают и анализируют файл robots.txt сайта, чтобы извлечь информацию о том, какие части сайта можно сканировать. REP не применяется к краулерам Google, управляемым пользователями (например, подписки на фиды), или краулерам, используемым для повышения безопасности пользователей (например, анализ вредоносного ПО).
На этой странице описывается интерпретация REP компанией Google. С оригинальным стандартом можно ознакомиться в.
RFC 9309
Что такое файл robots.txt
Если вы не хотите, чтобы краулеры получали доступ к разделам вашего сайта, вы можете создать файл robots.txt с соответствующими правилами. Файл robots.txt — это текстовый файл, содержащий правила о том, какие краулеры могут получать доступ к каким частям сайта. Например, файл robots.txt для example.com может выглядеть следующим образом:
Если вы новичок в работе с robots.txt, начните с нашейвводной информации по robots.txt
. Вы также можете найти.
советы по созданию файла robots.txt
Расположение файла и область действия Вы должны разместить файл robots.txt в корневом каталоге сайта по поддерживаемому протоколу. URL-адрес файла robots.txt (как и другие URL-адреса) чувствителен к регистру. В случае Google Search поддерживаемыми протоколами являются HTTP, HTTPS и FTP. По протоколам HTTP и HTTPS краулеры запрашивают файл robots.txt с помощью безусловного запроса HTTP GET ; по FTP краулеры используют стандартную команду RETR (RETRIEVE)
с использованием анонимного входа.
Правила, перечисленные в файле robots.txt, применяются только к хосту, протоколу и номеру порта, на которых размещен файл robots.txt.
Примеры действительных URL-адресов robots.txt
| В следующей таблице приведены примеры URL-адресов robots.txt и пути URL, для которых они действительны. В первом столбце указан URL-адрес файла robots.txt, а во втором — домены, к которым этот файл robots.txt применялся бы или не применялся бы. | |
|---|---|
Примеры URL-адресов Robots.txt | https://example.com/robots.txt Это общий случай. Он недействителен для других поддоменов, протоколов или номеров портов. Он действителен для всех файлов во всех подкаталогах на том же хосте, протоколе и номере порта.
https://example.com/folder/file
|
https://example.com:8181/ | https://www.example.com/robots.txt Файл robots.txt на поддомене действителен только для этого поддомена. https://www.example.com/
|
https://example.com/folder/robots.txt | Недействительный файл robots.txt. Кроулеры не проверяют наличие файлов robots.txt в поддиректориях. |
https://www.exämple.com/robots.txt | IDN эквивалентны их пуникод-версиям. См. также Действительно для:
Недействительно для: |
ftp://example.com/robots.txt | Действительно для: Недействительно для: |
https://212.96.82.21/robots.txt | Файл robots.txt с IP-адресом в качестве имени хоста действителен только для сканирования этого IP-адреса как имени хоста. Он не распространяется автоматически на все веб-сайты, размещенные на этом IP-адресе (хотя возможно, что файл robots.txt является общим, и в этом случае он также будет доступен под общим именем хоста). Действительно для: Недействительно для: |
https://example.com:443/robots.txt | Стандартные номера портов ( Действительно для:
Недействительно для: |
https://example.com:8181/robots.txt | Файлы robots.txt на нестандартных номерах портов действительны только для контента, доступного через эти номера портов. Действительно для: Недействительно для: |
Обработка ошибок и кодов состояния HTTP
При запросе файла robots.txt код состояния HTTP ответа сервера влияет на то, как файл robots.txt будет использоваться поисковыми роботами Google. В следующей таблице обобщено, как Googlebot обрабатывает файлы robots.txt для различных кодов состояния HTTP.
| Обработка ошибок и кодов состояния HTTP | |
|---|---|
2xx (успешно) | Коды состояния HTTP, сигнализирующие об успехе, побуждают роботов Google обрабатывать файл robots.txt в том виде, в каком он предоставлен сервером. |
3xx (перенаправление) | Google следует как минимум пяти перенаправлениям (хопам), как определено в Google не следует логическим перенаправлениям в файлах robots.txt (фреймы, JavaScript или |
4xx (ошибки клиента) | Роботы Google обрабатывают все |
5xx (ошибки сервера) | Если Google находит файл robots.txt, но не может его получить, Google ведет себя следующим образом:
|
| Другие ошибки | Файл robots.txt, который не может быть получен из-за проблем с DNS или сетью, таких как тайм-ауты, недействительные ответы, сброшенные или прерванные соединения и ошибки фрагментации HTTP, обрабатывается как ошибка сервера. |
Кэширование
Google обычно кэширует содержимое файла robots.txt на срок до 24 часов, но может кэшировать его дольше в ситуациях, когда обновление кэшированной версии невозможно (например, из-за тайм-аутов или 5xx ошибок). Кэшированный ответ может совместно использоваться различными роботами.
Google может увеличивать или уменьшать время жизни кэша на основе
max-age Cache-Control
HTTP-заголовки.
Формат файла
Файл robots.txt должен быть
UTF-8 закодированным текстовым файлом, а строки должны разделяться CR, CR/LF, или
LF.
Google игнорирует недействительные строки в файлах robots.txt, включая
Маркер последовательности байтов
(BOM) в начале файла robots.txt, и использует только действительные строки. Например, если загруженный контент представляет собой HTML вместо правил robots.txt, Google попытается проанализировать контент, извлечь правила и проигнорировать все остальное.
Аналогично, если кодировка символов файла robots.txt не UTF-8, Google может проигнорировать символы, не входящие в диапазон UTF-8, что потенциально может сделать правила robots.txt недействительными.
Google устанавливает лимит размера файла robots.txt в 500
кибибайт (KiB). Контент, находящийся после максимального размера файла, игнорируется. Вы можете уменьшить размер файла robots.txt, объединив правила, которые привели бы к созданию слишком большого файла robots.txt. Например, поместите исключенный материал в отдельную директорию.
Синтаксис
Действительная строка robots.txt состоит из поля, двоеточия и значения. Имена полей нечувствительны к регистру (например, User-agent и user-agent обрабатываются одинаково). Пробелы необязательны, но рекомендуются для улучшения читаемости. Пробелы в начале и в конце строки игнорируются. Чтобы добавить комментарии, поставьте перед комментарием
# символ. Имейте в виду, что все, что находится после # символа, будет проигнорировано. Общий формат:
<field>:<value><#optional-comment>.
Google поддерживает следующие поля (другие поля, такие как crawl-delay , не поддерживаются):
user-agent: определяет, к какому краулеру применяются правила.allow: путь URL, который разрешено сканировать.disallow: путь URL, который запрещено сканировать.sitemap: полный URL файла sitemap.
The allow и disallow поля также называются правилами (также известными как
директивы). Эти правила всегда задаются в виде
правило: [path] где [path] необязательно. По умолчанию нет никаких ограничений на сканирование для указанных сканеров. Сканеры игнорируют правила без
[path].
Значение [path] , если оно указано, отсчитывается от корня веб-сайта, с которого был загружен файл robots.txt (с использованием того же протокола, номера порта, хоста и доменных имен). Значение пути должно начинаться с / чтобы указать корень, и значение чувствительно к регистру. Узнать больше о
сопоставлении URL на основе значений путей.
user-agent
Строка user-agent определяет, к каким сканерам применяются правила. См.
Сканеры Google и строки user-agent
для получения полного списка строк user-agent, которые вы можете использовать в своем файле robots.txt.
И имя поля user-agent , и его значение не зависят от регистра.
disallow
Правило disallow определяет пути, к которым не должны иметь доступ сканеры, определяемые строкой user-agent , с которой сгруппировано правило disallow .
Сканеры игнорируют правило без пути.
Google не может индексировать содержимое страниц, сканирование которых запрещено, но он все равно может индексировать URL-адрес и показывать его в результатах поиска без фрагмента. Узнайте, как
заблокировать индексацию.
Имя поля (disallow) не зависит от регистра, но его значение чувствительно к регистру.
Использование:
allow
Правило allow определяет пути, к которым разрешен доступ указанным сканерам. Если путь не указан, правило игнорируется.
Имя поля (allow) нечувствителен к регистру, но его значение чувствительно к регистру.
Использование:
sitemap
Google, Bing и другие основные поисковые системы поддерживают поле sitemap в файле
robots.txt, как определено в sitemaps.org.
Имя поля (sitemap) нечувствительно к регистру, но его значение чувствительно к регистру.
Использование:
Строка [absoluteURL] указывает на расположение файла sitemap или индексного файла sitemap. Это должен быть полный URL-адрес, включая протокол и хост, и он не обязательно должен быть URL-кодирован. URL-адрес не обязательно должен находиться на том же хосте, что и файл robots.txt. Вы можете указать несколько полей sitemap без ограничений на количество включаемых sitemap. Поле sitemap не привязано к какому-либо конкретному агенту пользователя и может обрабатываться всеми краулерами при условии, что его обход не запрещен.
Например:
Группировка строк и правил
Вы можете сгруппировать правила, применяемые к нескольким агентам пользователя, повторяя строки
user-agent для каждого краулера.
Например:
В этом примере есть четыре отдельные группы правил:
- Одна группа для агента пользователя “a”.
- Одна группа для агента пользователя “b”.
- Одна группа для агентов пользователей “e” и “f”.
- Одна группа для агента пользователя “h”.
Техническое описание группы см. в
разделе 2.1 REP.
Порядок старшинства для агентов пользователя
Для конкретного краулера действительна только одна группа. Краулеры Google определяют правильную группу правил, находя в файле robots.txt группу с наиболее специфичным агентом пользователя, который соответствует агенту пользователя краулера. Другие группы игнорируются. Весь текст, не соответствующий условиям, игнорируется (например, и googlebot/1.2 и googlebot* эквивалентны googlebot). Порядок групп внутри файла robots.txt не имеет значения.
Если для агента пользователя объявлено более одной специфичной группы, все правила из групп, применимых к конкретному агенту пользователя, внутренне объединяются в одну группу. Группы, специфичные для агента пользователя, и глобальные группы (*) не объединяются.
Примеры
Сопоставление полей user-agent
Вот как сканеры выберут соответствующую группу:
| Группа, за которой следует сканер | |
|---|---|
| Googlebot News | googlebot-news следует группе 1, поскольку группа 1 является наиболее специфичной. |
| Googlebot (веб) | googlebot следует группе 3. |
| Googlebot Storebot | Storebot-Google следует группе 2, поскольку нет конкретной группыStorebot-Google |
| Googlebot News (при сканировании изображений) | При сканировании изображений googlebot-news следует группе 1.googlebot-news не сканирует изображения для Google Картинок, поэтому он следуеттолько группе 1. |
| Otherbot (веб) | Другие сканеры Google следуют группе 2. |
| Otherbot (новости) | Другие сканеры Google, которые сканируют новостной контент, но не идентифицируют себя какgooglebot-news следуют группе 2. Даже если есть запись для связанного сканера, она действительна только в том случае, если она точно совпадает. |
Группировка правил
Если в файле robots.txt имеется несколько групп, относящихся к определенному user-agent,
сканеры Google объединяют эти группы внутри себя. Например:
Сканеры внутренне группируют правила на основе user-agent, например:
Правила, отличные от allow, disallow, и user-agent ,
игнорируются парсером robots.txt. Это означает, что следующий фрагмент robots.txt рассматривается
как одна группа, и таким образом, как user-agent a , так и b находятся под влиянием disallow: / rule:
Когда сканеры обрабатывают правила robots.txt, они игнорируют sitemap строку.
Например, вот как сканеры восприняли бы предыдущий фрагмент robots.txt:
Сопоставление URL на основе значений путей
Google использует значение пути в правилах allow и disallow в качестве основы для определения того, применяется ли правило к конкретному URL на сайте. Это работает путем сравнения правила с компонентом пути URL, который сканер пытается получить.
Путь в правилах может состоять либо из необработанных символов UTF-8, либо из строк UTF-8 с процентным кодированием
(согласно RFC 3986).
Как определено в RFC 9309 Section 2.2.2,
сканеры Google сравнивают правила с URL-адресами, используя их формы с процентным кодированием, и автоматически приводят необработанные пути правил UTF-8 к формам с процентным кодированием. Это означает, например, что
Disallow: /foo/bar/ツ и Disallow: /foo/bar/%E3%83%84 обрабатываются синтаксическим анализатором одинаково.
Google, Bing и другие основные поисковые системы поддерживают ограниченную форму wildcards для значений путей. Эти символы подстановки:
*означает 0 или более вхождений любого допустимого символа.$означает конец URL.
В следующей таблице показано, как различные символы подстановки влияют на синтаксический анализ:
| Примеры совпадений путей | |
|---|---|
/ | Соответствует корню и любому URL более низкого уровня. |
/* | Эквивалентно /. Замыкающий символ подстановки игнорируется. |
/$ | Соответствует только корню. Сканирование любых URL более низкого уровня разрешено. |
/fish | Соответствует любому пути, начинающемуся с Соответствует:
Не соответствует:
|
/fish* | Эквивалентно: Соответствует:
Не соответствует:
|
/fish/ | Соответствует всему в папке Соответствует:
Не соответствует:
|
/*.php | Соответствует любому пути, содержащему Соответствует:
Не совпадает:
|
/*.php$ | Совпадает с любым путем, который заканчивается на Совпадает:
Не совпадает:
|
/fish*.php | Совпадает с любым путем, который содержит Совпадает:
Не совпадает:
|
Порядок приоритета правил
При сопоставлении правил robots.txt с URL-адресами краулеры используют наиболее специфичное правило на основе длины пути правила. В случае конфликтующих правил, включая правила с подстановочными знаками, Google использует наименее ограничивающее правило.
Следующие примеры демонстрируют, какое правило краулеры Google применят к заданному URL-адресу.
| Примеры ситуаций | |
|---|---|
https://example.com/page | Применимое правило: |
https://example.com/folder/page | Применимое правило: |
https://example.com/page.htm | Применимое правило: |
https://example.com/page.php5 | Применимое правило: |
https://example.com/ | Применимое правило: |
https://example.com/page.htm | Применимое правило: |
Как мы это применяем
The formal specification resolves the arguments that the introductory guide leaves open, particularly around precedence and wildcards. We cite it directly when a developer and an SEO disagree about whether a rule applies.
Связанные услуги