En 2026, cuando alguien se plantea con qué construir su web y quiere algo más moderno que el gestor de siempre, uno de los nombres que aparece es Payload CMS. No es un plugin ni una plantilla: es una forma distinta de entender qué es un gestor de contenidos, pensada desde el primer día para quien construye webs y aplicaciones a medida. En Next.js vs WordPress explicamos cuándo conviene una web a medida; aquí respondemos a lo que viene después: qué es Payload, cómo funciona y en qué se diferencia del resto de opciones, desde el clásico WordPress hasta otros CMS headless como Strapi o Sanity.
Qué es Payload CMS
Payload CMS es un gestor de contenidos —un CMS, como lo es WordPress— pensado para desarrolladores. Su diferencia de fondo se resume en dos palabras: code-first, es decir, "primero el código". En la mayoría de gestores, para crear una sección nueva —por ejemplo, un catálogo de productos— vas pinchando opciones en un panel. En Payload, esa estructura se escribe directamente en el código del proyecto, y a partir de ahí el propio sistema construye solo todo lo demás.
¿Qué construye "solo"? Tres cosas:
- El panel de administración, donde los editores escriben y suben contenido, con su aspecto visual ya montado.
- El almacén donde se guardan los datos (la base de datos).
- Las conexiones que permiten que tu web —o una app móvil, o cualquier otro sistema— pida ese contenido y lo muestre.
La palabra headless ("sin cabeza") describe justo eso: Payload se ocupa del contenido, pero no decide cómo se ve. El diseño de la web lo pones tú por separado, normalmente con Next.js —la tecnología con la que están hechas muchas webs modernas, incluida esta—. Es lo contrario del modelo clásico de WordPress, donde el mismo sistema guarda el contenido y dibuja la página.
La novedad que lo cambió todo llegó con Payload 3.0: fue el primer gestor que se instala dentro de la propia web Next.js, en lugar de funcionar como un programa aparte. En la práctica, el panel, el almacén de datos y la web pública viven en un único proyecto y se publican juntos. La versión actual es la 3.86, y ya se trabaja en Payload 4.0.
Un apunte que da tranquilidad sobre su futuro: Payload es gratuito y de código abierto —cualquiera puede usarlo y modificarlo, bajo licencia MIT— y, desde junio de 2025, forma parte de Figma, la conocida herramienta de diseño. Sigue siendo gratis y puedes alojarlo donde quieras, pero ahora con una empresa grande detrás.
Cómo funciona por dentro
La mejor forma de entenderlo es ver lo corto que es crear una sección. Este trozo de código define un apartado de artículos de blog, con su título, su cuerpo, su autor y su fecha:
export const Posts = {
slug: 'posts',
fields: [
{ name: 'title', type: 'text', required: true }, // título
{ name: 'content', type: 'richText' }, // cuerpo del artículo
{ name: 'author', type: 'relationship', relationTo: 'users' }, // autor
{ name: 'publishedAt', type: 'date' }, // fecha
],
}
No hace falta entender cada línea; basta con quedarse con la idea: con unas pocas líneas, Payload ya sabe crear el formulario del panel, guardar los datos y ponerlos a disposición de la web. Esa definición es la "fuente de la verdad", y todo lo demás se genera a partir de ella. Si mañana añades un campo, el panel y el almacén se actualizan solos.
Las piezas que merece la pena conocer, en cristiano:
- La base de datos, a tu elección. Payload no te obliga a usar una tecnología concreta para guardar los datos: funciona con las más habituales (es database-agnostic: MongoDB, PostgreSQL o SQLite). Traducido: puedes usar la que ya tengas o la que mejor encaje, sin cambiar de gestor.
- Usuarios y permisos incluidos. Trae de serie el registro e inicio de sesión y un control muy fino de quién puede ver o editar cada cosa, hasta el nivel de un dato concreto dentro de una ficha.
- Gestión de imágenes y archivos, como un banco de recursos. Sube imágenes y las redimensiona solo, permite organizarlas en carpetas, guardar versiones y buscarlas por etiquetas, sin necesidad de programas ni servicios extra.
- Tareas automáticas. Puede encargarse de trabajos que tardan o que se repiten —enviar correos, procesar cosas de madrugada— sin ralentizar la web, algo poco común en gestores de este tipo.
- Contenido listo para cualquier pantalla. Ofrece el contenido de varias formas para que lo consuma una web, una app móvil u otro sistema; y como vive dentro de Next.js, la web puede pedírselo directamente, sin rodeos, y cargar más rápido.
Payload CMS vs WordPress: comparativa rápida
Si solo tienes un minuto, esta tabla resume las diferencias con el gestor más extendido. En negrita, la opción más fuerte en cada criterio:
| Criterio | WordPress 7.0 | Payload CMS |
|---|---|---|
| Modelo de configuración | Panel visual, sin código | Estructura en código (TypeScript) |
| Edición de contenido | Para cualquier persona, desde el primer minuto | Panel cómodo, pero hay que montarlo antes |
| Rendimiento | Bueno, con optimización continua | Excelente de serie sobre Next.js |
| Seguridad | Requiere vigilancia constante | Superficie de ataque mínima |
| Lenguaje | PHP | TypeScript de punta a punta |
| Ecosistema | Decenas de miles de plugins y temas | Joven, en crecimiento |
| Curva de aprendizaje (editor) | Mínima | Baja, una vez configurado |
| Curva de aprendizaje (desarrollo) | Media (PHP + ecosistema) | Requiere React y TypeScript |
| Hosting | PHP + base de datos | Node.js / serverless, o Payload Cloud |
El resto del artículo desgrana las filas que más pesan en una decisión real.
Dos filosofías opuestas
WordPress nació como un sistema para publicar sin saber programar, y ahí sigue estando su fuerza. Es un monolito: el mismo servidor PHP guarda el contenido en una base de datos MySQL y genera la página pública en cada visita, apoyándose en un tema y en los plugins que tengas instalados. Cualquiera puede escribir un artículo, subir una foto o cambiar un texto desde un panel visual sin tocar una línea de código.
Payload invierte el punto de partida. Asume que hay un desarrollador construyendo la web y le da superpoderes: define el modelo de contenido en código y obtiene a cambio un backend completo y un panel de administración sin escribirlos a mano. El contenido se separa de la presentación, y el frontend —normalmente Next.js— decide cómo y cuándo mostrarlo, con la opción de servirlo ya preparado desde un CDN.
La consecuencia es directa: WordPress optimiza la experiencia de quien edita contenido; Payload optimiza la de quien construye la web. Casi todas las demás diferencias se derivan de esa decisión de origen.
Edición de contenido
Aquí WordPress mantiene su ventaja histórica. Con el panel renovado de la versión 7.0, listados más ágiles y la IA integrada en el núcleo, la experiencia editorial es cómoda desde el minuto uno y no requiere absolutamente nada técnico. Para un cliente que publica a diario y quiere autonomía total, es difícil de superar.
Payload no se queda lejos, pero con un matiz importante: su panel también es visual y agradable de usar, una vez que un desarrollador lo ha configurado. El editor de texto, los campos personalizados o los bloques de contenido reutilizables ofrecen una experiencia moderna y muy pulida. La diferencia no está en el día a día del editor, sino en el punto de partida: en WordPress instalas y ya editas; en Payload alguien prepara antes la estructura del contenido.
Dos piezas recientes acercan además esa experiencia a la de un CMS visual de primera línea. El editor de texto usa Lexical —la tecnología de edición de Meta—, que permite incrustar elementos interactivos dentro del propio texto. Y la previsualización en vivo (Live Preview) deja al editor ver el diseño final exacto mientras escribe, sin sorpresas entre lo que edita y lo que se publica.
La captura resume bien la diferencia: el editor no rellena campos a ciegas, sino que trabaja sobre la página final, moviendo y editando bloques directamente donde se van a ver.
Rendimiento y seguridad
En rendimiento, Payload parte con la ventaja de Next.js: puede preparar las páginas por adelantado y servirlas desde el CDN, sin ejecutar código ni consultar la base de datos en cada visita. Los Core Web Vitals excelentes salen casi de serie —lo desarrollamos en nuestra guía práctica de Core Web Vitals—. WordPress puede ser rápido, pero exige trabajo continuo: caché, optimización de imágenes, disciplina con los plugins y un buen hosting.
Un dato que ilustra el salto: en una migración documentada de una tienda WooCommerce con más de 15.000 productos, los tiempos de carga de las fichas cayeron un 74 % (de 4,2 a 1,1 segundos), el panel de administración respondió un 85 % más rápido y la tasa de conversión subió del 2,1 % al 3,2 %. Son cifras de un caso concreto, no una promesa, pero apuntan en la misma dirección que la teoría.
En seguridad ocurre lo mismo. Una web construida con Payload y Next.js puede publicar su parte pública como páginas ya preparadas, sin panel de acceso expuesto ni base de datos accesible desde fuera. WordPress, por ser el CMS más popular del mundo, concentra la mayoría de los ataques automatizados a gestores de contenido, y su punto débil suele ser el ecosistema de plugins de terceros. No es que WordPress sea inseguro, sino que exige una vigilancia recurrente que alguien tiene que hacer y presupuestar.
Conviene ser justo en los dos sentidos. A favor de Payload: trae de fábrica el control de acceso, las sesiones seguras y la limitación de intentos, sin plugins. En su contra: al ser code-first, eres tú quien define las reglas de quién puede ver qué, y si no las declaras puedes dejar un dato sensible al descubierto; y como cualquier software, no es infalible —a principios de 2026 se detectó y corrigió un fallo de seguridad, lo que recordó la importancia de configurarlo con cuidado—. La ventaja frente al monolito no es la ausencia de fallos, sino una superficie de ataque mucho menor.
Ecosistema y madurez
Y aquí es donde WordPress golpea de vuelta. Dos décadas de historia se traducen en un ecosistema descomunal: decenas de miles de plugins y temas, una comunidad enorme, tutoriales para cualquier duda y profesionales en cada ciudad. Si necesitas una tienda, un sistema de reservas o un campus online, es casi seguro que existe un plugin que lo resuelve hoy.
Payload es joven en comparación. Su comunidad crece rápido y el respaldo de Figma le da estabilidad, pero no hay un "plugin para todo": lo que en WordPress es instalar y configurar, en Payload muchas veces es desarrollar. Para un equipo técnico eso es una ventaja (control total, sin sorpresas de terceros); para quien busca montar algo estándar sin desarrollo, es un coste.
Gobernanza y soberanía
Hay un factor que antes no aparecía en estas comparativas y ahora sí: quién controla la plataforma. La gobernanza de WordPress está muy centralizada en Automattic y su cofundador, y la crisis de 2024 con WP Engine —con bloqueos de acceso al repositorio oficial de plugins y actualizaciones— demostró que una disputa corporativa puede afectar a millones de webs. Con Payload, toda la configuración vive en tu propio proyecto bajo licencia MIT y no dependes de un repositorio central para funcionar ni para actualizar la seguridad: el control sobre tu web es total.
Payload frente a otros CMS headless
WordPress es solo una de las alternativas. Si ya tienes claro que quieres un CMS headless, la comparación relevante es con los otros pesos pesados del sector: Strapi, Sanity y Contentful. Cada uno resuelve el mismo problema de forma distinta.
| Criterio | Payload | Strapi | Sanity | Contentful |
|---|---|---|---|---|
| Configuración | Código (TypeScript) | Panel + código | En código | Panel (en la nube) |
| Alojamiento | Propio o Payload Cloud | Propio | En la nube del proveedor | En la nube del proveedor |
| Base de datos | MongoDB, PostgreSQL o SQLite | Solo SQL | Propietaria | Propietaria |
| Vive dentro de Next.js | Sí, de forma nativa | No, programa aparte | No | No |
| Coste | Gratis (licencia MIT) | Gratis (versión Community) | De pago por usuario | De pago, gama alta |
| Control de los datos | Total, en tu servidor | Total | En servidores del proveedor | En servidores del proveedor |
- Strapi es el rival de código abierto más directo, pero mantiene el modelo clásico de dos programas separados —el gestor por un lado y la web por otro—, con la lentitud añadida de que tengan que hablar entre ellos por la red. Payload se ahorra ese salto al vivir dentro de Next.js. Además, Strapi solo funciona con bases de datos SQL, mientras que Payload admite también MongoDB.
- Sanity es excelente para contenido muy estructurado y trabajo en equipo en tiempo real, y también define el contenido en código. La gran diferencia es el modelo: es un servicio en la nube, tus datos viven en sus servidores y la factura crece por usuario y por uso. Payload lo alojas tú, así que el control de los datos es tuyo —algo innegociable en sanidad, banca o administración pública—. Sanity, además, obliga a aprender su propio lenguaje para pedir datos; Payload usa los estándares del sector.
- Contentful es la opción para grandes corporaciones: muy potente, pero con un precio y una complejidad que lo hacen desproporcionado para la mayoría de proyectos.
- Opciones más ligeras como Keystatic guardan el contenido como simples archivos de texto dentro del proyecto: perfectas para documentación o blogs sencillos, pero se quedan cortas en cuanto necesitas usuarios, permisos o muchos datos relacionados entre sí, terreno donde Payload juega en otra liga.
Resumido: frente a los servicios de pago (Sanity, Contentful), Payload gana en control y coste; frente a Strapi, en integración con Next.js; y frente a las opciones más simples, en potencia para aplicaciones de verdad.
Qué cambia con la compra de Figma
Payload se anunció como parte de Figma en la conferencia Config 2025, con su creador y CEO, James Mikrut, al frente del proyecto. Para quien evalúa adoptarlo, lo importante son las dos garantías que acompañaron al anuncio: se pausaron las nuevas altas del hosting gestionado Payload Cloud —para concentrar recursos en la integración con Figma—, pero se ratificó la licencia MIT del núcleo, así que el CMS sigue siendo gratuito, modificable y autoalojable sin ataduras.
La lógica de la operación explica hacia dónde va el producto. Payload define el contenido en código, con una estructura que se parece mucho a un sistema de diseño; la apuesta es que los componentes y estilos creados en Figma se traduzcan de forma casi automática en estructura de contenido en Payload, acercando diseño y datos y recortando el eterno "toma y daca" entre quien diseña y quien programa.
Cuándo elegir Payload
- Equipo técnico que quiere control total y TypeScript de punta a punta: Payload. El modelo de contenido en código es un placer para desarrollar y mantener.
- Cliente no técnico que publica a diario y quiere autonomía: WordPress. La edición sin desarrollo previo sigue siendo su gran baza.
- Web o aplicación a medida sobre Next.js que además necesita panel de contenido: Payload. Al vivir dentro del mismo proyecto, evita el pegamento entre gestor y web.
- Proyecto que se apoya en funcionalidad muy específica ya hecha (membresías, cursos, reservas complejas): WordPress, salvo que quieras desarrollar esos sistemas a medida.
- Producto digital, portal con roles y permisos finos, o base de una app: Payload. El control de acceso al detalle es de los mejores del mercado.
- Sectores con datos sensibles (salud, finanzas, administración): Payload, por poder eliminar el panel expuesto y la base de datos pública, y por mantener los datos en tu propio servidor.
¿Y la comparación con WordPress headless (usar WordPress solo como almacén de contenido y Next.js como web)? Es una alternativa legítima, pero ahí sigues arrastrando dos sistemas y dos despliegues; Payload unifica todo en un único proyecto sobre Next.js. Si ya vives en el ecosistema JavaScript, esa unificación es su mayor argumento.
Conclusión: ¿es Payload CMS para ti?
No hay tecnología ganadora universal, hay proyectos y perfiles. Payload CMS brilla cuando manda quien construye: control total, TypeScript de punta a punta, rendimiento y seguridad de serie, y un backend completo que vive dentro de tu propia app Next.js, con los datos siempre bajo tu control. Frente a WordPress gana cuando el equipo es técnico y el rendimiento importa; frente a los CMS de pago en la nube (Sanity, Contentful), en control y coste; frente a Strapi, en integración con Next.js.
Nuestra forma de decidirlo es sencilla: miramos quién va a tener las manos en la web el día a día y cuánto pesa el contenido frente a la funcionalidad a medida. En nuestro servicio de desarrollo web partimos de esa pregunta antes de recomendar nada, y en nuestros proyectos puedes ver distintos enfoques funcionando en producción.
