Best CMS for a Next.js Marketing Website
A decision guide for choosing Sanity, Payload, Contentful, WordPress, Webflow, or MDX for a Next.js marketing website.
Pick a CMS for a Next.js marketing site and you're really answering one question: how much of your content workflow lives in code versus in a dashboard. Get that boundary right and the tool almost picks itself. Get it wrong and you'll either bottleneck marketing or hand developers a UI they didn't want.
We build Next.js marketing sites on a tight timeline, and the CMS choice shapes the next two years of publishing. Here's how we narrow it down.
Match the tool to publishing volume
Start with how much you actually publish. A site that ships a post a month and a site that runs weekly campaigns want different tooling. Low volume with developer authors? MDX in the repo is a legitimate answer: git history, typed frontmatter, zero vendor cost. High volume with marketing authors who need drafts and scheduling? You want a real CMS dashboard. Volume is the first fork in the road.
Be honest about what editors need
Decide whether your editors genuinely need drafts, previews, scheduling, and roles, or whether you're buying features to feel safe. If marketers must publish without touching code, those features are non-negotiable and MDX is the wrong call. If developers own all content and value git workflow, a polished editorial UI is overhead nobody uses.
Model the schema before comparing vendors
Sketch your content types (posts, pages, FAQs, authors, sources, and CTAs) before you shortlist. The schema reveals how much structure you need, and structure is exactly where these tools differ. A site that's mostly flexible landing pages has different needs than one that's mostly structured blog content.
The realistic shortlist for Next.js
| Option | Where it shines | Watch out for |
|---|---|---|
| Sanity | Mature App Router patterns, live preview, typed queries | Studio config and GROQ learning curve |
| Payload | Self-host, code-defined schema, owns data | You run the infra; younger ecosystem |
| Contentful | Solid, enterprise roles and governance | Heavier and pricier for small teams |
| WordPress (headless) | Familiar editorial for existing teams | Bridge maintenance, weaker typing |
| Webflow | Design-led visual editing | Tighter for deep Next.js integration |
| MDX in-repo | Free, versioned, developer-owned | No drafts/preview/scheduling for non-devs |
Sanity and Payload have the most mature Next.js integration today: live preview, typed queries, webhooks. Contentful is solid but heavier for small teams. WordPress works headless but adds a bridge to maintain. Don't avoid WordPress reflexively, though. If your team already runs it well, the familiarity can outweigh the downsides.
Prototype against one real route
Connect one content type to one Next.js route before signing anything. Specifically, prototype one blog post type, one flexible page, and one SEO metadata flow. Then have an editor complete a publish. If it takes more than fifteen minutes after a short training, reconsider the tool. That friction compounds with every future post.
Validate that SEO comes from typed fields
Make sure metadata and structured data generate from typed fields, not hardcoded in templates. Title, description, canonical, OG image, and Article schema should all trace back to the CMS record so they never drift from the content. This is the difference between a CMS marketing can own and one that keeps routing changes back to engineering.
Common mistakes
- Buying for imagined scale. Choose for how you'll publish this year, not a hypothetical content team.
- Skipping the publish timing test. Fifteen minutes is the bar; measure it.
- Hardcoding SEO. Metadata in templates means editors can't fix titles.
- Ignoring who maintains the bridge. Headless WordPress isn't free of upkeep.
What to do next
Estimate your publishing volume and model your schema this week, then prototype one route in your top candidate. If you'd like the decision and the build handled together, Metamatter ships Next.js marketing sites with Sanity, Payload, or MDX, chosen for your team rather than for a trend.
What we'd choose by team shape
Quick heuristics from the projects we run. Solo founder or tiny team that codes? MDX in-repo, every time, until publishing volume forces a dashboard. Marketing-led team shipping weekly with a developer on call? Sanity, for its mature App Router preview and typed content. Engineering-led team that wants to own its data and infrastructure? Payload. Larger org with strict roles and governance needs? Contentful. Already happy in WordPress with a team that knows it? Keep it headless rather than forcing a migration nobody asked for. None of these is a universal answer. They're starting points you confirm with one prototype. The wrong-but-popular move is copying whatever a famous startup uses without checking whether you have their engineering team.
FAQ
Is MDX in the repo a real CMS option?
Yes for developer-owned publishing and small teams. You get git history, typed frontmatter, and zero vendor cost. It's wrong when marketers need drafts, previews, and scheduling without touching code.
Which CMS has the best Next.js integration?
Sanity and Payload both have mature App Router patterns: live preview, typed queries, webhooks. Contentful is solid but heavier for small teams. WordPress works headless but adds bridge maintenance.
Should I avoid WordPress for new Next.js sites?
Not if your team already runs WordPress well. Avoid it when you want typed models, static performance, and minimal plugin surface. Many migrations we do are WordPress to headless for exactly those reasons.
What should I prototype before signing a contract?
One blog post type, one flexible page, and one SEO metadata flow. If editors can't complete a publish in under fifteen minutes after training, reconsider the tool.