Un cliente me llamó en 2021, una inmobiliaria, presupuesto decente, acababa de despedir a su agencia anterior. El brief era simple: reconstruir su portal de listados. El desarrollador que se iba había pasado ocho meses armando una aplicación Next.js hecha a medida. Se veía brillante en demostraciones. No podía ser actualizada por una sola persona en su equipo sin un pull request y un pipeline de despliegue. El agente inmobiliario que manejaba los listados estaba usando una hoja de Google como solución temporal.
Conclusión clave: WordPress gana cuando los editores necesitan autonomía y el contenido cambia diariamente; Next.js gana cuando el sitio es un producto con ingeniería detrás. El equipo decide, no el framework.
Lo reconstruí en WordPress con Advanced Custom Fields Pro en aproximadamente seis semanas. Ellos lo han estado gestionando por su cuenta desde entonces.
Esa historia no es un argumento en contra de Next.js. Es un argumento en contra de elegir una herramienta antes de haber entendido el problema. Yo también he hecho lo inverso, le entregué a un cliente un multisitio WordPress cuando necesitaba una aplicación impulsada por React, y la vi crujir bajo la presión dieciocho meses después.
Después de construir más de 12,000 sitios en Seahawk Media, dejé de preocuparme por cuál framework "gana". Me importa cuál se entrega, funciona bien, y no vuelve a perseguirte a las 11pm un domingo.
---
El estado honesto de ambas tecnologías en este momento
WordPress impulsa algo más del 43% de toda la web. Ese número se lanza tan a menudo que ha perdido significado, pero piénsalo un segundo. Cuarenta y tres por ciento. Eso no es inercia heredada, es efecto de red, ecosistema de plugins, infraestructura de hosting, y dos décadas de conocimiento institucional integrados en cada servidor compartido del planeta.
Next.js, mientras tanto, se ha convertido en el framework React dominante para aplicaciones en producción. Los datos de uso de Vercel de 2023 mostraron que procesa cientos de miles de millones de solicitudes al mes. El App Router introducido en Next.js 13 cambió cómo la gente piensa sobre componentes de servidor, y sí, también rompió muchos tutoriales publicados antes de 2023, lo que sigue causando confusión en servidores de Discord en todas partes.
Pero aquí está la cosa: estas dos tecnologías en realidad no son competidores de la manera en que los argumentos de Twitter las hacen parecer. WordPress es un CMS con una capa de temas. Next.js es un framework React con integración CMS opcional. El diagrama de Venn de en qué son realmente buenos tiene muy poco solapamiento una vez que especificas los requisitos.
---
Dónde WordPress Es Realmente Imbatible
Sitios Pesados en Contenido Administrados por No-Desarrolladores
Seré directo. Si tu cliente tiene un equipo de marketing, un gestor de contenido, o alguien que necesite publicar sin tocar código, WordPress es casi siempre la respuesta correcta. El editor Gutenberg, ya lo ames o lo odies (he tenido una relación complicada con él desde 2018), ofrece a usuarios no técnicos una experiencia de edición basada en bloques que realmente funciona.
Nada en el ecosistema React se acerca a la experiencia editorial de WordPress de inmediato. Sanity.io tiene un estudio hermoso, Contentful es sólido para contenido estructurado, pero ninguno tiene el ecosistema de plugins o la familiaridad con buscadores que WordPress tiene. El contratante de marketing promedio ha usado WordPress antes. No han usado un CMS headless.
Profundidad del Ecosistema de Plugins
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Estos no son solo plugins, son plataformas completas con sus propios ecosistemas. Cuando Seahawk hace un proyecto de e-commerce para un cliente con un catálogo modesto (digamos, menos de 5,000 SKUs), WooCommerce combinado con un hosting decente en Kinsta o WP Engine lo maneja bien. Estamos hablando de tiempos de carga por debajo de 2 segundos después del almacenamiento en caché, gestión completa de inventario, recuperación de carrito abandonado, integración con Stripe, todo configurado en una tarde.
¿Replicar esa funcionalidad en una construcción personalizada con Next.js, Shopify o una capa de comercio headless? Estás viendo semanas de tiempo de desarrollo y costos de mantenimiento continuo que la mayoría de clientes pymes no pueden justificar.
Realidades de Presupuesto y Cronograma
Honestamente, la mayoría de los proyectos no tienen presupuesto para una aplicación React hecha a medida. Un sitio WordPress bien construido con un tema premium como Kadence o Blocksy, ACF para estructuras de datos personalizadas, y WP Rocket para rendimiento puede entregarse en dos a cuatro semanas y ser mantenido por casi cualquiera. Eso no es una limitación, es pragmatismo.
---
Dónde Next.js Realmente Justifica su Complejidad
Interactividad y Lógica de Aplicación
Allá por 2022, Seahawk tenía un proyecto fintech, un dashboard para una firma de análisis de crédito. Feeds de datos en tiempo real, filtrado complejo, control de acceso basado en roles, integraciones API con tres proveedores de datos diferentes. Miré WordPress headless durante unas dos horas antes de admitir que era totalmente la herramienta equivocada. Lo construimos en Next.js con NextAuth.js para autenticación y React Query para la obtención de datos. Sigue funcionando, sigue siendo rápido, y la base de código es algo a lo que el equipo interno del cliente puede realmente contribuir.
WordPress técnicamente puede hacer cosas tipo aplicación. Pero cada vez que he intentado llevarlo a territorio genuinamente dinámico, piensa en formularios multistep con lógica condicional alimentando APIs externas, dashboards en tiempo real, cualquier cosa que requiera estado client-side de grano fino, termino luchando contra la arquitectura en lugar de trabajar con ella.
Rendimiento a Escala Sin Dependencia de Plugins
Next.js con Static Site Generation (SSG) o Incremental Static Regeneration (ISR) puede producir páginas que son casi vergonzosamente rápidas. Sin plugins de caché requeridos. Sin diales de configuración de WP Rocket. Las páginas son simplemente... HTML estático con hidratación donde lo necesitas.
La documentación de Vercel sobre ISR explica bien el mecanismo, pero la implicación práctica es esta: un sitio Next.js para una publicación de noticias con 50,000 artículos puede revalidar páginas individuales según un cronograma sin reconstruir todo el sitio. Eso es genuinamente poderoso y algo que WordPress solo puede aproximar a través de caché de fragmentos.
Experiencia del Desarrollador y Composición del Equipo
Si eres una agencia con un equipo de desarrollo React, el desarrollo en WordPress tiene una curva de aprendizaje real que a menudo se subestima. PHP, la jerarquía de plantillas de WordPress, arquitectura de hooks, el agujero de conejo de functions.php, no es difícil, pero es diferente. He contratado desarrolladores JS talentosos que miraban una base de código de tema WordPress y se sentían perdidos las primeras dos semanas.
A la inversa, si tu equipo vive en TypeScript y React, un proyecto Next.js con un CMS headless como Contentful o Sanity es un entorno más cómodo. El código es testeable, los tipos son explícitos, y el flujo de implementación a través de Vercel o Netlify es genuinamente bueno.
---
El Término Medio de WordPress Headless (Y Sus Problemas Reales)
Muchas agencias han optado por "WordPress headless" como un compromiso, WordPress como backend CMS, Next.js como frontend. El pitch suena perfecto. El equipo editorial mantiene su interfaz familiar; los desarrolladores obtienen un stack frontend moderno.
¿En la práctica? Es genuinamente útil en situaciones específicas y un verdadero dolor de cabeza en otras.
Los buenos casos:
- Plataformas grandes de publicación donde el flujo editorial es innegociable pero el rendimiento del frontend también es un requisito crítico
- Organizaciones ya invertidas en infraestructura WordPress que quieren modernizar el frontend sin reentrenar a los equipos de contenido
- Sitios con relaciones de contenido complejas que se benefician del modelado de datos de ACF pero necesitan React para la capa de visualización
Los problemas reales:
- WPGraphQL es excelente, pero depurar el rendimiento de consultas GraphQL en un contexto WordPress es complicado. Estás agregando una capa de complejidad que puede causarte problemas.
- La funcionalidad de preview para editores, ver un borrador de post en el frontend de Next.js, es una fuente constante de bugs. He desperdiciado días en esto en múltiples proyectos.
- Alojar dos sistemas separados significa dos puntos de falla separados, dos conjuntos de costos de infraestructura, y dos pipelines de despliegue que mantener.
- Las características en tiempo real siguen siendo incómodas. No estás consiguiendo WebSockets de una API REST de WordPress sin trabajo adicional significativo.
WordPress headless no es un punto medio mágico. Es una tercera opción con sus propios trade-offs, y solo tiene sentido cuando los requisitos específicos justifican genuinamente la complejidad.
---
Cómo Realmente Tomo la Decisión (Mi Lista Actual)
Después de suficientes proyectos, lo he reducido a un conjunto rápido de preguntas que hago antes de la segunda llamada con el cliente.
Inclinarme por WordPress cuando:
- El cliente o su equipo necesita gestionar contenido de forma independiente
- El proyecto es principalmente páginas de contenido y marketing (incluso complejas)
- El presupuesto es menor a £20K y el cronograma es menor a ocho semanas
- Se necesita comercio electrónico pero el catálogo tiene menos de ~10,000 productos
- El cliente ya está en WordPress y migrar no tiene un propósito real
Inclinarme por Next.js cuando:
- El proyecto tiene requisitos significativos interactivos o similares a una aplicación
- El equipo está compuesto principalmente por desarrolladores de JS/React
- Necesitas control granular sobre la estrategia de renderizado (SSG, SSR, ISR por ruta)
- El sistema de diseño del frontend es personalizado y está orientado a componentes React
- Hay una razón genuina para integrar un CMS headless moderno como Sanity o Contentful
- A largo plazo, el cliente quiere ser propietario y extender el frontend por cuenta propia con desarrolladores JS internos
Y algunas banderas rojas que deberían hacerte pausar sin importar hacia dónde te inclines:
- Un cliente exigiendo Next.js porque leyó que es "más moderno", eso no es un requisito.
- Elegir WordPress porque "es más fácil" cuando el proyecto genuinamente necesita lógica de aplicación
- Cualquiera que use la frase "a prueba de futuro" como justificación sin articular qué es lo que el futuro realmente requiere
---
Rendimiento: Usemos Números Reales
Aquí es donde la conversación suele descarrilarse. La gente lanza puntuaciones de Lighthouse como si fueran la historia completa.
Un sitio WordPress bien optimizado, hosting decente, WP Rocket o FlyingPress, imágenes WebP, un tema bien construido, rutinariamente puntúa 90+ en PageSpeed Insights. Seahawk ha entregado sitios WordPress en 95+ consistentemente. No es magia; es solo configuración adecuada.
Una aplicación Next.js mal configurada con obtención de datos del lado del cliente en todas partes, imágenes sin optimizar y sin una estrategia de caché adecuada obtendrá puntuaciones en los 50. Lo he visto.
La brecha entre un "sitio WordPress rápido" y un "sitio Next.js rápido" es mucho más estrecha de lo que sugieren los evangelistas del framework. La propia investigación de Core Web Vitals de Google muestra que la tecnología de origen importa mucho menos que la calidad de la implementación. Los cuellos de botella en la mayoría de sitios con mal desempeño son imágenes, recursos que bloquean el renderizado, y tiempos de respuesta del servidor, ninguno de los cuales son problemas inherentes de WordPress o Next.js.
Lo que Next.js sí ofrece genuinamente es más control sobre el rendimiento. Puedes tomar decisiones precisas por ruta sobre cómo se obtienen los datos y cuándo se renderizan las páginas. Pero el control solo te ayuda si lo ejerces correctamente.
---
SEO: WordPress Tiene la Ventaja del Ecosistema, No la Ventaja Inherente
Aquí hay una idea errónea que tengo que corregir regularmente: WordPress no es inherentemente mejor para SEO. Las apps Next.js con server-side rendering adecuado son completamente rastreables por Google. El componente <Head>, generación de sitemap vía next-sitemap, datos estructurados vía JSON-LD, todo es alcanzable.
Lo que WordPress tiene es Yoast SEO o Rank Math, que le dan a usuarios no técnicos una interfaz visual para gestionar títulos meta, descripciones, URLs canónicas y marcado de esquema. Esa es una ventaja de flujo editorial, no una técnica.
Si el sitio será gestionado por desarrolladores que entienden meta tags y datos estructurados, SEO en Next.js no es más difícil de implementar. Si el sitio necesita que un consultor SEO o gerente de marketing ajuste títulos de página sin presentar un ticket, dale WordPress.
---
FAQ
¿No es WordPress viejo y está siendo reemplazado por frameworks modernos?
WordPress ha estado "siendo reemplazado" desde al menos 2014, cuando comencé a escuchar el argumento en serio. No ha pasado y no espero que suceda. La pregunta no es si WordPress es moderno, es si resuelve el problema que tienes. Para un porcentaje enorme de sitios web, lo hace. Automattic continúa invirtiendo fuertemente en Gutenberg y la experiencia de Full Site Editing. Está evolucionando, solo no de formas que entusiasmen a las redes sociales.
¿Puedes usar WordPress como backend con un frontend React?
Sí, esto es WordPress headless, y cubrí las compensaciones arriba. La versión corta: usa WPGraphQL o la REST API para servir contenido, construye tu frontend en Next.js. Funciona. También agrega complejidad. Solo hazlo si los requisitos realmente lo exigen, no porque suene architectónicamente interesante.
¿Cuánto tiempo tarda construir un sitio Next.js comparado con WordPress?
Genuinamente depende del alcance, pero para un sitio de marketing comparable, Next.js típicamente toma 40-60% más tiempo para construir para la entrega inicial. Estás escribiendo componentes desde cero, configurando un sistema de diseño, integrando un CMS, configurando el despliegue. WordPress con un tema premium y ACF te lleva mucho más lejos, más rápido. Donde Next.js compensa la inversión de tiempo es en escalabilidad a largo plazo y ergonomía del desarrollador, siempre que la composición del equipo lo justifique.
¿Qué hay de Astro, Remix u otros frameworks?
Vale la pena saberlo. Astro es particularmente interesante para sitios estáticos con mucho contenido y he estado experimentando con él en proyectos más pequeños en Seahawk. Remix tiene un modelo de carga de datos convincente. Pero ninguno tiene la madurez del ecosistema ni la familiaridad del cliente que tiene WordPress, ni la adopción empresarial de Next.js. Para la mayoría de las decisiones de agencia ahora mismo, sigue siendo una elección entre WordPress o Next.js, con todo lo demás como una consideración de nicho.
¿Debería siempre recomendar la opción técnica "mejor" a mis clientes?
No. La mejor opción técnica que el equipo de un cliente no puede mantener es peor que la segunda mejor opción que realmente pueden usar. He aprendido esto de la manera difícil más de una vez. Entrega lo que funciona para los humanos involucrados, no solo para el diagrama de arquitectura.
---
La habilidad real no es conocer WordPress o conocer Next.js. Es saber cuándo recurrir a cada uno, y ser lo suficientemente honesto contigo mismo y con tus clientes para tomar esa decisión basada en su realidad, no en tus preferencias.
¿Ese cliente de propiedades de 2021? Todavía en WordPress. Todavía administrando sus propios listados. Sin llamadas telefónicas mías el domingo por la noche.