Перейти к содержимому
Ответственное использование

robots.txt, правила сервиса и разрешение на автоматизацию

Robots Exclusion Protocol сообщает пожелания владельца по обходу URI, но сам стандарт прямо говорит: это не механизм авторизации и не защита закрытых данных.

2 мин чтенияПроверено и обновлено: 6 августа 2026 г.

Главное за минуту

  • Разрешение определяют договор, правила сервиса и согласованный scope.
  • Неопределённость трактуется как запрет до уточнения.
  • Редирект на новый домен требует новой проверки scope.
  • Версия robots.txt входит в доказательства конкретного запуска.

Роль robots.txt

Файл задаёт Allow и Disallow для crawler user-agent и помогает снизить нежелательный обход. Публикация пути в нём не делает путь закрытым.

Парсер должен получать robots.txt по стандартному пути, учитывать код ответа, редиректы, кодировку и наиболее специфичное совпадение. Кэшируйте правила ограниченное время и повторно загружайте их по расписанию. Даже строка Allow не заменяет условия использования сайта: она описывает поведение crawler, а не коммерческие права на данные.

Письменный scope

Для тестирования и автоматизации фиксируют домены, IP-диапазоны, методы, окна времени, лимиты, разрешённые учётные записи и запрещённые действия.

Храните scope в машинно-проверяемом виде: точные FQDN, методы, пути, аккаунты, окна, максимальную частоту и дату окончания разрешения. Wildcard допускайте только после отдельного одобрения. Если редирект ведёт на другой домен, automation должна остановиться до проверки, входит ли новое назначение в согласованные границы.

Остановка по сигналу

429, явный запрет, рост ошибок, неожиданная авторизация или выход за согласованный домен должны останавливать сценарий и вызывать проверку человеком.

Стоп-условия сделайте техническими: доля 5xx, 429, неожиданный 401 или 403, рост времени ответа, изменение схемы API и выход за список путей. Остановка должна сохранять checkpoint и причину без автоматического переключения IP. Возобновление выполняет ответственный после подтверждения владельца ресурса или устранения собственной ошибки.

Аудит выполнения

Каждый запуск связывают с владельцем, версией задания, временем и результатом. Это помогает доказать соблюдение границ и расследовать сбой.

Для каждого цикла создавайте run ID и сохраняйте версию scope, robots.txt, программы и лимитов, а также агрегированное число запросов и исход. Не храните скачанное содержимое дольше цели. При споре журнал должен показать, что система проверяла границы перед запросом, а не пыталась получить запрещённый ресурс.

Практический чек-лист

  1. 1Получите подтверждение владельца ресурса.
  2. 2Зафиксируйте разрешённые цели и методы.
  3. 3Добавьте автоматические стоп-условия.
  4. 4Сохраняйте версию scope и правил для каждого run ID.
  5. 5Останавливайте переходы на домены вне списка.

Источники и документы

Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.

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

  1. 1.RFC Editor / IETF: RFC 9309: Robots Exclusion Protocol
  2. 2.OWASP Foundation: APTS Scope Enforcement
  3. 3.Президент России: Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»

Продолжить чтение

Материалы по близкой теме

Персональные данные

Минимизация персональных данных в сервисе прокси

Читать

Правовые основы

Политика обработки, согласие и договор: разные основания

Читать

Инфраструктура и право

Локализация и трансграничная передача данных: карта маршрута

Читать