Traducción del artículo

He estado enviando sitios Next.js desde los días del Pages Router, y he perdido la cuenta de cuántas veces he visto un artículo "mejor CMS" escrito por alguien que claramente instaló la cosa una vez, siguió el tutorial de inicio rápido, y lo llamó una reseña. Esto no es eso.

En Social Animal, ejecutamos sitios de producción en múltiples arquitecturas de CMS -- desde Payload CMS impulsando una aplicación de healthcare hasta Supabase sirviendo 253,000+ páginas en tres plataformas diferentes. Hemos evaluado Strapi 5, Sanity y Contentful para proyectos de clientes reales. ¿Y este sitio que estás leyendo? Está construido en archivos MDX confirmados en un repositorio Git.

Así que cuando digo "probamos 6 en producción", quiero decir que hemos lidiado con los dolores de cabeza de migración, las sorpresas de tiempo de construcción, los mensajes de Slack a las 3 AM sobre contenido que no se publica. Aquí está todo lo que hemos aprendido sobre elegir el CMS correcto para Next.js App Router en 2026.

Tabla de Contenidos

Mejor CMS para Next.js App Router 2026: Probamos 6 en producción

Por qué el App Router cambia la ecuación del CMS

Si aún estás pensando en la selección de CMS de la forma en que lo hacías con el Pages Router, te estás dejando rendimiento sobre la mesa. El App Router cambió fundamentalmente cómo fluyen los datos a través de una aplicación Next.js, y eso tiene implicaciones directas para qué CMS se ajusta mejor.

Aquí está lo que importa ahora:

Los Server Components son el predeterminado. Tu obtención de datos del CMS sucede en el servidor sin enviar ningún JavaScript al cliente. Esto significa que los CMS con SDK nativos de Node.js o -- mejor aún -- API locales que omiten la red por completo tienen una ventaja masiva.

React Server Components + caché de fetch. El almacenamiento en caché y deduplicación de fetch integrado del App Router significa que tus patrones de integración de CMS se ven completamente diferentes. No estás recurriendo a getStaticProps o getServerSideProps más. Estás escribiendo componentes asincronos que llaman a tu CMS directamente.

Parallel Routes e Intercepting Routes. Estos patrones desbloquean diseños impulsados por CMS que antes eran dolorosos de construir. Un CMS que admita modelado de contenido flexible (no solo publicaciones de blog y páginas) brilla aquí.

Partial Prerendering (PPR). A partir de Next.js 15, PPR te permite servir un shell estático con agujeros dinámicos. Esto cambia completamente el debate de ISR vs. SSR, y significa que tu estrategia de revalidación de CMS importa más que nunca.

Con todo ese contexto, entremos en las pruebas reales.

Los 6 CMS que probamos (y cómo los probamos)

Nuestra evaluación no fue teórica. Para cada CMS, ya sea que enviamos páginas de producción o hicimos una evaluación técnica profunda para un proyecto de cliente real. Medimos:

  • Experiencia del desarrollador con App Router específicamente
  • Tiempos de construcción en varios conteos de páginas
  • UX del editor de contenido para miembros del equipo no desarrolladores
  • Precios a escala (no solo el nivel gratuito)
  • Calidad de la integración de TypeScript
  • Patrones de revalidación (ISR, bajo demanda, webhooks)

Vamos a repasar cada uno.

1. Payload CMS 3 -- Mejor en general para Next.js

Nuestro veredicto: La mejor experiencia de desarrollador para Next.js App Router, punto.

Payload CMS 3 es el que me hizo replantear lo que un CMS podría ser. No es un servicio separado que llames por HTTP. Vive dentro de tu aplicación Next.js. Mismo repositorio, mismo despliegue, mismo tipos de TypeScript.

Ejecutamos Payload 3 en producción en SleepDr, una plataforma de healthcare con 228 páginas, control de acceso multinivel, y contenido que necesita ser preciso (es relacionado con la salud, así que contenido incorrecto no es solo una mala apariencia -- es un pasivo).

Lo que hace a Payload especial para App Router

La Local API es la función asesina. En lugar de hacer solicitudes HTTP a tu CMS, importas una función y la llamas directamente:

// 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} />
}

Sin salto de red. Sin gastos generales de REST o GraphQL. Sin SDK para instalar. La llamada a la función está completamente tipada porque Payload genera interfaces de TypeScript desde tus configuraciones de colecciones. Cuando refactorizas un nombre de campo, tu IDE atrapa cada referencia rota al instante.

Live Preview con App Router

La vista previa en vivo de Payload 3 funciona con Server Components. Tus editores de contenido ven cambios en tiempo real en el diseño del sitio real -- no alguna aproximación en el panel de administración. Configuramos esto para SleepDr y el equipo editorial pasó de "Necesito que un desarrollador verifique esto" a publicación autosuficiente en una semana.

Control de acceso que realmente funciona

El control de acceso a nivel de campo y a nivel de colección de Payload se define en código:

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: [
    // ...
  ],
}

Para una aplicación de healthcare, esta granularidad no es opcional. Es un requisito.

Las compensaciones

Payload se ejecuta en tu infraestructura. Si deseas una experiencia SaaS completamente gestionada, Payload Cloud existe (comenzando alrededor de $35/mes para producción), pero aún eres responsable de entender el despliegue. También es una dependencia de tiempo de ejecución de Node.js, lo que significa que tu hosting necesita soportarlo (Vercel funciona, pero los costos aumentan con conexiones persistentes a tu base de datos).

Para nuestro trabajo de desarrollo Next.js, Payload 3 es ahora nuestra recomendación por defecto para sitios con mucho contenido bajo 5,000 páginas.

Mejor CMS para Next.js App Router 2026: Probamos 6 en producción - arquitectura

2. Supabase-as-CMS -- Mejor para escala (10K+ páginas)

Nuestro veredicto: Técnicamente no es un CMS, pero nada más se acerca para conjuntos de datos estructurados masivos.

Esta es la opción poco convencional, y es la que más me entusiasma. Supabase no se comercializa como un CMS. Es una plataforma PostgreSQL con auth, almacenamiento y Edge Functions. Pero cuando tu "contenido" es realmente datos estructurados -- perfiles de celebridades, listados de negocios, bases de datos de productos -- los CMS tradicionales colapsan a escala, y Supabase ni siquiera se resquebraja.

Ejecutamos tres sitios de producción en Supabase-as-CMS:

  • DA -- 91,000+ páginas de datos de celebridades en 30 idiomas
  • NAS -- 137,000+ listados de negocios
  • HostList -- 25,000+ listados de proveedores de hosting

Eso es 253,000+ páginas. Déjame decirte qué sucede cuando intentas poner 91,000 entradas en un CMS headless tradicional: el panel de administración se vuelve inutilizable, los tiempos de construcción llegan al infinito, y tu factura se dispara.

La arquitectura

No usamos generateStaticParams para 253K páginas. Usamos renderizado totalmente dinámico con almacenamiento en caché agresivo:

// 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 // Revalidar diariamente

¿Tiempo de construcción? Aproximadamente 10 segundos. Las páginas se renderizan bajo demanda y se almacenan en caché en el edge. Cuando alguien busca una celebridad que no hemos servido recientemente, la primera solicitud llama a Supabase (típicamente 20-50ms desde el edge), renderiza la página, la almacena en caché, y cada visitante posterior obtiene la versión almacenada en caché.

Row-Level Security como control de acceso

Las políticas de RLS de Supabase reemplazan lo que normalmente construirías en un admin de CMS:

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');

El problema de la edición de contenido

Aquí está la desventaja honesta: el Table Editor de Supabase está bien para desarrolladores, pero no es una experiencia de edición de contenido. Construimos interfaces de administrador personalizadas para nuestros equipos editoriales usando las librerías de cliente de Supabase. Si no quieres construir tu propio interfaz de administración, este enfoque no es para ti.

Supabase Pro corre $25/mes, y incluso con 253K páginas, estamos lejos de los límites de computación o almacenamiento. Compara eso con los precios de Contentful o Sanity a escala similar.

Para nuestras soluciones de desarrollo de CMS headless, recomendamos este enfoque para cualquier proyecto por encima de 10,000 páginas de contenido estructurado.

3. Strapi 5 -- Mejor para equipos no técnicos

Nuestro veredicto: La mejor experiencia de modelado de contenido visual, ideal cuando tus editores no son desarrolladores.

Evaluamos Strapi 5 en profundidad para un proyecto de cliente y escribimos una extensa comparación Payload vs Strapi (que aparece en la página 1, así que claramente otros están haciendo las mismas preguntas). Si bien finalmente elegimos Payload para ese proyecto, Strapi tiene un caso de uso claro.

El Content-Type Builder de Strapi 5 permite a miembros del equipo no técnico crear y modificar estructuras de contenido a través de una GUI de arrastrar y soltar. Sin código. Sin archivos de configuración. Sin despliegues. Tu gerente de marketing puede agregar un tipo de contenido "testimonial" con campos para cita, autor, empresa y calificación sin presentar un ticket de Jira.

Integración con App Router

Strapi 5 expone API REST y GraphQL. La integración con App Router es directa pero requiere solicitudes de red:

// 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()
}

Funciona. Pero comparado con la Local API de Payload, sientes la falta de impedancia. Estás serializando y deserializando datos que podrían haberse mantenido en proceso. Los tipos de TypeScript necesitan generarse por separado (Strapi tiene una CLI para esto, y ha mejorado en v5).

Precios de Strapi 5 (2026)

Plan Precio Asientos Activos
Community Gratuito (autohospedado) Ilimitado Ilimitado
Team $29/mes/asiento 5-20 100GB
Business $99/mes/asiento Personalizado 500GB
Enterprise Personalizado Personalizado Personalizado

Autohospedar Strapi es genuinamente gratuito y funciona bien. Los planes Cloud agregan hosting gestionado y soporte premium.

4. Sanity -- Mejor para colaboración en tiempo real

Nuestro veredicto: La mejor experiencia de edición en tiempo real, pero GROQ es un compromiso amor-u-odio.

Evaluamos Sanity en serio para el proyecto DA (91K páginas de celebridades) antes de elegir Supabase. Sanity Studio es genuinamente impresionante -- es una aplicación React que puedes personalizar hasta el nivel de campo. La colaboración en tiempo real funciona sin problemas. Dos editores pueden trabajar en el mismo documento simultáneamente, estilo Google Docs.

GROQ: Poderoso pero polarizante

Sanity usa GROQ, su propio lenguaje de consulta:

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

GROQ es realmente elegante una vez que lo aprendes. La sintaxis de proyección (->) para resolver referencias es mejor que GraphQL para muchos casos de uso. Pero es otro lenguaje de consulta que tu equipo necesita aprender y mantener. Y cuando llegas a casos extremos, la documentación puede sentirse delgada.

Por qué no elegimos Sanity para DA

A los 91,000 documentos, los precios de Sanity se vuelven significativos. El plan Growth ($15/usuario/mes) incluye 1M solicitudes de API CDN. Suena como mucho hasta que te das cuenta de que un sitio con 91K páginas que genera tráfico decente consume eso rápidamente. Estimamos que nuestra factura mensual de Sanity sería $300-500/mes solo para DA. Supabase Pro a $25/mes fue un no-brainer.

Sanity es excelente para sitios con 50-5,000 elementos de contenido donde múltiples editores necesitan colaborar. Los equipos editoriales en compañías de medios lo aman.

5. Contentful -- Mejor para empresa (con presupuesto)

Nuestro veredicto: El CMS headless más maduro, pero pagarás por esa madurez.

Contentful existe desde 2013. Es el CMS headless por defecto para equipos empresariales, y hay una razón: el modelado de contenido es excelente, la API es sólida como una roca (SLA de 99.99% en Premium), y el ecosistema de integraciones es incomparable.

Hemos evaluado Contentful para múltiples proyectos de cliente empresarial. El constructor de modelos de contenido es pulido, el explorador de API en la aplicación web es genuinamente útil para depuración, y el sistema de webhooks se integra limpiamente con la revalidación bajo demanda de Next.js.

La etiqueta de precio

Plan Precio (2026) Tipos de contenido Locales Llamadas API
Free $0 48 2 1M/mes
Basic $300/mes 48 6 2M/mes
Premium Personalizado (típicamente $3,000+/mes) Ilimitado Ilimitado Personalizado

El salto de Free a Basic es empinado. El salto de Basic a Premium es un acantilado. Si eres una empresa con un presupuesto SaaS de $50K+/año, Contentful es una apuesta segura. Si eres una startup tratando de mantener la tasa de quema baja, mira en otro lugar.

Integración con App Router

El SDK de JavaScript de Contentful funciona bien con 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]
}

El SDK se mantiene bien y está completamente tipado con contentful-typescript-codegen. Sin quejas en el frente de DX.

6. Markdown/MDX -- Mejor para blogs de desarrolladores

Nuestro veredicto: Cero gastos generales, control máximo, flujos de trabajo nativos de Git.

Este sitio -- socialanimal.dev -- se ejecuta en MDX. Cada artículo es un archivo en el repositorio con metadatos de frontmatter:

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

He estado enviando sitios Next.js desde los días del Pages Router...

Con @next/mdx o contentlayer2 (el fork de la comunidad), MDX se integra nativamente con el App Router. Tu contenido ES tu base de código. Control de versiones, ramificación, revisiones de solicitudes de extracción -- todos los flujos de trabajo que ya conoces.

Cuándo MDX se rompe

Los no desarrolladores no pueden usarlo. Punto. Si tu equipo de marketing necesita publicar publicaciones de blog, MDX significa que están aprendiendo Git o construyendo un interfaz de edición (en cuyo caso, solo usa Payload).

MDX tampoco escala bien a miles de páginas. En alrededor de 500+ archivos MDX, los tiempos de construcción comienzan a arrastrarse y tu IDE se ralentiza. Para un blog de empresa o sitio de documentación, es perfecto. Para una plataforma de contenido, no lo es.

Para nuestro trabajo de desarrollo Astro, usamos MDX aún más extensamente ya que las colecciones de contenido de Astro proporcionan excelente seguridad de tipos para contenido Markdown/MDX.

Comparación de métricas de producción

Aquí están los datos de nuestros despliegues de producción reales y evaluaciones:

CMS Páginas en producción Idiomas Tiempo de construcción Costo mensual Nuestro veredicto
Payload 3 228 (SleepDr) 1 ~45s $35 (Payload Cloud) Mejor DX para Next.js
Supabase 253K (DA+NAS+HostList) 30 ~10s $25 (plan Pro) Mejor para escala
Strapi 5 0 (evaluado) N/A N/A Gratuito (autohospedado) Mejor para editores GUI
Sanity 0 (evaluado) N/A N/A ~$300-500 est. Mejor para colaboración
Contentful 0 (evaluado) N/A N/A $300+ (Basic) Mejor para empresa
MDX ~60 (este sitio) 1 ~30s $0 Mejor para blogs de dev

La columna de tiempo de construcción merece explicación. Payload en 45 segundos incluye generar 228 páginas estáticas. Supabase en 10 segundos es porque no generamos estáticamente 253K páginas -- usamos renderizado dinámico con ISR. MDX en 30 segundos es para ~60 artículos con resaltado de sintaxis y optimización de imágenes.

Marco de decisión: cómo elegir tu CMS

Olvida las listas de características. Responde estas cuatro preguntas:

1. ¿Quién está editando contenido?

  • Solo desarrolladores → MDX o Payload
  • Desarrolladores + editores técnicos → Payload o Sanity
  • Equipo de marketing no técnico → Strapi o Contentful

2. ¿Cuántas páginas?

  • Menos de 500 → Cualquier CMS funciona. Elige según UX del editor.
  • 500-5,000 → Payload o Sanity. Ambos manejan este rango bien.
  • 5,000-50,000 → Supabase o Contentful (con presupuesto).
  • 50,000+ → Supabase. Nada más tiene sentido económico.

3. ¿Cuál es tu presupuesto mensual de CMS?

  • $0 → Payload autohospedado, Strapi autohospedado, o MDX
  • $25-50 → Supabase Pro o Payload Cloud
  • $100-500 → Sanity Growth o Strapi Cloud
  • $500+ → Contentful o Sanity Enterprise

4. ¿Necesitas colaboración en tiempo real?

  • Sí, crítico → Sanity (mejor de su clase)
  • Agradable tener → Payload (vista previa en vivo está cerca)
  • No me importa → Cualquier otra cosa

Lo que haríamos diferente

La visión retrospectiva es valiosa. Aquí está lo que cambiaríamos:

Habríamos comenzado con Payload antes. Construimos algunos proyectos iniciales con paneles de administrador personalizados en Supabase antes de que Payload 3 madurara. Para sitios bajo 5K páginas, Payload habría ahorrado significativo tiempo de desarrollo de UI de administrador.

Habríamos estandarizado nuestros patrones de Supabase-as-CMS antes. Cada uno de nuestros tres proyectos de Supabase tiene convenciones ligeramente diferentes para modelado de contenido, almacenamiento en caché y revalidación. Desde entonces hemos creado una plantilla interna que usamos para todos los nuevos proyectos de alto volumen.

Habríamos saltado la evaluación de Contentful para clientes no empresariales. El acantilado de precios es real, y dos veces pasamos por evaluaciones de múltiples semanas solo para darnos cuenta de que el presupuesto del cliente no coincidía con los precios de Contentful. Deberíamos haber preguntado sobre presupuesto primero.

Si enfrentas una decisión similar de CMS para un proyecto Next.js, estamos felices de compartir más detalles sobre nuestra experiencia. Consulta nuestra página de precios o ponte en contacto directamente -- hacemos este trabajo todos los días.

Preguntas frecuentes

¿Cuál es el mejor CMS headless para Next.js en 2026? Basado en nuestra experiencia de producción en 253K+ páginas, Payload CMS 3 es la mejor opción en general para Next.js App Router. Su Local API elimina la sobrecarga de red, los tipos de TypeScript se generan automáticamente, y el panel de administración vive dentro de tu aplicación Next.js. Para sitios que exceden 10,000 páginas, recomendamos Supabase como una capa de CMS con un interfaz de administración personalizado.

¿Es Payload CMS realmente gratuito? Payload CMS es de código abierto y gratuito para autohospedar sin restricciones de características. Necesitarás proporcionar tu propio hosting y base de datos (MongoDB o PostgreSQL). Payload Cloud, su servicio de hosting gestionado, comienza en aproximadamente $35/mes para cargas de trabajo de producción en 2026. No hay cargos por asiento en la versión autohospedada.

¿Puedo usar Supabase como CMS para Next.js? Sí, y lo hacemos a escala. Ejecutamos tres sitios de producción totalizando 253,000+ páginas en Supabase. Funciona excepcionalmente bien cuando tu contenido es datos estructurados (perfiles, listados, catálogos de productos) en lugar de contenido editorial largo. El principal tradeoff es que necesitarás construir tu propio interfaz de edición de contenido -- el Table Editor de Supabase no está diseñado para flujos de trabajo editoriales.

¿Cómo se compara Strapi 5 con Payload CMS 3 para Next.js? Strapi 5 sobresale en edición de contenido no técnica con su Content-Type Builder visual. Payload 3 sobresale en experiencia del desarrollador con su Local API y enfoque nativo de TypeScript. Si tus editores son desarrolladores, elige Payload. Si tus editores son comerciantes, elige Strapi. Escribimos una comparación detallada Payload vs Strapi cubriendo este tema a profundidad.

¿Cuál es el CMS headless más barato para Next.js? Payload CMS autohospedado y Strapi autohospedado son ambos genuinamente gratuitos. Los archivos MDX en un repositorio Git no cuesta nada más allá de tu hosting. Para servicios gestionados, Supabase Pro a $25/mes ofrece el mejor valor a escala -- servimos 253K páginas en un plan único Pro. El nivel gratuito de Sanity también es generoso para proyectos pequeños (hasta 3 usuarios, 500K solicitudes de API/mes).

¿Vale la pena el precio de Contentful para proyectos Next.js? Contentful vale la pena si eres un equipo empresarial que necesita un SLA de 99.99%, integraciones establecidas con herramientas como Commercetools o Salesforce, y tienes el presupuesto ($300+/mes para Basic, $3,000+/mes para Premium). Para startups y compañías medianas, Payload o Sanity entregan funcionalidad comparable a una fracción del costo.

¿Debo usar ISR o SSR con un CMS headless en Next.js App Router? Depende de tu número de páginas y frecuencia de actualización de contenido. Para sitios bajo 5,000 páginas, generación estática con revalidación bajo demanda vía webhooks es ideal. Para 5,000+ páginas, renderizado dinámico con ISR (revalidate = 3600 o similar) es más práctico -- no puedes construir 50K páginas en cada despliegue. Con la Local API de Payload, la distinción importa menos porque no hay sobrecarga de red de cualquier manera.

¿Puedo migrar de WordPress a un CMS headless para Next.js? Absolutamente. Hemos hecho múltiples migraciones de WordPress. El camino típico es: exportar contenido de WordPress vía REST API o WP-CLI, transformar e importar a tu CMS destino, luego reconstruir el frontend en Next.js. Payload CMS hace esto especialmente suave porque puedes modelar tus colecciones para coincidir con tus tipos de publicaciones de WordPress existentes. Para más detalles en este proceso, consulta nuestras soluciones de desarrollo de CMS headless.