Allow и Disallow в robots.txt: как проверить конфликт правил

Если страница открывается у посетителя, но робот считает её закрытой, перестановка строк в robots.txt обычно не поможет. Для Google и Яндекса среди подходящих правил выбранной группы действует более конкретное правило; при равной длине конфликтующих путей приоритет получает Allow.

Проверять нужно связку «точный URL — конкретный робот — полученный robots.txt». Ни разрешение обхода, ни ответ страницы 200 сами по себе не гарантируют попадание в поиск.

1. Зафиксируйте адрес и нужного робота

Запишите полный публичный URL, включая протокол, поддомен, регистр букв, завершающий слеш и параметры. Рядом укажите, для кого проверяете доступ: например, Googlebot или основной робот Яндекса.

Получите robots.txt именно проверяемого хоста. Файл на HTTPS и файл на HTTP, как и версии с www и без него, имеют отдельную область действия. Эта граница описана в документации Google.

Убедитесь, что загружен текст правил, а не HTML-заглушка или страница входа. Если файл недоступен, сначала разберите ошибку получения robots.txt: сравнивать приоритеты в недоставленном файле преждевременно.

2. Найдите применимую группу User-agent

Не собирайте все Disallow из файла в один список. Сначала определите группу нужного робота: у Google специальная группа Googlebot не дополняется правилами общей группы со звёздочкой.

Например:

User-agent: *
Disallow: /catalog/

User-agent: Googlebot
Allow: /catalog/

Для Googlebot каталог здесь разрешён. Проверка только общей группы даст ошибочный вывод. Для другого поисковика отдельно определите применимые группы по его документации и анализатору.

Если для Googlebot объявлено несколько подходящих специальных групп, Google объединяет их правила. Порядок выбора групп и их объединение объяснён в спецификации Google.

3. Выпишите все правила, совпавшие с URL

Рассмотрим условный каталог:

User-agent: *
Disallow: /catalog/
Allow: /catalog/help/
Disallow: /catalog/help/private/

Здесь результат зависит от адреса:

• /catalog/item/ — запрещён правилом Disallow: /catalog/;
• /catalog/help/payment/ — разрешён более длинным Allow: /catalog/help/;
• /catalog/help/private/note/ — снова запрещён ещё более конкретным правилом.

Это не последовательное выполнение команд сверху вниз. Перенос Allow в конец не отменит более длинный подходящий Disallow. Такой принцип и разрешение конфликта равной длины описаны у Яндекса.

Отдельный простой случай:

User-agent: *
Disallow: /catalog/help/
Allow: /catalog/help/

Одинаковые пути дают разрешение обхода. Однако такой дубль лучше убрать: при следующем изменении он затруднит чтение файла.

Проверьте границы совпадения

По RFC 9309 сравнение начинается с начала пути, учитывает регистр, а наиболее конкретное совпадение определяется по байтам. Для кириллицы и кодированных символов не стоит вручную считать видимые буквы: сравните результат в анализаторе.

Без указания конца правило работает как префикс. Поэтому Disallow: /sale затронет и /sale/, и /sales/. Запись Disallow: /sale/ уже не совпадёт с /sales/.

Звёздочка * обозначает произвольную последовательность символов, а $ — конец совпадения. Например, Disallow: /offer$ закрывает /offer, но не /offer/ и не /offer?src=test. Уберите или добавьте слеш и параметры в тестовом наборе, чтобы проверить именно нужную границу, а не похожий адрес.

4. Испытайте правку до замены файла

Сохраните рабочую версию и составьте небольшой набор проверок:

1. URL, который требуется открыть роботу.
2. Соседний публичный URL, который должен остаться открытым.
3. Технический URL, который должен остаться закрытым.
4. Вариант проблемного адреса со слешем или параметрами, если он используется на сайте.

Для каждой строки запишите ожидаемый результат и правило-победитель. Проверьте изменённый текст в анализаторе robots.txt Яндекс Вебмастера для нужного робота; для Google сверяйтесь с его правилами интерпретации.

Меняйте минимальный участок: например, уточните слишком широкий префикс или добавьте узкое исключение. Не снимайте общий запрет со всего каталога ради одной страницы без проверки остальных адресов.

После выкладки снова получите файл с публичного адреса и повторите набор тестов. Совпадение результата на локальной копии не подтверждает, что CMS или CDN уже выдаёт эту же версию. Если проблема возникла при смене сервера, пригодится сравнение robots.txt после переезда.

Что считать результатом проверки

Диагностика закончена, когда для каждого контрольного URL известны робот, полученный файл, применимая группа, совпавшие правила и итоговое разрешение. Сохраните этот набор для следующего релиза: он полезнее отметки «robots.txt проверен».

Если обход разрешён, а страница всё ещё отсутствует в поиске, отдельно проверьте noindex и canonical. Если требуется защитить личные данные, используйте авторизацию: robots.txt не ограничивает доступ посетителей.

Web-Puls помогает контролировать доступность публичного URL и ожидаемый текст в ответе, но не заменяет анализ приоритета правил поискового робота.

Следующий шаг — добавить сайт в мониторинг и включить в контроль публичный robots.txt после проверки его логики.