«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 – это серверная часть; что увидит реальный посетитель зависит еще от его устройства, сети и веса картинок и скриптов.
