Настоящий ли Googlebot в логах: как проверить запросы

Чтобы проверить Googlebot в логах, сначала установите реальный адрес источника запроса, затем подтвердите происхождение по официальной процедуре Google. Строки User-Agent недостаточно. Для ручной проверки сопоставляют обратное DNS-имя и прямое разрешение обратно в исходный IP, а при автоматизации используют соответствующие опубликованные диапазоны.

Первый вопрос — чей адрес вы проверяете

Если перед сервером стоит CDN или обратный прокси, адрес соединения в журнале может принадлежать этому промежуточному узлу. Проверка такого IP отвечает на вопрос о прокси, а не об исходном посетителе. Поэтому начните с описания пути запроса и смысла поля журнала.

В документации Cloudflare о заголовках CF-Connecting-IP описан как адрес клиента, передаваемый от сети Cloudflare к исходному серверу. Но в своей инфраструктуре нужно отдельно проверить доверенную цепочку. Название заголовка само по себе не делает произвольное полученное значение подтверждённым адресом клиента.

В инструкции восстановления IP Cloudflare приведены настройки доверенных прокси. Не копируйте их вслепую в работающий сервер. Для текущей задачи достаточно выяснить, откуда взят проверяемый адрес и почему этому источнику можно доверять.

Как выглядит ручное подтверждение

1. Возьмите IP из проверенного поля журнала и сохраните соответствующее событие. Не подставляйте адрес CDN вместо исходного клиента.
2. Выполните обратное DNS-разрешение этого адреса. Установите полное полученное имя, а не только наличие слова Google.
3. Сопоставьте имя с официальными правилами для предполагаемой категории загрузчика. Проверяйте доменную границу, а не произвольное вхождение строки.
4. Разрешите полученное имя прямым DNS-запросом. Среди полученных адресов должен быть исходный проверяемый IP.
5. Сохраните результат, время и использованное основание. Ошибку или недоступность проверки отметьте отдельно от подтверждённого несоответствия.

Этот порядок основан на документации Google по проверке запросов. Она различает основные роботы, специальные загрузчики и запросы, запускаемые пользователями. Поэтому правило для обычного Googlebot нельзя без проверки распространять на любое обращение, связанное с инфраструктурой Google.

Таблица решений по наблюдаемым данным

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

Почему поиск слова в имени недостаточен

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

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

Автоматическая проверка тоже требует правильного входа

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

Для администрирования сервера составьте небольшое описание: где завершается внешнее соединение, какие узлы доверены и какое поле использует анализатор. Оно полезнее длинного списка разрешённых адресов без объяснения. При изменении CDN это описание пересматривают вместе с форматом логов.

Подтверждённый робот не получает неограниченный доступ

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

В SEO-проверке сопоставляйте подтверждённые обращения с URL и ответами сервера. Само посещение не гарантирует включение в индекс. Если ожидали обход статьи, а в журнале найден другой загрузчик и другой документ, нельзя считать исходную задачу подтверждённой.

Как принять проверяющий механизм без настоящих пользователей

• Строка User-Agent есть, а подтверждения адреса нет: результат остаётся неподтверждённым.
• В журнале записан прокси: система требует установить исходный адрес, а не классифицирует посетителя по адресу прокси.
• Первый DNS-шаг выглядит подходящим, второй не совпадает: полного подтверждения нет.
• Проверка временно недоступна: состояние отличается от установленного несоответствия.
• Категория подтверждена: политика допуска остаётся ограниченной своей задачей.

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

В отчёте сохраняйте доказательство и предел вывода. «Происхождение подтверждено выбранным способом» точнее, чем «всё хорошо с Google». Такая формулировка помогает отличить вопрос о конкретном запросе от доступности сайта, политики обхода и участия страницы в поиске.