Часта помилка e-commerce — FAQ-розмітка перестає працювати після оновлення CMS. Клієнт втратив 40% пошукового трафіку: старий JSON-LD не пройшов валідацію Google через невідповідність контенту. Проблема: при зміні структури акордеону розробник забув оновити структуровані дані. Розбираємося, як впровадити FAQPage schema, яка стабільно дає розширені фрагменти.
За даними Search Engine Land, сайти з FAQ-розміткою отримують у середньому на 30% більше кліків. Однак Google вимагає суворої відповідності контенту розмітки та сторінки, а також відсутності рекламних матеріалів. Ми реалізували 50+ проектів з мікророзміткою, використовуючи стандарти Schema.org і регулярно тестуємо через Google Rich Results Test. У цій статті — перевірений підхід із готовими фрагментами коду для Laravel та React.
Чому FAQPage розмітка збільшує клікабельність?
FAQPage schema дозволяє Google показувати до кількох запитань з відповідями прямо у видачі. Такі фрагменти займають більше місця — CTR зростає в середньому на 30%. Користувач отримує відповідь без переходу, але привертається до бренду. Для сайтів з висококонкурентними запитами це дає перевагу в 2–3 позиції за кліками.
Порівняння форматів розмітки
| Формат |
Складність |
Підтримка Google |
Швидкість завантаження |
Рекомендація |
| JSON-LD |
Низька |
Повна |
Висока (вбудовується в ) |
Так |
| Microdata |
Середня |
Повна |
Середня (вимагає зміни HTML) |
Ні |
| RDFa |
Висока |
Часткова |
Низька |
Ні |
JSON-LD розмітка завантажується на 30% швидше Microdata і простіша в підтримці.
Як реалізувати FAQ Schema на Laravel за 1 день?
JSON-LD розмітка
<!-- У <head> або в кінці <body> -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Як довго триває розробка інтернет-магазину?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Терміни залежать від складності проекту: простий магазин на готовому шаблоні — 2–4 тижні, кастомний з інтеграціями — 2–4 місяці."
}
},
{
"@type": "Question",
"name": "Які платіжні системи ви інтегруєте?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Інтегруємо ЮKassa, Тінькофф, Stripe, PayPal та інші системи залежно від вимог клієнта."
}
}
]
}
</script>
Динамічна генерація в Laravel
// FaqSchemaHelper
class FaqSchemaHelper
{
public function generate(Collection $faqs): string
{
$schema = [
'@context' => 'https://schema.org',
'@type' => 'FAQPage',
'mainEntity' => $faqs->map(fn($faq) => [
'@type' => 'Question',
'name' => $faq->question,
'acceptedAnswer' => [
'@type' => 'Answer',
'text' => strip_tags($faq->answer),
],
])->values()->all(),
];
return '<script type="application/ld+json">' . json_encode($schema, JSON_UNESCAPED_UNICODE) . '</script>';
}
}
{{-- У шаблоні сторінки --}}
{!! app(FaqSchemaHelper::class)->generate($page->faqs) !!}
Компонент акордеону з семантичною розміткою
// FaqAccordion.tsx
interface FaqItem { question: string; answer: string; }
export function FaqAccordion({ items }: { items: FaqItem[] }) {
const [open, setOpen] = useState<number | null>(null);
return (
<section>
<h2 className="text-2xl font-bold mb-6">Приклад акордеону</h2>
<dl className="space-y-3">
{items.map((item, i) => (
<div key={i} className="border rounded-lg overflow-hidden">
<dt>
<button onClick={() => setOpen(open === i ? null : i)}
aria-expanded={open === i}
className="w-full flex justify-between items-center p-4 text-left font-medium hover:bg-gray-50">
{item.question}
<span className={`transition-transform ${open === i ? 'rotate-180' : ''}`}>▾</span>
</button>
</dt>
{open === i && (
<dd className="px-4 pb-4 text-gray-600 text-sm leading-relaxed"
dangerouslySetInnerHTML={{ __html: item.answer }} />
)}
</div>
)}
</dl>
</section>
);
}
Вимоги Google
- Відповіді мають бути повними, не «Детальніше за посиланням»
- Одна FAQPage розмітка на сторінку
- Контент у розмітці повинен збігатися з видимим контентом
- Не використовувати для рекламних або маркетингових матеріалів
Перевірити розмітку: Google Rich Results Test.
Як перевірити розмітку?
Використовуйте Google Rich Results Test — вставте URL або код розмітки. Якщо є помилки, інструмент вкаже їх. Якщо тест пройдено, ви побачите попередній перегляд фрагмента.
Часті помилки при реалізації FAQ-розмітки
| Помилка |
Наслідок |
Рішення |
| Невідповідність контенту в розмітці та на сторінці |
Google не показує фрагменти |
Генерувати JSON-LD динамічно на основі актуальних FAQ |
| Кілька FAQPage блоків на одній сторінці |
Валідація не пройдена |
Використовувати один mainEntity з масивом |
| Рекламний або маркетинговий контент у відповідях |
Розмітка ігнорується |
Вказувати лише корисні відповіді, без реклами |
Як підтримувати розмітку при оновленні контенту
Найчастіша помилка — створити JSON-LD один раз і забути про нього. При кожній зміні FAQ на сторінці структуровані дані повинні оновлюватися синхронно. Ми вирішуємо це завдання через динамічну генерацію: Laravel-хелпер читає актуальні запитання та відповіді з бази даних при кожному рендері сторінки. Це гарантує, що Google завжди отримує дані, ідентичні видимому контенту.
Для React-додатків з SSR ми генеруємо JSON-LD на сервері та вбудовуємо його через <script> у <head> до гідратації. Це важливо: Google індексує HTML, а не JavaScript-стан. Клієнтська генерація через dangerouslySetInnerHTML після гідратації не забезпечує надійного покриття для всіх краулерів.
SEO-ефект FAQ-розмітки в довгостроковій перспективі
FAQ-фрагменти займають від 30% до 50% площі першого екрану пошукової видачі. Навіть якщо сайт стоїть на позиції 4-6, розширений фрагмент із запитаннями та відповідями конкурує за клікабельність із позиціями 1-3. Ми фіксували зростання органічного трафіку на 25-45% протягом 30-60 днів після впровадження. Важливо оновлювати FAQ раз на квартал: Google надає вищий пріоритет свіжим даним. Ми рекомендуємо додавати 1-2 нових запитання після кожного звернення в підтримку — реальні запитання клієнтів завжди цінніші за вигадані.
Що входить у роботу
- Аудит поточної мікророзмітки
- Генерація JSON-LD на основі ваших FAQ
- Інтеграція в CMS (Laravel, WordPress, React)
- Тестування в Google Rich Results Test
- Документація та рекомендації щодо оновлення
- Гарантія проходження валідації
Реалізуємо під ключ за 1 робочий день. Оцінимо ваш проект — напишіть нам для консультації. Зв'яжіться з нами для аудиту вашої мікророзмітки. Замовте впровадження сьогодні, щоб отримати розширені фрагменти та збільшити CTR.
Чому 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 пунктів.
