Налаштування Open Graph та Twitter Card мета-тегів

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Налаштування Open Graph та Twitter Card мета-тегів
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Після публікації посилання на новий продукт у Facebook замість картки з ціною та назвою відображається випадковий банер. Це типова ситуація при відсутності коректних Open Graph і Twitter Card мета-тегів. Без них соцмережі вибирають контент на свій розсуд: перше зображення, уривок тексту або alt-тег. Налаштування OG-тегів вирішує цю проблему: ми впроваджуємо og:title, og:description, og:image для кожної сторінки, гарантуючи гарний сніпет. Результат — зростання клікабельності (CTR) на 30–50% у соціальних мережах. Зв'яжіться з нами — оцінимо поточну мікророзмітку та назвемо терміни.

Чому Open Graph та Twitter Card так важливі?

Open Graph — протокол, розроблений Facebook, а Twitter Card — аналогічний стандарт для Twitter. Вони фіксують заголовок, опис, зображення та тип контенту (продукт, стаття, відео). Без них соцмережі показують випадковий контент: замість заголовка — alt-текст картинки, замість опису — уривок тіла сторінки. Дослідження показують зростання CTR до 50% для постів із налаштованими og-тегами. Згідно з документацією Facebook, зображення 1200×630 забезпечує оптимальний вигляд.

Які проблеми вирішують ці теги?

  • Некоректне зображення — соцмережа бере не ту картинку або не показує її взагалі. og:image задає конкретне зображення з потрібним співвідношенням сторін (1200×630 для Facebook, 1200×628 для Twitter).
  • Обрізаний текст — без og:description сніпет містить перші 150 символів сторінки, часто безглузді. Ми задаємо лаконічний опис до 200 символів.
  • Довге кешування — Telegram кешує OG-теги при першому перегляді. Якщо змінити зображення, потрібно додати GET-параметр до url картинки. Ми розповімо, як оновити кеш.

Як налаштувати Open Graph: приклади коду

<!-- Обов'язкові -->
<meta property="og:title"       content="Купити iPhone 15 Pro 256GB — ТехноМагазин">
<meta property="og:description" content="Найкраща ціна на iPhone 15 Pro. Доставка за 1 день.">
<meta property="og:image"       content="https://example.ru/og/iphone-15-pro.jpg">
<meta property="og:url"         content="https://example.ru/products/iphone-15-pro">
<meta property="og:type"        content="product">
<meta property="og:site_name"   content="ТехноМагазин">
<meta property="og:locale"      content="uk_UA">

<!-- Для продуктів -->
<meta property="product:price:amount"   content="89990">
<meta property="product:price:currency" content="UAH">

<!-- Для статей -->
<meta property="article:published_time" content="2024-01-01T10:00:00+03:00">
<meta property="article:author"         content="Іван Іванов">
Тег Опис Приклад вмісту
og:title Заголовок сторінки (до 95 символів) "Купити iPhone 15 Pro"
og:description Опис (до 200 символів) "Найкраща ціна на iPhone 15 Pro. Доставка за 1 день."
og:image URL зображення (1200x630) "https://example.com/image.jpg"
og:url Канонічний URL "https://example.com/page"
og:type Тип контенту "product", "article", "website"
og:site_name Назва сайту "ТехноМагазин"

Як налаштувати Twitter Card

<meta name="twitter:card"        content="summary_large_image">
<meta name="twitter:title"       content="Купити iPhone 15 Pro 256GB">
<meta name="twitter:description" content="Найкраща ціна на iPhone 15 Pro.">
<meta name="twitter:image"       content="https://example.ru/og/iphone-15-pro.jpg">
<meta name="twitter:site"        content="@technoshop_ua">
Тип Опис Коли використовувати
summary Маленьке зображення (120x120) зліва від тексту Статті, новини
summary_large_image Велике зображення (1200x628) зверху (найчастіше) Продукти, лендінги, яскраві картинки
app Пряме посилання на мобільний додаток Промо додатків
player Відеоплеєр (HLS, MP4) Відеоконтент

summary_large_image дає CTR у 2–3 рази вищий за summary для візуальних сторінок.

Порівняння вимог до зображень Facebook та Twitter

Параметр Facebook (OG) Twitter (summary_large_image)
Розмір зображення 1200x630 (мін 600x315) 1200x628
Співвідношення сторін 1.91:1 2:1
Формат JPG, PNG, WebP JPG, PNG, GIF
Максимальний розмір файлу 8 MB 5 MB

Рекомендації щодо зображення: включайте логотип і назву, уникайте дрібного тексту, використовуйте контрастні кольори. Мінімальний розмір — 600x315.

Динамічна генерація OG-зображень

Для сторінок з унікальними даними (товари, статті) статичний банер неефективний. Ми використовуємо автоматичну генерацію через Puppeteer/Chrome headless або бібліотеку Intervention Image. Кожен товар отримує унікальний сніпет із ціною, назвою, акцією — CTR зростає на 30–40% порівняно з універсальним зображенням.

// Через Puppeteer/Chrome headless або бібліотеку Intervention Image
Route::get('/og-image/product/{product}', function (Product $product) {
    $image = ImageManager::gd()->create(1200, 630);

    // Фон
    $image->fill('#1a1a2e');

    // Текст
    $image->text($product->name, 600, 300, function ($font) {
        $font->filename(public_path('fonts/Inter-Bold.ttf'));
        $font->size(48);
        $font->color('#ffffff');
        $font->align('center');
    });

    return response($image->toJpeg(90))->header('Content-Type', 'image/jpeg')
           ->header('Cache-Control', 'public, max-age=86400');
});

Альтернатива — Vercel OG (@vercel/og) для Next.js: генерує зображення з JSX на edge runtime. Це швидше та не вимагає додаткового сервера.

Як налагоджувати та тестувати?

Використовуйте валідатори: Facebook Debug Tool та Twitter Cards Validator. Вони показують, які теги розпізнано, та попереджають про помилки. Telegram не має валідатора — для скидання кешу додайте GET-параметр до URL зображення (наприклад, ?v=2). Ми включаємо це в процес налаштування, щоб клієнт не чекав оновлення кешу.

Процес роботи та що входить

  1. Аналітика — аудит поточних мета-тегів, виявлення помилок, формування чек-листа.
  2. Проектування — вибір типів og:type для кожної сторінки, підготовка макету зображення.
  3. Реалізація — правка шаблонів (head-секція), налаштування динамічної генерації (якщо потрібно).
  4. Тестування — перевірка через усі валідатори, контроль кешування.
  5. Деплой — викладка на продакшн, моніторинг результатів (CTR у соцмережах).

У склад робіт входить: консультація щодо структури тегів, налаштування шаблонів, тестування на реальних посиланнях, навчання вашої команди (як змінювати og:title для нових сторінок), документація щодо процесу. Ми даємо гарантію на коректну роботу тегів протягом місяця після запуску — якщо щось зламається, виправимо безкоштовно.

Чек-лист перевірки OG-тегів
  • og:title ≤ 95 символів
  • og:description ≤ 200 символів
  • og:image розмір 1200x630, не більше 8MB
  • twitter:card встановлено
  • Усі обов'язкові теги дублюються в Twitter Card
  • Зображення оптимізовано (формат JPG/PNG/WebP)
  • Немає конфлікту з іншими мета-тегами
  • Протестовано через Facebook Debug Tool та Twitter Cards Validator
  • Telegram кеш оновлено (додано GET-параметр до url зображення)

Строки та вартість

Базове налаштування OG/Twitter Card тегів займає від кількох годин до 2 днів. Якщо потрібна динамічна генерація зображень — додається 1–2 дні. Вартість розраховується індивідуально залежно від кількості шаблонів та складності інтеграції. Замовте налаштування — отримайте гарний сніпет та зростання CTR. Наш досвід — 5+ років у веб-розробці, понад 100 реалізованих проектів. Ми не просто вставляємо теги — ми тестуємо кожен випадок, щоб сніпет виглядав ідеально.

Зв'яжіться з нами для оцінки вашого проекту — ми проаналізуємо поточну мікророзмітку та запропонуємо оптимальне рішення. Отримайте консультацію з налаштування OG та Twitter Card вже сьогодні.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

  1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
  2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
  3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
  4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

  • Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
  • Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
  • Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
  • Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
Типовий сценарій CLS до CLS після Основний фікс
Банер знижок без min-height 0.42 0.02 min-height: 300px
Картинки в статтях без атрибутів 0.18 0.01 width/height + aspect-ratio
Віджет чату, що завантажується через 3с 0.35 0.05 position: fixed із зарезервованим відступом

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

  • Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
  • Важкі event listeners без debounce/throttle
  • Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
  • Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

  • E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
  • Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
  • Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
  • FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Типові помилки при впровадженні Schema.org
  • Вказано price без priceCurrency — розмітка ігнорується.
  • ratingValue без reviewCount — у видачі не показується.
  • Кілька Product на одній сторінці без @type: ItemList — Google бере тільки перший.
  • JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
Етап роботи Що входить Термін
Аудит Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами 1–2 тижні
Оптимізація одного шаблону LCP, CLS, INP, впровадження SSR/SSG, налаштування preload 2–4 тижні
Повна технічна оптимізація Всі шаблони, code splitting, Web Workers, моніторинг в CI 4–10 тижнів
Впровадження Schema.org JSON-LD генерація, валідація, тестування rich snippets 1–3 тижні

Що входить в роботу

  • Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
  • Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
  • Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
  • Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.