CMS for React: Three Questions Before You Pick a Platform

A CMS for React has one job: let someone publish without opening a pull request. Pricing tier, editor polish, and plugin count are details you sort out later. Three harder questions come first. Does the app need a CMS at all? Self-hosted or managed? And how does new content actually reach a rendered page?

Most roundups skip straight to naming platforms. Storyblok, Sanity, Contentful, Payload, Strapi. React 19 hit 48.4% daily use within months of release, per the 2025 State of React survey. The CMS market serving that base keeps splitting into more options every year. More names on a list make “which one” louder as a question, not easier to answer.

Question One: Do You Even Need a CMS?

If the person editing content is a developer, you don’t. A Markdown file in the repo, reviewed through a pull request, ships faster and skips the API round trip entirely.

Reach for a CMS once a non-developer needs to publish without you. Or once content changes faster than your deploy cycle can keep up. A marketing team running weekly campaigns. A support team updating FAQ copy every day. That’s the real trigger, and it has nothing to do with tech stack. It’s about who’s allowed to hit publish.

Question Two: Self-Hosted or Managed?

This gets sold as a technical decision. It’s really a cost decision wearing a technical costume, and most comparison posts skip the math.

On raw dollars, self-hosted wins big. A self-hosted open-source CMS can run 600to600to15,000 over five years on a modest VPS. A managed plan can climb into six figures over that same stretch for a busy site.

The dollar figure isn’t the whole cost. Someone still has to run the thing. Even with solid automation, a self-hosted CMS eats roughly one to two hours a month in ops time: patches, backups, uptime checks. That’s a small tax for a team that already has spare engineering hours. It’s a real cost for a two-person team shipping features full time.

A working rule: count your editors and your spare engineering hours, not just the number on a pricing page. Small teams with no ops slack usually come out ahead on managed. Agencies running several client sites, or teams with room in the sprint, tend to earn that cost back within 12 to 18 months of self-hosting.

Question Three: How Does Content Reach the Page?

This is the part that’s actually specific to React, and the part generic CMS roundups skip.

A headless CMS is API-first. Content comes back as JSON or over GraphQL, decoupled from any one front end. That’s what makes it work equally well for a React site, a mobile app, or anything else reading from the same source. An old-style CMS welds its front end to its content store. Wiring that into a React app usually means fighting the platform rather than using it.

Once a CMS is API-first, a React or Next.js app has three real ways to pull from it:

• Fetch at build time. Static generation reads content once, at build. Fast and cheap, stale until the next deploy. Fine for content that barely moves.
• Fetch on every request. Server components hit the CMS on each page load. Always current, but every visitor pays the CMS’s response time.
• Cache the response, clear it on demand. Pages serve from cache like static output. A webhook tells the app to drop specific entries the moment content actually changes.

The third option is the one worth the setup time, and almost nobody writes about it. Most teams either over-fetch on every request or under-fetch and serve stale pages for hours. A webhook closes that gap for free.

Wiring Up Webhook-Driven Cache Clearing

Next.js’s revalidateTag clears cache by tag instead of by page. Tag a fetch once, then clear that exact tag when the CMS tells you something changed:

// app/posts/[slug]/page.tsx

async function loadPost(slug: string) {

const response = await fetch(`https://cms.example.com/api/posts/${slug}`, {

next: { tags: [`post:${slug}`] },

});

return response.json();

}

// app/api/cms-webhook/route.ts

import { revalidateTag } from “next/cache”;

export async function POST(request: Request) {

const token = request.headers.get(“x-cms-signature”);

if (token !== process.env.CMS_WEBHOOK_SECRET) {

return new Response(“Unauthorized”, { status: 401 });

}

const { slug } = await request.json();

revalidateTag(`post:${slug}`);

return Response.json({ ok: true });

}

The CMS calls this endpoint on publish, and only the matching tag clears. A site with thousands of pages doesn’t rebuild the whole thing because one entry changed. Draftbase’s own webhooks run this exact pattern. A publish event pushes to your app, so nothing has to poll for changes. Check the signature header before touching the payload. An open revalidation endpoint is a free invitation to hammer your cache.

Does the CMS Choice Change React SEO?

Only through rendering, not through the CMS itself. A React app that renders content purely client-side ships an empty shell to a crawler until the JavaScript finishes running. Google’s own guidance on JavaScript SEO describes a second rendering wave for JS-heavy pages, well behind text-first pages in the queue. Server components and static generation skip that wave entirely, since the HTML a crawler sees already has the content baked in.

What the CMS needs to get right is narrow. Clean, structured fields for title, description, and Open Graph image that map onto Next.js’s Metadata API. And a way to list published slugs for a sitemap. A CMS that lets raw HTML leak into a title field makes both jobs harder. So does hiding the slug behind a picker with no API access.

When an Old-Style CMS Still Wins

A fair comparison has to say this part too. A team with no front-end developer, and no plan to build a custom app, ships faster with a single bundled CMS and a theme than with any headless setup. If the actual requirement is “we need a whole website with an editor attached,” going headless solves a problem that team doesn’t have yet. The moment a real React front end enters the picture, that trade reverses.

The Schema Outlasts the Platform Pick

Whatever CMS wins, the content schema is the part that survives the tooling decision. A content type built around one loose rich-text blob turns every layout change into a migration project. Fields modeled as typed, reusable pieces survive a redesign, because only the component rendering the data has to change, not the data itself. Spend the modeling time up front. It costs less than fixing content after the fact.

Common Questions

Does a headless CMS work cleanly with the Next.js App Router?
Yes, with one adjustment. Fetches inside Server Components run without client-side context, so pass any CMS config or client instance as props rather than through a provider.

Is a headless CMS overkill for a small React app?
For a five-page site updated twice a year, yes. A Markdown file per page is simpler to maintain. The CMS earns its keep once publishing frequency or editor headcount climbs.

Can you swap CMS platforms later without a full rewrite?
Only if the fetch logic lives behind your own data functions, not scattered across components. Worth doing regardless of which CMS gets picked first.

Does going headless hurt React SEO?
No, as long as pages render server-side or statically. The SEO risk comes from client-only rendering, not from where the content is stored.

Making the Call

Skip the platform-name debate until the three real questions are answered. Does a non-developer need to publish? Does the team have spare hours to run its own CMS? Will the fetch pattern keep pages both fast and current? Get those right first. The specific platform, a hosted React CMS framework or otherwise, ends up a much smaller decision than the marketing pages make it look.