The best CMS is the one your team can use: Webflow, WordPress or headless

Most CMS decisions get argued the wrong way round. Whoever is building the site writes the shortlist, the criteria are technical, and the person who will actually use the thing four times a week gets asked last, if they get asked at all.

The short answer: choose Webflow when marketing ships its own pages and the website is where that content is used. Choose headless, with Sanity, when the same content also has to appear in a product interface, a customer email or a second site. Running several sites is not the test on its own. Skip the CMS when nobody edits. WordPress is what serious teams migrate off.

Jump to:

• The CMS chooser
• All seven platforms, side by side
• How to choose a CMS in five steps
• Common CMS questions

That is how a business ends up with a platform its developers like and its marketing team works around. Marketing briefs a change, waits three days, and learns not to bother. The site stops being edited. Nobody decides that. It just happens.

One thing to clear up first, because CMS covers too much ground. This article is about a website CMS: the marketing site, the pages prospects read. In-product content, help docs and app copy are a different problem, and a platform that is right for one is often wrong for the other.

E-commerce sits outside this article too. A store's content problem is products, variants, inventory and checkout, and that pulls the decision somewhere else. Shopify is in the table below so the comparison is honest, but choosing a platform to sell on is a different article. Our e-commerce web design work is the better starting point for that.

If no row quite fits, answer four questions further down and get a starting point.

Who will actually edit the site?

Four questions settle most of it, and none of them are about technology:

1. Who changes the site, and is it their job or the thing they do after their job?
2. How often? Weekly, or twice a year when a product launches?
3. What has to be reviewed before a change goes live?
4. What happens when the person who knows how it works leaves?

Answer those honestly and the shortlist usually collapses to one or two options. Honest means for today. A lot of teams move to Webflow or Framer precisely because marketing wants to own the site and currently cannot, and that is a fine reason to migrate. Just make sure taking it over is the actual plan, or you will buy the wrong thing and blame the software.

What happens when an editor gets it wrong?

Two questions decide this, and most evaluations only score the first. Ease of use tells you whether someone junior can finish the task. What breaks when they get it wrong, and how far it spreads, is the second, and that is the one that costs you a weekend.

A visual builder does brilliantly on the first question, and the second depends entirely on the seat you give someone. On a design seat, the interface that lets them fix a typo also lets them drag a section into the wrong container. Both Webflow and Framer also sell a content editor seat: it edits text, images and CMS items and cannot touch styles, structure or components. Set that up and a visual builder is a structured CMS for everyone who does not need the canvas.

A structured CMS flips that. The first week is harder, because fields are more abstract than dragging boxes around a page. After that, an editor can only fill in the fields a developer set up. They can still publish the wrong words or unlink something that matters, but they cannot move a section, break a grid or delete a component. The layout is not theirs to change.

So both can be locked down, and the difference is where the guardrail lives. On a visual builder it is a permission: someone has to assign it, and someone can widen it again. On a structured CMS it is the schema, and there is no wider setting to grant. That matters little on a team with a named site owner and a lot on a team without one.

Most teams find that trade-off out after they have bought, which is the wrong way round. If several people will edit the site at different levels of confidence, guardrails are a feature, not a limitation. Decide who gets the canvas and who gets content only on the day the site launches, not the day someone breaks a page.

When is Webflow or Framer the right call?

When marketing needs the page the day it asks for it. A visual builder like Webflow gives marketing a landing page on the day it is needed, not the week a developer can fit it in. That is not a small thing. A campaign page that goes live while the campaign is still running is worth more than a tidy content model.

The other thing Webflow has become is a marketing engine. Split testing and personalisation are built in through Optimize, analytics through Analyze, both paid add-ons, and its AI tools sit inside the same designer. None of it needs wiring together, and that matters more than it sounds, because building the same stack by hand is a project of its own.

Webflow is building further in that direction. Source, announced at its 2026 conference, is aimed at marketing teams and the AI agents working beside them, and it is meant to sit over the code and the marketing tools a team already runs. It is worth knowing about. It is not worth choosing on yet: as at 16 September 2026 it is a limited research preview you have to apply to join.

It is also the low-maintenance option of the three. Webflow is hosted, so there are no plugins to update, no servers to patch and no plumbing to own. A WordPress site needs an owner and a custom headless build needs a maintainer. A Webflow site mostly just runs, and for a team with nobody to give that job to, that alone can settle the choice. It settles a lot of our Webflow agency work.

That is the real reason teams choose Webflow or Framer. The designer is structured enough that marketing can change real pages themselves, not just blog posts. Headless usually means a fully custom site, real web development rather than configuration. You lose that ready-made structure, you get more flexibility, and you take on more responsibility for making it all hang together.

Visual builders' limit: reused content

The limit is reach. Webflow's Collections give you structured, reusable content, but they stop at the website. As soon as the same fact also has to feed the product UI, an email or another site, you are keeping copies. Copies are fine until they disagree. Then it is a support ticket about pricing that is wrong on one page.

Be precise about what does carry across, because Webflow shares more than people expect. Libraries push components, variables, fonts and assets to every site in a Workspace, so a set of project sites can run one design system and take a button change together. What Libraries does not carry is the content. Collections belong to the site they were made in.

Worth separating two things that get lumped together. Sending leads to a CRM and sign-ups to Mailchimp is data leaving the site, and Webflow does that well. HubSpot has an official Webflow app, a Webflow form can post straight into a Mailchimp audience, and Zapier covers the rest. Most Webflow sites run exactly that way, and nobody needs a headless CMS to get an enquiry into HubSpot.

Sharing content is the other direction, and it is the one Webflow cannot do on its own. The same price, product fact or case study has to appear on the site, in the app, in a customer email and on a partner's page. Collections stop at the website. You can push items in with the Data API, or let an app like Syncmate keep them in step on a schedule, and plenty of teams run exactly that way. It is still copies, and copies drift.

A headless CMS like Sanity is built for that direction. Content is global: pricing, features and case studies live in one place, and the website, the app, customer emails and any partner feed all read from that one source. Update it once and it is right everywhere. If leads into a CRM is the only integration you need, that is not a reason to go headless.

When does WordPress stop fitting?

When nobody genuinely owns it. WordPress is where most websites start, and for a while it is enough. It earns its keep in two narrow situations: someone on the team genuinely owns it and runs it well, or a plugin exists that nothing else replaces. Outside those two, the case for staying is thinner than it looks.

The trade-off is ownership. Themes, plugins, security and updates all need someone responsible, and an unmaintained WordPress site decays: slower every year, a plugin one version behind, an update nobody dares run. When the website turns serious, when it has to win work rather than just exist, that burden is usually the first thing a team pays to leave behind. When WordPress work reaches us, it is usually a migration to a new web design.

What does headless buy, and what does it cost?

It buys one source of content for every surface, and it costs you the plumbing. Headless keeps the content separate from where it shows up, as structured data any surface can request. Sanity is what this site runs on. If you have more than one surface, that is the whole argument, and it is a good one.

The cost is rarely on the comparison chart. You now own the plumbing, and on a multi-site build you own a front end for every site as well. Webflow would have hosted and patched those for you.

This website is built with Astro, hosted on Cloudflare, with Sanity as the blog CMS. It reads its content when the site is built, not when a page is requested. Every page ends up a static file, which is fast, cheap and very hard to take down. The trade is that publishing is a deploy, so something has to notice a publish and start a build.

On this site that meant a webhook, a check that the webhook is genuine, and a build trigger kept as a secret. None of it is hard, and none of it shows up in a feature comparison. It is work a visual builder never asks of you.

Does AI change which CMS to choose?

Only if you already have developers. AI changes the choice for teams that have them and barely at all for teams that do not. Worth spelling out, because the question now comes up in every conversation.

Webflow has not stood still. Its MCP server hit 2.0 in July 2026, and it lets an AI assistant read and write pages, elements, styles, components and CMS collections directly, inside your existing design system rather than around it. Building in Webflow is no longer only done with a mouse.

If the marketing team builds its own landing pages, Webflow still wins. Someone in marketing can open a campaign page, duplicate a section and ship it that afternoon without asking anyone. No amount of AI tooling replaces that, because the constraint was never how fast a page could be built. It was who was allowed to build it.

If developers and designers are already across every page, the maths has changed. A team that already owns page production in code, with a component system built, can now stand up marketing pages on a headless setup faster than the same work moves through Webflow. Without that, the advantage disappears. If every page already goes through a developer, a visual editor is an extra step.

A property developer is the clean example, and it splits in two. If each project site carries its own listings and its own floor plans, Webflow handles it: Libraries keeps the design consistent across all of them, and the only thing shared is the look. If the same listing, price or floor plan has to be right on the project site, the head office site and the sales brochure, that is one set of content with several readers, and it belongs in one place. Sanity is built for the second case.

One caution before anyone rebuilds in code: having developers free is not the same as having the skill set. Split testing, analytics and personalisation are their own craft, and with Webflow that engine comes off the shelf. A developer team choosing headless is signing up to assemble its own, or to live without one.

What does each option cost to run?

None of these paths is free, they just bill differently. Webflow is a licence, plus paid add-ons like Optimize and Analyze if you want the marketing engine. What you are not paying for is anyone's time to keep it running.

WordPress looks cheapest on paper and rarely is: hosting, premium plugins and, above all, someone's hours every month to own updates and security. The licence is free. The ownership is not.

Headless is the opposite shape: more to build up front, then a licence for the CMS and a maintainer for the plumbing. It pays back when the same content runs several surfaces, and not before.

All seven platforms, side by side

Two names come up often enough to place them. Framer sits beside Webflow: more design-led, faster from canvas to page, lighter on content structure, with the same editing risk. HubSpot sits beside WordPress: a traditional CMS inside a marketing suite. Teams land on it because marketing already lives there, and the convenience is real. So is the lock-in: the deeper the site goes, the harder it is to leave, and when a team gets serious about its website, the site is usually the first thing to move out of the suite.

One row is missing on purpose: the site nobody edits. Plenty of sites change twice a year, and paying a monthly licence plus a retainer for a CMS nobody opens is worth deciding on purpose.

Sanity, Contentful or Strapi?

How to choose a CMS in five steps

Before you shortlist anything, write down five answers. The chooser below turns four of them into a starting point.

1. Who needs to create new layouts, not just edit words?

If the answer is marketing, you need a visual builder. If it is only ever a developer, a visual editor is an extra step in the way.

2. Which surfaces does the content feed: the site alone, or an app, emails and feeds too?

The site alone points at Webflow. More than one surface is the one reason to go headless.

3. Who owns maintenance: updates, plugins, tokens, hosting?

Nobody is a real answer, and it points at Webflow: hosted, patched, nothing to own. Headless assumes a named maintainer.

4. What needs approval before it goes live, and how do you roll a mistake back?

Ask each vendor to show you the undo, not the publish. On a visual builder the answer is roles and locked components. On a structured CMS it is fields.

5. How much building and running can the team honestly carry?

Honest means for today. Wanting to own the site is a fine reason to migrate, so long as owning it is the actual plan.

Common CMS questions

Will it work in year two?

Choose the platform your team can still use in year two, once the people who launched the site have moved on.

Every CMS demo shows the same thing: a clean setup, a confident editor, a change live in seconds. None of them show the day someone needs to change a phone number on eleven pages, the person who built the site has left, and the agency that made it has been replaced.

That is the day worth planning for. Not the platform with the best feature list, but the one the people still here can actually use, and cannot accidentally break.

It is the same test we run on every project in our case studies, whatever platform the answer turns out to be.