Page Analyzer AI: один из десятков похожих инструментов разового аудита страниц — не системный AI-краулер

Имя Page Analyzer AI указывает на широкую и довольно многолюдную категорию инструментов, а не на одного конкретного, легко идентифицируемого игрока: в вебе одновременно существует множество похожих по названию и функции бесплатных сервисов — AI Web Page Analyzer, Web Analyzer, AI SEO Checker, SEO Website Scanner и десятки других, — каждый из которых предлагает пользователю ввести URL и получить автоматический аудит страницы по параметрам SEO, скорости или содержимого. Точного, однозначно подтверждённого совпадения именно с токеном page analyzer ai среди крупных задокументированных операторов найти не удалось — это, по всей видимости, один из представителей этой многочисленной категории небольших, часто бесплатных инструментов.

Что объединяет инструменты этой категории

Общий паттерн у подобных сервисов один: пользователь вручную вводит адрес интересующей его страницы в веб-форму, инструмент в моменте (или в течение нескольких секунд-минут) обращается к этому URL, разбирает HTML на предмет заголовков, meta-тегов, структуры контента, скорости загрузки или иных технических параметров, а затем показывает пользователю отчёт с рекомендациями. Ключевая черта — обход инициируется вручную конкретным человеком по конкретному запросу, а не системным расписанием краулера, который сам находит и обходит миллионы страниц независимо от чьих-либо действий.

Параметры

Почему шаблонная категоризация «AI и LLM-краулер» здесь спорна

Формулировка «наполнение AI-индекса или обучающей/retrieval-выборки» предполагает системное накопление данных для чужого AI-продукта общего назначения. Но если реальное поведение этого бота соответствует широкой категории «инструмент для разового анализа страницы по запросу пользователя» (что подсказывает и само название — «анализатор страницы», а не «краулер» или «индексатор»), логика ближе к разобранному ранее SMARTSEO Checker: точечный, инициированный человеком запрос, а не фоновый сбор впрок. Слово «AI» в имени, скорее всего, указывает на использование AI-модели самим инструментом для формулировки рекомендаций пользователю (по аналогии с многочисленными «AI SEO Checker»-подобными сервисами), а не на то, что содержимое сайта уходит в обучающий датасет чужой большой языковой модели.

Как это проверить по факту в собственных логах

Единственный надёжный способ подтвердить или опровергнуть эту гипотезу для конкретного сайта — посмотреть на паттерн запросов:

# Базовый поиск
grep -i "page analyzer ai" /var/log/nginx/access.log

# Проверка: разовые точечные запросы или системный обход
grep -i "page analyzer ai" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Временное распределение — концентрация в узком окне или постоянный фон
grep -i "page analyzer ai" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

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

Стоит ли блокировать

• если по факту логов запросы точечные и редкие — вероятно, это разовая проверка, которую кто-то (возможно, сам владелец сайта или его подрядчик) запустил через один из множества подобных бесплатных инструментов; специальной блокировки это не требует;
• если объём заметный и не похож на разовые проверки — разумно относиться к боту так же, как к любому неподтверждённому агенту без опубликованной документации: с базовой осторожностью;
• на позиции в поисковой выдаче Google, Bing или Яндекса присутствие или отсутствие этого бота не влияет.

Как заблокировать

Стандартный запрет через robots.txt:

User-agent: page analyzer ai
Disallow: /

Поскольку официального подтверждения соблюдения robots.txt для этого агента нет, для надёжности запрет стоит продублировать на уровне сервера:

if ($http_user_agent ~* "page analyzer ai") {
    return 403;
}

Если полный запрет кажется избыточным при небольшом точечном объёме запросов, разумная альтернатива — ограничение частоты вместо жёсткой блокировки:

limit_req_zone $binary_remote_addr zone=pageanalyzerai:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "page analyzer ai") {
        limit_req zone=pageanalyzerai burst=20 nodelay;
    }
}