La web genérica construida con una plantilla para cada ocasión está perdiendo terreno. La IA ha acelerado la creación de interfaces, prototipos y código personalizado, pero eso no significa que todas las webs deban convertirse en aplicaciones React. Si estás intentando entender cómo elegir entre WordPress y Next.js según el tipo de proyecto web, mira primero la función de la plataforma, su complejidad, cuánto contenido publicarás, qué interacción tendrá el usuario, quién la mantendrá y cómo esperas que evolucione.
WordPress y Next.js parten de filosofías diferentes. WordPress es un CMS que ya incorpora administración de contenidos, usuarios, medios y mecanismos editoriales. Next.js es un framework basado en React con el que puedes construir interfaces y aplicaciones web a medida. Compararlos como si fueran dos versiones del mismo producto sería parecido a discutir si para un proyecto es mejor PostgreSQL o Python: la pregunta está incompleta hasta que defines qué quieres construir.
A partir de aquí veremos qué criterios pesan realmente en la decisión, qué proyectos suelen funcionar mejor alrededor de un CMS, cuándo Next.js proporciona una arquitectura más coherente y en qué situaciones merece la pena conectar WordPress con un frontend desacoplado. También entraremos en una parte que suele quedar fuera de las comparativas: quién tendrá que mantener todo esto cuando hayan pasado tres años y el repositorio ya tenga unas cuantas cicatrices de guerra.
WordPress y Next.js no resuelven exactamente el mismo problema
Idea clave: WordPress concentra gestión de contenido, medios, usuarios, permisos y extensiones dentro de un CMS preparado para publicar. Next.js proporciona la arquitectura sobre la que desarrollas interfaces y aplicaciones personalizadas con React. Puedes utilizarlos de forma independiente o conectarlos, pero sus responsabilidades de partida son diferentes.
La documentación oficial define Next.js como un framework de React para crear aplicaciones web full-stack. Sobre los componentes de React añade capacidades relacionadas con routing, obtención de datos, renderizado, caché, revalidación y ejecución del lado servidor (Next.js, 2026).
Eso significa que Next.js te entrega piezas para construir el sistema, pero no un departamento editorial empaquetado dentro del proyecto. Si quieres que una persona de marketing gestione páginas, campos, imágenes, autores, taxonomías y permisos, tendrás que desarrollar esas capacidades o conectar un CMS.
WordPress empieza desde el extremo contrario. Su backend está preparado alrededor del contenido y mantiene elementos como administración, biblioteca multimedia, usuarios y estructura editorial. En una instalación tradicional, el propio CMS participa además en la generación del frontend (WordPress VIP, 2026).
WordPress vs Next.js · punto de partida
Dos enfoques distintos para construir y gestionar una web
WordPress parte de un sistema de gestión de contenidos preparado para publicar, mientras que Next.js proporciona una base de desarrollo sobre la que se construyen la interfaz, la lógica y las integraciones necesarias para cada proyecto.
| WordPress | Next.js |
|---|---|
| CMS completo. | Framework de desarrollo. |
| Panel editorial incluido. | Interfaz desarrollada a medida. |
| Centrado en gestión de contenido. | Centrado en lógica e interacción. |
| Ecosistema de plugins. | Integraciones mediante código y paquetes. |
| Publicación inmediata desde el panel. | Ciclo de desarrollo configurable. |
| Mayor autonomía editorial de partida. | Mayor control sobre la aplicación. |
La diferencia principal está en el punto de partida: WordPress integra desde el inicio la gestión editorial, mientras que Next.js ofrece una base de desarrollo más abierta para construir el comportamiento de la aplicación. Compararlos solo por velocidad o tecnología deja fuera una parte importante de la decisión.
La pregunta que aclara casi toda la discusión
Antes de abrir una hoja de cálculo con veinte criterios, plantéate esto:
¿Dónde está la complejidad de tu proyecto: en el contenido o en el comportamiento?
Si necesitas publicar, actualizar, clasificar, revisar, programar y relacionar cientos o miles de contenidos, el problema principal es editorial. El software debe facilitar que las personas gestionen información sin tratar cada actualización como una nueva versión de una aplicación.
En cambio, puedes tener un proyecto con quince pantallas y una complejidad de ingeniería considerable. Piensa en usuarios autenticados que consultan datos privados, cálculos en tiempo real, estados persistentes, integraciones con APIs, permisos diferentes y dashboards personalizados. La cantidad de páginas es pequeña; el comportamiento del sistema no lo es.
Regla mental · CMS frente a framework
Una forma sencilla de pensar qué tipo de arquitectura necesitas
En lugar de empezar preguntando qué tecnología es mejor, puede resultar más útil observar dónde se concentra la complejidad real del proyecto: en la gestión editorial o en el comportamiento de la aplicación.
Complejidad editorial alta
Mucho contenido, publicación frecuente, múltiples editores o necesidad de gestionar la web desde un panel.
Complejidad de comportamiento alta
Lógica propia, interacciones avanzadas, flujos personalizados o comportamiento de aplicación.
Algunos proyectos necesitan al mismo tiempo una gestión editorial potente y un comportamiento de aplicación complejo. Ahí empieza a tener sentido estudiar arquitecturas desacopladas, en las que la gestión del contenido y la capa de presentación pueden resolverse por separado.
Úsalo como orientación, no como regla rígida: la complejidad editorial empuja hacia soluciones con capacidades de CMS, mientras que la complejidad funcional aumenta el valor de un framework de aplicación. Si ambas son elevadas, la arquitectura puede necesitar combinar los dos enfoques.
Qué criterios deberían decidir realmente entre WordPress y Next.js
Qué debes saber: SEO, velocidad y precio importan, pero rara vez bastan para escoger una arquitectura. Deberías evaluar quién publicará, cuánto cambia el contenido, qué lógica ejecutará la interfaz, qué sistemas externos intervienen, cuánto desarrollo permanente puedes asumir y cómo esperas que sea la plataforma dentro de tres años.
Una comparativa de WordPress vs Next.js centrada exclusivamente en PageSpeed es técnicamente pobre. Puedes construir un WordPress rápido y un Next.js torpe; también puede ocurrir lo contrario. WordPress VIP recuerda que desacoplar un CMS no produce automáticamente mejores tiempos de carga, porque entran en juego APIs, estrategia de caché, renderizado, JavaScript y capacidad del equipo de ingeniería (WordPress VIP, 2026).
Lo mismo sucede con el SEO. Un framework no recibe puntos extra por llevar React en la camiseta, y un CMS no posiciona por arte de magia porque instales un plugin. La indexabilidad, la estructura HTML, los metadatos, el contenido, los enlaces, el rendimiento y los Core Web Vitals dependen de decisiones concretas de implementación.
Utiliza una matriz más cercana a esta:
WordPress vs Next.js · matriz de decisión
Las preguntas que realmente ayudan a decidir entre WordPress y Next.js
La tecnología debería responder al funcionamiento real del proyecto. Frecuencia editorial, autonomía del equipo, lógica propia, usuarios, integraciones, mantenimiento y evolución futura aportan más información que comparar únicamente rendimiento o popularidad.
| Criterio | Pregunta que deberías hacerte | Señal hacia WordPress | Señal hacia Next.js |
|---|---|---|---|
| Frecuencia editorial | ¿Publicas continuamente? | Alta. | Baja o media. |
| Edición | ¿Marketing debe cambiar páginas? | Muy relevante. | Requiere CMS o desarrollo. |
| Lógica | ¿La web ejecuta procesos propios? | Limitada o convencional. | Alta. |
| Usuarios | ¿Hay cuentas y áreas privadas complejas? | Posible. | Encaja de forma natural. |
| Personalización | ¿Cada usuario ve datos distintos? | Requiere planificación. | Muy habitual. |
| APIs | ¿Consumes varios servicios externos? | Posible. | Parte natural de la arquitectura. |
| Mantenimiento | ¿Quién actualizará el sistema? | Perfiles WordPress. | Equipo de desarrollo. |
| Presupuesto inicial | ¿Quieres reducir desarrollo personalizado? | Puede favorecerlo. | Suele exigir más ingeniería. |
| Coste a tres años | ¿Cuánto soporte permanente necesitas? | Depende del ecosistema elegido. | Depende del código y la infraestructura. |
| Cambio de proveedor | ¿Otro equipo entenderá el proyecto? | Depende de plugins y personalizaciones. | Depende de arquitectura y documentación. |
| Evolución | ¿La web terminará siendo producto? | Puede quedarse corta. | Pensado para crecer como aplicación. |
| SEO / CWV | ¿Existe capacidad técnica para optimizar? | Depende de implementación. | Depende de implementación. No diferencia por sí solo ambas opciones |
Busca patrones, no una suma de puntos: si la mayoría de tus necesidades están relacionadas con publicación, autonomía editorial y menor desarrollo personalizado, la arquitectura tenderá en una dirección. Si predominan lógica propia, personalización, integraciones y evolución hacia producto, tenderá en otra. Algunos criterios —como SEO o Core Web Vitals— dependen principalmente de cómo se implemente cada solución.
Un selector rápido de arquitectura
WordPress vs Next.js · matriz de decisión
Las preguntas que realmente ayudan a decidir entre WordPress y Next.js
La tecnología debería responder al funcionamiento real del proyecto. Frecuencia editorial, autonomía del equipo, lógica propia, usuarios, integraciones, mantenimiento y evolución futura aportan más información que comparar únicamente rendimiento o popularidad.
| Criterio | Pregunta que deberías hacerte | Señal hacia WordPress | Señal hacia Next.js |
|---|---|---|---|
| Frecuencia editorial | ¿Publicas continuamente? | Alta. | Baja o media. |
| Edición | ¿Marketing debe cambiar páginas? | Muy relevante. | Requiere CMS o desarrollo. |
| Lógica | ¿La web ejecuta procesos propios? | Limitada o convencional. | Alta. |
| Usuarios | ¿Hay cuentas y áreas privadas complejas? | Posible. | Encaja de forma natural. |
| Personalización | ¿Cada usuario ve datos distintos? | Requiere planificación. | Muy habitual. |
| APIs | ¿Consumes varios servicios externos? | Posible. | Parte natural de la arquitectura. |
| Mantenimiento | ¿Quién actualizará el sistema? | Perfiles WordPress. | Equipo de desarrollo. |
| Presupuesto inicial | ¿Quieres reducir desarrollo personalizado? | Puede favorecerlo. | Suele exigir más ingeniería. |
| Coste a tres años | ¿Cuánto soporte permanente necesitas? | Depende del ecosistema elegido. | Depende del código y la infraestructura. |
| Cambio de proveedor | ¿Otro equipo entenderá el proyecto? | Depende de plugins y personalizaciones. | Depende de arquitectura y documentación. |
| Evolución | ¿La web terminará siendo producto? | Puede quedarse corta. | Pensado para crecer como aplicación. |
| SEO / CWV | ¿Existe capacidad técnica para optimizar? | Depende de implementación. | Depende de implementación. No diferencia por sí solo ambas opciones |
Busca patrones, no una suma de puntos: si la mayoría de tus necesidades están relacionadas con publicación, autonomía editorial y menor desarrollo personalizado, la arquitectura tenderá en una dirección. Si predominan lógica propia, personalización, integraciones y evolución hacia producto, tenderá en otra. Algunos criterios —como SEO o Core Web Vitals— dependen principalmente de cómo se implemente cada solución.
El coste de cambiar una landing
Imagina una situación nada exótica: marketing quiere modificar una landing, publicar tres artículos y crear una página para un nuevo servicio.
En un WordPress correctamente preparado con bloques y componentes reutilizables, una parte importante del trabajo puede resolverse desde el panel. Publicar deja de depender del ciclo de ingeniería, y el equipo editorial conserva capacidad de actuación.
En un proyecto Next.js donde el contenido vive dentro del repositorio o los componentes están codificados directamente, la misma petición puede generar un ticket, una rama de Git, modificación del componente, revisión, pruebas, merge, build y deployment. No hay nada técnicamente incorrecto en ese proceso. El problema aparece cuando aplicas un flujo propio del desarrollo de software a tareas editoriales rutinarias.
Si Next.js está conectado a un CMS adecuado, la ecuación cambia. Por eso no deberías interpretar “Next.js” como sinónimo de “todo se edita mediante código”.
La deuda técnica aparece en las dos direcciones
WordPress puede sufrir cuando empiezas a utilizar plugins como si fueran módulos improvisados de una aplicación empresarial. Cada nueva necesidad añade hooks, tablas, metadatos, dependencias y comportamientos que inicialmente parecían pequeños. Llega un momento en el que el CMS sigue funcionando, pero el sistema se ha convertido en una criatura que requiere conocer quince plugins antes de atreverse a tocar una línea.
Next.js puede sufrir el problema contrario. Una web corporativa con páginas de servicios y un blog termina necesitando desarrolladores para modificar elementos que en un CMS serían operaciones editoriales corrientes.
La arquitectura incorrecta genera deuda técnica por exceso de ingeniería o por intentar estirar una herramienta más allá de su zona cómoda.
¿Y si tu proveedor desaparece dentro de dos años?
Esta pregunta suele ser bastante más útil que preguntar qué framework está de moda.
Deberías revisar:
- quién controla el dominio, hosting, repositorio y cuentas;
- cómo está documentado el despliegue;
- qué plugins o paquetes son privados;
- dónde se almacena el contenido;
- qué dependencias externas utiliza el sistema;
- cuánto conocimiento existe únicamente en la cabeza del desarrollador original;
- si otro equipo puede reconstruir el entorno de desarrollo;
- cómo se realizan copias, actualizaciones y recuperaciones.
En WordPress, un desarrollo demasiado dependiente de plugins privados puede generar bloqueo. En Next.js, una aplicación con arquitectura peculiar, escasa documentación y despliegues artesanales puede producir exactamente el mismo efecto con distinto sabor tecnológico.
El viejo principio UNIX de construir sistemas comprensibles sigue funcionando bastante bien unas cuantas décadas después.
Qué proyectos deberían construirse alrededor de WordPress o de otro CMS
Veredicto técnico: Un CMS suele encajar mejor cuando el trabajo diario consiste en crear, revisar, ordenar y publicar información. Podrías programar esas capacidades sobre Next.js, pero reconstruir herramientas editoriales maduras mediante código personalizado añade trabajo que únicamente compensa cuando existen necesidades específicas que lo justifican.
Aquí merece la pena separar “se puede construir” de “tiene sentido construirlo así”. Con suficiente presupuesto puedes desarrollar casi cualquier plataforma sobre un framework moderno. También podrías escribir tu propio servidor HTTP desde cero; que sea posible no significa que debas celebrar esa idea en la reunión de planificación.
Caso 1. Medio digital, revista o portal informativo
Piensa en un periódico, una revista especializada o un portal con varios redactores. El sistema tendrá entradas, autores, categorías, imágenes, borradores, revisiones, permisos, programación, histórico y relaciones entre contenidos.
El problema de ingeniería que más pesa no está en dibujar la tarjeta de una noticia en React. Está en proporcionar un entorno donde muchas personas puedan producir y mantener información sin pisarse entre ellas.
WordPress VIP destaca precisamente que WordPress tradicional conserva edición, vistas previas, roles y flujos editoriales que pueden requerir reconstrucción cuando el frontend se desacopla (WordPress VIP, 2026).
Si varias personas trabajan diariamente dentro del panel editorial, el proyecto necesita un CMS aunque el visitante nunca sepa cuál estás utilizando.
Ese CMS puede ser WordPress, Drupal u otra plataforma especializada. La decisión concreta dependerá del modelo de contenido, la organización y los requisitos técnicos.
Caso 2. Web corporativa intensiva en contenido
Imagina una empresa con cincuenta páginas de servicios, varios sectores, casos de éxito, recursos descargables, formularios, campañas, versiones en varios idiomas y un blog activo.
Puede tener una interfaz pública visualmente sofisticada y seguir siendo, arquitectónicamente, un proyecto dominado por contenido.
Marketing necesitará crear páginas, corregir textos, lanzar campañas y sustituir recursos sin convertir cada modificación en una historia dentro del backlog de desarrollo. En este escenario, la capacidad editorial tiene un valor operativo directo.
Una buena pregunta sería:
¿Necesito código nuevo para crear contenido nuevo?
Si la respuesta es “sí” con demasiada frecuencia y la mayoría de esas modificaciones son editoriales, probablemente estás trasladando complejidad al lugar equivocado.
Caso 3. Ecommerce relativamente estándar
Un comercio electrónico basado en catálogo, carrito, promociones, pagos y gestión convencional de pedidos puede encajar perfectamente en una plataforma CMS/ecommerce como WordPress con WooCommerce.
Next.js también puede formar parte de una arquitectura de comercio electrónico, especialmente cuando existen requisitos de frontend muy personalizados. Sin embargo, al desacoplar WooCommerce aparecen responsabilidades adicionales alrededor de carrito, sesiones, checkout y compatibilidad con extensiones, según explica ACF (ACF, 2026).
Antes de sustituir un flujo ecommerce maduro por desarrollo personalizado, comprueba qué problema concreto estás intentando resolver.
Qué proyectos deberían desarrollarse como aplicación con Next.js
En pocas palabras: Next.js empieza a encajar especialmente bien cuando la interfaz forma parte del propio producto. Si el usuario inicia sesión, modifica estados, consulta información privada, ejecuta cálculos, conecta servicios o interactúa continuamente con datos dinámicos, estás más cerca de desarrollar software web que de publicar páginas.
Next.js incluye un modelo preparado para desarrollar aplicaciones React con componentes de servidor y cliente, rutas, obtención de datos, caché, revalidación y mecanismos de servidor dentro del mismo framework (Next.js, 2026).
Eso no obliga a implementar cada proyecto con la máxima sofisticación disponible. Una de las ventajas de un framework es precisamente poder elegir qué necesita cada ruta en lugar de tratar todas las páginas de la misma manera.
Caso 1. SaaS con dashboard y usuarios
Supón que desarrollas una plataforma en la que cada cliente puede:
- iniciar sesión;
- conectar varias fuentes de datos;
- consultar dashboards privados;
- configurar alertas;
- generar informes;
- administrar miembros de su organización;
- modificar preferencias;
- pagar una suscripción.
Aquí empiezas a trabajar con autenticación, permisos, estado de aplicación, datos específicos de cada usuario, operaciones de lectura y escritura, APIs y navegación propia de software interactivo.
La diferencia conceptual puede resumirse en una frase:
El problema principal ya no consiste en publicar contenido, sino en ejecutar software a través del navegador.
Intentar resolver ese núcleo funcional ensamblando plugins de WordPress puede funcionar durante una primera fase en algunos proyectos. A medida que la lógica de negocio se vuelve específica, resulta más difícil razonar sobre el sistema, probarlo y evolucionarlo.
En una aplicación Next.js, esa lógica puede organizarse como software desde el principio: componentes, tipos, servicios, validaciones, tests, control de versiones y pipelines de despliegue.
Caso 2. Plataforma altamente interactiva
Piensa ahora en un configurador industrial donde el usuario selecciona componentes y el sistema calcula compatibilidades, o en un simulador financiero que modifica resultados al cambiar decenas de parámetros.
El mismo patrón aparece en:
- comparadores inmobiliarios avanzados;
- marketplaces con flujos específicos;
- plataformas logísticas;
- herramientas de reservas complejas;
- sistemas de planificación;
- productos de analítica;
- portales con información altamente personalizada.
El usuario filtra, guarda, calcula, compara, crea alertas y consulta servicios externos. La interfaz deja de ser un envoltorio para contenido y se convierte en parte del motor del producto.
Aunque técnicamente pudieras programar estos comportamientos sobre WordPress, Next.js u otro framework de aplicación suele proporcionar una base más coherente para modelarlos.
WordPress o Next.js tampoco decide el rendimiento por ti
Que Next.js pueda utilizar distintas estrategias de renderizado no significa que cualquier aplicación vaya a obtener buenos Core Web Vitals.
La documentación de ACF insiste en que el rendimiento de una arquitectura desacoplada depende de cómo se renderiza y cachea el contenido. Un frontend mal configurado puede perder frente a un WordPress tradicional correctamente optimizado (ACF, 2026).
Desde el punto de vista técnico, cómo elegir entre WordPress y Next.js según el tipo de proyecto web exige separar capacidad de resultado. Una herramienta puede ofrecer SSG, renderizado de servidor o revalidación; después alguien tiene que diseñar el sistema correctamente.
El compilador tampoco arreglaba un algoritmo malo en C, y cuarenta años después seguimos sin haber inventado un framework capaz de salvar todas las decisiones arquitectónicas.
Cómo decidir entre WordPress, Next.js o WordPress headless + Next.js
Idea final: WordPress tradicional encaja cuando domina la publicación; Next.js resulta natural cuando domina la lógica de aplicación; una arquitectura WordPress headless + Next.js puede tener sentido cuando necesitas conservar un CMS potente y entregar el contenido mediante un frontend independiente que justifique esa complejidad adicional.
La elección deja de ser binaria cuando introduces un CMS desacoplado.
WordPress dispone de una REST API que permite a aplicaciones externas consultar y gestionar información mediante JSON. La propia documentación explica que esta interfaz puede utilizarse para construir experiencias frontend independientes del tema tradicional (WordPress.org, 2024).
Arquitectura desacoplada · flujo básico
Cómo se conectan el equipo editorial, el CMS y Next.js
En una arquitectura desacoplada, el equipo editorial puede seguir trabajando sobre un CMS mientras la capa pública se desarrolla de forma independiente. La API actúa como conexión entre ambos entornos.
La clave del desacoplamiento está en separar responsabilidades: el CMS conserva la gestión editorial y Next.js controla la capa pública de la aplicación. La API permite que ambas partes intercambien la información necesaria sin obligarlas a funcionar como un único sistema monolítico.
WordPress sigue encargándose del contenido, mientras Next.js controla la presentación y el comportamiento del frontend.
Opción 1 — WordPress tradicional
Suele tener sentido cuando predominan:
- contenido y publicación;
- edición frecuente;
- autonomía del equipo de marketing;
- funcionalidades web conocidas;
- necesidad de lanzar sin construir un frontend separado;
- mantenimiento asumible por perfiles especializados en WordPress.
Opción 2 — Next.js
Empieza a encajar cuando predominan:
- lógica propia;
- interacción;
- usuarios;
- datos dinámicos;
- APIs;
- personalización;
- comportamiento de aplicación;
- equipo técnico capaz de mantener código, infraestructura y despliegues.
Opción 3 — WordPress headless + Next.js
Puede resultar adecuada cuando necesitas capacidades editoriales de WordPress y existe una razón técnica concreta para desacoplar el frontend.
Por ejemplo, puedes tener un gran equipo de contenido y, al mismo tiempo, una experiencia pública con requisitos de presentación muy personalizados o distribución hacia varias interfaces.
Aquí aparece el precio arquitectónico. ACF señala que pasar a headless implica mantener la capa WordPress y el frontend JavaScript, mientras algunas extensiones ligadas al tema dejan de trasladarse directamente a la experiencia pública (ACF, 2026).
WordPress VIP añade que las vistas previas, determinadas funciones editoriales y parte de la instrumentación pueden requerir trabajo adicional de ingeniería después del desacoplamiento (WordPress VIP, 2026).
En otras palabras: headless no es el modo “pro” de WordPress. Es otra arquitectura.
Matriz práctica por tipo de proyecto
Tipo de proyecto · adecuación arquitectónica
Qué arquitectura suele encajar según el tipo de proyecto
Un blog, una web corporativa, un SaaS o un marketplace no plantean el mismo problema técnico. Esta matriz permite comparar de forma orientativa cuándo WordPress, Next.js o una arquitectura desacoplada pueden tener más sentido según el peso del contenido y de la lógica de aplicación.
| Proyecto | WordPress | Next.js | CMS + Next.js |
|---|---|---|---|
| Blog profesional | Recomendado Edición y publicación dominan el proyecto. | Poco adecuado Puede añadir desarrollo innecesario sin CMS. | Viable Útil si existen requisitos especiales de frontend. |
| Medio digital | Recomendado Flujos editoriales y múltiples autores. | Poco adecuado Necesitaría una capa editorial adicional. | Recomendado en ciertos escenarios Cuando el desacoplamiento está justificado. |
| Web corporativa | Recomendado Marketing puede operar con autonomía. | Viable Mejor con CMS cuando cambia mucho el contenido. | Viable Mayor complejidad operativa. |
| Ecommerce estándar | Recomendado Ecosistema comercial ya resuelto. | Viable Interesante con necesidades personalizadas. | Viable Exige reconstruir parte de la experiencia pública. |
| SaaS | Poco adecuado La lógica domina sobre la publicación. | Recomendado Arquitectura orientada a aplicación. | Poco adecuado El CMS rara vez es el núcleo funcional. |
| Dashboard | Poco adecuado | Recomendado | Poco adecuado |
| Marketplace complejo | Poco adecuado | Recomendado | Viable si existe una capa editorial relevante |
| Configurador | Poco adecuado | Recomendado | Viable en proyectos híbridos |
| Contenido + aplicación | Viable | Recomendado para la aplicación | Recomendado si el CMS tiene peso real |
La matriz describe patrones de proyecto, no reglas universales: el mismo tipo de web puede necesitar una arquitectura distinta si cambian el volumen editorial, la lógica propia, las integraciones o el equipo que deberá mantenerla. Úsala para acotar opciones y después contrasta los requisitos concretos del proyecto.
La matriz es orientativa. Un ecommerce puede requerir una aplicación completamente personalizada, y una plataforma aparentemente compleja puede tener requisitos que un CMS resuelva con elegancia. La arquitectura se decide con requisitos, no mirando el logotipo de la tecnología.
¿WordPress, Next.js o arquitectura headless?
Antes de cerrar una decisión, responde estas diez preguntas:
- ¿Publicarás contenido nuevo todas las semanas?
- ¿Marketing necesita crear o modificar páginas sin desarrolladores?
- ¿Habrá usuarios autenticados con información diferente?
- ¿La interfaz procesa o transforma datos?
- ¿Necesitas integrar varias APIs o sistemas internos?
- ¿El producto incluye dashboards o herramientas interactivas?
- ¿Dispones de desarrolladores de forma permanente?
- ¿Esperas que la web evolucione hacia una aplicación?
- ¿Necesitas controlar completamente el frontend?
- ¿Puedes mantener dos capas tecnológicas si eliges headless?
Si la mayoría de tus respuestas apuntan a edición, publicación y autonomía, WordPress o un CMS equivalente merece mucha atención.
Si dominan la lógica, el estado, los usuarios y las integraciones, Next.js empieza a encajar con bastante naturalidad.
Si tienes un volumen editorial considerable y al mismo tiempo necesitas un frontend independiente por razones concretas, puedes evaluar CMS + Next.js. WordPress VIP recomienda analizar la capacidad del equipo, los flujos editoriales, el gobierno del contenido y los costes de operación antes de desacoplar (WordPress VIP, 2026).
Esta checklist orienta; no sustituye un análisis de arquitectura.
Decide dónde quieres pagar la complejidad
La pregunta cómo elegir entre WordPress y Next.js según el tipo de proyecto web tiene una respuesta bastante menos espectacular que cualquier guerra de frameworks: identifica primero qué hace realmente el sistema.
Si tu activo digital vive de publicar y mantener información, el CMS elimina una enorme cantidad de trabajo que no merece la pena reconstruir. Si el navegador está ejecutando un producto con lógica, usuarios, datos y comportamiento personalizado, un framework de aplicación ofrece un terreno más coherente para desarrollar.
Y cuando necesitas las dos cosas, puedes desacoplar. Eso sí: separar frontend y CMS significa que alguien tendrá que mantener la frontera entre ambos. Las APIs son fantásticas, pero siguen sin alimentarse solas después de medianoche.
Antes de decidir tecnología, responde tres preguntas:
¿Quién publicará, qué hará realmente el usuario y qué necesitará la web dentro de tres años?
Normalmente te llevarán bastante más lejos que preguntar simplemente: “¿WordPress o Next.js es más rápido?”.
Referencias consultadas:
- Advanced Custom Fields. (2026, 12 de mayo). What is Headless WordPress and is it worth it?
- Ludington, J. (2026, 23 de marzo; actualizado el 29 de septiembre de 2026). When WordPress shouldn’t be headless: Evaluating Headless WordPress tradeoffs before you decouple your CMS. WordPress VIP.
- Next.js. (2026). Next.js documentation. Vercel.
- WordPress.org. (2024, 16 de enero). REST API Handbook. WordPress Developer Resources.
