Best CMS for a Next.js blog — how the options compare

There is no CMS called "Next.js CMS", which is why the search is really a comparison. Next.js is a rendering framework with no opinion about where content lives, so a blog built on it needs a second system — and the choice between the candidates is mostly a choice about who writes the posts and how often, not about API design.

What a Next.js blog actually needs from a CMS

Strip away the demo videos and the requirements list is short:

1. A list endpoint with pagination and taxonomy — posts newest-first, filterable by category or tag, with cursors or offsets that survive a redeploy.
2. A single-post endpoint with everything a page needs in one call — body, title, excerpt, meta title and description, canonical, Open Graph fields, categories, tags, dates.
3. Body content you can render safely — either sanitized HTML you inject, or structured blocks you map to components. Raw, unsanitized HTML from a rich-text editor is a cross-site-scripting bug waiting to ship.
4. Images with dimensions — next/image needs width and height to avoid layout shift, so a CMS that returns bare URLs pushes that work onto you.
5. A change signal — an updatedAt field or a webhook, so you can revalidate one page instead of rebuilding the site.
6. Structured data — FAQPage, HowTo, Article JSON-LD, or the fields to build it.

Anything beyond that — preview, scheduling, roles, localisation — matters in proportion to how many people edit.

The options, compared

Option	Where it runs	Who edits	API shape	Who writes the posts	SEO fields
Markdown / MDX in the repo	Your git repository	Developers, in an editor	None — files at build time	You	Frontmatter you define
Headless WordPress	Your hosting, on a subdomain	Anyone, in wp-admin	REST (/wp-json/wp/v2) or GraphQL via a plugin	You	Via an SEO plugin exposed through the API
Payload	Inside your Next.js app, or its cloud	Editors, in an admin built from your config	REST + GraphQL, TypeScript types	You	Fields you model
Hosted headless CMS (Sanity, Contentful and similar)	Vendor cloud	Editors, per-seat	REST / GraphQL / query language	You	Fields you model
Structura	Vendor cloud	Reviewers, in a portal	Three public read endpoints, JSON	Structura, on a schedule	Meta, OG, keyphrase and JSON-LD in the response

A few things the table flattens.

MDX in the repo is the right answer for a developer's own blog and the wrong one the moment a non-developer needs to publish. It is free, versioned, and reviewable in a pull request; it also means every post is a commit.

Headless WordPress brings the most mature editor and the largest plugin ecosystem, at the price of running a second application whose theme layer you no longer use. The REST API has been in core since 2016 and covers a blog completely; the work is on the front end — metadata, links that point at the CMS host, preview. The headless WordPress entry covers the trade-offs.

Payload is the option Google's results favour for this query, and for a reason: it is open source, TypeScript-first, and installs into a Next.js application rather than beside it, so the admin UI, the API and the front end deploy together. The editor is generated from a schema you write in code. That is a strength for a developer-led team and a hurdle for a marketing-led one.

Hosted headless CMSs trade control for operations: nothing to host, structured content modelling, collaboration features, and a bill that scales with seats and API calls. They are built for organisations with many editors and many surfaces; a single blog uses a fraction of what you pay for.

Structura is a different category answering the same requirements list. It is a content backend with a read API — sanitized HTML or blocks, SEO fields, images with dimensions, JSON-LD out of band, updatedAt on every post — but the posts inside it are researched, written and published on a schedule by the service, and a person reviews rather than writes. It is not the tool for a team that already writes well and often; it is the tool for the far more common team that set up a CMS and then never filled it.

How to choose

Decide who writes before deciding what stores.

• Developers write, in Markdown, occasionally → MDX in the repo.
• A marketing team writes, and wants a familiar editor → headless WordPress, or a hosted CMS if you would rather not host PHP.
• Developers own the whole stack and want the admin in TypeScript → Payload.
• Nobody has the hours to write three posts a week → Structura, alone or feeding the same front end alongside any of the above.

The rendering strategy matters more than the CMS. Whatever you pick, generate HTML at build time or with incremental static regeneration, revalidate on the CMS's change signal rather than on a timer alone, and keep client-side rendering for the interactive parts. A blog that renders only in the browser indexes late regardless of how good its CMS is.

How Structura handles this

Structura serves a Next.js blog as a headless space: you create it in the customer portal, run campaigns, review the posts, and your front end fetches them from a public read API. There is no authentication because the API only ever returns published posts; there is nothing to host because Structura is the backend.

The single-post response carries what the requirements list above asks for — html with a strict tag allowlist you can inject directly, a blocks array if you prefer components, metaTitle, metaDescription, keyphrase, Open Graph fields, categories and tags, featured and body images with width, height and alt, an array of schema.org JSON-LD objects delivered separately so the sanitizer cannot strip them, and publishedAt / updatedAt. Lists paginate by cursor in both directions and are CDN-cached, so an ISR setup keys revalidation off updatedAt and leaves the rest alone.

If you already run headless WordPress, Structura works there too: the plugin publishes native posts into the WordPress you have, with links pointed at your public domain. The API-first CMS page has the contract and a Next.js example.

FAQ