WhatsApp Bot: как работает загрузка превью ссылок и что видно в логах

WhatsApp Bot в серверных логах чаще всего означает не поисковый crawler и не систему массовой индексации, а автоматический запрос, связанный с созданием превью ссылки в WhatsApp.

Когда пользователь вставляет URL в чат, WhatsApp пытается получить страницу и сформировать карточку: заголовок, описание, изображение и адрес ресурса. Для владельца сайта такой запрос является автоматическим трафиком, хотя его инициатором косвенно выступает реальный пользователь.

Поэтому правильнее классифицировать WhatsApp как Social / Link Preview, а не как универсального веб-краулера.

Параметр	Значение
Название	WhatsApp link preview client
Оператор	Meta / WhatsApp
Основной токен	WhatsApp
Документированный формат UA	WhatsApp/2.x.x.x A|I|N
Назначение	Создание превью конкретной ссылки
HTTP-метод	GET
Open Graph	Используется для формирования карточки
Массовая поисковая индексация	Нет
Связанная Meta-инфраструктура	facebookexternalhit и другие link-preview механизмы Meta
AI training	Не является назначением WhatsApp link-preview запроса
Категория TrafficVeil	Социальные / сервисные агенты, Link Preview
Статус	Легитимный при подтверждённом поведении

Зачем WhatsApp загружает страницу сайта

Представим, что пользователь вставляет в сообщение ссылку:

https://example.com/article

Вместо показа одного URL WhatsApp старается создать более информативную карточку.

Она может содержать:

• название страницы;
• краткое описание;
• изображение;
• домен;
• сам URL.

Для этого приложению необходимо получить исходный HTML страницы и найти метаданные, предназначенные для социальных сервисов.

Запрос может появиться ещё до отправки сообщения

Это одна из самых интересных особенностей WhatsApp link preview.

Автоматический запрос может возникнуть в access.log уже тогда, когда пользователь просто вставил URL в поле сообщения и ещё не нажал «Отправить».

Поэтому наличие запроса WhatsApp не доказывает, что ссылка действительно была отправлена получателю или опубликована в группе.

Для веб-аналитики это принципиально важно.

Событие:

WhatsApp requested /article

нельзя автоматически интерпретировать как:

пользователь поделился /article

или тем более как реальный переход посетителя.

Как выглядит User-Agent WhatsApp

В документированном формате используется:

WhatsApp/2.x.x.x A|I|N

Значение после версии помогает определить тип клиента.

Суффикс	Среда
A	Android
I	iOS
N	Web

Примеры документированных вариантов:

WhatsApp/2.22.20.72 A
WhatsApp/2.22.19.78 I
WhatsApp/2.2236.3 N

Версии изменяются вместе с самим приложением, поэтому TrafficVeil не должен хранить полную строку как жёсткий идентификатор.

Практичнее использовать токен:

WhatsApp/

а затем анализировать оставшуюся часть строки.

Почему одного токена WhatsApp недостаточно

User-Agent — обычный HTTP-заголовок.

Злоумышленник или скрипт может отправить:

User-Agent: WhatsApp/2.22.20.72 A

не имея никакого отношения к WhatsApp.

Поэтому правило:

UA contains WhatsApp → bypass WAF

создаёт ненужный риск.

Для принятия решения TrafficVeil желательно учитывать:

• полный User-Agent;
• IP и ASN;
• HTTP-метод;
• запрашиваемый URL;
• частоту;
• характер дальнейших запросов;
• соответствие типичному link-preview сценарию.

facebookexternalhit и WhatsApp — почему в логах всё сложнее

Экосистема Meta использует общую инфраструктуру для обработки ссылок.

Один из наиболее известных агентов:

facebookexternalhit/1.1

Он принадлежит Meta и используется для получения информации о ссылках, опубликованных в приложениях семейства Meta.

Crawler собирает и кэширует такие данные, как:

• title;
• description;
• thumbnail;
• метаданные страницы.

Поэтому для диагностики проблем с WhatsApp preview недостаточно искать только слово WhatsApp.

Полезно отдельно анализировать и семейство Meta link-preview crawlers.

Не смешивайте WhatsApp preview с AI-crawler Meta

Это особенно важно для правил TrafficVeil.

Meta использует разные User-Agent для разных задач.

facebookexternalhit связан с social/link preview.

Другие агенты Meta могут иметь иное назначение, включая сбор общедоступного веб-контента.

Поэтому нельзя создавать одно правило:

Meta = Allow

или:

Meta = Deny

Правильнее классифицировать конкретного агента и его функцию.

Какие Open Graph-теги читает WhatsApp

Для качественной карточки странице стоит отдавать стандартную Open Graph-разметку непосредственно в HTML.

Базовый вариант:

<meta property="og:title" content="Название материала">
<meta property="og:description" content="Краткое описание страницы">
<meta property="og:url" content="https://example.com/article">
<meta property="og:image" content="https://example.com/article-cover.jpg">

Эти значения позволяют WhatsApp сформировать информативное превью вместо простой текстовой ссылки.

Почему server-side HTML особенно важен

Для link-preview crawler нельзя рассчитывать на то, что метаданные обязательно появятся после выполнения клиентского JavaScript.

Если приложение сначала отдаёт:

<head>
  <title>Loading...</title>
</head>

а затем React или другой JavaScript меняет Open Graph-теги в браузере, автоматический fetcher может получить исходную версию без нужных данных.

Надёжнее формировать:

• og:title;
• og:description;
• og:image;
• og:url

на сервере или при SSR/SSG.

Почему Open Graph лучше располагать в начале HTML

В документации WhatsApp отдельно обращается внимание на расположение метаданных внутри HTML.

Для стабильной работы лучше помещать Open Graph непосредственно в <head> и не раздувать начало страницы огромными inline-скриптами и стилями.

Практически это означает:

<head>
  <title>...</title>

  <meta property="og:title" content="...">
  <meta property="og:description" content="...">
  <meta property="og:image" content="...">
  <meta property="og:url" content="...">

  ...
</head>

а не размещение OG-разметки глубоко после сотен килобайт HTML.

Accept-Language: ещё один интересный сигнал

При link-preview запросе WhatsApp может передавать заголовок:

Accept-Language

со значением языка пользователя.

Например:

Accept-Language: en

или:

Accept-Language: de

Это позволяет сайту отдавать соответствующие локализованные метаданные.

Но использовать язык как доказательство подлинности агента нельзя — этот HTTP-заголовок тоже легко подделывается.

Как найти WhatsApp в access.log

Базовый поиск:

grep -i "whatsapp" /var/log/nginx/access.log

Количество запросов:

grep -ic "whatsapp" /var/log/nginx/access.log

Наиболее активные IP:

grep -i "whatsapp" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -nr \
| head -20

Наиболее часто запрашиваемые URL:

grep -i "whatsapp" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -nr \
| head -30

HTTP-коды:

grep -i "whatsapp" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -nr

Стоит отдельно искать Meta preview crawler

grep -iE "whatsapp|facebookexternalhit" /var/log/nginx/access.log

Такой поиск полезнее простого grep whatsapp при диагностике отсутствующих карточек.

Но в аналитике эти агенты лучше сохранять раздельно, поскольку происхождение и механизм запроса могут отличаться.

Как выглядит нормальный профиль WhatsApp link preview

Для обычного сценария характерно:

• запрашивается конкретный URL;
• используется GET;
• нет полноценной пользовательской сессии;
• нет типичной последовательности человеческой навигации;
• запрос появляется рядом с моментом потенциального sharing;
• целью является получение метаданных страницы.

Необязательно видеть следующий переход пользователя после fetch.

Человек мог просто вставить ссылку, посмотреть карточку и удалить сообщение.

Что для WhatsApp нетипично

Если клиент с UA WhatsApp:

• перебирает тысячи страниц sitemap;
• сканирует пагинацию;
• ищет /.env;
• открывает /.git/config;
• атакует /wp-login.php;
• отправляет POST в формы авторизации;
• перебирает phpMyAdmin;
• создаёт устойчивый высокий RPS часами;

такое поведение плохо соответствует задаче создания link preview.

Даже наличие корректно выглядящего User-Agent не должно мешать TrafficVeil применять обычные правила безопасности.

Какая нагрузка от WhatsApp считается нормальной

Здесь нельзя применять логику традиционного crawler.

WhatsApp не должен по собственной инициативе обходить весь сайт.

Количество запросов в значительной степени зависит от того, сколько конкретных URL пользователи вставляют в WhatsApp.

Если материал активно распространяется в чатах, число автоматических fetch может увеличиться одновременно с популярностью ссылки.

Это отличает WhatsApp от обычного crawler:

Сценарий	Характер трафика
Популярная статья активно пересылается	Повторные обращения к одному или нескольким URL
Новая страница никто не распространяет	WhatsApp-запросов может не быть вообще
Тысячи URL обходятся последовательно	Нетипично для обычного link preview
Высокий RPS на security-sensitive URL	Требуется проверка spoofing или другой автоматизации

Почему WhatsApp может искажать статистику

Для веб-сервера fetch preview — обычный HTTP request.

Поэтому server-side analytics может ошибочно считать:

1 request = 1 visitor

хотя фактически страницу загрузил автоматический агент.

Это способно завышать:

• число запросов;
• просмотры страниц в серверной аналитике;
• bandwidth;
• географию «посетителей»;
• количество дата-центровых IP;
• популярность конкретного URL.

TrafficVeil полезно отделять такой трафик от человеческих визитов.

Почему нельзя считать запрос доказательством отправки ссылки

Поскольку fetch может начаться ещё во время подготовки сообщения, запрос означает только:

WhatsApp попытался получить этот URL для preview

Он не означает достоверно:

сообщение было отправлено

или:

получатель открыл ссылку

Это важно при построении маркетинговой аналитики и атрибуции.

Что произойдёт, если заблокировать WhatsApp preview

Сам URL обычно не перестанет работать.

Пользователь всё ещё может отправить обычную ссылку.

Но WhatsApp может не получить данные для красивой карточки.

В результате вместо:

• изображения;
• заголовка;
• описания;
• привлекательного preview

получатель увидит менее информативный URL.

Для медиа, магазина, SaaS, блога или новостного сайта это может ухудшить внешний вид ссылок при распространении.

Почему CAPTCHA особенно вредна для link preview

Bot protection иногда не блокирует запрос напрямую, а возвращает challenge page.

Например, вместо статьи crawler получает:

<title>Checking your browser...</title>

Для браузера человека это может быть промежуточным этапом.

Для link-preview агента результат часто оказывается бесполезным: Open Graph исходной страницы не получен.

Поэтому при диагностике необходимо искать не только 403, но и ответы 200 OK, внутри которых фактически находится страница CAPTCHA.

Почему redirect chains тоже создают проблемы

Ссылка может проходить через несколько перенаправлений:

http://example.com
→ https://example.com
→ https://www.example.com
→ https://www.example.com/article

Каждый дополнительный hop увеличивает время получения конечного HTML.

Для социальных preview-клиентов лучше иметь короткую и предсказуемую цепочку redirect.

Как диагностировать отсутствующий preview

Если карточка WhatsApp не появляется:

1. проверьте, что URL доступен без авторизации;
2. убедитесь, что сервер возвращает 200 OK;
3. посмотрите исходный HTML, а не DOM после JavaScript;
4. проверьте og:title;
5. проверьте og:description;
6. проверьте og:image;
7. убедитесь, что изображение доступно извне;
8. проверьте redirects;
9. посмотрите WAF logs;
10. поищите WhatsApp и facebookexternalhit;
11. убедитесь, что crawler не получает CAPTCHA, 403 или 429.

Как самостоятельно посмотреть страницу с User-Agent WhatsApp

curl -A "WhatsApp/2.22.20.72 A" \
-L \
https://example.com/article

Чтобы посмотреть только заголовки:

curl -I \
-A "WhatsApp/2.22.20.72 A" \
https://example.com/article

Но такой тест показывает лишь реакцию вашего сервера на User-Agent. Он не подтверждает, что реальный WhatsApp будет использовать именно этот IP, версию клиента или сетевой маршрут.

Нужно ли управлять WhatsApp через robots.txt

robots.txt можно использовать как декларативное правило для совместимых агентов, но для link preview не стоит рассматривать его как security control.

Например:

User-agent: WhatsApp
Disallow: /

не является техническим эквивалентом блокировки на WAF.

Кроме того, реальная инфраструктура Meta link preview может идентифицироваться другими User-Agent.

Поэтому для гарантированного ограничения используйте TrafficVeil, reverse proxy или веб-сервер.

Блокировка через Nginx

Если превью WhatsApp принципиально не требуется:

if ($http_user_agent ~* "whatsapp") {
    return 403;
}

При необходимости отдельно рассматривайте Meta preview crawler:

if ($http_user_agent ~* "facebookexternalhit") {
    return 403;
}

Однако широкая блокировка второго агента способна затронуть link preview не только WhatsApp, но и других сервисов Meta.

Блокировка через Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} WhatsApp [NC]
RewriteRule ^ - [F,L]

И снова: правило фильтрует строку User-Agent, а не подтверждённую идентичность клиента.

Нужен ли WhatsApp rate limit

В большинстве случаев специально ограничивать легитимный link-preview fetch не требуется.

Если один материал вирусно распространяется, повышение количества запросов может быть естественным.

Но если UA WhatsApp стабильно генерирует сотни запросов в секунду или обходит огромное число несвязанных URL, проблема уже не похожа на обычное создание карточек.

Тогда нужно анализировать:

• IP;
• ASN;
• URL;
• методы;
• частоту;
• повторяемость;
• security-paths;
• соседние User-Agent.

WhatsApp в TrafficVeil

Для TrafficVeil правильная классификация — легитимный link-preview агент, а не обычный crawler.

При обнаружении желательно:

1. найти токен WhatsApp;
2. сохранить полный User-Agent;
3. определить Android/iOS/web вариант, если он указан;
4. проверить IP и ASN;
5. посмотреть URL;
6. проверить HTTP-метод;
7. исключить security scanning;
8. не смешивать WhatsApp с другими Meta crawlers;
9. применить соответствующую политику.

Как должна выглядеть карточка WhatsApp в TrafficVeil

Поле	Рекомендуемое значение
Название	WhatsApp Link Preview
Оператор	Meta / WhatsApp
Категория	Social / Link Preview
Статус	Легитимный
Основной токен	WhatsApp
Назначение	Получение метаданных для карточки ссылки
SEO crawler	Нет
Рекомендация	Allow при нормальном link-preview поведении
Проверка	UA + IP/ASN + URL + поведение

Когда WhatsApp лучше разрешить

• сайт активно распространяется через мессенджеры;
• важен внешний вид карточек;
• это новостной или контентный проект;
• это интернет-магазин;
• пользователи отправляют ссылки на товары;
• Meta/WhatsApp traffic соответствует link-preview профилю.

Когда блокировка допустима

• владелец принципиально не хочет создавать preview;
• URL не предназначены для публичного sharing;
• UA явно подделан;
• источник занимается security scanning;
• поведение не соответствует получению конкретных ссылок;
• наблюдается вредоносная или аномальная автоматизация.

Практический чек-лист при обнаружении WhatsApp

1. Посмотрите полный User-Agent. Простого слова WhatsApp недостаточно.
2. Проверьте URL. Один или несколько конкретных shared URL являются нормальным сценарием.
3. Проверьте метод. Для preview ожидается GET.
4. Посмотрите IP и ASN. Не создавайте bypass только по UA.
5. Проверьте Open Graph. Карточка зависит от корректной серверной разметки.
6. Найдите facebookexternalhit. Meta использует и другие preview-механизмы.
7. Проверьте WAF. CAPTCHA, 403 и 429 способны сломать preview.
8. Не считайте fetch посещением. Это автоматический запрос, а не человек на странице.
9. Не считайте его доказательством share. Fetch способен произойти ещё до отправки сообщения.

Итог

WhatsApp в access.log обычно означает автоматическое получение страницы для создания link preview. Это легитимный сервисный запрос, косвенно инициированный пользователем, а не систематический поисковый обход сайта.

Документированный User-Agent имеет семейство WhatsApp/2.x.x.x A|I|N, позволяющее различать Android, iOS и web-клиенты. В экосистеме Meta при обработке ссылок также может встречаться facebookexternalhit, поэтому искать только один токен недостаточно.

Главная техническая задача владельца сайта — обеспечить доступность корректной Open Graph-разметки непосредственно в исходном HTML. Если WAF возвращает CAPTCHA, 403 или 429, карточка ссылки может не сформироваться, хотя сам сайт прекрасно работает у людей.

Для TrafficVeil WhatsApp лучше классифицировать как Social / Link Preview. Нормальные запросы имеет смысл разрешать, но не предоставлять безусловный bypass только по User-Agent. Сочетание UA, IP, ASN, HTTP-метода, URL и поведенческого профиля позволяет отделить реальное создание превью от клиента, который лишь назвался WhatsApp.