Un cliente me llamó en 2021 — inmobiliaria, presupuesto decente, acababa de despedir a su agencia anterior. El encargo era simple: reconstruir su portal de listados. El desarrollador saliente había pasado ocho meses estructurando una aplicación Next.js personalizada. Se veía brillante en las demostraciones. Nadie en su equipo podía actualizarla sin una solicitud de cambios y una canalización de despliegue. El agente inmobiliario que gestionaba los listados estaba usando una Hoja de Cálculo de Google como solución provisional.
Lo reconstruí en WordPress con Advanced Custom Fields Pro en aproximadamente seis semanas. Desde entonces lo han estado gestionando ellos mismos.Advanced Custom Fields Proin about six weeks. They've been managing it themselves ever since.
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. También he hecho lo contrario — entregué a un cliente un multisitio de WordPress cuando necesitaban una aplicación adecuada impulsada por React, y la observé rechinar bajo la presión dieciocho meses después.
Después de construir más de 5,000 sitios en Seahawk Media, he dejado de preocuparme por cuál framework "gana". Me preocupa cuál se lanza, funciona bien, y no vuelve a atormentarte a las 11 de la noche un domingo.Seahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
El estado honesto de ambas tecnologías en este momento
WordPress potencia algo más del 43% de la web completa. Ese número se repite tan frecuentemente que ha perdido significado, pero detente un segundo a pensarlo. 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 integrado 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ó la forma en que 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 por 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 contenidos, o alguien que necesita publicar sin tocar código — WordPress casi siempre es la respuesta correcta. El editor Gutenberg, ya sea que lo ames u odies (he tenido una relación complicada con él desde 2018), le da a usuarios no técnicos una experiencia de edición basada en bloques que realmente funciona.anyonewho needs to publish without touching code — WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
Nada en el ecosistema React se acerca a la experiencia editorial de WordPress lista para usar. Sanity.io tiene un estudio hermoso, Contentful es sólido para contenido estructurado — pero ninguno tiene el ecosistema de plugins o la familiaridad con los motores de búsqueda que tiene WordPress. El contratista 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. No son solo plugins — son plataformas completas con sus propios ecosistemas. Cuando Seahawk hace un proyecto de comercio electrónico 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 funciona sin problemas. Estamos hablando de tiempos de carga menores a 2 segundos después del caché, gestión completa de inventario, recuperación de carritos abandonados, integración con Stripe — todo configurado en una tarde.Kinstaor WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration — all configured in an afternoon.
¿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 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 mantenerse 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 panel de control para una firma de análisis crediticio. Feeds de datos en tiempo real, filtrado complejo, control de acceso basado en roles, integraciones de API con tres proveedores de datos diferentes. Miré WordPress headless durante unas dos horas antes de admitir que era la herramienta completamente equivocada. Lo construimos en Next.js con NextAuth.js para autenticación y React Query para 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 de múltiples pasos con lógica condicional que se alimenta en APIs externas, paneles en tiempo real, cualquier cosa que requiera estado del lado del cliente de grano fino — termino peleándome 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 en 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.explains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
Experiencia del Desarrollador y Composición del Equipo
Si eres una agencia con un equipo de desarrollo nativo en React, el desarrollo en WordPress tiene una curva de aprendizaje real que a menudo se subestima. PHP, la jerarquía de plantillas de WordPress, la arquitectura de hooks, el agujero de conejo de functions.php — no es difícil, pero es diferente. He contratado desarrolladores de JS talentosos que miraron una base de código de tema WordPress y se sintieron perdidos las primeras dos semanas.functions.phprabbit hole — it's not hard, but itisdifferent. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
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 llegado al "WordPress headless" como un compromiso — WordPress como backend CMS, Next.js como frontend. El argumento 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 casos buenos:goodcases:
- 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:actual problems:
- WPGraphQL es excelente, pero depurar el rendimiento de consultas GraphQL en un contexto WordPress es doloroso. Estás agregando una capa de complejidad que puede causarte problemas.is excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- La funcionalidad de vista previa para editores — ver un post en borrador en el frontend de Next.js — es una fuente constante de errores. 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 señales de alerta que deberían hacerte pausar sin importar hacia dónde te inclinas:red flagsthat should make you pause regardless of which direction you're leaning:
- Un cliente que exige 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 construido correctamente — rutinariamente obtiene 90+ en PageSpeed Insights. Seahawk ha entregado sitios WordPress de 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 Google sobre Core Web Vitals muestra que la tecnología de origen importa mucho menos que la calidad de 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.Google's own Core Web Vitals researchshows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times — none of which are inherently WordPress or Next.js problems.
Lo que Next.js 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.more controlover performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
SEO: WordPress Tiene la Ventaja del Ecosistema, No la Ventaja Inherente
Aquí hay una idea equivocada que tengo que corregir regularmente: WordPress no es inherentemente mejor para SEO. Las aplicaciones Next.js con renderizado del lado del servidor 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.<Head>component, sitemap generation vianext-sitemap, structured data via JSON-LD — it's all achievable.
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, Next.js SEO no es más difícil de implementar. Si el sitio necesita un consultor de SEO o gerente de marketing que ajuste títulos de página sin abrir un ticket — usa 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 sucedido 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 sigue invirtiendo fuertemente en Gutenberg y la experiencia de Full Site Editing. Está evolucionando, solo no de maneras que hagan emocionarse a los feeds de Twitter.
¿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 tarda 40–60% más en construirse 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 de 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 basándote 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.