"Headless" is marketed as a "do it quickly and flexibly" button. It's really a decision about one thing: where the content lives and who is responsible for displaying it.
In a monolithic CMS — WordPress, OpenCart, Bitrix — the content store and the page template lie in one application. The editor clicked Save, the same application assembled the HTML and fed it to the browser. In headless, the repository provides content through an API in the form of data, and collecting the page from this data requires a separate frontend, which someone must write and then maintain.
Everything else is a consequence of this separation. Both pleasant and not so.
What separates content and display gives
The content ceases to be a page. In a monolithic CMS, the "product" entry exists as an HTML page. In headless, this is a set of fields: name, price, characteristics, image, availability. The same fields are given to the site, to the mobile application, to the YML-feed for the marketplace, to the mailing list. One source, multiple showcases.
Structured markup can be generated instead of hand-stuffed. When the price is in the price field and not inside a paragraph of text, JSON-LD is assembled from the same fields automatically. Google reads the page as text and is not obliged to guess where the price is, where the work schedule is, and where the breadcrumbs are. The markup says so directly, and the page becomes eligible for an extended snippet in the output.
This is the fair limit here. Google writes in its own documentation that structured data makes a page suitable for extended results, and expressly refuses to guarantee their display. Items are not marked up. It affects the CTR of the position you already have — and only if Google chooses to show the expanded view. There is no universal growth figure; yours is visible only in your own Search Console.
Separately, about the risk that we recorded in ourselves. In our own SaaS platform for rewriting product descriptions, JSON-LD has an aggregateRating of 4.8 out of 50 ratings, and no reviews on the page. This is not an advantage, it is a reason for manual sanctions for self-serving marking. Auto-generation scales both correct and incorrect — it is necessary to validate exactly what is actually shown to the user.
The frontend can be rewritten without touching the content. Redesign in a monolithic CMS is work in the same application where the data resides. In headless, the frontend is a separate project, and its replacement does not affect the repository.
What headless does not provide
The most common promise is "headless = fast site". This is not true, and we have our own measure that shows it.
On July 31, 2026, we measured 16 live portfolio sites using the same methodology: time to first byte and full HTML load time, multiple measurements, median. Two stores from this sample are on the same OpenCart platform, that is, on a classic monolithic CMS. Natural Cosmetics Store: TTFB 126.3ms, Full HTML in 172.4ms at 196KB. Underwear retail store on the same CMS: TTFB 1,544.5ms. The difference is twelve times.
Another reference from the same sample: a tactical equipment store, also a monolithic CMS, returns the first byte in 413.8 ms on a catalog of 54,302 products - we confirmed the catalog number with two independent methods, a discrepancy of 0.4%.
Speed is determined by caching, PHP version, nginx settings, the number of requests to the database and the weight of HTML. CMS architecture is not the first in this list.
A fair margin on the other hand: speed doesn't make an offer attractive. If the price is higher than the market or the product is out of stock, a site with a response time of 200ms will simply give the person a reason to leave faster. Speed removes technical loss, not creates demand. And TTFB is the backend; what a real visitor will see depends on his device, network and weight of pictures and scripts.
