Фейковый Googlebot: как сайты проверяют личность краулера

Заголовок User-Agent — это обычное текстовое поле, и ничто не мешает любому скрипту установить его в значение Googlebot/2.1 (+http://www.google.com/bot.html). Скраперы делают это постоянно, обычно чтобы обойти простые фильтры ботов, которые смотрят только на эту строку. При этом настоящий Googlebot, Bingbot и десятки других легитимных краулеров действительно представляются точно так же — по имени, в том же заголовке. Сайту, который хочет относиться к «Googlebot» по-особому, сначала нужно ответить на один вопрос: этот запрос действительно от Google — или от кого угодно, кто написал правильные слова?

Ключевые выводы

• Заявленная в User-Agent личность сама по себе ничего не доказывает — это произвольный текст, и для любого, кто хочет выдать себя за настоящий краулер, скопировать его строку — вопрос одной строчки кода.
• Обратный DNS с прямым подтверждением (forward-confirmed reverse DNS) — классическая проверка: сначала выясняют, кто контролирует исходный IP, затем сверяют этот ответ с DNS-записями, которые публикует сам оператор.
• Опубликованные операторами списки диапазонов IP — более быстрая и дешёвая альтернатива для операторов, которые их ведут, ценой устаревания между обновлениями.
• Криптографические подписи (RFC 9421 / Web Bot Auth) заменяют предположение доказательством: успешно проверенная подпись показывает, каким ключом подписан запрос, а не просто из какой сети он пришёл.
• Реестры операторов — самый новый вариант: BotBase от Cloudflare позволяет оператору зарегистрировать личность, которую сайт может просто найти в справочнике, причём сам реестр заново прогоняет за сайт проверки по DNS, спискам IP и подписям.
• Эти четыре метода проверяют разные вещи и ломаются по-разному, поэтому знать, на какой именно метод опирается сайт, так же важно, как знать, что проверка вообще существует.

Заявление бесплатно, доказательство — нет

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

Метод 1: обратный DNS с прямым подтверждением

Старейшая и всё ещё самая распространённая проверка выполняется в два шага, и пропуск второго шага — как раз та ошибка, из-за которой первый шаг теряет смысл.

Шаг первый — обратный запрос. Берём исходный IP-адрес запроса и ищем его PTR-запись, которая сопоставляет IP с именем хоста. Если краулер действительно принадлежит Google, это имя должно заканчиваться на googlebot.com, google.com или googleusercontent.com — именно эти три домена собственная документация Google по проверке краулеров разрешает владельцам сайтов считать подлинными.

Шаг второй — прямое подтверждение. Само по себе это имя хоста пока ничего не доказывает, потому что PTR-записи контролирует тот, кто администрирует зону обратного DNS для данного IP-адреса, — а вовсе не тот, кем вам хотелось бы, чтобы владелец этого адреса был. RFC 1912 как раз описывает именно такие риски неправильной настройки и злоупотребления DNS, а терминология DNS в RFC 8499 структурно подтверждает ту же мысль: то, что мы называем обратным DNS, — это всего лишь направление «адрес → имя», которое обслуживают зоны IN-ADDR.ARPA и IP6.ARPA и наполняет тот, кому делегирован соответствующий блок адресов, а не сертификат, выданный доверенной третьей стороной. Так что проверка ещё не окончена. Сайт берёт имя хоста из первого шага и разрешает его в прямом направлении — обычный запрос A/AAAA — и проверяет, что результат совпадает с исходным IP. Только когда оба направления совпадают, личность подтверждается: атакующий, не контролирующий DNS для googlebot.com, не может заставить PTR-запись произвольного IP разрешаться в имя хоста, которое, в свою очередь, прямо разрешается обратно в тот же IP.

Именно поэтому такую двухшаговую версию называют обратным DNS «с прямым подтверждением», и именно поэтому одна лишь обратная проверка не является методом верификации — она лишь смотрит на значение, которое контролирует кто-то другой.

Метод 2: опубликованные операторами диапазоны IP

Некоторые операторы краулеров вообще обходятся без DNS и публикуют список диапазонов IP, с которых они обходят сайты. Сайт скачивает этот список, проверяет, попадает ли исходный IP запроса в один из диапазонов, и при совпадении считает запрос подтверждённым. Это простая проверка принадлежности множеству — гораздо дешевле, чем два DNS-запроса подряд, — что важно при том объёме запросов, который генерируют крупные краулеры.

Google публикует такие списки в виде JSON-файлов с блоками CIDR, разбитых по классам краулеров: common-crawlers.json — поисковые краулеры, special-crawlers.json — продукты вроде AdsBot, плюс отдельные файлы для запросов, инициированных пользователем. В документации Google сверка с этими файлами описана как автоматический вариант в противовес ручному обходу через DNS — тот же вопрос, но более дешёвый ответ.

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

Метод 3: криптографические подписи

DNS и диапазоны IP проверяют сеть — того, кто владеет данным блоком адресов, или того, кто заявил о владении им. Подпись проверяет нечто другое: того, кто владеет конкретным приватным ключом. Оператор подписывает каждый исходящий запрос с помощью HTTP Message Signatures (RFC 9421) — стандарта, на котором строится архитектурный черновик Web Bot Auth (это Internet-Draft IETF, который всё ещё переписывают и переименовывают, а не готовый стандарт), — и публикует соответствующий публичный ключ. Сайт проверяет подпись по этому ключу, вообще не задаваясь вопросом об IP-адресе запроса.

Наш гид по методам обнаружения ботов подробно разбирает этот механизм в разделе «Криптографическая идентификация ботов: Web Bot Auth» — стоит прочитать, если вам нужна лежащая в основе криптография; здесь же важнее более узкий момент: проверка подписи отвечает на вопрос «какой ключ подписал этот запрос», а это отличается от вопроса «из какой сети пришёл этот запрос» — и ответы на них иногда расходятся, что стоит иметь в виду.

Метод 4: реестры операторов

2026 год добавил четвёртый ответ на тот же вопрос. Вместо того чтобы каждый сайт сам выводил личность из сетевого адреса или ключа, оператор теперь может один раз зарегистрироваться в справочнике, который делает эту работу за всех. BotBase от Cloudflare для операторов, запущенный 28 августа 2026 года, позволяет оператору бота отправить и поддерживать собственную запись в справочнике — заявив, кто он, чем занимается и каким способом его можно проверить, — а затем отслеживать эту заявку по статусам вроде «ожидает рассмотрения», «принята» и «отклонена», прежде чем она получит отметку «Verified».

Самое важное происходит как раз во время этого рассмотрения. Cloudflare не принимает заявление на веру: она проверяет, действительно ли работает заявленный способ верификации, — валидирует списки IP оператора, его настройку обратного DNS и подписи Web Bot Auth. Иначе говоря, справочник не заменяет первые три метода — он прогоняет их один раз, централизованно, чтобы отдельные сайты получали готовый ответ вместо того, чтобы каждый заново выстраивал те же три проверки.

Со стороны владельца сайта тому же сюжету соответствует Bot Preference Sync, который разворачивает направление: владелец сайта один раз задаёт в панели управления свою политику для поисковых, агентских и обучающих краулеров, а Cloudflare автоматически вписывает соответствующие правила в robots.txt этого сайта. Это механизм политики, а не верификации, — но работают они только вместе, потому что предпочтение, адресованное «Googlebot», стоит ровно столько, сколько стоит способность сайта понять, действительно ли его читает Googlebot.

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

Эти четыре проверки — не просто одна и та же вещь, сделанная всё лучше на каждом шаге. Первые три проверяют по-настоящему разные объекты, четвёртая проверяет их за вас, и ломается каждая по-своему:

• Обратный DNS с прямым подтверждением и опубликованные диапазоны IP проверяют сеть. Они дают сбой при неправильной настройке DNS или при устаревшем списке диапазонов — в обоих случаях настоящий краулер ошибочно оказывается за бортом; куда реже — если атакующий каким-то образом контролирует одновременно прямую и обратную зоны для полученного им адреса (редко, но не невозможно для хорошо оснащённого атакующего).
• Подпись проверяет владельца ключа. Она даёт сбой только при утечке приватного ключа — это проблема криптографии и операционной безопасности, не имеющая никакого отношения к DNS или сетевой топологии.
• Запись в справочнике проверяет то, что реестр проверил за вас. Она ровно настолько надёжна, насколько надёжны стоящие за ней проверки, и добавляет два собственных способа отказа: слабую проверку со стороны самого реестра и легитимного оператора, который просто ещё не зарегистрировался.

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

Что это значит для вашего собственного браузера

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

Рамки этой статьи сужены намеренно. Этот гид посвящён только одному вопросу — проверке краулера, который уже заявил о себе конкретную личность. Он не рассказывает, как отличить нежелательную, незаявленную автоматизацию от настоящего посетителя только по клиентским сигналам (см. наш гид по методам обнаружения ботов); он не рассказывает про ИИ-агента, управляющего настоящим браузером реального пользователя с его собственными учётными данными (см. обнаружение трафика ИИ-агентов); и он не рассказывает о том, как человек может доказать, что он человек, не становясь при этом отслеживаемым (см. анонимные удостоверения в вебе). Каждый из этих вопросов отдельный, и ответ на него свой; этот же материал — конкретно о том, как превратить утверждение «этот запрос — от Googlebot» из строки, которой просто доверяют, в проверенный факт.

Часто задаваемые вопросы

Можно ли просто доверять заголовку User-Agent, если там написано Googlebot?

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

В чём разница между обратным DNS и обратным DNS с прямым подтверждением?

Обычный обратный (PTR) запрос говорит лишь о том, какое имя хоста решил опубликовать администратор этого IP, — что ничего не доказывает, если вы изначально не доверяете этому администратору. Обратный DNS с прямым подтверждением добавляет второй шаг: снова разрешить это имя хоста в прямом направлении и проверить, что результат совпадает с исходным IP. Пропуск этого шага прямого подтверждения — самая распространённая ошибка в этой проверке.

Является ли криптографическая подпись однозначно лучше проверки на основе DNS?

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

Нужно ли мне также проверять TLS- или TCP-фингерпринт запроса?

Это отдельный, дополняющий сигнал, а не замена — наш гид по TCP/IP-фингерпринтингу объясняет, как характеристики сетевого уровня могут выявить несоответствие между заявленным клиентом и его реальным стеком, что полезно наряду с проверкой личности, но само по себе не подтверждает, чей именно это краулер.

Защищает ли проверка Googlebot от всех видов поддельных краулеров?

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

Рекомендуем почитать

• Обнаружение ботов: как выявляют ботов и краулеров
• ИИ-агенты в браузере: как сайты отличают их от ботов и людей
• Анонимные удостоверения: доказать человечность без слежки
• Как обнаружить подмену user-agent и почему её легко заметить
• Что такое строка User-Agent? Как её прочитать и проверить свою
• TCP/IP-фингерпринтинг: как сервер узнаёт вашу ОС до TLS