Let me save you a meeting. If your technology team is debating "headless versus traditional CMS" as a binary choice, the framing is probably why the decision keeps getting deferred.
The useful questions are more specific. Which experiences need visual page management? Which content must be reusable across channels? How much presentation control does the development team need? Who will operate the resulting platform?
I should disclose the commercial context upfront: Distinction is a Kentico partner. We implement and advise on Xperience by Kentico, so we have expertise and an incentive in this market. This article examines how its hybrid model works and where the fit can break down. Use the same scrutiny with us that you would apply to any vendor or implementation partner.
This is distinct from the collection's vendor-neutral guide to headless and traditional CMS choices. The job here is to test a particular platform claim against the buyer's operating reality.
Three models in practical terms
Traditional or coupled CMS. Content, page structure and presentation are managed as one website-oriented system. Editors can often create and preview pages in a familiar context. Developers work within the platform's presentation model. This can be efficient for a principal website and constraining when the same structured content needs to serve several applications.
Headless CMS. The content service is separate from presentation and delivers structured content through APIs. Application teams choose their own front ends and channels. Editors may gain strong structured-content workflows, but visual page composition and preview depend on what the product and implementation provide. "Headless" does not automatically mean a spreadsheet-like editor, just as it does not guarantee a perfect preview.
Hybrid approach. A platform supports website-oriented page management and API-led delivery in the same content estate. The organisation can use different delivery modes for different channels, provided its content models, licences and operating model support them.
Hybrid is not automatically simpler. It gives the buyer more options inside one platform. Those options still need architecture decisions, implementation and governance.
The decision Kentico is trying to solve
Many mid-market service firms have two legitimate needs.
Marketing wants to publish and arrange website pages without raising a development ticket for routine work. Technology wants structured, reusable content and a supported way to serve experiences beyond a conventional website. Buying separate products for each need can add integrations and suppliers; choosing only one mode can burden one team.
Xperience by Kentico's current product model supports website channels, reusable content in a Content hub and headless channels. The official business-user documentation distinguishes website pages, reusable content items and headless content delivered through a GraphQL API.
That is the substance behind the hybrid claim. It is more precise than saying the platform gives everybody "the best of both worlds".
Website channels and Page Builder
Website channels manage pages tied to a website context. Pages use content types that define editable fields and can participate in workflows. Xperience also provides Page Builder, a visual interface where editors arrange configurable widgets and sections prepared by developers.
The phrase "prepared by developers" matters. The Page Builder documentation describes a framework that must be enabled and implemented with appropriate components. A buyer should not interpret drag and drop as an unlimited no-code page designer available without delivery work.
The potential benefit is controlled editorial autonomy. The organisation creates an approved component system, and editors use it to assemble pages within design, accessibility and brand boundaries. That can reduce tickets while avoiding a page estate assembled from arbitrary styling.
Test the experience with real editors and content. Can they build the campaign, service page and case study they manage today? Can they preview responsive behaviour, schedule, review, localise and recover from mistakes? Which changes still require development? A product demonstration rarely exposes governance and exception work.
Also review the technical implications of the implementation. The current Page Builder documentation notes specific Content Security Policy limitations for pages using builder content. Security teams should assess the actual architecture and current vendor guidance rather than assume a visual editor is operationally neutral.
Content hub and reusable content
The Content hub manages reusable content items and assets that can be shared across channel types. A biography, service description, office, disclaimer or article metadata can be modelled independently and referenced where needed.
This is valuable only when reuse is real. A service description may need a common core and channel-specific context; forcing every sentence into one universal record can make content harder to write and govern. Define which fields are canonical, where variation is allowed and who owns change.
Reusable content also changes editorial responsibility. Updating a shared item may affect several pages or channels. Preview, impact awareness, workflow and release coordination become important. Ask the implementation partner to demonstrate how editors identify where an item is used and how a change reaches each destination.
Content structure should serve user and business needs. Do not design a complex taxonomy because the platform can support one.
Headless channels and GraphQL delivery
Xperience's headless channels hold content intended for API delivery to external applications or services. The official headless-channel documentation says each channel has a secured GraphQL endpoint and can reuse items from the Content hub.
This can support a mobile app, portal, external website or other service. It gives development teams a product-supported content API rather than requiring an improvised export from a website page tree.
There are material details to evaluate:
- Headless-channel features currently require the Advanced licence tier.
- API keys, server-side handling, CORS, caching and monitoring need a secure design.
- The channel has a common preview URL; the current documentation says individual headless items cannot each have a separately assigned preview URL, so the target preview experience needs implementation.
- Editors manage headless items in a channel-specific application, which may differ from the website-page experience.
- GraphQL schemas and content models still need disciplined ownership and change management.
Those are neither reasons to reject the platform nor footnotes to discover after purchase. They affect cost, editorial work and delivery capability.
What progressive adoption can mean
A hybrid platform may let a firm begin with a website channel and reusable content, then add a headless channel when a real requirement appears. That can preserve a route to new delivery modes without introducing every layer on day one.
Progressive does not mean free or automatic. A future portal may need a different content model, identity, workflow and support arrangement. Reusing content across it can still require migration and design. The value is that the platform has a supported pattern available, rather than that no further architecture work will be needed.
Define the trigger for each step. For example:
- a client application needs approved service content independent of website releases;
- several sites need to share governed people and service records;
- a partner channel needs a secured content feed;
- front-end release needs have diverged from editorial releases.
If none is foreseeable and the firm manages one fairly simple website, hybrid capability may add little value. Buy for plausible requirements, rather than an abstract desire to appear modern.
Where Xperience can fit
The model deserves consideration when several conditions are present.
Editors need controlled visual composition. Marketing should manage important website experiences using an implemented design system, with workflow and preview.
Structured reuse has a clear purpose. Content must support several website areas, brands or channels, and ownership can be governed.
The firm has .NET delivery capability or an appropriate partner. Xperience website development uses its supported ASP.NET Core model. Headless channels broaden front-end options, while the platform itself still needs specialist implementation and operation.
Digital marketing capabilities are part of the requirement. Assess the specific features, data use, licence and operating effort rather than treating "DXP" as automatic value.
One platform is preferable to integrating separate CMS products. Concentration reduces some integration work and increases dependence on Kentico, its roadmap and the implementation ecosystem. The trade-off should be explicit.
Where the fit can break down
Xperience may be excessive for a simple site with a small budget and no credible reuse or marketing requirement. The licence, implementation and specialist capability need to earn their place.
A pure headless product may suit a digital product team that wants content services deeply integrated with its application code and does not value Xperience's website or digital-marketing model. A simpler coupled CMS may suit an editorial team whose needs are contained and who has little development capacity.
Hybrid can also become an excuse for unclear architecture. Teams create pages, reusable items and headless items without rules, duplicate models and make editors guess where content belongs. The platform offers several modes; governance decides whether they form one system or three overlapping ones.
Vendor concentration matters. Review data portability, content export, custom code, upgrade process, hosting, service levels, support and the cost of changing partner. A supported API does not eliminate lock-in.
Questions to put to Kentico and your partner
Ask for evidence using your content and journeys.
- Which of our requirements use website pages, reusable content and headless items, and why?
- Which editorial tasks work out of the box, which require configuration and which require custom development?
- What licence tier and usage assumptions does the proposed architecture require?
- How will preview, workflow and impact analysis work across channels?
- How are GraphQL access, secrets, caching, monitoring and failure handled?
- What will our internal team own after launch?
- How will content and integrations be extracted if the platform or partner changes?
- Which requirement would make you recommend a different CMS?
That final question is especially useful when the adviser is also a partner.
A hybrid option, rather than a magic answer
Xperience by Kentico can combine governed website pages, reusable content and GraphQL headless channels in one platform. That is a real architectural option supported by the current product documentation.
It does not remove the need to model content, implement editorial components, secure APIs, select a licence and operate the service. Whether it is better than a traditional or pure headless alternative depends on how much the firm values both modes and whether it can support them.
Read the companion platform evaluation for the wider Kentico decision, including capability beyond content delivery. If you are comparing vendors, use the separate Kentico alternatives article rather than treating this architecture as the whole selection.
The CMS architecture decision guide below maps traditional, hybrid and headless approaches against editor needs, development capability, channel requirements and integration complexity. Use it with your steering group, then test the resulting hypothesis against real workflows and current vendor terms.
