Как проверить Googlebot и YandexBot по логам

Строка Googlebot или YandexBot в журнале сервера ещё не доказывает, что запрос отправила поисковая система. User-Agent — обычный текстовый заголовок, который способен подставить любой скрипт. Ошибка в другую сторону тоже опасна: если защита принимает настоящего робота за злоумышленника, важные страницы получают 403, 429, капчу или пустой ответ, хотя посетителям сайт кажется исправным.

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

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

Почему User-Agent недостаточно

User-Agent помогает предварительно отобрать кандидатов в большом логе, но не является удостоверением личности. Клиент сам формирует этот заголовок и может написать в нём что угодно. Поэтому правило WAF вида «если строка содержит Googlebot, пропустить запрос» создаёт обход защиты: атакующему достаточно повторить известную строку. Обратное правило «все боты заблокированы» способно закрыть обход поисковым системам и сервисам проверки.

Даже подлинный адрес Google или Яндекса не всегда означает основной индексирующий обход. У поисковой компании есть роботы рекламы, инструментов вебмастера, проверки доступности, изображений и запросов, запущенных пользователем. Их назначение и отношение к robots.txt могут отличаться. Решение «разрешить индексатору HTML» нельзя автоматически распространять на любой запрос из сети той же компании или на все продукты с похожим именем.

Наконец, проверка источника не отвечает на вопрос о качестве ответа. Настоящий Googlebot может получить 200 с заглушкой, 403 от пограничного сервера или HTML без основного текста. Для поиска важен фактический результат. Поэтому идентификация всегда идёт рядом с проверкой статуса, заголовков и содержимого; значения основных кодов разобраны в материале об HTTP-ответах сервера.

Какие данные взять из серверного лога

Минимальная запись содержит время, IP клиента, метод, hostname, путь, код, число переданных байтов, User-Agent, Referer и длительность ответа. Для сайта за CDN особенно важно сохранить два адреса: соединение с origin и исходный клиентский IP, который передал доверенный прокси. Если приложение без проверки принимает произвольный X-Forwarded-For, злоумышленник подменит адрес так же легко, как User-Agent.

Настройте доверие только к заголовку и диапазонам вашего CDN. Origin не должен быть общедоступным в обход пограничного слоя; иначе часть запросов окажется в логах без одинаковой схемы. Полезно добавить идентификатор запроса, действие WAF, правило кеша и upstream status. Эти поля позволяют увидеть, кто сформировал 403 или 429: CDN, балансировщик либо приложение.

Перед анализом проверьте цепочку прокси контрольным запросом с известного адреса. Запишите, какой узел добавляет каждое значение, очищает ли CDN входной заголовок клиента и в каком порядке перечислены hop. Если сервис несколько раз прошёл через балансировщики, выбор «первого» или «последнего» IP без схемы может дать адрес посетителя, edge либо внутренней сети. Полезный тест включает прямой запрос к закрытому origin: он обязан отклоняться, а подставленный заголовок не должен менять записанный клиентский адрес. После обновления CDN эту проверку повторяют, потому что имя доверенного заголовка и поведение соединения могут измениться.

Для расследования выгружайте интервал до и после события, а не одну подозрительную строку. Один 404 может быть обычной проверкой старого URL, но сотни 429 по Sitemap показывают системное ограничение. Сгруппируйте записи по адресу, семейству User-Agent, пути, коду и минуте. Практика подготовки данных подробно описана в статье об анализе серверных логов для SEO.

Если журнал огромный, выборка должна сохранять редкие ошибки. Случайные десять тысяч строк могут почти целиком состоять из успешных ответов и скрыть короткий всплеск 503. Сначала посчитайте все коды по минутам и шаблонам URL, затем берите примеры из каждого сегмента: успешный HTML, редирект, отсутствующий адрес, 403, 429, 5xx, IPv4 и IPv6. Отдельно сохраняйте первые и последние события серии. Для сравнения до и после используйте одинаковые границы и правила классификации. Иначе изменение фильтра выдаст себя за улучшение доступности, хотя запросы просто перестали попадать в отчёт.

Проверьте также часовой пояс и синхронизацию времени на edge и origin. Сдвиг даже на несколько минут мешает соединить запрос, действие WAF и ответ приложения, из-за чего правильная причина инцидента теряется между журналами.

Не публикуйте сырые журналы в открытом тикете. В них бывают query-параметры, токены, внутренние hostname, адреса пользователей и пути к служебным файлам. Для совместной диагностики оставьте необходимые технические поля, удалите секреты и ограничьте срок хранения. Проверяющий должен получить достаточно данных для воспроизведения, но не копию всей пользовательской активности.

Как устроены диапазоны Google в 2026 году

Google публикует IP-диапазоны своих crawler и fetcher в JSON. С 31 марта 2026 года официальное расположение перенесено из каталога /search/apis/ipranges/ в более общий /crawling/ipranges/, потому что инфраструктура используется не только Поиском. Старые адреса временно сохраняются, однако конфигурации и загрузчики следует переключить на новую базу, не полагаясь на вечное существование совместимого пути.

Для обычных автоматических роботов, включая Googlebot, применяется список common-crawlers.json. Отдельно опубликованы диапазоны special-case crawler и нескольких классов запросов, инициированных пользователями. Файлы содержат IPv4- и IPv6-префиксы в CIDR, поэтому нельзя сравнивать адрес простым совпадением строки. Клиентский IP должен попадать внутрь сети, описанной соответствующим префиксом.

Загрузчик проверяет успешный HTTP-ответ, корректный JSON и наличие ожидаемых полей, а затем атомарно заменяет предыдущую версию. Если сеть недоступна или документ повреждён, безопаснее временно оставить последнюю проверенную копию и отправить сигнал, чем очистить allowlist. Одновременно задайте срок: устаревший список нельзя считать достоверным бессрочно. Изменение источника должно проходить такой же контроль, как конфигурация SEO-регрессионных тестов.

При переходе на адреса /crawling/ipranges/ не ограничивайтесь заменой строки в загрузчике. Проверьте редиректы, Content-Type, максимальный размер ответа и схему объекта; сохраните предыдущий URL только как временный аварийный вариант с датой удаления. Тестовый набор должен включать один IPv4 внутри префикса, соседний адрес вне него, IPv6 в полной и сокращённой записи, пустой массив и неизвестное поле. Если структура внезапно изменилась, обновление останавливается до разбора, но активная проверенная версия не удаляется. Журнал фиксирует URL источника, время, хеш, число сетей и результат переключения — так можно отличить устаревшие данные от поломанного парсера.

Не подменяйте официальный список общей сетью Google Cloud или всеми адресами ASN компании. В облачной инфраструктуре могут работать клиенты, не связанные с поисковым обходом. Нужен именно класс crawler, соответствующий задаче. Если продукт не требует автоматического allowlist, разовая DNS-проверка отдельного IP остаётся понятным способом расследования.

Как проверить Googlebot через DNS

Для ручной проверки возьмите IP из доверенного поля лога и выполните reverse DNS lookup. У обычного Googlebot полученное имя обычно заканчивается на googlebot.com, у некоторых других crawler и fetcher используются google.com или googleusercontent.com. Проверяйте границу домена, а не наличие подстроки: имя googlebot.com.example.org принадлежит владельцу example.org.

Одного PTR-ответа недостаточно. После получения hostname выполните forward DNS lookup для A и AAAA и убедитесь, что исходный адрес присутствует среди результатов. Эта последовательность называется forward-confirmed reverse DNS. Она мешает владельцу постороннего IP просто назначить красивую PTR-запись. Базовую механику записей и кеширования объясняет руководство по DNS сайта.

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

Для DNS полезна четырёхсостоянийная модель. «Подтверждён» означает правильный суффикс и возврат исходного IP; «опровергнут» — чужой суффикс либо успешный прямой ответ без этого адреса; «нет данных» — отсутствие PTR; «временная ошибка» — timeout или SERVFAIL. Только первое состояние получает профиль подтверждённого crawler. Второе и третье обрабатываются как обычная неизвестная автоматизация, а четвёртое повторяется через другой доверенный resolver с ограничением попыток. Такая модель не позволяет короткому сбою DNS ни открыть привилегии, ни создать многодневную блокировку. Для каждого решения храните обе DNS-операции и время, но не полагайтесь на устаревший кеш после истечения заданного срока.

Как подтвердить YandexBot

Яндекс рекомендует аналогичную пару DNS-проверок. Сначала по IP получают имя хоста, затем убеждаются, что оно оканчивается на yandex.ru, yandex.net или yandex.com. После этого выполняют прямой запрос и сравнивают его адреса с исходным. Если PTR отсутствует, суффикс другой или forward lookup не возвращает исходный IP, запрос нельзя считать подтверждённым YandexBot.

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

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

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

Как автоматизировать проверку

Автоматический классификатор принимает нормализованный IP и возвращает не просто true или false, а тип, способ проверки, версию данных и время. Для Google он сопоставляет адрес с нужным официальным CIDR-файлом. Для Яндекса выполняет PTR, проверяет допустимый доменный суффикс и подтверждает исходный адрес через A или AAAA. Неизвестные и временно непроверенные запросы остаются отдельными состояниями.

Официальные JSON-файлы загружайте по расписанию и до применения проверяйте. Сохраняйте checksum, дату получения, число IPv4- и IPv6-префиксов. Резкое обнуление либо изменение формата должно остановить обновление. Новая копия сначала проходит тесты на известных примерах, затем атомарно становится активной. Это предотвращает массовый запрет из-за частично записанного файла.

Сам классификатор должен быть воспроизводимым. В событие записывают нормализованный адрес, найденный префикс или DNS-имя, класс робота, версию набора, срок кеша и итоговую причину. Решение не пересчитывают задним числом после обновления списка: для расследования важно знать, на каких данных оно было принято тогда. Держите отдельные счётчики ошибок загрузки, DNS timeout, неподтверждённых кандидатов и смены класса. Canary-версия сначала считает результат параллельно с рабочей и ничего не разрешает; расхождения разбираются на выборке. Только после этого она влияет на WAF. Откат возвращает предыдущую версию логики и данных вместе, иначе получится несовместимая пара.

DNS-ответы кешируйте с учётом TTL и ограничением сверху. Положительный результат не должен жить месяцами после изменения адресов, отрицательный — превращать краткий сбой resolver в длительный бан. При недоступности DNS выберите заранее утверждённый режим: ограниченный доступ к публичным GET/HEAD либо обычные защитные лимиты без привилегий. Никогда не открывайте административные пути только из-за неудавшейся проверки.

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

Как различать виды роботов и fetcher

Google разделяет common crawler, special-case crawler и несколько классов user-triggered fetcher. Обычные crawler автоматически обходят сеть и соблюдают robots.txt. Special-case запросы связаны с отдельными продуктами и могут работать по другим условиям. User-triggered fetcher приходит после действия человека, например когда сервису поручили получить конкретный URL. Для каждого класса опубликованы свои диапазоны и DNS-маски.

Это различие важно для WAF и аналитики. Всплеск user-triggered запросов не следует складывать с обычным crawl demand, а AdsBot не обязательно объясняет изменение индексации. В отчёте храните исходный User-Agent и подтверждённый класс, не заменяя всё ярлыком «Google». Аналогично у Яндекса основной YandexBot отличается от роботов Картинок, Вебмастера и других сервисов.

Не определяйте назначение только по пути: запрос к картинке может сделать основной renderer, а HTML — инструмент проверки. Сначала подтвердите источник и тип, затем анализируйте действие. Учитывайте GET и HEAD, IPv4 и IPv6, разные hostname, мобильные варианты User-Agent. Версии браузерного движка меняются, поэтому точное совпадение всей длинной строки быстро ломает правило.

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

Что проверить после идентификации

Запросите несколько публичных URL через тот же маршрут, который проходит робот: главную, статью, категорию, ресурс и несуществующий адрес. Сравните коды, Location, Content-Type, robots meta, canonical и размер тела. Подлинному роботу нужна та же содержательная версия, что обычному неавторизованному посетителю. Специально улучшенный ответ по User-Agent создаёт риск клоакинга и скрывает реальные дефекты.

Проверьте robots.txt и Sitemap без cookie. Файл robots должен быть доступен, а правила — соответствовать нужному crawler. Если WAF отвечает на robots.txt капчей или 403, робот не получает конфигурацию. Отдельно убедитесь, что XML-карты не требуют JavaScript и не перенаправляются в бесконечную цепочку; основы перечислены в руководстве по Sitemap.

Для JavaScript-сайта сравните исходный HTML и отрендеренную версию в инструментах поисковой системы. Успешный 200 ещё не доказывает наличие текста: CDN может вернуть пустую оболочку, а API — заблокироваться по другому правилу. Диагностика таких приложений разобрана в материале о JavaScript SEO.

Если обнаружены 429, 500 или 503, не маскируйте их ответом 200. Исправьте лимит или неисправный upstream и повторите проверку. Временный 503 подходит для короткого обслуживания, но не для постоянной фильтрации; корректный сценарий описан в статье о технических работах. Зафиксируйте время восстановления, чтобы сопоставить его со следующим обходом.

Составьте матрицу не только из «хороших» URL. В ней нужны публичный GET, условный GET с ETag, HEAD, отсутствующая страница, закрытый preview, POST формы, файл robots.txt, Sitemap, CSS и запрос к API рендеринга. Каждый сценарий запускают с подтверждённым адресом, поддельным User-Agent и обычным клиентом. Ожидания различаются: робот получает публичный документ без капчи, но не приватный экран; подделка не получает привилегий; 404 остаётся 404; условный запрос может вернуть 304. Сравнивайте код, редирект, заголовки, размер и смысловой фрагмент HTML. Так проверка доказывает ограниченность разрешения, а не только доступ к одной заранее прогретой странице.

Числовой пример разбора логов

За сутки CDN магазина записал 1 840 000 запросов. По User-Agent отобрали 96 400 кандидатов: 89 740 называли себя Googlebot, 6 660 — YandexBot. После проверки официальных диапазонов и DNS подтверждены 87 600 запросов Google и 5 900 запросов Яндекса. Ещё 2 900 не прошли проверку. Баланс сходится: 87 600 + 5 900 + 2 900 = 96 400.

Неподтверждённая группа состояла из 2 140 псевдо-Googlebot и 760 псевдо-YandexBot; 2 140 + 760 = 2 900. Большинство обращалось к поиску по сайту и формам, а не к документам из Sitemap. Команда убрала правило, пропускавшее строку Googlebot без проверки, и применила к этой группе обычные ограничения. Публичные страницы не закрывали, а методы записи продолжили требовать штатную защиту.

Из подтверждённых запросов случайно выбрали 300 URL и повторили их внешнюю проверку. Получено 276 ответов 200, 12 ответов 304, 8 ответов 429 и 4 ответа 503. Всего 276 + 12 + 8 + 4 = 300. Ошибочными для текущего теста считались 12 ответов 429/503, то есть 12 ÷ 300 × 100 = 4% выборки.

Причиной оказался общий rate limit на одном из четырёх edge-кластеров. После отдельного правила для подтверждённых common crawler и снижения нагрузки повторная выборка из 300 URL дала 286 ответов 200 и 14 ответов 304: 286 + 14 = 300, ошибок 429/503 — ноль. Это не гарантировало индексацию или позиции; тест подтвердил только подлинность источников и доступность выбранных URL в заданный момент.

Как построить мониторинг

Ежедневный отчёт показывает подтверждённые запросы по системе и типу робота, долю 2xx/3xx/4xx/5xx, медиану и высокий перцентиль времени ответа, число уникальных URL и действие WAF. Смотрите сегменты hostname и edge, иначе проблема одного узла растворится в среднем. Резкий рост обхода сам по себе не является атакой; сначала сопоставьте его с обновлением сайта, Sitemap и логами.

Отдельный сигнал нужен на поддельные User-Agent. Он полезен для безопасности, но не должен автоматически менять SEO-настройки. Записывайте частоту, методы и затронутые пути, затем корректируйте общую защиту. Если запросы идут к формам, пригодятся меры из руководства по защите форм от спама; не создавайте исключение только из-за известного имени.

Алерт доступности срабатывает, когда подтверждённые crawler массово получают 403, 429 или 5xx, когда размер HTML резко падает либо robots.txt меняет код. У сигнала есть владелец, ссылка на последние записи, версия правил CDN и способ отката. Более широкий регламент метрик описан в статье про SEO-мониторинг.

После изменения CDN или DNS выполните контролируемый smoke-тест и дождитесь реального обхода. Инструмент Search Console помогает посмотреть обработку URL Google, но его fetcher может отличаться от обычного Googlebot; это ещё один источник, а не абсолютная копия каждого запроса. Основные отчёты разобраны в инструкции по Google Search Console.

Для инцидента заранее задайте уровни реакции. Единичный неподтверждённый кандидат попадает в статистику; рост таких запросов запускает проверку безопасности. Один 503 сохраняется как диагностическое событие; серия на разных URL и одном edge вызывает откат недавнего правила. Массовые 403 подтверждённому crawler требуют сверить версию диапазонов, доверенный proxy header и порядок WAF до изменения robots.txt. После исправления команда повторяет ту же выборку и наблюдает реальные журналы хотя бы полный цикл обновления кеша. Закрывать инцидент только после успешного curl с ноутбука нельзя: он проходит другой маршрут, имеет другой адрес и почти всегда попадает в иной профиль защиты.

Регламент безопасной проверки

Назначьте владельца списка источников и политики доступа. Он отслеживает изменения официальной документации, обновление JSON, работоспособность DNS resolver и срок кеша. Все правила хранятся в системе версий. Изменение сначала проходит staging с реальными примерами IPv4 и IPv6, затем включается на небольшой доле трафика и только после наблюдения распространяется на все edge.

В runbook запишите, где брать клиентский IP, какие прокси считаются доверенными, какие суффиксы допустимы, как выполняется forward lookup и что происходит при недоступности источника. Добавьте отрицательные тесты: поддельный User-Agent, похожий домен, PTR без обратного совпадения, адрес общей облачной сети и устаревший JSON. Именно отрицательные случаи защищают от слишком широкого allowlist.

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

Наконец, сохраняйте доказательства каждого инцидента: интервал лога, IP, User-Agent, способ подтверждения, коды, правило, изменение и повторный тест. Не связывайте техническое исправление с обещанием роста. Корректная проверка снижает риск ложной блокировки и обхода защиты, но попадание страницы в поиск зависит также от доступности, содержания, сигналов сайта и решений поисковой системы.

Раз в квартал проведите учебный разбор на заранее подготовленных примерах. Один запрос должен пройти CIDR-проверку, второй — полную DNS-цепочку, третий иметь правдоподобный, но ложный User-Agent, четвёртый — корректный PTR без прямого совпадения, пятый — IPv6. Участник по журналу объясняет каждое решение и находит правило, которое сформировало ответ. Затем моделируются недоступность JSON и timeout resolver: система сохраняет безопасный режим, сигнализирует владельцу и не открывает приватные маршруты. Такой тест проверяет не только код, но и документацию, доступ дежурного к данным и способность команды восстановить проверку без опасного временного исключения.

После учения обновите примеры команд и ожидаемые ответы в runbook. Удалите устаревшие адреса, но сохраните обезличенный журнал решения. Новый инженер должен воспроизвести проверку без доступа к памяти автора правила и без ручного редактирования рабочего allowlist.

Главный вывод

Проверка Googlebot и YandexBot — это воспроизводимая цепочка, а не поиск знакомого слова в логе. Для Google используйте актуальные классы и JSON из нового каталога /crawling/ipranges/ либо подтверждённый прямым запросом reverse DNS. Для Яндекса применяйте PTR, допустимый доменный суффикс и обязательное обратное совпадение адреса. После идентификации всегда проверяйте фактический ответ страницы. Такая схема позволяет отсечь подделки, не выдавать лишних привилегий и быстрее находить ошибочные ограничения CDN или сервера.