Не работает превью ссылок в Telegram и соцсетях — почему и что делать

Знакомая картина: маркетолог кидает ссылку на сайт в рабочий чат Telegram, и вместо аккуратной карточки с картинкой и заголовком в сообщении остаётся голый URL. Или превью «вечно грузится» и не появляется никогда. Или появляется через раз — в одном чате есть, в другом нет.

Дальше начинается стандартный круг: переписали og-теги, поменяли картинку, сбросили кеш, проверили сертификат. Ничего не изменилось. Валидаторы при этом показывают, что с разметкой всё в порядке.

Для сайтов на российском хостинге причина в большинстве случаев вообще не в разметке. Разберём по порядку.

TL;DR

Сначала проверьте, видит ли краулер вашу разметку вообще. Половина случаев — og-теги подставляются на клиенте JavaScript’ом, лежит относительный путь к картинке или картинка закрыта авторизацией.
Open Graph и Schema.org — разные вещи. Telegram, VK и WhatsApp читают Open Graph. JSON-LD со Schema.org они не читают вообще: он нужен поисковикам, а не мессенджерам.
Если разметка в порядке, а превью нет — почти наверняка сетевая фильтрация. Краулер приходит на сервер, запрос виден в логах с кодом 200, но ответ до краулера не доходит. Фильтрация односторонняя, поэтому сайт при этом прекрасно открывается у людей.
Первое действие — письмо в поддержку хостинга. Иногда это локальная проблема маршрутизации, которую чинят на стороне провайдера бесплатно и за несколько часов.
Если не помогло — GeoDNS-сплит. Российские посетители идут на основной сервер напрямую, весь остальной мир и краулеры соцсетей — через зарубежную точку входа. Два варианта точки входа: свой VPS с nginx (3–5 € в месяц) или CDN на Bunny.net (от 1 $ в месяц).
Cloudflare для этой задачи не подходит. Он заворачивает за границу весь трафик, включая российский, и сам нестабильно доступен из РФ.

Часть 1. Что вообще читают мессенджеры

Open Graph — это то, из чего строится карточка

Когда вы отправляете ссылку в Telegram, её открывает не ваш собеседник, а серверный краулер мессенджера — TelegramBot (like TwitterBot). Он скачивает HTML страницы, ищет в <head> метатеги Open Graph и по ним собирает превью:

<meta property="og:title" content="Заголовок карточки" />
<meta property="og:description" content="Два-три предложения описания" />
<meta property="og:image" content="https://example.ru/og/main.jpg" />
<meta property="og:url" content="https://example.ru/" />
<meta property="og:type" content="website" />

Если Open Graph нет, Telegram пытается взять <title> и <meta name="description"> — карточка получится текстовой, без картинки. Картинка берётся только из og:image (или из twitter:image, если он есть).

У остальных площадок логика та же: facebookexternalhit у Facebook, vkShare у VK, WhatsApp у WhatsApp. Все они опираются на Open Graph, различаясь мелочами в требованиях к картинке.

Schema.org решает другую задачу

Разметка Schema.org (обычно в виде блока JSON-LD) — это структурированные данные для поисковых систем. Она отвечает за расширенные сниппеты в выдаче Яндекса и Google: рейтинг у товара, цена, хлебные крошки, часы работы у организации, карточка рецепта.

Мессенджеры и соцсети её не читают. Это регулярная путаница: на сайте аккуратно размечены Organization, LocalBusiness и BreadcrumbList, разработчик отчитался «микроразметка стоит», а превью в Telegram как не было, так и нет. Оно и не появится — это разные механизмы, живущие в одной странице параллельно.

	Open Graph	Schema.org (JSON-LD)
Кто читает	Telegram, VK, WhatsApp, Facebook, LinkedIn	Яндекс, Google
Что даёт	карточка ссылки в чате и ленте	расширенный сниппет в поиске
Где лежит	`<meta property="og:*">` в `<head>`	`<script type="application/ld+json">`
Нужно ли обоим	да	да

Ставить нужно и то, и другое — просто не рассчитывайте, что одно заменит другое.

Требования к og:image, о которые спотыкаются чаще всего

Абсолютный URL с https://. Относительный путь вида /og/main.jpg работает не везде, и Telegram — как раз то место, где он не работает.
Картинка доступна без авторизации, cookie и редиректов. Проверяется одной командой: curl -sI https://example.ru/og/main.jpg из любого места, где нет ваших cookie.
JPEG или PNG. WebP формально поддерживается частью площадок, но ведёт себя нестабильно — для og-картинки берите JPEG.
Пропорции 1.91:1, ориентир 1200×630 px, вес до нескольких мегабайт.
Хост картинки должен быть доступен снаружи. Если og:image лежит на отдельном поддомене вроде cdn.example.ru, а превью чините только для основного домена — картинка так и не подтянется.

Кеш Telegram — отдельная ловушка

Telegram кеширует результат обхода, причём и удачный, и неудачный. Один раз не получив ответа, он какое-то время не пробует снова. Поэтому после любой правки нужно принудительно сбросить кеш: отправить ссылку боту @WebpageBot и дождаться подтверждения. Для Facebook то же самое делает Sharing Debugger, для VK — их отладчик OG-разметки.

Без сброса кеша вы будете проверять исправление и видеть старый результат.

Ещё три частые причины, не связанные с сетью

Теги подставляются на клиенте. SPA на React или Vue без серверного рендеринга отдаёт краулеру пустой <head>, а og-теги дописывает JavaScript уже в браузере. Краулер JavaScript не выполняет и видит пустоту. Лечится SSR или пререндером.
Краулера режет защита. Антибот-плагин, WAF, ограничение по частоте запросов или капча отдают боту челлендж вместо HTML. Проверяется по логам: код ответа не 200.
robots.txt закрывает картинки или всю страницу. Часть краулеров его уважает.

Проверить, что именно видит бот, можно прямо с любой машины:

curl -s -A "TelegramBot (like TwitterBot)" https://example.ru/ | grep -i "og:"

Если теги в выводе есть, разметка на месте и дело не в ней.

Часть 2. Сетевая причина: почему сайт открывается, а превью нет

Что происходит

Российские магистральные операторы фильтруют трафик к части IP-диапазонов крупных зарубежных площадок — в первую очередь Meta (автономная система AS32934), в 2026 году к этому добавилась планомерная деградация Telegram, о которой Роскомнадзор объявил в феврале 2026 года.

Ключевая деталь — фильтрация асимметричная. Входящий пакет от краулера до вашего сервера доходит нормально. Сервер формирует ответ. А вот ответ по пути обратно теряется.

Отсюда и вся странность симптомов:

в логах сервера запрос от TelegramBot или facebookexternalhit есть, и код ответа 200;
превью при этом не появляется;
сайт у обычных посетителей работает идеально — их трафик никто не фильтрует;
поведение нестабильное: сработало один раз из пяти, потому что фильтрация задевает не весь диапазон, а отдельные подсети.

Именно поэтому переписывание тегов ничего не даёт: разметка правильная, её просто некому доставить.

Диагностика за пять минут

Зайдите по SSH на сервер сайта и попробуйте достучаться до площадок в обратную сторону:

curl -sI --max-time 10 https://www.facebook.com/
curl -sI --max-time 10 https://api.telegram.org/

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

Заодно посмотрите, приходят ли краулеры вообще:

grep -iE "facebookexternalhit|TelegramBot|vkShare|WhatsApp" /var/log/nginx/access.log | tail -20

Есть запросы с кодом 200, а превью нет — вопрос закрыт, проблема в обратном маршруте.

Часть 3. Шаг ноль — письмо в поддержку хостинга

Это первое, что нужно сделать, и делать это нужно до любых архитектурных решений. Иногда проблема локальная: конкретный аплинк провайдера, конкретный маршрут, конкретный IP, попавший под фильтр. Такое чинится на стороне хостера бесплатно и за несколько часов.

Формулировка, которая экономит переписку:

Здравствуйте. На сервере не проходит исходящий трафик к подсетям Meta (AS32934) и к серверам Telegram: curl -sI --max-time 10 https://www.facebook.com/ уходит в таймаут. Входящие запросы от краулеров этих сервисов до сервера доходят и отдаются с кодом 200 — проблема односторонняя, на обратном маршруте. Просьба проверить маршрутизацию исходящего трафика к этим диапазонам с вашей стороны и, если проблема в аплинке, рассмотреть смену маршрута. Дополнительно прошу подтвердить, что на вашей стороне нет фильтров, режущих запросы краулеров соцсетей.

Заодно спросите две вещи:

можно ли сменить IP-адрес сервера — если под фильтр попал конкретный адрес, переезд на соседний решает всё;
нет ли на стороне хостера собственного антибот-фильтра — на шаред-хостингах такое встречается и режет краулеров молча.

Если поддержка развела руками — переходим к архитектуре.

Часть 4. Решение: GeoDNS-сплит

Идея

Одна и та же A-запись домена отдаёт разный IP-адрес в зависимости от того, из какой страны пришёл DNS-запрос:

Россия → IP основного сервера. Напрямую, без посредников. Это ваши 95% трафика, и их маршрут не меняется вообще.
Весь остальной мир, включая краулеры соцсетей → IP зарубежной точки входа, которая проксирует запросы на основной сервер.

Краулеры Telegram, Meta и VK ходят из-за рубежа, поэтому попадают во вторую ветку и получают ответ от зарубежной ноды — той, чей обратный маршрут никто не фильтрует.

Работает это именно потому, что фильтруются конкретные подсети соцсетей, а не весь зарубежный трафик подряд. Ваш собственный прокси в Германии в эти списки не входит, и связка «сервер в РФ ↔ нода в Германии» остаётся живой. Прежде чем что-то настраивать, это стоит проверить с сервера: curl -sI --max-time 10 https://<IP-кандидата>/.

Отдельный плюс схемы: российские посетители остаются на российском сервере. Формы, персональные данные и скорость для основной аудитории не меняются, а если зарубежное плечо когда-нибудь отвалится, сайт для России продолжит работать — сломаются только превью, то есть ровно то, что и так сейчас сломано.

Ограничение, о котором надо знать: гео-логика DNS работает по адресу резолвера, а не самого пользователя. С публичными резолверами (8.8.8.8 и подобные) это смягчается механизмом EDNS Client Subnet, но точность остаётся на уровне страны. Для нашей задачи этого достаточно с запасом.

Вариант А. Свой реверс-прокси на зарубежном VPS

Самый прямолинейный путь. Берётся дешёвый VPS в Германии, Нидерландах или Польше — 1 ядро, 1–2 ГБ памяти, 3–5 € в месяц, — на нём поднимается nginx, который перекладывает запросы на основной сервер.

Что важно не забыть в конфиге:

правильный Host и SNI при проксировании на HTTPS-бэкенд (proxy_set_header Host, proxy_ssl_name, proxy_ssl_server_name on) — иначе бэкенд отдаст не тот виртуальный хост или оборвёт handshake;
собственный сертификат Let’s Encrypt на ноде прокси;
проброс реального IP (X-Forwarded-For плюс set_real_ip_from на основном сервере) — без этого вся зарубежная аудитория склеится в логах в один адрес, что сломает аналитику и антифрод-логику;
таймауты и буферизацию под ваш бэкенд.

Плюсы	Минусы
Полный контроль над конфигурацией	Ещё один сервер, который надо обновлять и мониторить
Предсказуемая фиксированная цена	Одна точка отказа без резервирования
Можно проксировать что угодно, включая нестандартные схемы	Сертификаты, логи, ротация — всё своё

Вариант Б. CDN с edge-кешем на Bunny.net

Вместо собственного сервера — сеть точек присутствия. Заводится Pull Zone, в качестве origin указывается основной сервер, дальше edge-узлы Bunny сами ходят за контентом и кешируют его.

Для нашей задачи это ложится особенно удачно: краулеру нужны всего две вещи — HTML страницы и файл og:image. И то, и другое отлично кешируется на краю, поэтому в типичном случае краулер получает ответ прямо из edge-кеша, вообще не дожидаясь российского origin. Быстро, стабильно и без нагрузки на основной сервер.

Цены на август 2026 года:

Bunny DNS — бесплатно: до 500 зон, без лимита на запросы, гео- и latency-маршрутизация (smart records) входит в бесплатный набор. Именно он и даёт нам GeoDNS.
CDN-трафик: 0,01 $/ГБ по Европе и Северной Америке, 0,03 $/ГБ по Азии и Океании, 0,045 $/ГБ по Южной Америке, 0,06 $/ГБ по Ближнему Востоку и Африке.
Минимальный платёж — 1 $ в месяц. Для сайта, у которого через CDN идёт только зарубежный хвост трафика и обходы краулеров, счёт этим минимумом и ограничится.

Что придётся настроить аккуратно:

исключить из кеша динамику — админку, корзину, личный кабинет, обработчики форм; в Bunny это делается правилами Pull Zone;
разумный TTL для HTML — короткий, минуты, иначе после правки og-тегов краулер ещё сутки будет видеть старую версию;
реальный IP посетителя — приходит заголовком, origin надо научить его читать;
сброс кеша после публикации изменений — на стороне CDN, а потом на стороне Telegram.

Плюсы	Минусы
Не нужен собственный сервер и его обслуживание	Кеш надо настраивать осознанно, иначе можно закешировать лишнее
TLS-сертификат выпускается и продлевается автоматически	Оплата по трафику, а не фикс (для мелких сайтов разница копеечная)
Ответ краулеру отдаётся из кеша, origin не нагружается	Меньше контроля над низкоуровневым поведением
Резервирование из коробки, нет единой точки отказа	Ещё один внешний сервис в контуре

Что выбрать

	Свой VPS + nginx	Bunny.net CDN	Cloudflare
Цена в месяц	3–5 €	от 1 $	0 $ на free-плане
Кто обслуживает	вы	провайдер	провайдер
Российский трафик	идёт напрямую	идёт напрямую	заворачивается за границу
Доступность из РФ	стабильная	стабильная	нестабильная
Ускорение зарубежных посетителей	нет	да, edge-кеш	да
Порог входа	нужен сисадмин	средний	низкий

Практическое правило: если в команде есть человек, который спокойно поддерживает ещё один Linux-сервер, — берите VPS, он предсказуемее. Если такого человека нет и не хочется заводить, — Bunny.net закрывает задачу без своего железа и стоит около доллара.

Почему не Cloudflare

Cloudflare чинит превью — это правда. И всё же для сайта с российской аудиторией он в этой задаче создаёт больше проблем, чем решает:

Он заворачивает весь трафик, а не зарубежный хвост. Российский посетитель пойдёт на зарубежный edge и вернётся обратно — это прямой удар по TTFB и LCP у 95% вашей аудитории ради 5% случаев с превью.
Cloudflare сам нестабильно доступен из России. С ноября 2024 года Роскомнадзор блокирует TLS-соединения с расширением ECH, которое Cloudflare включил по умолчанию; полного запрета нет, но доступность сайтов за Cloudflare из российских сетей зависит от домена, оператора и региона. Вы меняете сломанные превью на риск сломанного сайта.
Собственные антибот-механизмы Cloudflare ломают превью. Челлендж, выданный краулеру вместо HTML, — это та же пустая карточка, только по другой причине.

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

Оговорка по-честному: любой зарубежный CDN, включая Bunny, Роскомнадзор в своих рекомендациях не приветствует. Разница в том, что при гео-сплите зарубежное плечо не является критическим — при его отказе сайт для России продолжает работать, теряются только превью.

Часть 5. Порядок работ

Проверить разметку: curl -s -A "TelegramBot (like TwitterBot)" https://example.ru/ | grep -i "og:". Если тегов нет — чинить разметку, дальше не идти.
Проверить доступность og:image без cookie и авторизации, убедиться, что URL абсолютный.
Сбросить кеш через @WebpageBot и проверить ещё раз — возможно, всё уже работает.
Диагностировать сеть: curl -sI --max-time 10 https://www.facebook.com/ с сервера. Таймаут — идём дальше.
Написать в поддержку хостинга по шаблону выше. Подождать ответа: это самый дешёвый сценарий.
Выбрать точку входа — VPS или Bunny.net — и проверить с сервера, что связность с её адресом в порядке.
Развернуть прокси или Pull Zone, проверить работу по прямому IP до всякого DNS.
За сутки до переключения снизить TTL записей до 300 секунд.
Перенести в GeoDNS все записи зоны: A, AAAA, CNAME, MX, TXT со SPF, DKIM, DMARC. Потерянная MX-запись роняет почту — это самая частая авария при таком переезде.
Настроить гео-правило на основной A-записи: Россия → IP основного сервера, остальное → точка входа.
Переключить NS у регистратора, дождаться раскатки (от 20 минут до нескольких часов).
Выпустить сертификат на точке входа, проверить сайт из России и из-за рубежа.
Сбросить кеш Telegram, Facebook и VK, проверить превью в реальном чате.
Через сутки заглянуть в логи: краулеры должны приходить и получать 200, посетители из РФ — идти напрямую.

Take aways

Превью в мессенджерах и микроразметка для поиска — две независимые системы. Open Graph для чатов, Schema.org для выдачи. Одно не заменяет другое, и путаница между ними стоит недель бесполезной работы.
Если разметка валидна, а превью нет, — проблема почти всегда сетевая. Запрос в логах с кодом 200 при отсутствующем превью — это подпись асимметричной фильтрации, и никакими правками тегов она не лечится.
Начинайте с бесплатного хода. Письмо в поддержку хостинга занимает десять минут и в части случаев закрывает вопрос полностью.
GeoDNS-сплит — правильная форма решения, потому что он не трогает основную аудиторию. Всё, что заворачивает российский трафик за границу целиком, чинит витрину ценой скорости и надёжности основного сайта.
Цена вопроса невелика: 3–5 € за VPS или около доллара за CDN. Сравните с недельным спором «а точно ли у нас правильные og-теги».

Смежные материалы: Яндекс.Метрика роняет Core Web Vitals, Миграция сайта на новую платформу без потери SEO.