Un cliente me llamó en 2021 -- inmobiliaria, presupuesto decente, acababan 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 construyendo una aplicación Next.js personalizada. Se veía brillante en las demostraciones. No podía ser actualizada por una sola persona en su equipo sin un pull request y un pipeline de deployment. El agente inmobiliario que gestionaba 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.WordPress wins when editors need autonomy and content changes daily; Next.js wins when the site is a product with engineering behind it. The team decides, not the framework.
Lo reconstruí en WordPress con Advanced Custom Fields Pro en aproximadamente seis semanas. Ellos lo han estado gestionando por su cuenta desde entonces.WordPress with Advanced Custom Fields Pro in 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. He hecho lo opuesto también -- entregué a un cliente un WordPress multisitio cuando necesitaban una aplicación impulsada por React, y la vi desmoronarse 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.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 impulsa un poco más del 43% de la web entera. Ese número se repite tan seguido que ha perdido significado, pero reflexiona sobre él 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 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 en 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.Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components -- and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
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 es casi siempre la respuesta correcta. El editor Gutenberg, 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.anyone who 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 de forma inmediata. Sanity.io tiene un estudio hermoso, Contentful es sólido para contenido estructurado -- pero ninguno tiene el ecosistema de plugins o la familiaridad con motores de búsqueda que WordPress tiene. El agente de marketing promedio ha usado WordPress antes. No han usado un CMS headless.Sanity.io has a beautiful studio, Contentful is solid for structured content -- but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
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 emparejado con un hosting decente en Kinsta o WP Engine lo maneja bien. Estamos hablando de tiempos de carga menores a 2 segundos después del caché, gestión completa de inventario, recuperación de carrito abandonado, integración con Stripe -- todo configurado en una tarde.Kinsta or 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 personalizada. 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 -- eso es pragmatismo.
---
Dónde Next.js Realmente Justifica su Complejidad
Interactividad y Lógica de Aplicación
En 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. Consideré headless WordPress durante aproximadamente dos horas antes de admitir que era completamente la herramienta incorrecta. Lo construimos en Next.js con NextAuth.js para autenticación y React Query para fetching 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 similares a aplicaciones. Pero cada vez que he intentado llevarlo a territorio genuinamente dinámico — piensa en formularios de múltiples pasos con lógica condicional alimentando APIs externas, dashboards en tiempo real, cualquier cosa que requiera estado del lado del cliente de grano fino — terminé peleando 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. 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 React-native, el desarrollo en WordPress tiene una verdadera curva de aprendizaje que a menudo se subestima. PHP, la jerarquía de templates de WordPress, la arquitectura de hooks, el agujero de conejo de functions.php — no es difícil, pero es diferente. He contratado desarrolladores JS talentosos que miraron una base de código de tema WordPress y se sintieron perdidos durante las primeras dos semanas.functions.php rabbit hole -- it's not hard, but it is different. 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 optado por "headless WordPress" como un compromiso — WordPress como backend CMS, Next.js como frontend. La propuesta suena perfecta. El equipo editorial mantiene su interfaz familiar; los desarrolladores obtienen un stack de frontend moderno.
¿En la práctica? Es genuinamente útil en situaciones específicas y un verdadero dolor de cabeza en otras.
Los buenos casos:good cases:
- 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 complicado. 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 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:red flags that should make you pause regardless of which direction you're leaning:
- 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 construido adecuadamente — rutinariamente obtiene 90+ en PageSpeed Insights. Seahawk ha entregado sitios WordPress con 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 bajo rendimiento son imágenes, recursos que bloquean render, y tiempos de respuesta del servidor — ninguno de los cuales son problemas inherentemente de WordPress o Next.js.Google's own Core Web Vitals research shows 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 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.more control over 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 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.<Head>component, sitemap generation via next-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, el SEO en Next.js no es más difícil de implementar. Si el sitio necesita un consultor SEO o gerente de marketing para ajustar títulos de página sin abrir 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 sucedido y no espero que suceda. La pregunta no es si WordPress es moderno, sino 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 que no de formas que emocionen 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 en 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 verdadera habilidad 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.