Поисковые роботы · SEO

Fake Googlebot и YandexBot: как проверить настоящего поискового робота

Подделать строку User-Agent Googlebot или YandexBot просто. Поэтому защита сайта не должна выдавать ALLOW только по имени робота. И Google, и Яндекс рекомендуют проверять источник через DNS/IP-механизм.

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

HTTP-заголовок User-Agent полностью контролируется клиентом. Любой скрипт может отправить строку, похожую на Googlebot или YandexBot. Поэтому правило if UA contains Googlebot → ALLOW создаёт обход антибота.

Проверка Googlebot

Google указывает, что crawler/fetcher можно проверять через reverse DNS или сопоставление IP с опубликованными диапазонами. Для common crawlers reverse DNS-имена относятся к доменам Googlebot, после чего нужно убедиться в соответствии IP.

  1. Получить source IP из access log.
  2. Выполнить reverse DNS (PTR).
  3. Проверить допустимый hostname suffix согласно документации Google.
  4. Сделать forward lookup hostname и убедиться, что исходный IP присутствует в результате — либо использовать официальные IP range lists.

Проверка YandexBot

Яндекс предупреждает, что роботы могут маскироваться под Yandex User-Agent. Рекомендованный порядок: reverse DNS исходного IP, проверка hostname на домены yandex.ru, yandex.net или yandex.com, затем forward DNS hostname и сравнение IP.

Что делать при ошибке DNS

DNS — внешняя зависимость. Timeout или временная ошибка не должны автоматически превращать заявленного crawler в fake. Практичная модель хранит TEMP_ERROR и повторяет проверку/использует cache в безопасной freshness policy.

SEO-инвариант

Подтверждённый crawler должен иметь hard ALLOW выше Browser/Risk. Иначе отсутствие JS или машинная частота могут переопределить верифицированную поисковую идентичность.

Что хранить в диагностике

  • declared crawler family;
  • source IP с учётом trusted proxy chain;
  • verification method;
  • verified/fake/temp-error state;
  • hostname/IP range evidence;
  • freshness/cache age;
  • финальное действие и override reason.
Как это связано с AntiPF

Crawler Verification в AntiPF

AntiPF разделяет declared identity и verified identity: подтверждённый crawler получает hard decision, fake crawler может быть ограничен, а DNS temporary error сохраняется отдельно. Browser/Adaptive score не должен переопределять verified ALLOW.

РешениеЗащита поисковых роботов →МодульCrawler Verification →МодульDecision Trace →СтатьяЧто такое антибот →

Источники и технические справки

Для проверяемых технических деталей использованы официальные материалы:

FAQ

Частые вопросы

Можно ли доверять User-Agent Googlebot?

Нет. Google прямо указывает, что User-Agent может быть spoofed; источник нужно проверять.

Как Яндекс рекомендует проверять робота?

Через reverse DNS, проверку принадлежности hostname доменам Яндекса и forward DNS обратно к исходному IP.

Что делать, если DNS временно не отвечает?

Не считать запрос автоматически fake или verified. Использовать TEMP_ERROR/UNKNOWN и безопасную retry/cache policy.

Почему verified crawler должен быть выше Risk?

Crawler может не выглядеть как обычный пользователь; статистический score не должен ломать подтверждённую поисковую идентичность.

Следующий шаг

Нужно проверить трафик на реальном сайте?

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