Best CMS for Next.js: what the App Router changed

TL;DR

Choosing a CMS for a Next.js project in 2026, the essentials:

• The App Router changed the evaluation criteria. Server Components moved content fetching to the server, so client SDK quality matters less than it used to. What matters now: how the CMS drives Draft Mode preview, and how a publish in the CMS invalidates the Next.js cache.
• The quick picks: Payload when a TypeScript team wants the CMS living inside the Next.js repo itself. Sanity when structured content and a tailored authoring experience justify engineering effort. Storyblok when marketers need visual editing against the live front end. Contentful when governance and procurement requirements lead. DatoCMS when you want structured content with strong localization and less ceremony.
• Markdown still wins a large class of projects. Developer-authored content belongs in MDX files in the repo, not behind an API.
• The platform matters less than the wiring. Preview, revalidation, and the content model are build decisions; every CMS here can be implemented well or badly. This page is about matching the platform to your team, then getting the wiring right.

Component-shaped content modeling, the other half of this decision, applies to every React front end and is covered once in our React CMS guide; it will not be repeated here.

What the App Router actually changes

Most “best Next.js CMS” lists mention App Router support the way they mention a free tier. Here is what the phrase has to mean before it is worth anything to you.

Server Components moved the CMS call server-side. In the Pages Router era, content often traveled through getStaticProps or was fetched client-side with a CMS SDK shipped to the browser. With React Server Components, your components fetch content directly on the server and ship HTML. Two consequences: the CMS SDK’s bundle size stops mattering, and what starts mattering is clean server-side data access, request deduplication, and typed responses. Any CMS with an HTTP API works; the good ones give you typed client libraries designed to be called from server code.

Preview became Draft Mode, and it has to be designed. Editors expect to click preview in the CMS and see the unpublished page. In the App Router that means the CMS calls a route handler that enables Draft Mode, and your data layer switches to fetching draft content for that session. Every platform on the shortlist supports this pattern, but the quality varies from copy-paste recipes to build-it-yourself. If editors preview twenty times a day, this workflow is a top-three selection criterion, and it is worth prototyping before you sign anything.

Publishing became a cache-invalidation problem. A static Next.js page does not update because the CMS changed; something has to tell Next.js. The clean pattern: the CMS fires a webhook on publish, a route handler calls revalidateTag or revalidatePath, and the affected pages regenerate on demand. Time-based revalidation works as a fallback but forces a trade between freshness and rebuild traffic. This is the wiring that separates a CMS integration that feels instant from one where marketing asks why the homepage is stale. Ask any implementation partner to demonstrate publish-to-live latency, not describe it.

If those three paragraphs sound like build decisions rather than CMS features, that is the honest conclusion: on Next.js, implementation quality dominates platform choice even more than usual. The rendering strategy behind these trade-offs is its own decision; our comparison of SSR, SSG, and CSR covers it.

The shortlist

Payload: the Next.js-native option

Payload occupies a position no other platform on this list can: since version 3 it installs directly into a Next.js application. The admin panel is a route in your app, the config is TypeScript in your repo, and the content lives in your database. There is no second vendor, no webhook round-trip to an external service, and no per-seat pricing; local development is one repo and one process, and CMS changes go through the same pull requests as everything else. It is open source under MIT.

Pick it when your team is TypeScript-fluent, wants full ownership of the stack, and prefers infrastructure it controls. Be honest about the cost side: you are operating a database and an upgrade path, the editor UX is functional rather than luxurious out of the box, and “the CMS is in the app repo” is only a virtue if the front-end team wants to own it. For marketer-heavy organizations that want a vendor accountable for uptime and support, the SaaS platforms below are the calmer choice.

Sanity: structured content with a first-class Next.js path

Sanity pairs naturally with Next.js: an official integration and starter ecosystem, live preview of draft content, and a React-based Studio your team customizes in code. Its deeper appeal is content as data: structured, queryable, reused across surfaces. Pick it when the content model is genuinely complex and the authoring experience deserves engineering investment. Skip it when nobody will own the Studio, or when usage-based pricing is hard to budget at your traffic. We run RudderStack’s Next.js site on it in production.

Storyblok: visual editing on top of your Next.js components

Storyblok gives editors a visual editor that renders your actual front end, with your components as the building blocks. On Next.js this takes deliberate setup to work smoothly with Server Components, but done properly it delivers the highest editor autonomy per developer hour on this list. Pick it when the publishing team is marketing and page composition is the daily job. Skip it when content is relational data rather than pages.

Contentful: the governance default

Contentful remains what large organizations pick when roles, workflows, environments, and vendor stability outrank everything else, and its Next.js integration path is mature and well documented. Pick it when procurement and multi-team governance lead the requirements. Budget for the real cost curve at scale, and for app-marketplace work to round out editor tooling. We migrated Danone’s Alpro onto Contentful with Next.js in front.

DatoCMS: structured content with less ceremony

DatoCMS is the quiet overachiever we keep shipping: clean structured content, GraphQL API, real-time preview, and localization that is a first-class dimension rather than an afterthought. Pick it for content-heavy marketing sites with multiple locales where you want strong defaults instead of a platform to configure. Skip it when you need the ecosystem breadth or procurement footprint of the bigger vendors. Bennetts runs three consolidated sites on it behind a Next.js front end, migrated off Sitecore without losing rankings.

A note on headless WordPress: keeping WordPress as the editorial backend behind a Next.js front end is a legitimate pattern when the editorial team’s tooling and habits are the thing worth preserving. Backlinko, a business built entirely on organic search, runs exactly this stack. Our headless WordPress evaluation covers when it makes sense.

When MDX beats every CMS on this page

Next.js has excellent support for MDX, and for developer-authored content it is the better tool: documentation, changelogs, engineering blogs, and marketing sites maintained by the people who commit code. Content lives in the repo, changes ship through pull requests, and there is no platform bill, no webhook wiring, and no preview infrastructure, because preview is a branch deploy.

The rule of thumb from our React CMS guide applies unchanged: count the non-developers who need to publish in the next year. Zero or one, start with MDX. The moment marketing needs to ship a landing page without an engineer, revisit this page.

The decision at estate scale

When the project is not one site but a multi-brand, multi-market estate, three Next.js-specific concerns join the usual governance and localization questions (covered once, in the React guide):

• Publish-to-live latency across markets. Tag-based revalidation across thousands of pages and a dozen locales needs deliberate cache design. Demand a demonstration at realistic content volume, not on a starter template.
• Preview security. Draft Mode endpoints and preview URLs multiply across environments and brands; they need to be secret-gated and kept out of search indexes. The silent failure modes are documented in our headless CMS SEO guide.
• Who owns the wiring. Webhooks, revalidation handlers, and preview routes are application code. After launch, someone maintains them through Next.js major versions. That someone should be named before the platform is chosen.

If you have not committed to Next.js yet

One honest caveat before the FAQ. Next.js is the right call for application-like sites: authenticated experiences, heavy interactivity, big teams that benefit from its conventions and hiring pool. For content-heavy marketing sites, we increasingly reach for Astro, which ships close to zero JavaScript by default and has a different, often simpler answer to the content question. The comparison is at Astro vs Next.js, and the CMS decision on that side is covered in best CMS for Astro.

Common questions

What is the best CMS for Next.js?

Depends on who publishes. Payload for TypeScript teams that want the CMS inside the Next.js repo; Sanity for complex structured content; Storyblok for marketer-led visual editing; Contentful for governance-heavy organizations; DatoCMS for multi-locale marketing sites with strong defaults. For developer-authored content, MDX in the repo beats all of them.

Does Next.js have a built-in CMS?

No. Next.js is a framework and ships no content management. The closest thing to “built in” is Payload, which installs into a Next.js application and serves its admin panel from your own routes, or MDX files committed to the repository.

Is Payload better than Sanity or Contentful for Next.js?

It is different, not better. Payload wins on ownership: one repo, one database, TypeScript config, no seat pricing. Sanity and Contentful win on managed operations, editor tooling, and having a vendor accountable for uptime. A developer-led product team and a 40-person marketing organization should choose differently.

How does CMS content stay fresh on a static Next.js site?

Through revalidation. The standard pattern is a publish webhook from the CMS hitting a route handler that calls revalidateTag or revalidatePath, regenerating affected pages on demand. Time-based revalidation is the fallback. If a CMS integration cannot demonstrate fast publish-to-live updates, the wiring is missing, whatever the platform.

Can I use WordPress as a CMS for Next.js?

Yes, headless WordPress over WPGraphQL or the REST API is a proven pattern for keeping familiar editorial tooling behind a modern front end. The cost is operating WordPress infrastructure alongside Next.js and carrying SEO metadata across the API boundary deliberately.