Робот получает 403 или 429: как найти блокировку

Когда поисковый робот получает 403 или 429, разрешение в robots.txt не решает проблему. Нужно найти слой, который возвращает отказ: CDN, WAF, веб-сервер или приложение. Начните с времени запроса, адреса страницы и записи в журнале защиты.

403 и 429 требуют разных исправлений

403 означает отказ в доступе. Причиной может быть правило по IP, стране, заголовкам или сессии. 429 означает ограничение частоты запросов. Сервер может передать Retry-After, чтобы указать время ожидания. Код ответа не объясняет, какое именно правило сработало: это выясняют по конфигурации и журналам.

В локальном анализаторе логов найдите пути с такими ответами. Отдельно посмотрите карточки, категории, robots.txt, sitemap и ресурсы JavaScript. Если HTML доступен, а файл приложения получает отказ, отрисованная страница может оказаться неполной.

Убедитесь, что запрос действительно от поисковика

Надпись Googlebot в User-Agent не подтверждает отправителя. Для Google используйте опубликованные категории IP или обратный DNS с проверкой допустимого домена и последующим прямым разрешением имени обратно в исходный IP. Проверка только части имени вроде «google» ненадёжна.

Для другого поисковика применяйте его способ проверки, а не список Google. Не давайте неограниченный доступ всем адресам облачного провайдера: в одной сети могут работать и обычные приложения.

Порядок расследования

1. Сохраните проблемный URL, время с часовым поясом и HTTP-код из панели поисковика или лога.
2. Найдите запрос на внешнем слое. При CDN origin может вообще не получить заблокированный запрос; пустой access-лог приложения не доказывает отсутствие проблемы.
3. Сопоставьте идентификатор запроса с событием WAF. Зафиксируйте правило, действие и основание срабатывания.
4. Проверьте подлинность бота. Затем определите минимальное исключение: конкретное правило, необходимые пути и подтверждённая группа клиентов.
5. Повторно проверьте ответ, а затем дождитесь фактического запроса поисковика. Сравните ошибки и время ответа до и после правки.

Пример: каталог доступен людям, но закрыт роботу

Учебная ситуация: в журнале CDN несколько запросов к категориям получили 403 после включения проверки браузера. Обычный посетитель проходит JavaScript-проверку, а робот — нет. На origin все видимые запросы имеют 200, потому что отказ произошёл раньше.

Правильное действие — проверить правило CDN и доступ подтверждённого робота к публичному каталогу. Неправильное — выключить WAF целиком или открыть административную панель для любого User-Agent с названием поисковика. После изменения проверяют не только статус, но и тело: страница проверки с ответом 200 всё ещё не является карточкой товара.

Что делать с ограничением частоты

Посмотрите, по какому ключу считается лимит: IP, сессия, путь или весь сайт. За обратным прокси все запросы иногда ошибочно считаются одним клиентом. Настройку доверенных прокси проверяют вместе с защитой от поддельного X-Forwarded-For; доверять этому заголовку от любого посетителя нельзя.

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

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

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

Поможет ли Allow в robots.txt?

Только если проблема в запрете обхода. WAF и ограничения веб-сервера действуют независимо. Сначала определите источник отказа.

Какие доказательства передать администратору

Сообщение «Google не видит сайт» слишком широкое для исправления. Подготовьте несколько строк: публичный URL, точное время с часовым поясом, ожидаемое содержимое, полученный код, слой отказа и результат проверки IP. Если есть request ID, добавьте его. Секретные заголовки, cookies администратора и полный журнал посетителей для этой задачи не нужны.

Приложите название сработавшего правила и его действие, если у вас есть доступ к панели защиты. Отметьте, воспроизводится ли проблема на всех категориях или только на конкретном параметре. Это помогает выбрать минимальное изменение. Например, исключение одного параметра из проверки может быть точнее, чем исключение всей папки каталога.

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

Как отличить единичный отказ от системной проблемы

Сравнивайте долю ошибок внутри одинаковой группы запросов и периода. Десять отказов на десять запросов категории и десять на миллион запросов всего сайта — разные ситуации. Не делите ошибки Googlebot на все запросы пользователей: знаменатель должен соответствовать вопросу анализа.

Посмотрите распределение по времени. Короткая серия 429 во время импорта каталога может указывать на конкуренцию за ресурсы, а постоянные 403 сразу после включения нового правила — на конфигурацию защиты. Такое совпадение ещё не доказывает причину, но даёт проверяемую гипотезу. Меняйте один существенный параметр за раз и сохраняйте конфигурацию до изменения.

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

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

Документация и проверка форматов

• Google: проверка роботов
• HTTP 429

Документация проверена 18 октября 2026 года.