A headless CMS is not automatically the right choice because an organization is large, has multiple teams, or wants a modern technology stack. The better question is whether your delivery channels, editorial workflow, frontend requirements, governance model, and operating capacity justify separating content management from presentation.
One marketing website with limited developer capacity may be better served by a traditional or hybrid CMS. A website, mobile application, partner portal, and product interface that reuse the same structured content have a stronger case for headless architecture. The comparison below is a shortlist guide, not a universal ranking.
Pricing and plan signals were checked on October 14, 2026. Vendor pages and entitlements change frequently, so verify limits and obtain a current quote before procurement.
Choose the architecture for the work your team must deliver and operate, not for the word “headless” on a product page.
Which headless CMS platform should you choose?
Use channel count and frontend ownership as the first gate. One website and limited development capacity usually justify evaluating a traditional or hybrid CMS first. Several independently designed surfaces make headless worth testing. Multiple channels without a team to own routing, preview, publishing, deployments, and frontend incidents point toward managed hybrid delivery or delaying full decoupling.
- Contentful: evaluate for API-led delivery when its published plan limits and commercial-use terms fit your requirements.
- Hygraph: shortlist when GraphQL federation across CMS content and remote sources is central.
- Sanity: consider when a configurable collaborative authoring environment is important.
- Strapi: assess when self-hosting and control over the CMS deployment matter.
- Ghost: consider for publishing-first teams, after testing which native features depend on its frontend.
- WordPress VIP: assess when WordPress familiarity and managed enterprise delivery are valuable.
- Kontent.ai: evaluate when managed governance, roles, and structured delivery are priorities, with current pricing confirmed.
- Agility CMS: evaluate when managed editorial operations and page management are important, while resolving its current pricing-page discrepancy.
These signals narrow the field. They do not replace a proof of concept using your content model, editors, frontend, environments, and publishing rules.
What changes when a CMS is headless?
A headless CMS manages structured content while a separately controlled frontend retrieves that content through APIs and renders the experience. A traditional CMS generally combines content management and presentation. A hybrid deployment preserves a native or managed frontend while also allowing API delivery. WordPress VIP documents single-stack, headless, and hybrid options, including APIs, editorial preview, and frontend hosting, in its headless WordPress overview.
Decoupling changes who owns parts of the publishing experience. The application team may need to implement or configure frontend routing, rendering, draft preview, SEO metadata, accessibility, localization, deployments, cache behavior, and incident response. An API does not automatically supply those capabilities.
Ghost makes this tradeoff concrete. Its headless documentation identifies routes, sitemaps, SEO metadata, Open Graph data, pagination, redirects, and frontend code injection as areas that may require additional work. Memberships and several related features require the native Ghost frontend. Before decoupling, assign an owner for routing, preview, SEO, deployment, and incidents. Separating the frontend can reduce some deployment coupling, but shared APIs, authentication, caches, and infrastructure can still create operational dependencies.
Compare eight headless and hybrid CMS platforms
The profiles below state the documented fit and the main qualification to test. Every price is a current public signal reviewed on October 14, 2026, not a total-cost benchmark.
WordPress VIP
WordPress VIP supports single-stack, headless, and hybrid implementations, with REST and GraphQL APIs, editorial preview, Node.js application hosting, and support for frontend technologies including React, Next.js, and Vue. It can suit organizations that want familiar WordPress authoring with managed enterprise delivery. Pricing is custom rather than a verified fixed annual starting price. The VIP FAQ says pricing depends on factors such as deployment scope, traffic, environments, support, and add-ons. A self-managed WordPress build using WPGraphQL is a separate evaluation. The plugin does not establish that every WordPress plugin works headlessly or that every requested object supports the same mutations and permissions.
Contentful
Contentful provides Content Delivery, Management, Preview, Images, and GraphQL APIs. Its Content Delivery API is read-only and can return HTTP 429 responses when limits are exceeded, so delivery and write-back should be designed as separate operations. The pricing page lists Free at $0, Lite at $300 per month, and custom Enterprise pricing. The current Free plan lists limits including 10 users, two roles, two locales, 100,000 API calls per month, 50 GB of monthly CDN bandwidth, and one Starter Space. Lite lists 20 users, three roles, three locales, 1 million API calls, and 100 GB of monthly CDN bandwidth. Free is positioned for testing and learning, and its commercial-use conditions and hard limits require confirmation in the usage-limit documentation.
Kontent.ai
Kontent.ai separates delivery from management. Its API inventory includes Delivery REST, Delivery GraphQL, Management, Sync, Subscription, and image-transformation APIs. The Management API is authenticated and supports read/write operations, while the Delivery GraphQL API is read-only and the Management API is rate limited. This distinction matters for migrations and automation. Current documentation describes usage measures such as active users, bandwidth, content items, content types, collections, and AI credits, but does not establish a universal public price formula. Review the API inventory, Management API reference, and current subscription terms before estimating.
Agility CMS
Agility CMS documents REST and GraphQL delivery, page management, sitemaps, URL control, scheduling, versioning, approval workflows, multilingual content, roles, and security controls. Its current pricing page lists a free Proof of Concept, Essentials at $699 per month, and custom Enterprise pricing. A separate official comparison page still shows older tier figures. Treat this as a vendor-page discrepancy. Confirm the exact plan version, included limits, and commercial quote in writing. Do not use the older Starter, Pro, and Enterprise figures as current pricing.
Hygraph
Hygraph is worth testing when GraphQL Content Federation is a core requirement. Federation can combine Hygraph content with remote REST or GraphQL sources through one GraphQL endpoint, including remote requests with custom headers. The remote services still need working credentials, stable schemas, and an availability policy. Current pricing lists Hobby at $0, Growth from $199 per month, and custom Enterprise pricing. The current page lists Growth limits including 10 seats, three locales, 1 million API calls, and 500 GB of asset traffic. Do not repeat older claims about 190 Edge CDN nodes unless current infrastructure documentation supports them.
Sanity
Sanity is a configurable collaborative content environment with GROQ and GraphQL options. Compare query paths against freshness needs: its API CDN supports cached GROQ and GraphQL requests, while uncached requests may be fresher and have different cost and performance implications. GraphQL APIs are deployed from a Studio schema and have version considerations. GROQ is a distinct query language, not another name for GraphQL. Current pricing lists Free, Growth at $15 per seat per month, and custom Enterprise pricing. Sanity Canvas is an authoring workspace with collaboration and AI assistance that can map content into Studio fields. It is not a substitute for testing the complete publishing workflow.
Ghost
Ghost is a publishing-first product with a built-in frontend and a headless option. It may suit publishers whose requirements align with its native publishing model, but test memberships, subscriptions, content gating, comments, analytics, redirects, and SEO before replacing the frontend. Ghost(Pro) Starter is listed at $18 per month when billed yearly for up to 1,000 members. Self-hosting is a different cost and operating model. Headless teams should test routes, sitemaps, metadata, image handling, redirects, and membership requirements against the official headless guidance.
Strapi
Strapi is an open-source CMS with REST and GraphQL APIs, role-based access control, custom fields, webhooks, TypeScript support, and a self-hosting option. It can suit teams that want control of the CMS software and hosting decisions, provided they can operate the deployment. The CMS pricing page lists Community as free, Growth at $45 per month, and custom Enterprise pricing. Strapi Cloud is a separate hosting product, so the CMS license is not the total deployment price. Review the Cloud fundamentals and current Cloud pricing separately.
How to shortlist by editorial workflow, API behavior, and ownership
Run a small proof of concept before procurement. Use one real content type, one locale, one draft-to-publish transition, and one frontend route. Test the editor-to-frontend experience, not only the CMS interface or a successful API response.
Compare API semantics rather than labels. Record whether each API is read-only or read/write, its authentication scope, how drafts and scheduled content appear, caching and freshness behavior, pagination, rate limits, and webhook support. Contentful’s Delivery API is read-only. Kontent.ai’s Management API supports authenticated writes while its Delivery GraphQL API is read-only. Never put management credentials in browser code.
Do not approve a CMS because an API request succeeded. Require an editor to preview a real draft, a technical owner to demonstrate published and failed delivery behavior, and an operations owner to explain who responds when a remote API or federated source is unavailable.
AI is optional. A bounded task such as proposing a mapping from legacy fields to a target content type may help with ambiguous source data. Deterministic rules should validate required fields, allowed values, locale, URL syntax, destination environment, duplicate state, and approval status. Keep human approval for public publishing, canonical URL changes, material edits, and low-confidence mappings. AI agent services may be relevant where the task, validation rules, and reviewer are explicitly defined.
Three implementation patterns to pressure-test
These are illustrative application designs, not turnkey vendor connectors. The named APIs document capabilities, while the field names, validation rules, and ownership below are proposed implementation choices.
| Pattern | Trigger and validation | Action and destination | Exception owner |
|---|---|---|---|
| Published content delivery | A page requests published content. Confirm the delivery API, required fields, locale, cache behavior, missing-content handling, authentication, and HTTP 429 response plan. | Map the response to a frontend view model and render it in the separately owned web or application frontend. Store request observations separately from content records. | Frontend or platform owner handles API errors, stale cache, routing, and rendering. Content owner corrects missing or invalid source content. |
| Controlled migration write-back | A migration job reads a source revision. Validate content type, required fields, locale, HTTPS URLs, destination environment, scoped credential, existing target state, and source revision. | Write a draft or staging item through an authenticated management API. Preserve provenance and publish only through the approved editorial workflow. | Migration lead resolves mappings. Editor approves content. Platform owner handles credentials, rate limits, conflicts, and retries. |
| Federated content query | A page combines CMS content with remote REST or GraphQL data. Validate authentication, schema mapping, pagination, nulls, timeouts, authorization failures, schema drift, and stale-data policy. | Return a composed response to the frontend with an explicit partial-data or unavailable state. The integration team owns remote credentials and schema mapping. | Integration owner handles source failures. Product or operations owner decides whether stale or partial data is safe to show. |
For delivery, a content item and a delivery observation are different records. One content item can appear on multiple routes or builds, and one request can retrieve several items. For migration, a source revision is not the same grain as a destination record, API request, citation, or publishing event.
Illustrative editorial design example, not a vendor schema: this payload represents one source record revision in one locale. It preserves provenance for review and rollback.
{
"source_system": "legacy_cms",
"source_record_id": "post-1042",
"source_revision_id": "rev-7",
"locale": "en-US",
"target_content_type": "article",
"transformation_version": "map-v3",
"review_status": "editor_review_required"
}Use a database-enforced unique key such as source_system + source_record_id + source_revision_id + locale, or an equivalent transactional upsert. A lookup followed by create is not race-safe when concurrent workers process the same revision. On a validation error, send the item to a review queue with the response and provenance. Do not silently retry malformed data. For Hygraph federation, define a visible partial-data or unavailable state because a single GraphQL endpoint still depends on remote credentials, schemas, and availability.
Estimate total operating cost, not just the subscription
Build a 12-month scenario that separates the CMS subscription or license from frontend hosting, CDN and bandwidth, implementation, migration, preview infrastructure, monitoring, support, and ongoing engineering. Add expected editors, locales, environments, API calls, content or entry limits, paid workflow features, and overage terms. A subscription price alone is not a total-cost comparison.
- Expected editors, roles, locales, environments, content volume, and retention requirements.
- Monthly API requests, bandwidth, frontend traffic, and the measurement scope for each limit.
- CMS subscription or license, frontend hosting, CDN, preview, monitoring, and incident response.
- Implementation, content modeling, migration, support, and ongoing engineering hours.
- Commercial-use terms, overages, paid governance features, and self-hosting or cloud costs.
- Pricing-page or quote date, exact plan name, included entitlements, and written confirmation.
Public pricing needs context. WordPress VIP and Kontent.ai require plan or quote verification. Agility’s official pages currently conflict. Contentful Free has usage caps and commercial-use qualifications. Ghost(Pro) and self-hosted Ghost are separate models. Strapi CMS licensing and Strapi Cloud hosting are separate decisions. Recheck the relevant vendor pages before procurement.
A practical final decision rule
Score shortlisted options against five needs: channel fit, editorial usability, API and delivery behavior, governance and security, and total operating ownership. Weight them according to the project, but treat security, must-have workflow, and named operational ownership as pass-or-fail gates. A high score must not compensate for a failed requirement.
Choose a traditional or hybrid setup when its integrated frontend solves the problem with less operational overhead. Choose full headless when channel or frontend requirements justify separating content from presentation and the team can own the added work. The right answer may also differ by property within the same organization.
Before committing, require an editor to preview a real draft in the target frontend, require a technical owner to demonstrate delivery and rollback behavior, and record who responds when a CMS API or federated source is unavailable. That evidence makes the shortlist defensible. For help mapping CMS responsibilities and operating ownership, see systems and operations consulting.