Which CMS for which job: 11 platforms compared for 2026

Most CMS comparisons mix tools that do different jobs and then rank them in one table. That produces tidy lists and weak decisions. Framer is a strong way to run a startup marketing site. Payload is a strong way to own structured content, access rules, and application logic in TypeScript. Ghost is built around publishing and memberships. Shopify runs commerce. None of those claims needs one platform to beat the others at every task.

This comparison starts with the job.

WAYF is an official Payload partner and top contributor, so we have an interest in this comparison.

CMS comparison at a glance

Platform	Type	Best fit	Who owns most of the setup	Commercial shape
Framer	Visual site builder with CMS	Design-led marketing sites and landing pages	Designer or marketer	SaaS plan, editor seats, CMS and bandwidth limits
Webflow	Visual site builder with CMS	Larger marketing sites with visual layout control	Designer or Webflow developer	SaaS site and workspace plans, usage limits
WordPress	Traditional CMS	Conventional websites, publishing, and plugin-led builds	Site owner, host, and WordPress developer	Free software plus hosting, plugins, and maintenance
EmDash	Astro-native full-stack CMS in beta	Astro sites seeking WordPress-style editorial UX	Astro team and content owner	Open-source software plus hosting and beta validation
Ghost	Publishing CMS	Blogs, media sites, newsletters, and memberships	Publisher or a small technical team	Open-source self-hosting or managed plan based partly on audience size
Shopify	Commerce platform with content tools	Stores where products, checkout, and orders are central	Merchant and Shopify partner	SaaS plan, payment and app costs
Payload	Code-first headless CMS and application framework	Owned content platforms with custom logic and access control	TypeScript engineering team	Open-source core, licensed enterprise features, self-hosting (Payload Cloud closed to new projects)
Sanity	Hosted content platform with React studio	Teams wanting a hosted content store and React-based studio	Frontend team and studio developer	SaaS seats and usage, custom enterprise plan
Contentful	Managed headless content service	Multi-team and multi-region content operations	Frontend team and content-platform owner	SaaS spaces, seats, usage, and enterprise plan
Storyblok	Visual headless CMS	Component-based sites with in-context editing	Frontend team and content designer	SaaS spaces, seats, traffic, requests, and locale allowances
Strapi	Self-hosted or managed headless CMS	Framework-neutral Node.js teams that want SQL database options	JavaScript team and platform owner	Free Community core, paid CMS capabilities, optional cloud

The table narrows the category. The next step is to compare the two or three tools that solve the same job.

Framer and Webflow for a marketing site

Framer and Webflow combine page design, content management, hosting, and publishing. They remove the need to assemble a frontend framework, CMS API, preview layer, and deployment pipeline for a standard marketing site.

Framer is the faster choice for a design-led team that works in a canvas and publishes a relatively compact site. Its current plans set limits around pages, CMS collections and items, bandwidth, editors, and locales. The Pro plan adds staging and branching. Enterprise adds custom limits, SSO, SCIM, and an uptime commitment. This makes the upgrade path legible, but the limits should be tested against the planned content estate.

Webflow has a deeper site-building and CMS workflow for teams that already know its class system and collection model. Its current plans also scale through bandwidth and organisational capabilities. Higher platform tiers add publishing workflows, governance, custom roles, and security controls.

Both are good when the website is the product of the CMS. They become awkward when the same content needs to feed a mobile app, a customer portal, or several independent frontends. An API-first CMS gives that content a cleaner home.

WordPress and EmDash for conventional publishing UX

WordPress remains a sensible choice for a content-led site whose editors know the interface and whose requirements fit maintained themes and plugins. It has a huge implementation market, wide hosting choice, and a familiar editorial model.

The assembled system creates the risk. The CMS may be free, while the production site depends on a theme, page builder, SEO plugin, forms plugin, security tooling, managed host, and the developer who knows how those parts interact. Price that whole system and the upgrade path. A carefully maintained WordPress build can run for years. An unowned plugin stack ages quickly.

Large publishers should evaluate WordPress VIP as a separate enterprise product. It packages managed hosting, security, service levels, and support around WordPress rather than behaving like a larger shared-hosting plan.

EmDash CMS is a new Astro-native alternative that follows WordPress’s editor-first approach to CMS UX. Its visual schema builder lets editors shape collections, while developers can generate TypeScript types from the live model. It is still in beta preview, so teams should prototype the publishing flow, permissions, backup recovery, and deployment before treating it as a production choice.

Ghost for publishing and memberships

Ghost has a clear job. It combines a publication, email newsletter, membership system, subscriptions, themes, and analytics. A founder publication or paid newsletter gets these pieces without assembling several plugins.

The managed Ghost(Pro) plans scale partly with audience size and team needs. Ghost can also be self-hosted because the software is open source. It is a weak fit for a product catalogue, a complex corporate site estate, or deeply relational content used across applications. Its narrower scope is the reason it works well for publishing.

Shopify when the site is a store

Shopify includes pages, blog posts, navigation, and theme content, so it often appears in CMS comparisons. Its centre is commerce. Products, variants, inventory, checkout, payments, discounts, orders, and the app market drive the platform choice.

Use Shopify when selling is the main system requirement. A separate CMS can sit beside it if brand storytelling or multi-channel product content grows past Shopify’s content model. Replacing Shopify with a headless CMS would remove the commerce engine and leave the harder half of the system unsolved.

Payload for an owned TypeScript content platform

Payload is my default for a product team that wants code-first TypeScript schemas, custom application logic, granular access control, and ownership of its data and deployment. A Payload configuration generates the admin panel, database schema and migrations, APIs, authentication, access control, and TypeScript types in the application codebase. It supports MongoDB, PostgreSQL, and SQLite, and the organisation can deploy it on its own infrastructure.

Payload serves Astro and other decoupled frontends through its REST and GraphQL APIs. Applications built with Next.js can also remove a network boundary through the Local API when sharing a runtime makes sense. In either setup, content-model changes can follow the same review and release process as application changes. Granular access control can reach operations, documents, and fields. Head-to-head detail on the pairs that come up most sits in Sanity vs Payload and Strapi vs Payload.

The trade is ownership. The engineering team or its delivery partner has to run the application, database, storage, backups, upgrades, and monitoring. That is a good exchange for teams that want an owned product platform. It is wasted work for a five-page site. SSO, publishing workflows, and a system-wide audit log sit outside the core as licensed enterprise features that Payload does not price publicly. Payload Cloud is closed to new projects following Figma’s acquisition of Payload in June 2025, so a new deployment is self-hosted or partner-run.

Sanity for a hosted content store and React studio

Sanity stores content in its hosted Content Lake and gives developers an open-source React studio they can configure around the content team. It supports structured content, live preview, visual editing, collaboration, and its GROQ query language.

Sanity runs the content store while the team owns the React studio as software. Include its development in the comparison rather than treating the CMS as ready on signup. Sanity vs Payload works through that difference in ownership at length.

Its current commercial model includes a free tier, per-seat Growth plan with usage allowances, and an Enterprise plan for custom roles, SAML SSO, support, retention, and quotas.

Contentful for managed content operations

Contentful is a mature managed headless content service. It gives teams structured content, APIs, environments, locales, editorial tools, and a large set of governance and infrastructure options on its higher plans. Salesforce completed its acquisition of Contentful on 1 September 2026; existing contracts run as written until renewal, and what the close changes for Contentful customers covers the day-one position.

It makes sense when several teams need a vendor-run content service and procurement accepts the cost model. The published plan structure uses spaces and quotas for roles, locales, API calls, bandwidth, records, and environments. Model growth across each dimension. The price of one site today does not describe the content platform three years from now.

Storyblok for visual headless editing

Storyblok keeps the API-first model and adds a visual editor that maps pages to reusable components. This gives editors an in-context view while developers keep control of production components and the frontend framework.

The implementation succeeds or fails on the component model. A disciplined set of components gives editors useful freedom. A loose set turns the design system into a long settings form.

Storyblok’s current plans vary by spaces, seats, traffic, API requests, content limits, locales, and governance. It belongs on the same shortlist as Sanity or Contentful when visual editing is a hard requirement.

Strapi for framework-neutral self-hosting

Strapi is a Node.js headless CMS that can run on the organisation’s infrastructure or on Strapi Cloud. It exposes REST and GraphQL APIs and supports PostgreSQL, MySQL, MariaDB, and SQLite. Content-type definitions move with the code between environments.

Self-hosting and framework independence are the attraction. The Community edition covers the core CMS. Growth adds Strapi AI, live preview, releases, content history, and basic support; review workflows and audit logs sit on Enterprise, and SSO is a Growth add-on that Enterprise includes.

Operations remain part of the decision. The deployment documentation calls out the production build, secrets, database, environment isolation, and schema changes that a team must manage even though the software itself is free. Strapi vs Payload compares where each project places governance features and per-seat cost.

How I would choose

Start with the primary job and remove the categories that do not fit:

• A visual marketing site points to Framer or Webflow.
• A conventional company site with a WordPress team points to WordPress or WordPress VIP. An Astro team seeking the same editor-first UX direction can prototype EmDash.
• A publication or newsletter points to Ghost.
• A store points to Shopify, with a separate CMS only when content needs justify it.
• An owned content platform with code-first TypeScript schemas, custom logic, and granular access control points to Payload.
• A managed headless service points to Sanity, Contentful, or Storyblok, depending on studio, governance, and visual-editing needs.
• Framework-neutral self-hosting points to Strapi.

Then build one representative content type in each finalist. Test editing, preview, permissions, localisation, migration, deployment, and export. Our article on what to ask before choosing a new CMS or migration partner turns those tests into buyer questions. Larger organisations should use the narrower enterprise CMS shortlist. Early-stage teams can use the CMS for startups guide.

If the shortlist still contains a visual builder, a commerce platform, a publishing system, and a headless CMS, the project has not named its primary job yet.

FAQ

Which CMS is best in 2026?

There is no single best CMS. Framer and Webflow fit visual marketing sites. WordPress remains useful for conventional publishing, while EmDash is a new Astro-native alternative following its editor-first approach to CMS UX. Ghost fits publications and newsletters. Shopify should own a store. Payload, Sanity, Contentful, Storyblok, and Strapi fit structured content delivered to custom websites and products.

Does Payload require Next.js?

No. Payload can serve Astro and other frontends through REST and GraphQL. Applications built with Next.js can also use its Local API, but the frontend framework does not determine whether Payload is a good fit. Choose it for code-first TypeScript schemas, ownership, access control, and custom application logic.

Should a business choose a traditional or headless CMS?

Choose a traditional or visual CMS when the website is the main output and editors need to control pages directly. Choose a headless CMS when the same structured content must feed several websites, apps, or product interfaces, and when an engineering team can own the frontend and preview experience.

How much should CMS pricing affect the decision?

Pricing should be modelled over three years. Include seats, API usage, bandwidth, locales, spaces or environments, hosting, plugins, upgrades, and engineering time. A free self-hosted CMS can cost more to operate than a paid service, while a low entry price can grow sharply with usage.

Sources

• Framer plans
• Webflow plans
• WordPress software
• WordPress VIP plans
• EmDash architecture
• EmDash repository and beta status
• Ghost(Pro) plans
• Shopify platform plans
• Payload overview
• Sanity plans
• Contentful plans
• Storyblok plans
• Strapi deployment documentation
• Strapi CMS plans
• Payload CMS, enterprise features (SSO, publishing workflows) — checked 11 September 2026
• Payload CMS, enterprise audit logs (system-wide activity and configuration history) — checked 11 September 2026

Product capabilities and plan structures were checked on 4 September 2026. The recommendations are WAYF’s judgement, based on the jobs and ownership models described above.