Ik ship Next.js-sites sinds de Pages Router-dagen, en ik heb het aantal keren verloren dat ik een "beste CMS"-artikel heb gezien geschreven door iemand die het ding duidelijk één keer heeft geïnstalleerd, de quickstart-tutorial is gevolgd, en het een review noemde. Dit is niet dat.

Bij Social Animal runnen we productiesites op meerdere CMS-architecturen -- van Payload CMS die een healthcare-app aanstuurt tot Supabase die 253.000+ pagina's aanstuurt over drie verschillende platforms. We hebben Strapi 5, Sanity en Contentful geëvalueerd voor echte clientprojecten. En deze site die je nu leest? Deze is gebouwd op MDX-bestanden die gecommit zijn naar een Git-repo.

Dus wanneer ik zeg "we hebben 6 in productie getest," bedoel ik dat we te maken hebben gehad met de migratieellende, de build-time-verrassingen, de Slack-berichten om 3 uur 's nachts over content die niet wordt gepubliceerd. Hier is alles wat we hebben geleerd over het kiezen van de juiste CMS voor Next.js App Router in 2026.

Inhoudsopgave

Best CMS voor Next.js App Router 2026: We hebben 6 in productie getest

Waarom de App Router de CMS-vergelijking verandert

Als je nog steeds na denkt over CMS-selectie op de manier waarop je dat deed met de Pages Router, laat je prestaties op tafel liggen. De App Router heeft fundamenteel veranderd hoe gegevens door een Next.js-applicatie stromen, en dat heeft directe implicaties voor welke CMS het beste past.

Dit is wat er nu toe doet:

Server Components zijn de standaard. Het ophalen van je CMS-gegevens gebeurt op de server zonder JavaScript naar de client te sturen. Dit betekent dat CMS'en met native Node.js SDK's of -- nog beter -- lokale API's die het netwerk volledig omzeilen, een enorm voordeel hebben.

React Server Components + fetch caching. De ingebouwde fetch-deduplicatie en caching van de App Router betekent dat je CMS-integratiepatronen volledig anders eruit zien. Je grijpt niet meer naar getStaticProps of getServerSideProps. Je schrijft async-componenten die rechtstreeks je CMS aanroepen.

Parallel Routes en Intercepting Routes. Deze patronen ontgrendelen CMS-aangestuurde layouts die vroeger pijnlijk waren om in te bouwen. Een CMS die flexibele content-modellering ondersteunt (niet alleen blogposts en pagina's) blinkt hier uit.

Partial Prerendering (PPR). Vanaf Next.js 15 kunt je met PPR een statische shell met dynamische gaten serveren. Dit verandert het ISR vs. SSR-debat volledig, en het betekent dat je CMS-revalidatiestrategie nu meer dan ooit van belang is.

Met al die context, laten we in de daadwerkelijke tests duiken.

De 6 CMS'en die we hebben getest (en hoe we ze hebben getest)

Onze evaluatie was niet theoretisch. Voor elk CMS hebben we ofwel productie-pagina's gepubliceerd ofwel een diepgaande technische evaluatie uitgevoerd voor een echte clientproject. We hebben gemeten:

  • Ontwikkelaarbelevenis specifiek met de App Router
  • Build-tijden bij verschillende paginatellerstanden
  • Content editor UX voor niet-developer teamleden
  • Prijzen op schaal (niet alleen de gratis tier)
  • TypeScript-integratie kwaliteit
  • Revalidatiepatronen (ISR, on-demand, webhooks)

Laten we ze allemaal doorlopen.

1. Payload CMS 3 -- Best Overall voor Next.js

Ons oordeel: beste ontwikkelaarbelevenis voor Next.js App Router, punt uit.

Payload CMS 3 is degene die me deed heroverdenken wat een CMS zou kunnen zijn. Het is geen aparte service die je via HTTP aanroept. Het leeft binnen je Next.js-applicatie. Dezelfde repo, dezelfde deployment, dezelfde TypeScript-typen.

We runnen Payload 3 in productie op SleepDr, een healthcare-platform met 228 pagina's, meerniveautoegangscontrole, en content die nauwkeurig moet zijn (het is gezondheidsgerelateerd, dus onjuiste content is niet alleen slecht voor je imago -- het is aansprakelijk).

Wat maakt Payload speciaal voor App Router

De Local API is de killer-functie. In plaats van HTTP-verzoeken naar je CMS te doen, importeer je een functie en roep je deze rechtstreeks aan:

// app/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      slug: { equals: params.slug },
      status: { equals: 'published' },
    },
  })
  
  const post = posts.docs[0]
  if (!post) notFound()
  
  return <Article post={post} />
}

Geen netwerksprong. Geen REST of GraphQL-overhead. Geen SDK om te installeren. De functieaanroep is volledig getypeerd omdat Payload TypeScript-interfaces uit je collection-configs genereert. Wanneer je een veldnaam refactort, vangt je IDE elk verbroken verwijzing onmiddellijk op.

Live Preview met App Router

Payload 3's live preview werkt met Server Components. Je content editors zien wijzigingen in real-time op de daadwerkelijke site-layout -- niet enige benadering in het admin panel. We hebben dit voor SleepDr geconfigureerd en het redactionele team ging van "ik heb een ontwikkelaar nodig om dit te controleren" naar zelfstandig publiceren binnen een week.

Toegangscontrole die echt werkt

De toegangscontrole op veld- en collection-niveau van Payload is in code gedefinieerd:

const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor' || user?.role === 'admin',
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    // ...
  ],
}

Voor een healthcare-app is deze granulariteit niet optioneel. Het is een vereiste.

De afwegingen

Payload draait op je infrastructuur. Als je een volledig beheerde SaaS-ervaring wilt, bestaat Payload Cloud (beginnend rond $35/maand voor productie), maar je bent nog steeds verantwoordelijk voor het begrijpen van de implementatie. Het is ook een Node.js runtime-afhankelijkheid, wat betekent dat je hosting dit moet ondersteunen (Vercel werkt, maar kosten stijgen met blijvende verbindingen met je database).

Voor ons Next.js-ontwikkelingswerk is Payload 3 nu onze standaardaanbeveling voor content-zware sites onder 5.000 pagina's.

Best CMS voor Next.js App Router 2026: We hebben 6 in productie getest - architectuur

2. Supabase-als-CMS -- Best voor schaal (10K+ pagina's)

Ons oordeel: technisch gezien geen CMS, maar niets anders komt dicht in de buurt voor massieve gestructureerde datasets.

Dit is de onconventionele keuze, en het is degene waarover ik het meest enthousiast ben. Supabase wordt niet als CMS vermarkt. Het is een PostgreSQL-platform met auth, opslag en Edge Functions. Maar wanneer je "content" eigenlijk gestructureerde gegevens is -- celebrity-profielen, bedrijfslijsten, productdatabases -- vallen traditionele CMS'en op schaal uit elkaar, en Supabase raakt niet eens buiten adem.

We runnen drie productiesites op Supabase-als-CMS:

  • DA -- 91.000+ pagina's met celebrity-gegevens over 30 talen
  • NAS -- 137.000+ bedrijfslijsten
  • HostList -- 25.000+ hostingprovider-lijsten

Dat zijn 253.000+ pagina's. Laat me je vertellen wat er gebeurt wanneer je 91.000 entries in een traditionele headless CMS probeert te zetten: het admin panel wordt onbruikbaar, build-tijden gaan naar oneindig, en je rekening schiet omhoog.

De architectuur

We gebruiken geen generateStaticParams voor 253K pagina's. We gebruiken volledig dynamische rendering met agressieve caching:

// app/[locale]/celebrity/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'

export default async function CelebrityPage({ params }: Props) {
  const supabase = await createClient()
  
  const { data: celebrity } = await supabase
    .from('celebrities')
    .select('*, social_profiles(*), net_worth_history(*)')
    .eq('slug', params.slug)
    .eq('locale', params.locale)
    .single()
  
  if (!celebrity) notFound()
  
  return <CelebrityProfile data={celebrity} />
}

export const revalidate = 86400 // Revalideer dagelijks

Build-tijd? Ongeveer 10 seconden. De pagina's worden on-demand weergegeven en in de cache opgeslagen aan de rand. Wanneer iemand zoekt naar een celebrity die we recent niet hebben bediend, raakt het eerste verzoek Supabase (typisch 20-50ms vanaf de rand), geeft de pagina weer, slaat deze op in de cache, en elke volgende bezoeker krijgt de gecachete versie.

Row-Level Security als toegangscontrole

De RLS-beleidsregels van Supabase vervangen wat je normaal in een CMS admin zou opbouwen:

CREATE POLICY "Public read access" ON celebrities
  FOR SELECT USING (status = 'published' AND locale = current_setting('app.locale'));

CREATE POLICY "Editor update access" ON celebrities
  FOR UPDATE USING (auth.role() = 'editor');

Het content-bewerkingsprobleem

Dit is de eerlijke nadeel: de Table Editor van Supabase is prima voor ontwikkelaars, maar het is geen content-bewerkingservaring. We hebben aangepaste admin-interfaces voor onze redactionele teams gebouwd met behulp van de clientlibraries van Supabase. Wil je je eigen admin UI niet bouwen, dan is deze aanpak niets voor jou.

Supabase Pro kost $25/maand, en zelfs met 253K pagina's, zijn we ver niet in de buurt van de compute- of opslaglimieten. Vergelijk dat met Contentful of Sanity-prijzen op vergelijkbare schaal.

Voor onze headless CMS-ontwikkeloplossingn bevelen we deze aanpak aan voor elk project boven de 10.000 gestructureerde content-pagina's.

3. Strapi 5 -- Best voor niet-technische teams

Ons oordeel: de beste visuele content-modelleringservaring, ideaal wanneer je editors geen ontwikkelaars zijn.

We hebben Strapi 5 diepgaand geëvalueerd voor een clientproject en schreven een uitgebreide Payload vs Strapi-vergelijking (die op pagina 1 staat, dus duidelijk stellen anderen dezelfde vragen). Hoewel we uiteindelijk Payload voor dat project kozen, heeft Strapi een duidelijk gebruiksscenario.

De Content-Type Builder van Strapi 5 stelt niet-technische teamleden in staat om content-structuren te maken en wijzigen via een drag-and-drop GUI. Geen code. Geen config-bestanden. Geen deployments. Je marketing manager kan een "testimonial" content-type toevoegen met velden voor citaat, auteur, bedrijf en beoordeling zonder een Jira-ticket in te dienen.

App Router integratie

Strapi 5 stelt zowel REST als GraphQL API's bloot. De integratie met App Router is ongecompliceerd maar vereist netwerkverzoeken:

// lib/strapi.ts
export async function getArticles() {
  const res = await fetch(
    `${process.env.STRAPI_URL}/api/articles?populate=*`,
    {
      headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
      next: { revalidate: 60 },
    }
  )
  return res.json()
}

Het werkt. Maar vergeleken met de Local API van Payload, voel je de impedantie-mismatch. Je serialiseert en deserialiseert gegevens die in-process hadden kunnen blijven. TypeScript-typen moeten afzonderlijk worden gegenereerd (Strapi heeft hier een CLI voor, en het is beter geworden in v5).

Strapi 5 prijzen (2026)

Plan Prijs Zetels Assets
Community Gratis (zelf-gehost) Onbeperkt Onbeperkt
Team $29/maand/zetel 5-20 100GB
Business $99/maand/zetel Aangepast 500GB
Enterprise Aangepast Aangepast Aangepast

Strapi zelf hosten is echt gratis en werkt goed. De Cloud-plannen voegen beheerde hosting en premium ondersteuning toe.

4. Sanity -- Best voor real-time samenwerking

Ons oordeel: beste real-time bewerkingservaring, maar GROQ is een liefst-het-of-haat-het-verplichting.

We hebben Sanity serieus geëvalueerd voor het DA-project (91K celebrity-pagina's) voordat we naar Supabase gingen. Sanity Studio is werkelijk indrukwekkend -- het is een React-applicatie die je tot het veldniveau kunt aanpassen. Real-time samenwerking werkt foutloos. Twee editors kunnen tegelijk aan hetzelfde document werken, Google Docs-stijl.

GROQ: Krachtig maar polariserend

Sanity gebruikt GROQ, zijn eigen querytaal:

*[_type == "article" && slug.current == $slug][0] {
  title,
  body,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  publishedAt
}

GROQ is eigenlijk elegant zodra je het leert. De projectiesyntaxis (->) voor het oplossen van verwijzingen is voor veel use cases aangenamer dan GraphQL. Maar het is een ander querytaal dat je team moet leren en onderhouden. En wanneer je randen cases raakt, kan de documentatie dun voelen.

Waarom we Sanity niet voor DA hebben gekozen

Bij 91.000 documenten worden de prijzen van Sanity aanzienlijk. Het Growth-plan ($15/gebruiker/maand) omvat 1M API CDN-verzoeken. Klinkt als een heleboel totdat je beseft dat een site met 91K pagina's met redelijk verkeer dat snel verbruikt. We schatten dat onze maandelijkse Sanity-factuur $300-500/maand voor DA alleen zou zijn. Supabase Pro voor $25/maand was een no-brainer.

Sanity is uitstekend voor sites met 50-5.000 content-items waarbij meerdere editors moeten samenwerken. Redactionele teams bij mediabedrijven houden ervan.

5. Contentful -- Best voor Enterprise (met budget)

Ons oordeel: de meest volwassen headless CMS, maar je betaalt voor die volwassenheid.

Contentful bestaat sinds 2013. Het is de headless CMS waarvoor enterprise-teams standaard gaan, en er is een reden voor: de content-modellering is uitstekend, de API is rotsvast (99,99% SLA op Premium), en het ecosysteem van integraties is zonder weerga.

We hebben Contentful voor meerdere enterprise-clientprojecten geëvalueerd. De content model-bouwer is gepolijst, de API-explorer in de web-app is werkelijk nuttig voor debugging, en het webhooks-systeem integreert schoon met Next.js on-demand revalidatie.

Het prijskaartje

Plan Prijs (2026) Content Types Locales API-aanroepen
Free $0 48 2 1M/maand
Basic $300/maand 48 6 2M/maand
Premium Aangepast (typisch $3.000+/maand) Onbeperkt Onbeperkt Aangepast

De sprong van Free naar Basic is steil. De sprong van Basic naar Premium is een klif. Als je een enterprise bent met een $50K+/jaar SaaS-budget, is Contentful een veilige gok. Bent je een startup die de burn rate laag probeert te houden, kijk dan ergens anders.

App Router integratie

De JavaScript SDK van Contentful werkt goed met Server Components:

import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!,
})

export async function getPage(slug: string) {
  const entries = await client.getEntries({
    content_type: 'page',
    'fields.slug': slug,
    include: 3,
  })
  return entries.items[0]
}

De SDK is goed onderhouden en volledig getypeerd met contentful-typescript-codegen. Geen klachten over de DX-kant.

6. Markdown/MDX -- Best voor developer blogs

Ons oordeel: nul overhead, maximale controle, Git-native workflows.

Deze site -- socialanimal.dev -- draait op MDX. Elk artikel is een bestand in de repo met frontmatter-metadata:

---
title: "Best CMS voor Next.js App Router 2026"
slug: "best-cms-nextjs-app-router-2026"
category: "Resources"
tags: ["nextjs", "cms", "payload", "supabase"]
publishedAt: "2026-01-15"
---

Ik ship Next.js-sites sinds de Pages Router-dagen...

Met @next/mdx of contentlayer2 (de community fork) integreert MDX native met de App Router. Je content IS je codebase. Versiebeheer, branching, pull request-reviews -- alle workflows die je al kent.

Wanneer MDX breekt af

Niet-ontwikkelaars kunnen het niet gebruiken. Punt. Wil je marketing team blog-posts publiceren, MDX betekent dat ze ofwel Git leren of je bent hun een bewerkingsinterface aan het bouwen (waarna je gewoon Payload gebruikt).

MDX schaalt ook niet goed tot duizenden pagina's. Bij ongeveer 500+ MDX-bestanden beginnen build-tijden te slepen en je IDE vertraagt. Voor een bedrijfsblog of documentatiesite is het perfect. Voor een content-platform is het niet.

Voor ons Astro-ontwikkelingswerk gebruiken we MDX nog veel uitgebreider aangezien Astro's content collections uitstekende type-veiligheid bieden voor Markdown/MDX-content.

Productie-metriek vergelijking

Dit zijn de gegevens van onze daadwerkelijke productieimplementaties en evaluaties:

CMS Pagina's in productie Talen Build-tijd Maandelijkse kosten Ons oordeel
Payload 3 228 (SleepDr) 1 ~45s $35 (Payload Cloud) Beste DX voor Next.js
Supabase 253K (DA+NAS+HostList) 30 ~10s $25 (Pro-plan) Best voor schaal
Strapi 5 0 (geëvalueerd) N/A N/A Gratis (zelf-gehost) Best voor GUI-editors
Sanity 0 (geëvalueerd) N/A N/A ~$300-500 est. Best voor samenwerking
Contentful 0 (geëvalueerd) N/A N/A $300+ (Basic) Best voor enterprise
MDX ~60 (deze site) 1 ~30s $0 Best voor dev blogs

De build-time kolom verdient uitleg. Payload op 45 seconden omvat het genereren van 228 statische pagina's. Supabase op 10 seconden is omdat we geen 253K pagina's statisch genereren -- we gebruiken dynamische rendering met ISR. MDX op 30 seconden is voor ~60 artikelen met syntaxismarkering en afbeeldingsoptimalisatie.

Besluitvormingskader: hoe kies je jouw CMS

Vergeet feature-checklists. Beantwoord deze vier vragen:

1. Wie bewerkt content?

  • Alleen ontwikkelaars → MDX of Payload
  • Ontwikkelaars + technische editors → Payload of Sanity
  • Niet-technisch marketing team → Strapi of Contentful

2. Hoeveel pagina's?

  • Onder 500 → Elke CMS werkt. Kies op basis van editor UX.
  • 500-5.000 → Payload of Sanity. Beide hanteren dit bereik goed af.
  • 5.000-50.000 → Supabase of Contentful (met budget).
  • 50.000+ → Supabase. Niets anders is economisch logisch.

3. Wat is je maandelijk CMS-budget?

  • $0 → Zelf-gehoste Payload, zelf-gehoste Strapi, of MDX
  • $25-50 → Supabase Pro of Payload Cloud
  • $100-500 → Sanity Growth of Strapi Cloud
  • $500+ → Contentful of Sanity Enterprise

4. Heb je real-time samenwerking nodig?

  • Ja, kritiek → Sanity (beste in klasse)
  • Leuk om te hebben → Payload (live preview is dicht)
  • Maakt niet uit → Alles anders

Wat zouden we anders doen

Achteraf inzicht is waardevol. Dit zouden we veranderen:

We zouden eerder met Payload zijn begonnen. We bouwden enkele vroege projecten met aangepaste admin-panelen bovenop Supabase voordat Payload 3 volwassen werd. Voor sites onder 5K pagina's zou Payload ons aanzienlijke admin UI-ontwikkelingstijd hebben bespaard.

We zouden onze Supabase-als-CMS-patronen eerder standaardiseren. Elk van onze drie Supabase-projecten heeft iets andere conventies voor content-modellering, caching en revalidatie. We hebben sinds een interne template gemaakt die we voor alle nieuwe high-volume-projecten gebruiken.

We zouden de Contentful-evaluatie voor niet-enterprise clients overslaan. De prijsklifis echt, en twee keer gingen we door multi-weken evaluaties voordat we realiseerden dat het budget van de client niet met Contentful's prijzen overeenkwam. We hadden eerst naar budget moeten vragen.

Sta je voor een vergelijkbare CMS-beslissing voor een Next.js-project, we delen graag meer details over onze ervaring. Bekijk onze prijspagina of neem direct contact op -- we doen dit spul elke dag.

Veel gestelde vragen

Wat is de beste headless CMS voor Next.js in 2026? Gebaseerd op onze productie-ervaring over 253K+ pagina's, is Payload CMS 3 de beste algehele keuze voor Next.js App Router. De Local API elimineert netwerkoverhead, TypeScript-typen worden automatisch gegenereerd, en het admin panel leeft binnen je Next.js-app. Voor sites boven 10.000 pagina's bevelen we Supabase aan als een CMS-laag met een aangepaste admin-interface.

Is Payload CMS echt gratis? Payload CMS is open-source en gratis om zelf te hosten zonder functiebeperkingen. Je zult je eigen hosting en database moeten leveren (MongoDB of PostgreSQL). Payload Cloud, hun beheerde hosting-service, begint bij ongeveer $35/maand voor productiewerkbelastingen in 2026. Er zijn geen per-seat kosten op de zelf-gehoste versie.

Kan ik Supabase als CMS voor Next.js gebruiken? Ja, en we doen het op schaal. We runnen drie productiesites met in totaal 253.000+ pagina's op Supabase. Het werkt uitzonderlijk goed wanneer je content gestructureerde gegevens is (profielen, lijsten, productcatalogi) in plaats van langdurige redactionele content. De belangrijkste afweging is dat je je eigen content-bewerkingsinterface moet bouwen -- de Table Editor van Supabase is niet ontworpen voor redactionele workflows.

Hoe vergelijkt Strapi 5 met Payload CMS 3 voor Next.js? Strapi 5 blinkt uit in niet-technische content-bewerking met zijn visuele Content-Type Builder. Payload 3 blinkt uit in ontwikkelaarbelevenis met zijn Local API en TypeScript-native aanpak. Zijn je editors ontwikkelaars, kies Payload. Zijn je editors marketeers, kies Strapi. We schreven een gedetailleerde Payload vs Strapi-vergelijking die dit onderwerp diepgaand behandelt.

Wat is de goedkoopste headless CMS voor Next.js? Zelf-gehoste Payload CMS en zelf-gehoste Strapi zijn beide werkelijk gratis. MDX-bestanden in een Git-repo kosten niets voorbij je hosting. Voor beheerde services biedt Supabase Pro voor $25/maand de beste waarde op schaal -- we serveren 253K pagina's op een enkel Pro-plan. De gratis tier van Sanity is ook genereus voor kleine projecten (tot 3 gebruikers, 500K API-verzoeken/maand).

Is Contentful de prijs waard voor Next.js-projecten? Contentful is het waard als je een enterprise-team bent die een 99,99% SLA nodig heeft, gevestigde integraties met tools als Commercetools of Salesforce, en je hebt het budget ($300+/maand voor Basic, $3.000+/maand voor Premium). Voor startups en middelgrote bedrijven leveren Payload of Sanity vergelijkbare functionaliteit aan een fractie van de kosten.

Moet ik ISR of SSR gebruiken met een headless CMS in Next.js App Router? Dit hangt af van je paginaantal en content-updatefrequentie. Voor sites onder 5.000 pagina's is statische generatie met on-demand revalidatie via webhooks ideaal. Voor 5.000+ pagina's is dynamische rendering met ISR (revalidate = 3600 of vergelijkbaar) praktischer -- je kunt niet 50K pagina's bij elke deployment bouwen. Met de Local API van Payload maakt het onderscheid minder uit omdat er toch geen netwerkoverhead is.

Kan ik van WordPress naar een headless CMS voor Next.js migreren? Absoluut. We hebben meerdere WordPress-migraties gedaan. Het typische traject is: WordPress-content exporteren via REST API of WP-CLI, transformeren en importeren in je doel-CMS, en vervolgens de frontend in Next.js herbouwen. Payload CMS maakt dit bijzonder soepel omdat je je collections kunt modelleren om met je bestaande WordPress-posttypen overeen te stemmen. Voor meer details over dit proces, zie onze headless CMS-ontwikkeloplossinglen.