Search Crawler Verification
Проверка supported crawler identity и authoritative decision.
Подробнее →
Crawler verification · Googlebot · YandexBot
Проверка поисковых роботов: настоящий Googlebot и YandexBot отдельно от поддельного User‑Agent
Любой web crawler, search engine spider или обычный HTTP-клиент может написать «Googlebot» в User‑Agent. AntiPF проверяет crawler identity и только подтверждённому поисковому роботу даёт hard‑ALLOW, который не должен быть переопределён Browser, Network или Adaptive risk score.
Reverse DNSForward DNSExact IP validationHard ALLOW > Risk
Crawler identity
User‑Agentclaims Googlebot
UNTRUSTEDReverse DNSprovider hostname
MATCHForward DNShostname → source IP
MATCHHard decisionverified crawler
ALLOWDNS temporary error — отдельное состояние. Ошибка проверки не должна автоматически превращаться ни в verified, ни в fake.
SEO-safe protection
User‑Agent — заявление, а не доказательство
Если антибот просто добавит Googlebot в allowlist по строке UA, этим воспользуется любой scraper. Если же он будет challenge‑ить всех без JS, пострадает индексация. Нужен отдельный crawler hard‑контур.
Spoofed Googlebot
Парсер подставляет известный User‑Agent и пытается получить безусловный доступ.
Googlebot Smartphone / Desktop
Разные варианты Googlebot остаются поисковыми crawler и должны проходить поддерживаемую identity verification, а не browser-проверку как человек.
robots.txt и доступ
robots.txt управляет допустимым обходом, но не подтверждает, что пришедший клиент действительно принадлежит поисковой системе.
JS/Cookie expectations
Настоящий crawler не обязан вести себя как обычный браузер, поэтому browser‑telemetry нельзя использовать против verified crawler.
DNS TEMP ERROR
Временная ошибка проверки — не повод делать ложный definitive verdict.
Конфликт с Risk Engine
Даже высокий risk score не должен переопределять подтверждённый hard‑ALLOW.
Как работает
Проверка идентичности до обычного risk
Crawler policy идёт до Browser/Adaptive score и формирует самостоятельное hard‑решение.
01Detect claim
User‑Agent похож на поддерживаемого crawler.
02Official context
При необходимости сверяются опубликованные диапазоны/проверочные инструменты поисковой системы.
03Reverse DNS
IP → hostname и проверка допустимого домена.
04Forward DNS
Hostname → IP и сопоставление с source.
05Identity state
VERIFIED / FAKE / TEMP_ERROR / NOT_CRAWLER.
06Authority
Verified ALLOW остаётся выше Risk/Adaptive.
SEO‑инвариант. Verified crawler ALLOW нельзя отменять статистическим browser/network/adaptive score.
Возможности AntiPF
Что входит в crawler‑контур
Это не просто allowlist строк — состояние идентичности участвует в общей Decision Trace.
Rule Engine
Дополнительные explicit policies и исключения.
Подробнее →Decision Trace
Показывает, почему crawler получил ALLOW или перешёл в normal policy.
Подробнее →Risk Engine
Работает для обычного/неподтверждённого трафика, но не перебивает verified hard‑ALLOW.
Подробнее →URL Map
Помогает видеть поисковый и HTTP‑контекст URL, которые посещают crawler.
Подробнее →SEO / HTTP
Indexability, canonical, X‑Robots‑Tag и технические сигналы рядом с защитой.
Подробнее →Ограничения
Проверка crawler identity подтверждает источник, но не заменяет SEO‑диагностику
Даже настоящий Googlebot может получать 404, noindex, неправильный canonical или редирект. Поэтому в AntiPF crawler‑контур дополнен URL Map и SEO/HTTP‑диагностикой.
И наоборот: хороший SEO‑статус URL не является основанием доверять неизвестному visitor.
Связанные сценарии
Что ещё может быть частью задачи
FAQ
Вопросы о Googlebot и YandexBot
Как проверить, что Googlebot настоящий?
Надёжная схема использует source IP, reverse DNS и forward confirmation с проверкой ожидаемого домена/адреса. Одного User‑Agent недостаточно.
Как проверить YandexBot?
Принцип тот же: заявленная crawler identity должна подтверждаться сетевой проверкой по поддерживаемой политике, а результат иметь отдельные VERIFIED/FAKE/TEMP_ERROR состояния.
Что делать при DNS ошибке?
Временную ошибку нужно считать TEMP_ERROR, а не автоматически «fake». Политика должна быть fail‑safe для SEO и не делать необратимый вывод без evidence.
Может ли Browser Signals повысить risk настоящего crawler?
Browser telemetry может быть отсутствующей у crawler, но hard‑ALLOW verified search bot имеет приоритет и не должен переопределяться risk score.
Почему просто allowlist IP недостаточно?
Диапазоны меняются, разные поисковые системы имеют свои правила, а статический список требует сопровождения. Google публикует диапазоны crawler IP и описывает DNS-проверку; у Яндекса есть собственная инструкция и инструмент проверки IP. AntiPF должен использовать поддерживаемую identity verification, а не случайный статический список.
Следующий шаг
Проверим, как ваш сайт обращается с поисковыми роботами
Можно начать с логов и текущей защитной конфигурации: какие crawler получают ALLOW, Challenge, 403/503 и где возможны SEO‑риски.