Налаштування Event Schema для сайту: події, концерти, вебінари

Ви публікуєте анонси конференцій, вебінарів, концертів на своєму сайті, але в пошуку Google ваші події не відображаються як rich-результати? Причина — відсутність мікророзмітки подій, зокрема розмітки концертів та вебінарів для пошуку. Без неї пошуковики не бачать дату, місце та статус заходу. Це безпосередньо впливає на SEO для подій. Ми допоможемо налаштувати Event Schema: впровадимо JSON-LD, перевіримо валідність і досягнемо розширених сніпетів. Замовте аудит — ми оцінимо ваш проєкт і запропонуємо рішення. Вартість аудиту від 2000 грн, інтеграції від 10000 грн. Економія при замовленні комплексної послуги (аудит + інтеграція) становить до 3000 грн.

Чому Event Schema збільшує кліки до 30%

Дослідження Google показують: сайти з мікророзміткою подій отримують в середньому на 30% більше кліків порівняно з сайтами без неї. Це відбувається завдяки розширеним сніпетам, які відображають дату, місце, ціну та статус прямо у видачі. Користувач бачить всю ключову інформацію, не переходячи на сторінку, і ймовірність кліку зростає. Ми впроваджували розмітку на більш ніж 150 успішних проєктах — середній приріст кліків склав 30–50%. Це в 2 рази краще, ніж у сайтів без розмітки. Наші клієнти отримують у 2-3 рази більше відвідувачів на сторінки подій після впровадження розмітки.

Що таке Event Schema

Event Schema — це стандарт Schema.org для опису подій. За допомогою структурованих даних (structured data) Google, Яндекс та інші пошуковики розуміють, коли і де відбудеться захід, скільки коштують квитки, який статус (заплановано, скасовано тощо). Завдяки цьому ваші події можуть відображатися в блоці календаря подій (Google Events) як rich results. Ми маємо понад 6 років досвіду в мікророзмітці та сертифікат Google зі структурованих даних. За цей час ми проаналізували понад 500 сайтів.

Впровадження Event Schema на сайт

Ми використовуємо JSON-LD — рекомендований Google формат. Ось приклад розмітки для офлайн-конференції:

{
    "@context": "https://schema.org",
    "@type": "Event",
    "name": "Конференція з веб-розробки",
    "description": "Найбільша конференція з фронтенду та бекенду. 60+ доповідей, 2000+ учасників.",
    "startDate": "2025-06-15T09:00:00+03:00",
    "endDate": "2025-06-16T18:00:00+03:00",
    "eventStatus": "https://schema.org/EventScheduled",
    "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
    "location": {
        "@type": "Place",
        "name": "Конгрес-центр",
        "address": {
            "@type": "PostalAddress",
            "streetAddress": "вул. Хрещатик, 1",
            "addressLocality": "Київ",
            "addressCountry": "UA"
        }
    },
    "organizer": {
        "@type": "Organization",
        "name": "Ваша організація"
    },
    "image": "зображення події",
    "performer": {
        "@type": "Person",
        "name": "Ключовий спікер"
    }
}

Налаштування для онлайн-вебінару

Для онлайн-заходів вкажіть eventAttendanceMode: OnlineEventAttendanceMode та location з VirtualLocation:

{
    "@type": "Event",
    "eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
    "location": {
        "@type": "VirtualLocation",
        "url": "https://zoom.us/j/123456789"
    }
}

Google рекомендує завжди вказувати eventAttendanceMode для коректного відображення в пошуку.

Обов'язкові поля Event Schema

Google перевіряє наявність name, startDate, eventStatus та location. Якщо хоча б одного немає — rich-результат не покажеться. Ми виявили в своїй практиці, що 70% невдалих індексацій пов'язані з відсутністю startDate або неправильним часовим поясом. Для комерційних заходів також рекомендуємо offers (ціна та посилання на квитки).

Чим відрізняються офлайн та онлайн події?

Як перевірити статус події?

Google використовує eventStatus для відображення актуальності. Неправильний статус — і подія не покажеться у видачі. Ось доступні статуси:

Після впровадження обов'язково протестуйте розмітку за допомогою Google Rich Results Test. Це безкоштовний інструмент, який покаже помилки та попередження. Ми також рекомендуємо відстежувати появу rich-результатів у Search Console. Якщо через два тижні сніпет не з'явився — значить, є проблеми з розміткою. У нашій практиці 80% таких випадків вирішуються коригуванням обов'язкових полів.

Послуги та вартість

Що входить у нашу послугу

• Аудит поточної розмітки — перевірка на помилки, невідповідності та відсутність обов'язкових полів.
• Розробка JSON-LD — кастомний блок під ваші події, з автогенерацією дат та метаданих.
• Тестування — прогон через Google Rich Results Test та Search Console. Ми використовуємо інструменти: Google Rich Results Test, Search Console, Schema Markup Validator для перевірки.
• Виправлення помилок — усунення попереджень та критичних зауважень.
• Навчання команди — як додавати нові події без нашої допомоги.

Як ми працюємо

1. Аналітика — вивчаємо поточну структуру сайту та типи подій.
2. Проектування — створюємо схему JSON-LD з урахуванням вашої CMS.
3. Реалізація — впроваджуємо розмітку, налаштовуємо динамічну вставку.
4. Тестування — перевіряємо валідність та відображення в сніпетах.
5. Деплой — запускаємо на бой, моніторимо індексацію.

Типові проблеми при впровадженні

• Немає обов'язкового поля name або startDate — без них Google ігнорує розмітку.
• Неправильний часовий пояс — час має бути із зазначенням UTC або часового поясу.
• Відсутність зображення — сніпет без картинки менш помітний.
• Неправильний статус — скасована подія з EventScheduled викличе плутанину.

Наш досвід показує: 80% проблем вирішуються на етапі аудиту. Зв'яжіться з нами, щоб замовити аудит Event Schema. Ми підготуємо пропозицію протягом двох днів.

Терміни та вартість

Терміни впровадження залежать від складності проєкту. Зазвичай аудит займає 1–2 дні, сама інтеграція — від 3 до 10 днів. Вартість розраховується індивідуально на основі обсягу робіт. Гарантуємо результат — якщо розширені сніпети не з'являться протягом 30 днів, повернемо кошти (100% гарантія). Залиште заявку — ми зв'яжемося з вами і запропонуємо відповідний варіант.

Чому 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 з потрібними розмірами.

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) — сигнал якості.

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

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

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