Подтверждённый робот
Hard ALLOW имеет более высокий authority, чем Risk/Adaptive.
Search Crawler Verification
Проверка поисковых роботов: настоящий Googlebot/YandexBot не должен проигрывать обычному Risk score
Подставить User-Agent поискового робота легко. AntiPF выделяет crawler identity в отдельный hard decision: VERIFIED получает ALLOW, fake crawler обрабатывается по hard policy, а временная DNS-ошибка не превращается автоматически ни в verified, ни в fake.
VERIFIED / FAKE / TEMP_ERRORHard ALLOWGooglebot / YandexBotSEO-safe authority
Crawler verification
User-AgentGooglebot
CLAIMReverse/forward DNSverified domain
MATCHCrawler decisionGooglebot
VERIFIEDAuthoritybefore Risk Engine
ALLOWBrowser/Adaptive score не должен переопределять подтверждённый crawler ALLOW.
SEO-safe security
Crawler identity должна проверяться отдельно от обычного посетителя
Search crawlers и AI/preview bots имеют отличающиеся сценарии: отсутствие JS, быстрый обход URL и необычные headers сами по себе не делают их атакой. Поэтому AntiPF отделяет crawler verification от browser-risk эвристик.
Поддельный User-Agent
Заявленное имя crawler не совпало с verification policy — применяется существующее hard rule.
Временная неопределённость
DNS/network failure сохраняется как отдельное состояние, а не выдаётся за доказанный fake.
Архитектура
Claim → verification → hard decision
Сначала определяется crawler-кандидат, затем проверяется identity, и только после этого обычные risk signals получают контекст.
Detect claim
User-Agent и crawler registry определяют кандидата.
Verify
Применяется versioned verification policy и сетевые проверки.
Classify
VERIFIED, FAKE, TEMP_ERROR или NOT_CRAWLER.
Hard authority
VERIFIED crawler получает отдельный hard decision.
Exclude telemetry
Crawler/system traffic не загрязняет browser/adaptive analytics.
Trace
Результат виден в Decision Trace и diagnostics.
SEO invariant. Verified crawler ALLOW не может быть отменён browser-risk, absence of JS или обычным Adaptive score.
Что умеет модуль
Что проверяется и зачем
Модуль защищает две стороны: SEO — от ложных блокировок, security — от простого спуфинга User-Agent.
Googlebot verification
Подтверждение crawler identity вместо доверия строке User-Agent.
Подробнее →YandexBot verification
Аналогичный hard-decision для роботов Яндекса.
Подробнее →Fake crawler handling
Поддельные claims могут идти в существующую hard security policy.
Подробнее →TEMP_ERROR semantics
Временная DNS/network проблема не подменяется выдуманным результатом.
Подробнее →Crawler analytics exclusion
Browser telemetry и behavioral training не должны обучаться на поисковых роботах как на людях.
Подробнее →AI crawler categorization
Crawler registry может учитывать отдельные категории AI/preview/system bots.
Подробнее →Readiness & evidence
Verification должна отличать неизвестность от отрицательного результата
Сетевые проверки могут временно не отвечать. Correctness важнее агрессивной классификации.
VERIFIED
Identity подтвержденаПрименяется crawler hard ALLOW.
FAKE
Claim не подтверждёнДальнейшее действие задаёт hard policy.
TEMP_ERROR
Проверка временно невозможнаНе считать автоматически verified или fake.
NOT_CRAWLER
Обычный запросПереходит в стандартный AntiPF pipeline.
Практическое применение
Какие проблемы закрывает verification
Модуль нужен владельцам сайтов с защитой и SEO-специалистам, которым важно не получить скрытый crawl-block.
SEO
Связанный сценарий →Проверка доступа роботов
Отделить реальный crawler от обычного подозрительного HTTP-трафика.
SECURITY
Связанный сценарий →Fake Googlebot
Не доверять одному User-Agent и применять policy после неуспешной verification.
DIAGNOSTICS
Связанный сценарий →Почему робот получил ALLOW
Decision Trace показывает hard decision и override обычного score.
ADAPTIVE
Связанный сценарий →Чистое обучение
Crawler traffic не должен искажать human/bot behavioral baseline.
Ограничения
Crawler verification не равна «разрешить всех известных ботов»
Категория crawler и действие policy — разные вещи. Verified search crawler имеет SEO-safe hard semantics; другие AI/preview/system bots могут иметь отдельную конфигурацию владельца сайта.
FAQ
Вопросы про проверку Googlebot/YandexBot
Почему нельзя доверять User-Agent?
Строку User-Agent может отправить любой HTTP-клиент. Поэтому crawler claim и подтверждённая identity — разные состояния.
Что происходит при проблеме DNS?
Корректное состояние — TEMP_ERROR. Оно не должно автоматически превращать робота в подтверждённого или поддельного.
Может ли Browser Signals заблокировать verified Googlebot?
Нет: crawler hard decision имеет более высокий authority, чем Risk/Adaptive/Browser score.
Нужно ли Googlebot проходить CAPTCHA?
Подтверждённый поисковый crawler не должен попадать в обычный human Challenge flow только из-за «нечеловеческих» browser signals.
Следующий шаг
Проверим, не мешает ли защита индексации
Можно отдельно протестировать Googlebot/YandexBot, fake crawler cases и текущие hard-rules, не включая агрессивный enforcement для обычного трафика.