Сначала подтвердите источник запроса
Для ручной проверки Яндекс описывает обратный DNS-запрос по адресу из журнала, проверку принадлежности полученного имени и затем прямой DNS-запрос. Исходный IP должен присутствовать среди адресов этого имени. Проверять только похожую строку домена недостаточно.
Google публикует способы проверки своих запросов, включая DNS и списки диапазонов для разных категорий роботов и загрузчиков. Используйте актуальный официальный источник для нужной категории; не переносите случайный список IP из старой статьи.
- Берите реальный адрес клиента из доверенной цепочки прокси, а не произвольный заголовок запроса.
- Различайте основной индексирующий робот, служебную проверку и загрузчик, запущенный пользователем.
- Не создавайте глобальное разрешение по User-Agent или всей сети без предусмотренной проверки.
Проверьте весь путь получения страницы
Ответ 200 ещё не доказывает, что робот увидел нужную страницу: вместо материала сервер может вернуть проверку браузера, пустую оболочку или общую страницу ошибки. Проверьте основной текст, заголовок и ссылки, затем стили, скрипты и изображения, необходимые для отображения.
Защита и правила индексации решают разные задачи. robots.txt управляет обходом, а не подтверждает личность робота и не защищает приватные данные. Если страница должна быть публичной, люди и поиск должны получать один основной материал.
- Выберите по одной странице каждого существенного типа: главная, решение, инструкция и документ.
- Проверьте HTTPS, цепочку перенаправлений и конечный HTTP-ответ.
- Убедитесь, что в ответе есть содержание выбранной страницы, а не сообщение о проверке.
- Проверьте доступ к нужным ресурсам и отсутствие противоречащих друг другу запретов обхода и индексации.
Отличайте проверочный запрос от настоящего обхода
Запрос с подставленным User-Agent полезен для отрицательной проверки: защита не должна считать его настоящим роботом только по имени. Но успешный ответ на такой запрос не подтверждает доступ реального поисковика.
Инструменты Вебмастера и Search Console дают дополнительную проверку доступности. После неё ищите в журнале реальные подтверждённые обращения нужного индексирующего робота. Если их ещё не было, так и фиксируйте: локальная проверка пройдена, настоящий обход пока не наблюдался.
| Наблюдение | Что оно подтверждает |
|---|---|
| Обычный браузер открыл страницу | Доступность для этого посетителя в этот момент. |
| Запрос с именем робота получил ответ | Поведение запроса с указанным заголовком, но не принадлежность поисковику. |
| Служебная проверка поисковика успешна | Доступ проверочного загрузчика в условиях проверки. |
| В журнале есть подтверждённый индексирующий робот | Факт его обращения и полученного ответа, но не решение включить URL в индекс. |
Исправляйте конкретное препятствие
При 403, 429, проверке браузера или ошибке сервера найдите причину и правило, действовавшее на этот запрос. Проблема может быть в лимите, WAF, настройке маршрута, TLS или недоступном origin. Отключение всей защиты скрывает причину и редко является хорошим постоянным решением.
В RoboGuard проверенные роботы и исключения должны соответствовать действующей политике сайта. Неизвестный источник может идти по обычным правилам до подтверждения. После публикации изменения проверяйте применённое состояние, а затем повторный доступ к странице и её ресурсам.
Контролируйте доступность после изменения
Сохраните URL, время проверки, ответ сервера и причину изменения. При следующем реальном обходе убедитесь, что исправление сработало и не ухудшило обычный пользовательский сценарий. Повторять все проверки без изменения условий не требуется.
Доступность — необходимое условие поиска, но не обещание индексации или высоких позиций. Если робот получает правильный материал, дальнейшие причины исключения разбираются по данным поисковой системы: canonical, дубли, качество и другие указанные ею обстоятельства.