Decision guide
The question "which CMS?" typically comes when marketing wants to edit pages, product wants to launch landing pages more often, and development does not want to merge copy changes in Git every week. Headless solves that by separating editorial from frontend — but it introduces a new system you must operate, secure, and pay for.
We have set up headless CMS behind Next.js sites, documentation portals, and marketing layers on top of SaaS products. The choice is about who edits, how often content changes, and how closely it must sit next to product data — not about which vendor won a benchmark.
TL;DR
Key takeaways
- Headless makes sense when the frontend is Next.js (or similar) and content must update without deploy.
- Markdown or MDX in repo is often right for small teams with few pages and developers close to copy.
- Preview and publishing flow matter more than the feature list in the sales brochure.
- SEO still requires your work: canonicals, sitemap, structured data, and fast pages do not come automatically.
- Migration from WordPress is a project — not a weekend export.
When headless beats a monolith
A classic WordPress theme is a full stack: PHP, plugins, database, security updates, and an editor that knows the whole site. That is fine for content-heavy sites where the team already knows WordPress. It cuts poorly when your "site" is a Next.js app with auth, dashboards, and APIs — because then you end up with two worlds that must be styled the same and share data.
Headless means: the CMS stores structured content and delivers it via API. Next.js fetches at build (SSG/ISR) or on demand, renders with your components, and you keep control over performance and routing. The editor gets a focused interface; the developer keeps type safety and preview deploys.
It does not make sense if you have five pages that change rarely, or if the only requirement is a blog and the team is already happy with WordPress. In those cases the complexity is often greater than the benefit.
Headless CMS vs. WordPress vs. files in repo
Headless CMS
Sanity, Contentful, Payload, Hygraph — editorial separated from deploy.
- Non-developers can edit without Git access
- Structured content — not just HTML in a WYSIWYG
- Preview URL before publishing is possible
- Extra system: users, API, backup, possibly licence
- Integration and migration plan must be thought through from the start
Alternatives
WordPress, markdown in repo, or hybrid with static sections.
- WordPress: strong for pure marketing sites with familiar editorial workflow
- MDX/markdown in Git: simple, versioned, free — requires dev for larger changes
- Hybrid: marketing on CMS, app and docs in repo
- Page builders in monolith: fast — harder to match custom app UX
- Choose based on team — not on what looks most modern
How we think about vendor choice
Sanity is our often-chosen default for marketing and product content: flexible schema, good developer experience, hosted or self-hosted options, and solid preview with Next.js. Contentful is strong in enterprise with many editors and good governance — at a cost in complexity and licence. Payload and Directus give self-hosted control when data must stay in your VPC. Hygraph and similar fit when GraphQL and federated content are central.
No vendor solves information architecture. You still must decide content types, slugs, locale structure, and who may publish. A bad schema in a good CMS gives a bad site — just with a prettier admin UI.
We recommend starting with few content types and tight fields rather than modelling the whole company on day one. It is easier to extend schema than to fix a thousand messy documents.
Questions you should have answers to before choosing
Use the list in discovery — it quickly reveals whether you even need headless yet.
- Who edits — marketing alone, or also product and support?
- How many languages must be supported, and who translates?
- Must content be previewed on a real URL before publishing?
- How closely must CMS content sit next to product data (features, docs)?
- What downtime is acceptable and who owns backup of content?
- Must old WordPress URLs preserve redirects and SEO value during migration?
Preview, ISR, and publishing
The flow editors feel is preview and publishing. We typically set up draft mode or a preview secret so changes can be seen on a real URL before they go live. Publishing triggers revalidation (ISR) or a webhook to build — depending on how fresh content must be.
Not everything must be dynamic. Marketing pages that change weekly can often be built statically and revalidated on demand. That is cheaper to run and better for performance than fetching everything from the CMS on every request.
Images and assets are best handled via the CMS asset pipeline or a dedicated CDN — not large files in Git. Alt text and cropping rules should be fields the editor sees, not something the developer fixes afterwards in code.
Questions we get again and again
Can we just keep WordPress as headless?
Yes — WordPress as an API backend is a valid migration step. You get a headless frontend without rewriting all content on day one. The downside is you still operate WordPress, plugins, and security. For many teams it is a bridge — not the end goal.
Is markdown in repo not good enough?
For docs, changelog, and sites with few contributors: often yes. It is versioned, reviewed in PR, and requires no extra login. When marketing must iterate without a dev queue, CMS becomes attractive. Many products run hybrid: CMS for marketing, markdown for technical content.
How do we handle multiple languages?
Choose a CMS with first-class locale or separate fields per language. Next.js app router with locale prefix matches well. Plan who translates and whether fallback is acceptable — technical setup is the easy part.
What about e-commerce content and Shopify?
Product data typically belongs in Shopify (or your PIM); marketing pages in CMS. Avoid duplicating product info in two systems without a sync strategy. CMS for campaign pages, Shopify for catalogue — with clear links between them.
How long does a migration from WordPress take?
Depends on number of pages, custom fields, media, and SEO requirements — not on CMS choice alone. We map URLs, redirects, and content types before migrate. A small marketing site is a different project than a site with hundreds of articles and custom post types.
Need editorial without redeploy?
Let us find the CMS level you actually need.
We help decide whether headless, hybrid, or files in repo is right — and set up preview, schema, and SEO so it holds up in operations.