Most headless CMS evaluations start with the wrong question. Teams open a comparison spreadsheet, score editing experience against API ergonomics and pricing tiers, pick a winner, and then architect the frontend around what they chose. This sequence routinely produces a CMS that publishes cleanly and feeds a rendering pipeline that takes 45 minutes to rebuild. The CMS wasn't the problem. The order of decisions was.
In 2026, the question that should lead an evaluation isn't "which CMS has the best editing experience." It's "how does content from this CMS reach my users, and how fast does a publish event propagate." Everything downstream of that question, including editorial UX, schema tooling, and pricing, is a second-order concern. Get the rendering architecture right first and half the shortlist eliminates itself before a single feature matrix gets opened.
The four filters in this piece run in sequence for a reason. Rendering strategy sets the requirements. Webhook behavior is the first pass/fail gate. Preview workflow determines editorial adoption. Schema governance and total cost determine long-term viability. Work through them in order and the decision becomes close to mechanical.
Copy link to headingKey takeaways
Most CMS evaluation failures are sequencing failures: teams pick a platform before defining the rendering architecture it has to feed, then discover the constraint after they've committed.
Webhook-driven on-demand ISR revalidation purges every edge region in approximately 300 milliseconds; any CMS that cannot drive revalidateTag reliably should not make the shortlist.
Full-rebuild SSG optimizes for a constraint that on-demand ISR already eliminated; a 45-minute build ceiling is an architecture problem, not a CMS problem.
Draft Mode is how Next.js handles editorial preview of unpublished content; the maturity of a CMS's Draft Mode integration varies enough that it must be tested in a prototype, not assumed from documentation.
Personalization that used to require SSR everywhere can run at the edge via Routing Middleware and Edge Config, which reduces what the CMS itself needs to do.
Copy link to headingChoose your rendering strategy before you evaluate any CMS
The rendering decision is the one that actually determines the requirements. Teams that treat it as an implementation detail to sort out after the CMS contract is signed run into a specific kind of painful surprise: a platform that looks excellent in a vendor demo but can't drive the revalidation pattern the frontend needs. The inverse assumption causes most of the friction that shows up in production.
The frontend needs a strategy for turning API content into HTML. Static site generation builds pages at compile time for CDN delivery. Server-side rendering generates HTML per request for content that must be fresh on every load. Incremental Static Regeneration serves pages from cache and regenerates them in the background after a publish event. Each strategy puts different demands on the CMS, and the mismatch between what got chosen and what the CMS can deliver is exactly what surfaces in production, never in the demo.
Copy link to headingWhat each rendering mode demands from a CMS
The demands aren't symmetric. Here's what each mode requires from the content layer:
SSG with on-demand revalidation: The CMS must fire webhooks on publish and provide draft preview access to unpublished content.
SSR: CMS reads need predictably low latency under real traffic, not just under a sales demo. Any latency variance shows up directly in response times.
ISR with tag-based revalidation: The CMS content model must map cleanly to cacheable tags by content type and entry ID, with slug available where routes depend on it.
That last requirement deserves more attention than it usually gets. Tag-based revalidation means a single editor's typo fix should invalidate one cache tag, not purge the entire site. If the CMS content model can't produce a clean tag per entry, the result is either over-invalidating on every publish or writing custom logic to compensate. The CMS model and the cache tag strategy have to be designed together, which is another reason the rendering decision comes first.
Copy link to headingWhy the sequence matters
The classic failure here isn't picking the wrong CMS. It's picking a CMS before the rendering architecture exists to evaluate it against. A team that chooses first and architects second can end up with a platform that publishes cleanly but feeds a pipeline with a long rebuild ceiling, not because the CMS is broken, but because nobody had decided they needed on-demand revalidation before the contract was signed.
Deciding how content becomes HTML before opening any vendor comparison makes the shortlist faster and eliminates the integration surprises that are hardest to recover from after launch. The architecture determines the requirements. That sequence is the right one.
Copy link to headingMake webhook-driven revalidation your first pass/fail filter
Treat webhook support for on-demand revalidation as a binary gate, not a weighted criterion. A CMS that scores well on editing experience, schema flexibility, and pricing, but can't reliably drive revalidateTag is the wrong CMS for a Next.js ISR deployment. Teams sometimes try to rationalize past this by planning to work around it with polling or timed revalidation intervals. That workaround doesn't hold, it trades a clean publish-to-edge path for a system that's eventually consistent by design, and eventually consistent content is a support ticket waiting to be filed.
Copy link to headingHow on-demand revalidation works
When an editor publishes, the CMS sends an HTTP POST to an endpoint on the frontend. That endpoint calls revalidateTag or revalidatePath, which marks the path or cache tag stale globally across every region on the Global Network in approximately 300 milliseconds. The frontend never polls the CMS, and high-traffic pages stop triggering API calls back to the CMS origin on every request. The publish event drives the cache state; the cache serves everything else.
Tag-based revalidation is the approach that scales. Instead of invalidating entire paths on every publish, cached content gets tagged by content type and entry ID, then specific tags get invalidated when the underlying entry changes. One editor's draft fix touches one tag. A content type migration touches that type's tags. Nothing else moves, and that granularity is only available if the CMS content model maps cleanly to those tags from the start.
GitBook runs 30,000 documentation sites on Vercel, serving 120 million page views a month, and processes 40,000 cache invalidations daily, with each resolving in under 300 milliseconds. That's the webhook-to-edge path working as designed across a real multi-tenant fleet. The number that matters isn't the 30,000 sites. It's the 300 milliseconds per invalidation across all of them.
Copy link to headingWhat to test before you commit
Documentation and production behavior diverge more often than vendors admit. Before any CMS makes the final shortlist, these are worth testing directly:
Webhook payload shape: Does it include the content type, entry ID, and slug the revalidation endpoint needs to construct the right cache tag?
Retry behavior: What happens when the endpoint is temporarily unavailable? Does the CMS retry, and on what schedule?
Required event types: Does the CMS fire on publish, unpublish, delete, and content type schema changes, or only on publish?
SDK CDN caching: If the CMS SDK has CDN caching enabled by default, a revalidation call won't be able to pull fresh data to update the ISR cache. Setting useCdn: false may be necessary. This is worth verifying before launch, not after the first stale-content incident.
Sanity's GROQ-powered webhooks provide fine-grained control over payload shape and filtering. Whatever's on the shortlist should be tested against the events the revalidation endpoint actually expects, not against a generic webhook demo.
Copy link to headingStop treating full-rebuild SSG as a viable 2026 strategy
Full-rebuild static generation is architectural debt, not a conservative choice. It's often framed as "keeping things simple," but the simplicity disappears the moment the content catalog grows past a few hundred pages, and by then the pipeline is load-bearing and expensive to replace.
The constraint is structural. SSG requires rebuilding the entire application before any page's content can change, so as the catalog grows, build times compound. Choosing a CMS based on how well it handles batch rebuilds means optimizing for a constraint that on-demand ISR already eliminated. That evaluation criterion was real in 2021. It isn't now.
Copy link to headingWhere full-rebuild breaks in production
Mecum Auctions manages 275,000 pages and 8 million assets using ISR with WordPress as the headless CMS. Their marketing teams launch content and campaigns without leaving the CMS environment. At 275,000 pages, a full-rebuild pipeline isn't slow, it's unworkable. The only reason it's routine for Mecum is that on-demand ISR decoupled publish frequency from deploy frequency entirely.
Rippling runs 600+ pages on Next.js and Vercel with WordPress as a headless CMS, and more than 90% of site changes ship without engineering involvement. That's not a process achievement. It's an architectural achievement: the webhook-plus-ISR path means a content change doesn't require a human to initiate a build.
Copy link to headingWhat ISR changes about your evaluation criteria
A CMS scoring model that still has a "build performance" criterion weighted meaningfully is answering the wrong question. The right question is whether the CMS can fire a webhook that drives revalidateTag on publish. Build performance at the CMS level is a 2021 concern. Webhook reliability at the edge is the 2026 one.
Any evaluation framework, analyst report, or vendor comparison that frames build-time coupling as an inherent tradeoff of headless architecture is describing a constraint that no longer needs to exist. That framing is a signal the guidance is out of date.
Copy link to headingTest the editorial preview path before you score anything else
A CMS earns or loses editorial adoption through preview, not through the editing interface, not through the publishing workflow, through preview. The moment a content editor can't see what their change looks like before it goes live, the relationship becomes a support relationship, not a content platform.
Editorial teams that move to headless sometimes find that visual editing disappeared entirely, and adjusting a layout or moving a component started requiring a developer ticket. It's a direct consequence of evaluating CMS features without testing the preview path end to end, and it's one of the most common reasons headless migrations lose editorial buy-in after launch.
Copy link to headingHow Draft Mode works
Draft Mode is how Next.js solves preview for headless CMS content. It lets editors view unpublished content rendered with all the normal styling and layout they'd see post-publish. It works by bypassing the ISR cache entirely: a draft request bypasses Incremental Static Regeneration and is not cached, so the content an editor writes is immediately available on the rendered site and shareable via link.
Two implementation details matter. Draft Mode requires ISR to be enabled on the pages where it's used. It also supersedes the legacy Pages Router Preview Mode API. CMS integration guides that still present res.setPreviewData() as the recommended preview workflow are describing the old API, if a CMS's documentation references that method as current, the integration guide hasn't been maintained, and that's worth knowing before committing.
Copy link to headingWhere preview implementations diverge
The gap between "this CMS supports Draft Mode" and "this CMS makes Draft Mode usable for a non-technical editor" is wider than most evaluations account for. Test the full path in a prototype, not in a vendor demo.
Sanity lists Live Preview and Visual Editing among its platform capabilities.
Storyblok documents Draft Mode integration and handles the lang route parameter for i18n deployments.
Contentful's Content Preview API supports preview workflows, though the integration effort differs enough from the others that it warrants direct comparison in a prototype.
On the Vercel side, Visual Editing and Content Link close the gap between preview and editorial autonomy. Changes made through Visual Editing appear the next time the page is viewed in Draft Mode. Content Link, available on Pro and Enterprise plans, connects preview deployments back to CMS fields so editors can jump from a rendered page directly into the relevant entry. The full Vercel Toolbar integration is worth evaluating before assuming a CMS-native editor is the only path to editorial autonomy. In several cases it isn't.
Copy link to headingWeigh schema governance and total cost of ownership together
Schema decisions and cost decisions look separable until they aren't. Both get underweighted during evaluation because neither shows up clearly in a feature matrix. Schema governance is a workflow question that only becomes painful after the first unreviewed field change breaks a build. Total cost only becomes painful after the first quarterly infrastructure invoice.
Copy link to headingSchema-as-code vs. UI modeling
For TypeScript teams with CI/CD discipline, schema-as-code is a structural constraint, not a preference. Sanity defines schema in TypeScript with version control, so schema changes go through the same pull request review process as frontend changes. A field addition is a diff. A field removal is a diff. A breaking change gets caught in review before it reaches production.
Contentful uses a visual modeler. That works well for teams that don't gate schema changes through code review. But for teams that treat unreviewed schema changes as a production risk, a UI-modeled CMS sits outside the review process by design, and the first time someone adds a field through the UI that breaks a TypeScript type in the frontend without a PR catching it, the mismatch becomes very concrete, very fast. Knowing which side of that line a team is on matters before the shortlist gets to demo calls.
Copy link to headingSelf-hosted vs. managed cost models
The open-source core of Strapi can be self-hosted, and the zero subscription cost looks attractive on a spreadsheet. The real cost doesn't live in the subscription line. It lives in infrastructure provisioning, DevOps overhead, security patching cadence, and the senior engineering hours required to keep a self-hosted CMS reliable under production load, costs that don't appear in the initial comparison and reliably surface in the first six months of operation.
The Hydrow migration makes the managed-CMS case concretely. Moving to managed Contentful with Next.js and Vercel cut authoring time from weeks to minutes and made website updates 3,000% faster. When the full cost gets modeled, including engineering hours, the subscription line of a managed CMS often looks very different than it does in isolation.
Copy link to headingCMS decision matrix
The table below maps the four filters from this piece against the platforms most commonly on headless shortlists in 2026. Use it as a starting point, not a verdict. Implementation quality and a team's specific content model matter more than any single cell.
Copy link to headingLet the edge handle personalization so the CMS doesn't have to
Showing different content to different users used to be assumed to force SSR everywhere and surrender the performance of static delivery. That assumption was correct for long enough that it's now baked into a lot of evaluation frameworks. It's no longer accurate.
The platform layer can carry personalization logic that used to live in the rendering layer. The CMS's job in that architecture is clean, cacheable content and reliable webhooks. Session logic, experiment variants, and geographic targeting sit between the edge cache and the user, outside the content store, and what's needed from the CMS changes materially once the edge is doing that work.
Copy link to headingPartial Prerendering and the static/dynamic split
Partial Prerendering changes what "static" means for a personalized page. At build time, Next.js generates a static HTML shell. At request time, the shell is served immediately from the CDN while request-time portions render and stream into Suspense boundaries. A CMS-driven page can serve its layout and navigation from edge cache instantly while streaming fresh or personalized content in without blocking the initial response.
The all-or-nothing choice between static speed and request-time freshness goes away. The static parts are static. The dynamic parts are dynamic. The CMS feeds both through the same content API, and the rendering layer decides what gets cached and what gets computed per request. This is what makes ISR and personalization compatible, and it reduces the surface area of what the CMS is being asked to do.
Copy link to headingRouting Middleware, Edge Config, and geographic personalization
Routing Middleware runs before the cache with no cold starts, so a team can show the control or experiment variant of a page immediately without third-party scripts that introduce the layout shift and CLS degradation that hurt both conversion and Core Web Vitals. Experiment variants generated at the edge avoid the client-side insertion problem entirely.
Edge Config backs feature flags and A/B logic at ultra-low latency, with most lookups returning in 5 milliseconds or less. Routing Middleware also exposes the visitor's country, region, and city from the IP, so geographic personalization needs no separate geolocation service.
Helly Hansen migrated off a client-rendered PWA to Next.js and Vercel. LCP improved 30% at launch, a Cumulative Layout Shift that had spiked above 2.8 was virtually eliminated, and the site delivered 80% Black Friday year-over-year growth. The CLS result is diagnostic: the layout shift was coming from client-side personalization insertion, and moving that logic to the edge removed the source rather than patching around it.
When a CMS evaluation accounts for the edge architecture it's feeding, the personalization requirement stops being a reason to choose a more capable CMS and starts being a reason to choose a simpler one. Clean content, reliable webhooks, solid preview. The edge handles the rest.
Copy link to headingThe evaluation is a sequencing problem, not a feature-matching problem
Step back from the four filters and a single structural observation emerges: costly CMS migrations tend to share a correct feature match and a wrong sequence. The platform supported webhooks. The platform had a preview API. The platform had competitive pricing. The evaluation happened in the wrong order, the architectural constraint got discovered late, and the cost of undoing a decision that had already shaped the frontend got absorbed after the fact.
The sequence is the framework. Rendering strategy first, because it determines what's needed. Webhook revalidation is second, because it's a binary gate that eliminates platforms that can't support the architecture. Preview path third, because editorial adoption is a launch risk, not a post-launch optimization. Schema governance and total cost fourth, because those determine whether the choice compounds positively over two years or turns into a migration project.
Get that order right and the shortlist shrinks fast. By the time pricing enters the room, the field is usually down to one or two platforms that satisfy the first three filters, and the decision reduces to which schema model fits the team's workflow and which cost structure fits the growth trajectory. That's a tractable decision. Weighing twelve platforms across forty criteria simultaneously is not, and it's the version that produces the wrong answer most often.
The CMS matters. The order in which it gets evaluated matters more.
Copy link to headingFAQs
Copy link to headingWhich headless CMS works best with Next.js and Vercel?
There is no single answer, but the filter that narrows the field fastest is webhook reliability for on-demand ISR revalidation. Sanity, Contentful, Storyblok, and WordPress (headless) all have documented integrations with Next.js and Vercel. Where they diverge is in webhook payload control, Draft Mode integration maturity, and schema governance model. Running the four filters in this piece in sequence makes the right platform for a given team's rendering strategy, editorial workflow, and schema discipline clear.
Copy link to headingCan WordPress work as a headless CMS for ISR-based sites?
Yes, and at scale. Mecum Auctions runs 275,000 pages and 8 million assets on ISR with WordPress as the headless CMS. Rippling runs 600+ pages with the same stack, with more than 90% of site changes shipping without engineering involvement. WordPress headless requires deliberate configuration of webhooks and REST or GraphQL endpoints, but the architecture is proven in production at significant page counts. The CMS platform matters less than the rendering architecture it feeds.
Copy link to headingIs Sanity or Contentful better for teams that version-control their schema?
Sanity is the stronger fit for teams that gate schema changes through code review. Sanity defines schema in TypeScript, which means schema changes are diffs in version control, reviewable in pull requests alongside frontend changes. Contentful uses a visual modeler, which places schema changes outside the code review process by design. For teams where an unreviewed field removal is a production risk, that difference is load-bearing. For teams where editorial velocity matters more than schema review discipline, Contentful's visual modeler is a genuine advantage.
Copy link to headingWhat is on-demand ISR revalidation and why does it matter for CMS selection?
On-demand ISR revalidation lets the cache for a static route be purged at any time, triggered by a webhook from the CMS rather than a time interval. When an editor publishes, the CMS fires an HTTP POST to a revalidation endpoint on the frontend, which calls revalidateTag or revalidatePath. That call marks the relevant cache tags stale across all regions of the Global Network in approximately 300 milliseconds. Pages stay static and CDN-served between publishes, and publish events update only what changed. Without it, cache state and content state drift apart, and the only way to reconcile them is a full rebuild or a time-based interval that guarantees staleness.