Ви налаштували сайт, вклалися в дизайн і контент, але в пошуку Google ваша компанія відображається як сірий рядок без логотипу та контактів. Клієнти не бачать телефон, адресу та години роботи прямо в видачі. Причина — відсутність мікророзмітки Organization Schema. Ця розмітка — єдиний спосіб повідомити пошуковику офіційні дані про бізнес і вплинути на появу Knowledge Panel. За даними Google Search Central, сайти з коректною структурою даних отримують на 30% більше кліків, а 90% проблем із невірним відображенням вирішуються впровадженням Organization Schema. Ми налаштуємо її за кілька годин, і ваш сайт почне виглядати авторитетно в очах користувачів та алгоритмів.
Що таке Organization Schema і як вона впливає на видимість?
Organization Schema — це структуровані дані за стандартом Schema.org, які говорять пошуковику: ось назва компанії, ось логотип, ось контакти. Без них Google збирає інформацію з випадкових джерел — старих каталогів, відгуків, партнерських сайтів. Результат: спотворені дані в Knowledge Panel, втрата довіри. З правильною розміткою ви отримуєте:
- Knowledge Panel з логотипом, контактами та соцмережами (CTR зростає на 20–30%)
- Точне відображення годин роботи в локальному пошуку (критично для офлайн-точок)
- Можливість вказати
sameAs — офіційні посилання на соцмережі, щоб Google не плутав їх з фейками
Мікророзмітка JSON-LD обробляється пошуковиками у 3 рази швидше порівняно з застарілими форматами (RDFa, Microdata). Це підтверджує наш досвід інтеграції на сотнях проектів. Наприклад, один клієнт отримав зростання CTR на 40% після впровадження — це в 1.4 рази більше, ніж середній показник.
Які проблеми вирішує мікророзмітка організації?
Без правильної розмітки Google збирає дані про компанію з різних джерел, часто неточних. Наприклад, адреса може бути взята зі старого каталогу, а телефон — з відгуків. Це призводить до помилок в Knowledge Panel і втрати довіри. 90% таких проблем вирішує впровадження Organization Schema.
Налаштування Organization Schema
Мікророзмітка впроваджується через JSON-LD — скрипт в <head> сайту. Ми використовуємо наступний шаблон (вкажіть власні дані):
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "ТОВ «ТехноМагазин»",
"alternateName": "TechnoShop",
"logo": {
"@type": "ImageObject",
"url": "https://technoshop.ru/images/logo.png",
"width": 200,
"height": 60
},
"contactPoint": [{
"@type": "ContactPoint",
"telephone": "+380-44-111-22-33",
"contactType": "customer service",
"contactOption": "TollFree",
"availableLanguage": "Ukrainian",
"areaServed": "UA"
}],
"address": {
"@type": "PostalAddress",
"streetAddress": "вул. Хрещатик, 1",
"addressLocality": "Київ",
"postalCode": "01001",
"addressCountry": "UA"
},
"sameAs": [
"https://vk.com/technoshop",
"https://t.me/technoshop",
"https://instagram.com/technoshop_ua"
]
}
Типові помилки при налаштуванні
| Помилка |
Як виправити |
Вказано невірний @type (наприклад, WebSite замість Organization) |
Використовуйте Organization, якщо це компанія, або LocalBusiness для конкретної точки |
| Логотип не відповідає вимогам Google (маленький розмір) |
Логотип повинен бути не менше 112×112px, формат PNG або JPEG |
Відсутній url або він веде на головну, а не на офіційний сайт |
Вкажіть точний URL сайту, що збігається з канонічним |
Немає поля areaServed для телефону |
Додайте areaServed: "UA", якщо номер обслуговує Україну |
Приклад із практики
Нещодавно до нас звернувся інтернет-магазин з п'ятьма офлайн-точками в Києві. У них була встановлена стара розмітка WebSite без зазначення адрес. Google плутав філії, і жоден не відображався в Knowledge Panel. Ми впровадили Organization Schema для головної компанії та LocalBusiness для кожного магазину, додали години роботи та sameAs. Через тиждень всі точки отримали Knowledge Panel, CTR зріс на 40%, а кількість дзвінків — на 25%.
Порівняння типів розмітки для бізнесу
| Тип |
Для кого |
Основні поля |
Вплив |
| Organization |
Всі компанії |
name, logo, url, contactPoint, address, sameAs |
Knowledge Panel, контакти в пошуку |
| LocalBusiness |
Офлайн-точки |
name, openingHours, geo, hasMap, review |
Відображення на карті, години роботи |
| WebSite |
Сайт в цілому |
name, url, potentialAction, searchAction |
Сніпет пошуку, прискорення індексації |
Перевірка коректності розмітки
Після впровадження використовуйте Google Rich Results Test та Яндекс.Вебмайстер. Вони підсвітять помилки та попередження. Повторна перевірка після виправлень гарантує, що Knowledge Panel з'явиться протягом 1–2 тижнів.
Важливість LocalBusiness для офлайн-точок
Якщо у вас є фізичний магазин або офіс, однієї Organization недостатньо. Додайте LocalBusiness (наприклад, Store, Restaurant, MedicalClinic). Це дозволяє Google відображати години роботи, геолокацію та відгуки прямо в карті. Без цього локальний пошук може ігнорувати вашу адресу.
Приклад JSON-LD для LocalBusiness:
{
"@context": "https://schema.org",
"@type": "Store",
"name": "ТехноМагазин на Хрещатику",
"openingHours": ["Mo-Fr 10:00-21:00", "Sa-Su 11:00-20:00"],
"hasMap": "https://yandex.ua/maps/-/CCU...",
"geo": { "@type": "GeoCoordinates", "latitude": 50.4501, "longitude": 30.5234 }
}
Процес роботи з нами
Ми впроваджуємо мікророзмітку під ключ всього за 1-2 дні. Ось етапи:
- Аналіз (1-2 години) — перевіряємо поточну розмітку та контент сайту, виявляємо помилки
- Проектування (2-4 години) — складаємо JSON-LD з урахуванням всіх полів, включаючи
sameAs та aggregateRating за наявності відгуків
- Реалізація (1-2 години) — розміщуємо скрипт на сайті через голову або плагін, налаштовуємо для всіх сторінок
- Тестування (1 година) — перевіряємо через Google Rich Results Test та Яндекс.Вебмайстер, виправляємо попередження
Терміни: від 4 годин до 2 днів залежно від кількості точок та складності інтеграції. У вартість входить інструкція з оновлення та 30 днів підтримки. Оцініть проект безкоштовно — пишіть нам. Ми маємо понад 200 успішних проектів із мікророзміткою та 7 років досвіду в SEO. Базове налаштування коштує від 2990 грн, але точна ціна залежить від складності.
Що входить в результат
Після налаштування ви отримуєте:
- Робочий JSON-LD код для організації та всіх офлайн-точок
- Інструкцію з оновлення при зміні даних (зміна адреси, контактів)
- Підтримку протягом 30 днів після впровадження (безкоштовні правки)
За даними Google, сайти з коректною мікророзміткою в 2 рази частіше отримують Knowledge Panel. Замовте налаштування мікророзмітки прямо зараз — ваш бізнес виглядатиме професійно в пошуку.
Детальний приклад додавання LocalBusiness
Якщо у вас кілька точок, створіть окремий блок для кожної. Обов'язково вкажіть координати та години роботи. Не забудьте додати hasMap з посиланням на карту.
Чому 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 на мобільному з'єднанні — це фізично повільно.
Рішення по кроках:
- Переносимо hero з CSS background в
<img> з fetchpriority="high" та loading="eager"
- Конвертуємо в WebP, додаємо
srcset: 800w для мобільних, 1400w для десктопа
-
<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
- Прибираємо всі 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 пунктів.