:format(webp)){kind=small}
What this hub helps you decide
The CMS hub helps teams shortlist platforms for marketing websites and reusable content applications. We focus on the editing experience, content model, implementation work and ongoing ownership a choice creates.
There is no universal winner. A guided page builder can suit one team, while another needs a custom editorial application. Start with who creates content, where it is reused, which requirements are mandatory and what your team can maintain.
How to read the pages
Platform profiles
Start with the direct answer, then use “Good fit” and “Consider alternatives” to check the main conditions. “Evidence by criterion” explains documented capabilities, assessment badges and material plan considerations. “Team takeaways” summarizes the implications for content teams and developers.
Comparisons
Comparisons begin with when to choose either platform or consider neither. Each criterion card reuses both platforms’ evidence and adds a summary of the difference. “Choosing between them” explains the decision implications and a practical next step. The final use-case recommendations bring those trade-offs together for common needs.
The platform evidence and comparison advice serve different purposes: one describes the capability and its limits; the other explains when that difference matters to a choice.
The 12 criteria
We use the same criteria across profiles and comparisons. Several overlap: visual editing can affect marketer autonomy and website fit. They are different decision lenses, not independent votes to add into a score.
Marketer autonomy
What editors can change without developers, how page composition is governed, and who maintains the blocks or custom editor that make that independence possible.
Content modeling
How pages, components, documents and relationships are modeled, validated and reused across websites, products and channels.
Workflow and governance
Collaboration, review, approvals, scheduling, releases, roles and history. We distinguish default capabilities from features requiring another plan or custom implementation.
Localization and multisite
How translations, market-specific content and separate sites are organized, including regional independence, publishing implications and the editing experience the team must maintain.
Developer experience
Schema management, API and CLI tooling, frontend integration and the ongoing responsibility for custom editor code, dependencies and upgrades.
APIs and extensibility
Delivery and management APIs, query capabilities, webhooks, live updates and integration options. Similar API names or quotas do not necessarily mean equivalent behavior.
Hosting and operations
Who runs the content backend, editor and delivery infrastructure, and who owns frontend hosting, deployments and recovery responsibilities. Editor self-hosting and content-backend self-hosting are separate questions.
Security and governance
Documented assurance, data residency and access controls, alongside plan-specific identity, backup, SLA and support requirements. Certification alone does not establish suitability for your organization.
Pricing and cost drivers
How spaces, seats, content, assets, locales, API usage and add-ons affect cost. Implementation, support and ongoing maintenance also belong in the budget.
Migration and exit
What export and import tools cover, and what still needs mapping or rebuilding: assets, relationships, translations, URLs, rich text and application code.
Marketing website fit
How the combined editing model, component library, localization approach and engineering responsibilities suit campaign and corporate websites. This is a synthesis of the other evidence.
Visual editing and preview
How editors see draft content, select content in context and receive live updates, including the frontend integration required to make the experience work.
What the assessment badges mean
Strength — an evidenced material advantage for the stated task or use case.
Supported — the capability is available and evidenced within the stated scope, without necessarily being a standout advantage.
Conditional — availability or suitability depends materially on the plan, configuration, custom work or your requirements.
Limitation — an evidenced material constraint for the stated use case.
Unknown — evidence is insufficient, conflicting or unverified. This is uncertainty, not a negative score.
Not applicable — the criterion does not apply to the product or use case.
A badge applies to the capability described beside it, not the whole platform. Comparisons reuse the profile’s assessment; their commentary explains the relevance to the decision. Ordinary frontend integration does not make every headless CMS feature conditional, but a material extra dependency should be stated.
We do not total badges, rank platforms by the number of strengths or calculate an overall winner score. The importance of each criterion depends on your operating model.
Where the evidence comes from
Platform evidence draws primarily on official documentation, pricing pages, security material and release notes. Each citation links to a source and explains which claim it supports. Use “View sources” beside the relevant claim to inspect those links and descriptions.
Documentation can establish that a feature is offered and describe its published limits. It cannot establish how usable your editors will find it, how long your implementation will take or which commercial terms you will negotiate. Missing documentation is not proof that a feature is absent.
Any first-hand experience or tested result must be identified with its task, environment, plan, date and limitations. We do not imply that every platform has been tested, or generalize one project’s outcome to all teams. Client details require permission.
Internally, we retain source access dates, verification and review dates, volatility and confidence. High confidence requires direct, scope-matched evidence without a material unresolved conflict; medium allows a disclosed, bounded inference; low reflects indirect, incomplete or conflicting evidence. Confidence describes the evidence, not product quality.
How recommendations depend on your use case
Recommendations connect the evidence to a concrete need. They should explain both why a platform fits and what could make the alternative preferable. Some requirements can rule out both products; enterprise requirements may need written confirmation before either can be recommended.
Marketing websites — guided visual composition, reusable components and who maintains the editing experience.
Structured content platforms — connected models and content reused independently of page layouts.
Multilingual multisite — translation structure, regional autonomy and the team’s ability to maintain the chosen model.
Ecommerce — connected product content versus composing storefront and campaign pages.
Enterprise governance — the exact workflow, identity, permissions, recovery and support requirements covered by the plan and contract.
Small teams — the implementation and ongoing ownership the team can realistically sustain, including whether a simpler CMS would be sufficient.
These are starting points, not automatic purchasing decisions. Test representative editing tasks, model your own content, try an export and confirm material plan assumptions before committing.
How we review and update the content
Our default review intervals are 30 days for highly changeable facts such as pricing, quotas and plan gates; 90 days for capabilities and workflows; and 180 days for stable architecture facts. These intervals guide editorial maintenance and do not guarantee that a claim remains correct until its next review.
A relevant product, plan, security or deprecation change calls for an earlier review. Any exception needs a reason, responsible author and alternative deadline. Before publishing a recommendation, overdue evidence that could change the conclusion should be rechecked, qualified or withdrawn.
Comparison cards reuse platform facts, but their commentary, direct answers and use-case recommendations are separately authored. A material change to platform evidence requires checking the affected comparisons. Updating the underlying facts does not itself mean that the comparison conclusions have been reviewed.
Review dates and confidence records are retained for editorial maintenance rather than displayed beside every claim. Shortening copy does not count as new product verification or reset those dates. A material change to this shared methodology also requires checking affected pages.