Page-preview-tool: превью-бот без подтверждённого имени

У большинства настоящих fetcher-ов превью-ссылок — Facebook External Hit, Twitterbot, Slackbot, LMArenaUnfurlBot — есть узнаваемое имя, прямо указывающее на платформу, и хотя бы минимальная официальная документация. У «page-preview-tool» этого нет: ни один открытый каталог краулеров, ни документация известных платформ обмена сообщениями не связывают этот конкретный токен с реальным сервисом. Название читается как родовое описание функции, а не как имя бренда — и это важный сигнал, который стоит учитывать раньше, чем просто довериться категории «легитимный».

1. Что такое page-preview-tool на самом деле

По открытым источникам — каталогам известных fetcher-ов превью (Facebook, Twitter/X, LinkedIn, Discord, Slack, Telegram и другие честно называют себя брендом в UA), документации платформ, независимым базам User-Agent — токен page-preview-tool нигде не фигурирует как опознанный, задокументированный сервис с публичным оператором. Настоящие unfurl-боты почти всегда содержат в UA либо название компании, либо прямую ссылку на документацию (сравните: facebookexternalhit, LMArenaUnfurlBot/1.0 (...; +https://lmarena.ai)). Отсутствие такой идентификации здесь — не техническая деталь, а содержательный пробел.

Наиболее вероятное объяснение — самодельный скрипт, использующий общее, ничего не раскрывающее название вместо честной идентификации: например, внутренний инструмент какого-то мессенджера или CMS, который не потрудился (или сознательно не стал) называть себя брендом. Это не доказывает злого умысла само по себе, но не даёт и оснований для автоматического доверия, которое обычно закладывается в категорию «Превью ссылок в соцсетях».

2. Зачем page-preview-tool приходит на сайт

Поскольку официальной идентичности нет, о назначении можно судить только по поведению, описанному в черновике, и по общей логике категории:

• обход URL из шеринга, og:image, главных лендингов — паттерн, характерный и для честных превью-ботов, и для скрейперов, маскирующихся под них;
• отсутствие нормальной сессии и повторяемый path-паттерн — типично для автоматизации в целом, ничего конкретного о цели не говорит;
• сам факт использования родового, не брендированного названия — сигнал, что оператор, вероятно, не заинтересован в том, чтобы его можно было идентифицировать и связаться с вопросом о происхождении трафика — в отличие от крупных платформ, которые прямо называют себя в UA именно для этого.

Типичный кейс из черновика — маркетинг видит всплеск hits в аналитике без реальных сессий — сам по себе не говорит ни в пользу, ни против легитимности: так выглядит и настоящий превью-fetcher, и скрейпер, который просто не потрудился имитировать более убедительный UA.

3. Нагрузка и риски

Главный риск здесь — не столько нагрузка, сколько неопределённость: без публичной идентификации нельзя достоверно исключить, что под этим общим названием скрывается не превью-fetcher, а сбор контента для republishing или другая автоматизация, которая просто использует правдоподобно звучащее, но непроверяемое имя.

Смотрите не только абсолютный RPS, но и глубину обхода, повторы URL, отсутствие cookie/сессий и концентрацию на служебных страницах — при отсутствии официальной идентичности эти поведенческие сигналы становятся единственным источником информации о реальном назначении бота.

4. Как найти page-preview-tool в логах

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

# Топ URL, которые вычитывает бот
grep -i "page-preview-tool" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA — при отсутствии официального диапазона это единственный ориентир
grep -i "page-preview-tool" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность
grep -i "page-preview-tool" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

# Проверка на разовый (fetcher-подобный) vs системный (скрейпер-подобный) паттерн
grep -i "page-preview-tool" /var/log/nginx/access.log | awk '{print $7}' | sort -u | wc -l

Верификация. Здесь верификация важнее, чем для большинства других записей в энциклопедии: строку UA подделать может любой скрипт, а поскольку у «page-preview-tool» нет ни официального оператора, ни опубликованных IP-диапазонов, единственный доступный метод — смотреть ASN и поведение целиком, не доверяя самому факту наличия правдоподобно звучащего названия в UA:

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

5. robots.txt для page-preview-tool

Поскольку публичного оператора нет, надеяться на добросовестное соблюдение robots.txt не стоит — правило имеет смысл выставить на всякий случай, но полагаться нужно на серверную блокировку.

# Жёсткий запрет
User-agent: page-preview-tool
Disallow: /

# Компромисс: закрыть личный кабинет и служебные разделы, если решите не блокировать полностью
User-agent: page-preview-tool
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

6. Блокировка вручную и через TrafficVeil

Nginx:

if ($http_user_agent ~* "page-preview-tool") {
    return 403;
}

limit_req_zone $binary_remote_addr zone=pagepreviewtool:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "page-preview-tool") {
        limit_req zone=pagepreviewtool burst=20 nodelay;
    }
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "page-preview-tool" [NC]
RewriteRule ^ - [F,L]

TrafficVeil:

• найдите page-preview-tool в разделе ботов домена или в /system/bots;
• поскольку у бота нет подтверждённого оператора и нет способа связаться с ним, стандартная рекомендация — rate-limit или Disallow, а не выжидательный allow «на всякий случай», который обычно применяется к настоящим превью-ботам;
• если наблюдаемый паттерн действительно разовый и точечный (единичные URL без повторного обхода) — риск ниже, и мягкий режим допустим;
• после изменения сверьте логи: хиты page-preview-tool должны уйти в блок/лимит, а нужные поисковики остаться.

7. Что делать: короткий алгоритм

• Нет подтверждённой личности оператора, паттерн похож на системный обход, а не на разовый fetcher — блокируйте, это самый безопасный вариант;
• Паттерн действительно точечный (единичные URL, без повторов) — можно оставить мягкий режим (rate-limit) до появления более веских оснований для полного deny;
• Не путайте отсутствие явного вреда с подтверждённой легитимностью — это разные вещи, особенно когда у бота нет публичной документации;
• Не блокируйте по маске User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.

8. Открытый вопрос по категоризации

Стоит отдельно обратить внимание: присвоенная категория «Легитимный / Превью ссылок в соцсетях» для этого токена не подтверждается ничем, кроме родового, ничего не доказывающего названия. Настоящие боты в этой категории (Facebook External Hit, LMArenaUnfurlBot, BufferLinkPreviewBot) либо прямо называют платформу в UA, либо имеют официальную документацию — у «page-preview-tool» нет ни того, ни другого. Это тот же паттерн, что ранее был отмечен для записей «SEO Robot», «AI Article Writer» и «AI SEO Crawler» — расплывчатое, не брендированное название без проверяемого оператора. Рекомендую пересмотреть статус в сторону «неопознанный» и, возможно, провести ревизию всех подобных записей в базе разом, а не по одной.

9. Стратегия allow/deny для page-preview-tool