Headless CMS: що це і коли вона потрібна сайту

Headless CMS це система керування контентом, яка зберігає тексти, фото, товари і статті окремо від дизайну сайту. Редактор працює в адмінці, а сайт, мобільний застосунок, чат-бот чи інший канал забирають контент через API і показують у своєму оформленні. Слово «headless» (без голови) означає, що в CMS немає власної вітрини: «голову» будують окремо, і їх може бути кілька.

Нижче пояснюємо, чим headless відрізняється від класичних CMS на кшталт WordPress, коли такий підхід виправданий і як ми тримаємо контент власного сайту.

Класична CMS і headless: у чому різниця

Класична CMS (WordPress, Joomla, OpenCart) поєднує все в одній системі: адмінку, базу контенту і шаблон, який малює сторінки. Зручно для швидкого старту: встановили тему, додали сторінки, сайт працює.

Headless CMS (Strapi, Sanity, Contentful, Directus та інші) займається лише контентом. Сайт будується окремо на сучасному фреймворку (Next.js, Nuxt, Astro) і отримує контент через API під час збирання чи запиту.

Коли headless CMS виправдана

• Кілька каналів. Той самий каталог показується на сайті, в мобільному застосунку і в чат-боті.
• Кілька мов. Контент з перекладами і спільною структурою.
• Швидкість і SEO. Статичні сторінки відкриваються миттєво, а це впливає на позиції в пошуку і конверсію.
• Складна логіка сайту. Калькулятори, кабінети, персоналізація, інтеграції, які незручно будувати в межах теми.
• Безпека. Адмінка не стоїть на тому самому сервері, що й публічний сайт, і поверхня атаки менша.
• Автоматизація контенту. Статті, описи товарів і переклади частково генеруються програмно і потрапляють у ту саму систему.

Коли краще класична CMS

• Сайт-візитка чи лендинг на кілька сторінок.
• Невеликий бюджет і потреба запуститись за тиждень.
• Контент лише на сайті, без застосунків і ботів.
• Команда вже вміє працювати з WordPress, і сайт закриває задачі.

Приклад: як влаштований контент initask.com

Наш власний сайт побудований за headless-принципом, і роль CMS у ньому виконує репозиторій з файлами.

• Статті живуть у Markdown-файлах з метаданими на початку: заголовок, опис, дата, теги, питання для FAQ, повʼязані статті. Українська і англійська версії лежать у різних папках і звʼязані спільним ключем перекладу.
• Один модуль читає контент для всього. Сторінки блогу, карта сайту і автоматичний конвеєр статей користуються тим самим модулем, тому розбіжність між ними неможлива.
• Сайт на Next.js збирає сторінки заздалегідь, додає розмітку статті, FAQ і хлібних крихт для пошуковиків.
• Валідатор перевіряє кожну статтю перед публікацією: обовʼязкові поля, довжину заголовка і опису для видачі, биті внутрішні посилання, пари перекладів, зламані таблиці.
• Конвеєр контенту пише нові статті у ті самі файли, і вони проходять ту саму перевірку, що й написані людиною.

Такий підхід дає історію кожної правки, перевірки до публікації і швидкий статичний сайт. Для команди, яка працює з кодом, це зручно. Для маркетолога без технічних навичок ми б поставили поверх окрему адмінку headless CMS.

Приклад: мережа довідкових сайтів

Для мережі наших довідкових сайтів статті зберігаються у файлах JSON з заголовком, описом, текстом, FAQ і фактами, на які стаття спирається. Під час старту кожен сайт імпортує нові статті у свою базу і показує їх у своєму дизайні. Контент один раз підготовлений, а вітрини різні: це і є головна ідея headless.

Як headless допомагає SEO і швидкості

Пошуковики і користувачі однаково не люблять повільні сторінки. У класичній CMS кожна сторінка часто збирається на льоту з бази даних і десятка плагінів. У headless-сайті сторінки можна зібрати заздалегідь і віддавати як готові файли з мережі доставки контенту, тому вони відкриваються майже миттєво навіть на слабкому мобільному інтернеті.

Друга перевага в контролі над розміткою. Розробник сам вирішує, які структуровані дані отримує кожна сторінка: стаття, товар, FAQ, хлібні крихти. Ці дані допомагають пошуковику і AI-асистентам зрозуміти сторінку і показати її у розширеному вигляді. У темі WordPress частина такої розмітки залежить від плагінів, які конфліктують між собою.

Третя перевага в перевірках до публікації. Коли контент проходить через збирання сайту, на цьому кроці можна автоматично ловити биті посилання, порожні описи і задовгі заголовки, і помилка не доходить до читача.

Як обрати headless CMS

1. Хто редагує. Маркетологу потрібна зручна адмінка з попереднім переглядом. Розробникам вистачить файлів.
2. Типи контенту. Статті, товари, сторінки послуг, відгуки, FAQ. Добра CMS дозволяє описати структуру кожного.
3. Мови. Підтримка перекладів на рівні полів.
4. Хостинг. Хмарний сервіс з оплатою за місця чи власне розгортання відкритої CMS на своєму сервері.
5. API і вебхуки. Сайт має дізнаватись про зміни і перезбирати сторінки.
6. Ролі. Автор, редактор, публікатор.
7. Медіа. Зберігання фото, стиснення, адаптивні розміри.

Типові помилки

• Обрати headless для сайту з пʼяти сторінок і платити за розробку фронтенду без потреби.
• Не налаштувати попередній перегляд, і редактор не бачить, як виглядатиме сторінка.
• Забути про вебхук на перезбирання, і зміни зʼявляються на сайті через день.
• Зберігати в CMS те, що має жити в обліковій системі: ціни і залишки краще брати з джерела напряму.
• Розкласти контент по полях надто дрібно, і редактор витрачає пів години на просту новину. Структура має бути такою, щоб звичайна правка займала хвилини.

Що питати у підрядника

• Хто і як редагуватиме контент після запуску?
• Скільки часу проходить від збереження в адмінці до появи на сайті?
• Як додаються нові типи сторінок і хто це робить?
• Де зберігається контент і як він резервується?

Сайти на headless-архітектурі і класичних CMS ми розробляємо в напрямі розробки сайтів, магазини з каталогом у кількох каналах у напрямі розробки інтернет-магазинів. Про вибір фреймворку у статті Next.js для бізнес-сайту. Опишіть свій сайт у формі на головній, оцінку дамо після брифу за робочий день.