«Headless» продають як кнопку «зробити швидко і гнучко». Насправді це рішення про одне: де живе контент і хто відповідає за його показ.
У монолітній CMS — WordPress, OpenCart, Bitrix — сховище контенту і шаблон сторінки лежать в одному застосунку. Редактор натиснув «Зберегти», той самий застосунок зібрав HTML і віддав його браузеру. У headless сховище віддає контент через API у вигляді даних, а зібрати з цих даних сторінку має окремий фронтенд, який хтось повинен написати й потім підтримувати.
Усе решта — наслідки цього розділення. І приємні, і не дуже.
Що дає розділення контенту й показу
Контент перестає бути сторінкою. У монолітній CMS запис «товар» існує як HTML-сторінка. У headless це набір полів: назва, ціна, характеристики, зображення, наявність. Ті самі поля віддаються на сайт, у мобільний застосунок, у YML-фід для маркетплейсу, у лист розсилки. Одне джерело, кілька вітрин.
Структуровану розмітку можна генерувати, а не набивати руками. Коли ціна лежить у полі price, а не всередині абзацу тексту, JSON-LD збирається з тих самих полів автоматично. Google читає сторінку як текст і не зобов'язаний вгадати, де тут ціна, де графік роботи, а де хлібні крихти. Розмітка каже це прямо — і сторінка стає придатною до розширеного сніпета у видачі.
Чесна межа тут така. Google у власній документації пише, що структуровані дані роблять сторінку придатною до розширених результатів, і прямо відмовляється гарантувати їх показ. Позиції розмітка не піднімає. Вона впливає на CTR на тій позиції, яка у вас уже є, — і лише якщо Google вирішить показати розширений вигляд. Універсальної цифри приросту не існує; свою видно тільки у власній Search Console.
Окремо про ризик, який ми зафіксували у себе. У нашій власній SaaS-платформі для рерайту описів товарів JSON-LD віддає aggregateRating 4,8 із 50 оцінками, а на сторінці немає жодного відгуку. Це не перевага, це привід під ручні санкції за self-serving розмітку. Автогенерація масштабує і правильне, і помилкове — валідувати треба саме те, що реально показано користувачу.
Фронтенд можна переписати, не чіпаючи контент. Редизайн у монолітній CMS — робота в тому ж застосунку, де лежать дані. У headless фронтенд є окремим проєктом, і його заміна не торкається сховища.
Чого headless не дає
Найпоширеніша обіцянка звучить як «headless = швидкий сайт». Це неправда, і в нас є власний замір, який це показує.
31 липня 2026 року ми виміряли 16 живих сайтів із портфоліо однаковою методикою: час до першого байта і час повного завантаження HTML, кілька замірів, медіана. Два магазини з цієї вибірки стоять на одній платформі OpenCart, тобто на класичній монолітній CMS. Магазин натуральної косметики: TTFB 126,3 мс, повний HTML за 172,4 мс при 196 КБ. Роздрібний магазин нижньої білизни на тій самій CMS: TTFB 1 544,5 мс. Різниця у дванадцять разів.
Ще один орієнтир із тієї ж вибірки: магазин тактичного спорядження, теж монолітна CMS, віддає перший байт за 413,8 мс на каталозі в 54 302 товари — цифру каталогу ми підтвердили двома незалежними методами, розбіжність 0,4%.
Швидкість роблять кешування, версія PHP, налаштування nginx, кількість запитів до бази і вага HTML. Архітектура CMS у цьому переліку не перша.
Чесна межа з іншого боку: швидкість не робить пропозицію привабливою. Якщо ціна вища за ринок або товару немає в наявності, сайт із відповіддю за 200 мс просто швидше покаже людині причину піти. Швидкість прибирає технічну втрату, а не створює попит. І TTFB — це серверна частина; що побачить реальний відвідувач, залежить ще від його пристрою, мережі та ваги картинок і скриптів.
Нова задача, якої не було в монолітній CMS
Коли фронтенд збирає сторінку вже в браузері, постає питання: а що бачить той, у кого браузера немає?
Пошукові боти й агенти AI-асистентів здебільшого не виконують JavaScript. Вони читають те, що віддано в HTML одразу. Якщо фронтенд — це оболонка, яка тягне контент через API на боці клієнта, бот отримає порожню сторінку і процитує когось іншого.
Ось як виглядає розв'язана версія цієї задачі на нашому проєкті — сайт клініки пластичної хірургії, вимір 31.07.2026. Сайт віддає різні відповіді залежно від User-Agent: браузеру — оболонку на 3,0 КБ без H1 і без meta description, пошуковому боту — повністю пререндерений HTML на 126 КБ (24 КБ у gzip) за 145 мс до першого байта і 178 мс до повного документа. Поряд лежить llms.txt на 22 810 байт і robots.txt із роздільною політикою для AI-кравлерів: блокує тренувальні (GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider), допускає ті, що ведуть живий трафік (ChatGPT-User, OAI-SearchBot, PerplexityBot). Такий поділ не самодіяльність — OpenAI сама документує різницю між своїми кравлерами в довідці для розробників.
Це і є ціна розділення. Пререндер треба свідомо побудувати, а потім за ним стежити. У монолітній CMS така задача не виникає взагалі, бо HTML і так збирається на сервері.
Чесна межа: ніхто, включно з нами, не може обіцяти згадку у відповіді AI-асистента — у вендорів немає ні зобов'язань, ні прозорих правил відбору. Обсяг переходів звідти поки що малий порівняно з класичним пошуком. Це робота на випередження з невідомою віддачею, і чесніше називати її саме так.
Де headless-проєкти ламаються найчастіше
Сучасний стек не рятує від базових технічних дірок. Нижче — те, що ми регулярно знаходимо на власних і чужих проєктах.
Карта сайту, яку ніхто не відкривав
На нашому сайті консалтингової компанії (Next.js, вимір 31.07.2026) robots.txt містить рядок Sitemap: .../sitemap.xml, а сам файл віддає 404. Директива є, карти немає. Сторінки, яких бот не знайшов, не приносять жодного відвідувача — це найбазовіший рівень, він не робить сторінку кращою, він робить її існуючою для пошуку.
Google прямо документує, що карта сайту допомагає знайти сторінки, але не гарантує ні сканування, ні індексації, а малому сайту з нормальною перелінковкою вона може бути й не потрібна. Кількість URL у карті ніколи не дорівнює кількості проіндексованих сторінок; реальну цифру видно тільки у Search Console.
Друга типова поломка неочевидніша за 404: /sitemap.xml відповідає HTTP 200 і тілом на 0 байт. Формально все добре, фактично бот не отримує нічого. Ми фіксували це на кількох магазинах — зокрема на магазині систем автоматичного поливу, вимір 01.08.2026: XML-карта порожня, працює лише HTML-карта на 89 посилань.
Розмітки немає взагалі
На тому ж сайті консалтингової компанії — нуль блоків JSON-LD. Для компанії, яка продає послуги, це означає, що Google не отримує структурованих даних про організацію: ні профілю діяльності, ні контактів, ні адреси.
Для контрасту — наш проєкт виробника негорючих стінових панелей на тому ж Next.js: 8 типів JSON-LD (Organization, PostalAddress, Country, QuantitativeValue, SearchAction, WebSite, ImageObject, EntryPoint), 164 URL у карті сайту і 164 унікальних, тобто жодного дубля, TTFB 244 мс на головній і 208 мс на каталозі продукції. Технологія в обох проєктах одна. Різниця в тому, чи дійшли руки.
Аналітика, яка виглядає робочою
На сайті клініки інлайновий GTM-сніпет самоблокується: змінна GTM_ID дорівнює 'G-XCE3BLJBSP', а умова виходу перевіряє GTM_ID === 'G-XCE3BLJBSP', тож return спрацьовує щоразу і контейнер не вантажиться ніколи. До того ж G-… — це ідентифікатор GA4, а не контейнера GTM. У коді тег на місці, даних немає.
Це не дрібниця. Без коректних подій конверсії Google Ads не має чого оптимізувати: рекламний бюджет витрачається наосліп навіть тоді, коли кампанії налаштовані правильно.
Чесна межа: лічильник нічого не покращує сам по собі, він лише дає можливість побачити. Дані ще треба читати й ухвалювати на їх основі рішення, а це окрема робота. Плюс точність обмежена — блокувальники, режим згоди (на тій самій клініці Consent Mode за замовчуванням denied), обмеження браузерів на cookie. GA4 показує тенденцію, а не бухгалтерську істину.
Коли розділення виправдане
Розділення виправдане, коли контент справді потрібен більш ніж в одному місці: сайт, застосунок, фід для маркетплейсу, екран у шоурумі, розсилка. Коли фронтенд змінюється частіше за структуру даних. Коли редакція велика і їй потрібні ролі, чернетки, попередній перегляд і історія змін окремо від коду.
Не виправдане, коли вітрина одна, а контент оновлюється кілька разів на місяць. Тоді ви платите двічі — за сховище контенту і за розробку фронтенду, який у монолітній CMS входив у комплект. Кожна нова структура сторінки в headless стає задачею розробнику; в адмінці монолітної CMS це був вибір шаблону зі списку.
Наскільки перехід вплине на ваші витрати, залежить від кількості вітрин і від того, як часто у вас реально змінюється розмітка сторінок, а не тексти в них. Без інвентаризації поточних задач це не рахується. Цифри штибу «економія N% на рік», названі до такої інвентаризації, беруться зі стелі.
Як перевірити свій сайт за півгодини
Аудит для базової діагностики не потрібен.
Подивіться, що бачить бот. Відкрийте вихідний код сторінки — Ctrl+U, саме він, а не панель інспектора, яка показує вже зібраний DOM. Якщо тексту, H1 і meta description там немає, бот бачить те саме. Для будь-якого сайту з клієнтським рендерингом це перша перевірка після запуску і після кожного релізу фронтенду.
Відкрийте robots.txt і перейдіть за директивою Sitemap. Шукайте два стани: 404 і відповідь 200 із порожнім тілом. Другий небезпечніший, бо формально відповідь є і моніторинг доступності мовчить.
Пошукайте в коді application/ld+json. Порожньо — структурованих даних немає. Не порожньо — звірте вміст із тим, що показано на сторінці, особливо рейтинги, відгуки й ціни.
Перевірте, чи вантажиться аналітика. Мережева панель браузера, фільтр по collect або gtm.js. Наявність тега в коді і робочий тег — різні стани.
Частину цього швидше зробити готовими інструментами Google — Search Console, Rich Results Test, PageSpeed Insights. Руками через curl вийде той самий результат, просто довше.
Коротко
Headless — це рішення про архітектуру контенту, а не про швидкість. Швидкість робиться інженерією конкретного проєкту: у нашій вибірці два сайти на одній монолітній CMS відрізняються по TTFB у дванадцять разів.
Розділення дає одне джерело контенту для кількох вітрин і чисту базу для структурованої розмітки. Натомість воно додає задачу пререндеру для ботів і другий рахунок за інфраструктуру.
Що з цього вийде саме у вас — питання кількості вітрин, розміру редакції й частоти змін розмітки. Це рахується до міграції.
