Після зміни обкладинки або SEO-метаданих можна побачити дивну ситуацію: Telegram уже показує нове og:image, а LinkedIn продовжує відображати старе зображення або взагалі не показує його.
Перша реакція зазвичай проста: "Open Graph налаштований неправильно".
Але якщо одна платформа вже прочитала правильне зображення, це сильний сигнал, що проблема може бути не в самих тегах, а в тому, коли і як конкретна платформа востаннє сканувала сторінку.
Правильний Open Graph не гарантує миттєве оновлення на всіх платформах
Telegram, LinkedIn та інші сервіси не зобов’язані отримувати сторінку одночасно.
Кожен сервіс має власного робота, власні правила повторного сканування і власний кеш.
Тому одна й та сама URL-адреса в один момент може мати різні попередні перегляди на різних платформах.
Спочатку перевірте HTML, який реально отримує робот
curl -s https://example.com/article \ | grep -iE \ 'og:title|og:description|og:image|og:url'Не починайте з кешу, доки не переконаєтеся, що поточна HTML-відповідь справді містить потрібні значення.
Особливо це важливо для застосунків із клієнтським рендерингом. Якщо meta tags змінюються лише після виконання JavaScript у браузері, робот соціальної мережі може їх взагалі не побачити.
Для такого сценарію SSR або серверно сформовані meta tags часто є критично важливими.
Перевірте базовий набір Open Graph-тегів
<meta property="og:title" content="Article title"> <meta property="og:description" content="Article description"> <meta property="og:image" content="https://example.com/media/cover.jpg"> <meta property="og:url" content="https://example.com/article"> <meta property="og:type" content="article">Якщо Telegram уже показує правильну картинку, og:image скоріше за все доступний хоча б для одного зовнішнього робота.
Але все одно потрібно перевірити повний набір тегів, абсолютні URL-адреси та відсутність суперечливих значень.
Перевірте саме URL з og:image, а не тільки сторінку
curl -I \ https://example.com/media/cover.jpgЗображення повинно бути доступне без авторизації та без внутрішньої сесії користувача.
Перевірте HTTP-статус, Content-Type, перенаправлення та те, чи робот взагалі може отримати файл.
Якщо URL відкривається тільки у вашому браузері через cookie або приватний доступ, соціальна мережа може не отримати його.
Для social preview краще віддавати абсолютні URL-адреси
<!-- Better --><meta property="og:image" content="https://example.com/media/cover.jpg"> <!-- Avoid relying on --><meta property="og:image" content="/media/cover.jpg">Найпідступніший випадок - коли файл змінився, а URL залишився тим самим
Уявімо, що обкладинка /media/post-cover.jpg була замінена новим файлом, але URL залишився незмінним.
Для браузера це може виглядати нормально, особливо після очищення локального кешу.
А соціальна платформа могла вже зберегти старий файл під цим URL і не мати причини негайно завантажувати його повторно.
У попереднього перегляду може бути кілька незалежних кешів
page HTML cache ↓CDN / reverse proxy cache ↓image cache ↓platform crawler cache ↓preview already attached to a postЧерез це "я вже змінила тег" не завжди означає "LinkedIn уже бачить новий тег".
Спочатку потрібно зрозуміти, на якому саме рівні залишився старий стан.
Telegram і LinkedIn не є взаємною перевіркою кешу
Якщо Telegram показує нову обкладинку, це підтверджує, що Telegram зміг отримати її.
Це не доводить, що LinkedIn уже повторно просканував сторінку.
І навпаки: старий LinkedIn preview не доводить, що Open Graph зараз неправильний.
Редагування вже створеного допису може не перебудувати старий preview
Ще один окремий сценарій - коли посилання вже було вставлене в допис, а потім сторінку або обкладинку змінили.
Навіть після повторного сканування URL сама вже створена картка в дописі може поводитися інакше, ніж нова вставка того самого посилання.
Тому під час діагностики корисно окремо порівнювати: новий preview для URL і картку, яка вже була прикріплена до раніше створеного допису.
Діагностуйте в правильному порядку
1. Перевірити HTML без браузерного JavaScript.2. Перевірити og:title / og:description / og:image / og:url.3. Відкрити og:image напряму.4. Перевірити HTTP status і Content-Type.5. Перевірити redirects.6. Переконатися, що image URL абсолютний.7. Перевірити, чи не змінився файл під старим URL.8. Окремо перевірити кеш конкретної платформи.9. Перевірити нову вставку URL.10. Лише після цього міняти Open Graph-логіку.Не виправляйте правильний код тільки через старий кеш
Це одна з найнеприємніших пасток.
Коли preview неправильний, легко почати міняти SSR, meta tags, canonical URL або генерацію медіа, хоча поточний HTML уже правильний.
Так можна створити нову помилку, намагаючись виправити старий кеш.
Для змінюваних обкладинок корисний стабільний спосіб версіювання URL
/media/article-cover-v1.jpg/media/article-cover-v2.jpg або /media/article-cover.jpg?v=2Головна ідея тут не в конкретному форматі параметра, а в тому, щоб зміна зображення могла отримати новий ресурсний ідентифікатор.
Це зменшує залежність від того, коли зовнішній робот вирішить оновити кеш старої адреси.
У SPA важливо перевіряти саме серверний HTML
У Vue/Inertia-застосунку браузер може показувати правильний title і meta після гідрації, але робот соціальної мережі може працювати лише з початковою HTML-відповіддю.
Тому перевірка у DevTools після повного завантаження сторінки не завжди достатня.
Надійніша перевірка - подивитися сирий HTML через curl або інший клієнт без виконання JavaScript.
Переконайтеся, що різні User-Agent не отримують різний HTML випадково
curl -s \ -A "Mozilla/5.0" \ https://example.com/article \ | grep -i 'og:image' curl -s \ -A "SocialPreviewBot" \ https://example.com/article \ | grep -i 'og:image'Зазвичай сторінка повинна віддавати однакові Open Graph-дані незалежно від робота.
Якщо reverse proxy, middleware або антибот-захист змінює відповідь для певного User-Agent, це вже окрема причина неправильного preview.
Для складних випадків допомагають серверні логи
Якщо незрозуміло, чи платформа взагалі повторно заходила на сторінку, корисно перевірити вебсерверні логи.
Вони можуть показати час запиту, User-Agent, HTTP-статус і те, чи робот звертався окремо до og:image.
Це значно надійніше за припущення "я натиснула refresh, значить платформа точно перечитала сторінку".
Корисно мати коротку матрицю перевірок
[ ] raw HTML contains current OG tags[ ] og:image returns 200[ ] og:image Content-Type is image/*[ ] image is public[ ] redirects are valid[ ] canonical and og:url point to expected page[ ] SSR output matches browser-visible metadata[ ] Telegram shows expected preview[ ] LinkedIn fresh preview shows expected data[ ] server logs confirm crawler requestРізний preview на різних платформах не означає автоматично різний HTML
Коли Telegram уже бачить нове Open Graph-зображення, а LinkedIn ще показує старе, це не привід одразу переписувати SEO-логіку.
Спочатку потрібно підтвердити поточний серверний HTML, доступність og:image, правильність HTTP-відповіді та SSR.
Якщо все це правильно, наступна підозра - окремий кеш платформи або вже збережена картка старого допису.
Попередній перегляд потрібно діагностувати як ланцюг: HTML -> URL зображення -> HTTP -> робот платформи -> кеш платформи -> конкретна картка допису.
Якщо одна платформа вже бачить правильне зображення, а інша ні, перевіряйте не тільки Open Graph - перевіряйте ще й момент останнього сканування та кеш конкретної платформи.
