NEXT.JS, ASTRO O WORDPRESS EN 2026

Next.js, Astro o WordPress es la pregunta que más me hacen fundadores y clientes de agencias. La respuesta casi nunca es la que esperan. La decisión no es framework versus framework. La decisión es intención: qué estás construyendo realmente, quién lo mantiene después del lanzamiento, y cuál es el modo de fallo que menos puedes permitirte. Una vez que esos tres son honestos, la elección del framework usualmente se elige sola.

Lo que sigue es la perspectiva del operador de doce años entregando los tres. En Seahawk Media ejecutamos WordPress, Next.js y Astro cada semana, frecuentemente en el mismo compromiso de cliente en diferentes etapas del ciclo de vida. Cada uno es software genuinamente bueno. Cada uno es la respuesta incorrecta para situaciones específicas. Esta guía es el árbol de decisión que realmente uso, no el tour de página de marketing.

Next.js

Next.js es un framework de React con una capa de renderizado en servidor, enrutamiento basado en el sistema de archivos, y un sistema de construcción que produce HTML estático, HTML renderizado en servidor, o cualquier cosa intermedia. El modelo App Router se ha estabilizado desde la versión 15, React Server Components son el valor predeterminado, y el framework es la opción dominante para proyectos React nuevos. Vercel lo distribuye, Netlify y Cloudflare lo ejecutan, y el ecosistema es vasto.

Astro

Astro es un framework enfocado en contenido que no envía JavaScript por defecto y te permite agregar componentes de React, Vue, Svelte o Solid solo donde necesites interactividad. Su punto fuerte son los sitios de contenido: páginas de marketing, blogs, documentación, sitios tipo catálogo. El modelo mental es "HTML por defecto, JS donde sea necesario", lo que invierte el supuesto de React de que todo es JavaScript hasta que se demuestre lo contrario.

WordPress (clásico y headless)

WordPress se ejecuta en PHP, vive en una base de datos MySQL, y tiene el ecosistema de plugins más grande de la web. En 2026 tiene dos modos de funcionamiento: clásico (WordPress renderiza tanto el backend como el frontend) y headless (WordPress es la API y CMS, mientras que Next.js, Astro o Nuxt manejan el renderizado). WordPress headless es lo que cierra la brecha entre el mundo de WordPress con editores y el mundo de Next.js con ingenieros.

Next.js gana en sitios con forma de producto. Específicamente: el equipo domina React, el producto tiene interactividad con estado más allá de un sitio de marketing típico, el modelo de datos es personalizado (no un blog o CMS genérico), y el equipo de ingeniería será propietario del código durante años.

Ejemplos concretos de proyectos que he enviado: un dashboard SaaS con una puerta de entrada de marketing, un marketplace con login y contenido personalizado, un sitio de una empresa de herramientas para desarrolladores con demostraciones profundamente personalizadas, una plataforma de directorio multi-tenant como HostList.io. Todos ellos se benefician de React Server Components, los primitivos de obtención de datos de Next.js, y la transición sin fisuras entre páginas de marketing estáticas y superficies de aplicaciones autenticadas bajo el mismo framework.

Donde Next.js se vuelve caro rápidamente es en sitios con mucho contenido y editores no técnicos. La integración con CMS siempre es personalizada, el flujo de trabajo editorial siempre se reconstruye, y el equipo que lo mantiene tiene que estar permanentemente dotado de personal de ingeniería. Si tu equipo editorial son tres escritores y quieres que publiquen sin intervención de ingeniería, Next.js está luchando la batalla equivocada.

Astro gana para sitios orientados al contenido con lenguaje de diseño sólido y capacidad de ingeniería para entregar componentes limpios. Específicamente: un sitio de marketing, un hub de documentación, un sitio de folleto, un portafolio, un sitio de agencia, un blog donde el rendimiento es parte de la marca. El tipo de sitio donde la experiencia del visitante es leer o escanear contenido, no interactuar con flujos con estado.

Este sitio, gautamkhorana.com, está construido en Astro. También lo están los sitios de marketing de muchas agencias lideradas por diseño y lanzamientos de productos indie en 2026. El argumento es simple: cero JavaScript por defecto significa que los puntajes de Lighthouse llegan a 100 sin esfuerzo, el modelo de contenido es markdown plano o Sanity o Supabase, y el pipeline de compilación produce HTML estático que resiste tráfico infinito en cualquier CDN. Los sitios que he entregado en Astro han tenido colectivamente cero regresiones de rendimiento desde el lanzamiento. No pocas. Cero.

Donde Astro es la opción incorrecta: cualquier cosa con estado de usuario autenticado significativo, cualquier cosa donde la complejidad del frontend supere la complejidad del contenido, cualquier cosa donde el equipo necesita moverse en idiomas React en toda la base de código. Astro es excelente en ser ligero; es la herramienta equivocada para construir un producto pesado.

WordPress gana para sitios orientados al contenido donde la experiencia del editor importa más que el rendimiento de renderización, donde el ecosistema de plugins resuelve un problema real, y donde el equipo no tendrá capacidad de ingeniería continua. El pilar /guides/wordpress/ cubre esto en detalle completo; la versión corta: si tienes editores no técnicos, la ventaja de plugins importa, y el costo total de propiedad durante tres años es la métrica decisiva, WordPress sigue siendo la respuesta correcta para la mayoría de sitios orientados al contenido.

Específicamente: sitios de folleto con actualizaciones editoriales regulares, sitios de comercio electrónico donde WooCommerce resuelve complejidad fiscal regional real, sitios de membresía donde MemberPress o Restrict Content Pro proporciona el flujo de trabajo listos para usar, sitios inmobiliarios o de bolsas de trabajo donde un plugin de nicho maneja el noventa por ciento del modelo, sitios donde el cliente explícitamente no quiere contratar a un desarrollador para cambios continuos.

WordPress headless es la arquitectura puente: mantén WordPress para la experiencia del editor y el ecosistema de plugins, pero renderiza el frontend con Next.js o Astro para rendimiento y control de diseño. Funciona en un conjunto de casos estrecho pero real.

Funciona cuando: el equipo editorial está comprometido con WordPress y no se mudará, pero el sitio de marketing es crítico en rendimiento (tráfico alto, anuncios caros, puntajes de Lighthouse sensibles a la marca). Funciona cuando el lenguaje de diseño es lo suficientemente inusual como para que la capa de tema de WordPress no pueda entregarlo, pero el modelo de contenido es genuinamente de forma WordPress (posts, pages, tipos de post personalizados, campos ACF). Funciona cuando la empresa tiene madurez editorial y madurez de ingeniería y puede contratar a ambas.

No funciona cuando: el equipo no tiene ni madurez editorial ni capacidad de ingeniería (terminas pagando el doble), el proyecto es genuinamente un sitio de folleto que se edita mensualmente, el presupuesto es lo suficientemente pequeño como para que el mantenimiento de doble stack sea inasequible. El costo honesto de ejecutar WordPress headless en 2026 es aproximadamente 1.5x a 2x el costo de ejecutar WordPress clásico durante doce meses. Asegúrate de que las ganancias de rendimiento y diseño lo justifiquen.

Dentro de Next.js específicamente, la elección de la estrategia de renderizado tiene más implicaciones de costo que la elección del framework en sí. Las cuatro opciones:

Static Site Generation (SSG)

Todas las páginas se construyen en tiempo de compilación y se sirven como HTML plano desde el CDN. La más económica, rápida y segura. La opción predeterminada correcta para sitios de marketing y blogs. La limitación es que los cambios de contenido requieren una compilación y redesplegue completos. Para sitios con menos de unos pocos miles de páginas, esto está bien. Para sitios con decenas de miles de páginas, los tiempos de compilación se convierten en el cuello de botella.

Incremental Static Regeneration (ISR)

Las páginas se generan estáticamente en tiempo de compilación, luego se revalidan bajo demanda o según una programación. El término medio para sitios de contenido a escala. El problema que la mayoría de los equipos encuentran: la facturación de ISR en Vercel es por invocación, y con 91,000 páginas con revalidación frecuente hemos visto meses de millones de eventos. Tenemos una regla explícita de "dos fusiones de producción por semana" en el sitio Deluxe Astrology precisamente porque cada fusión dispara aproximadamente seis millones de eventos de escritura ISR. ISR es una tecnología excelente con una curva de costo real a escala.

Server-Side Rendering (SSR)

Páginas renderizadas en cada solicitud. La respuesta correcta para dashboards autenticados, contenido personalizado y cualquier cosa donde el contenido de la página dependa del usuario que realiza la solicitud. El modelo de costo es por CPU por solicitud, lo que se vuelve costoso rápidamente en páginas públicas con alto tráfico. Evita SSR para páginas de marketing.

React Server Components (RSC)

El predeterminado de Next.js 15, a menudo usado en combinación con los anteriores. RSC traslada la obtención de datos al servidor y envía menos JavaScript al cliente. El modelo mental requiere algunos ajustes, pero las ganancias en rendimiento y DX son reales. La mayoría del nuevo trabajo de Next.js en 2026 debería usar RSC de forma predeterminada.

Si vas headless con Next.js o Astro, la decisión de la capa CMS es la segunda más importante después del framework. Las cinco opciones viables que evalúo en cada proyecto:

Sanity

Mi recomendación predeterminada para nuevos proyectos headless. El enfoque schema-as-code es el modelo de contenido más limpio del mercado, la experiencia del editor es genuinamente buena para editores no técnicos, y el lenguaje de consulta GROQ es más flexible que GraphQL para la mayoría de las estructuras de contenido. El precio escala razonablemente. Contrapartida: menos ecosistema de complementos que WordPress, fricción ocasional en flujos editoriales personalizados.

WordPress Headless (vía WPGraphQL o REST)

La respuesta correcta cuando la familiaridad del editor con WordPress es la restricción principal. WPGraphQL es maduro en 2026 y el stack Faust.js hace que la integración con Next.js sea directa. Costo: mantienes WordPress Y el frontend, que es la sobrecarga inherente de conectar ambos mundos.

Supabase

Mi elección cuando el modelo de contenido es más datos estructurados que prosa extensa: directorios, listados, sitios de SEO programático, cualquier cosa con forma de tabla. HostList.io corre en Supabase. Costo: Supabase es una base de datos con affordances de capa de contenido, no un CMS en sentido editorial. A los editores no les encanta.

Contentful

Opción de nivel empresarial con características sólidas de flujo de trabajo y soporte multilingüe. El precio escala rápido en los niveles superiores. Adecuado cuando el equipo tiene gobernanza de contenido formal y presupuesto para acompañarlo.

Payload, Strapi

Opciones auto-hospedadas cuando la residencia de datos o el control de costos es la preocupación principal. Ambas han madurado significativamente en 2025. Indicadas para equipos con capacidad de ingeniería que quieran ser dueños de la capa CMS.

Dónde despliegas es la tercera decisión que se compone con el tiempo. Los tres hosts viables:

Vercel

Host de Next.js de primera parte, experiencia de desarrollador más fluida, el nivel de precios más alto. El ancho de banda y las invocaciones de ISR son los levers de costo que la mayoría de equipos pasan por alto hasta que llega la factura. Genuinamente ejecutamos sitios en Vercel porque las ganancias de DX lo valen, pero la curva de costos es más pronunciada de lo que la gente espera. Presupuesta al menos el doble de tu estimación inicial en cualquier escala donde ISR esté en uso intensivo.

Netlify

Excelente para Astro y Next.js renderizado estáticamente, ligeramente menos pulido para Next.js App Router con RSC completo. El precio es más predecible que Vercel. El modelo de precios por minuto de compilación es el lever a vigilar. Este sitio se ejecuta en Netlify.

Cloudflare Pages y Workers

La mejor relación precio-rendimiento en 2026, materialmente más barato que los otros dos a escala, la red subyacente es sin rival para entrega global. Compromiso: el modelo de despliegue y la integración de Next.js es menos pulida que Vercel. Vale la pena elegir para proyectos sensibles al costo con capacidad de ingeniería para navegar los aspectos más ásperos.

Elige el framework que coincida con el equipo que lo mantendrá. Suena obvio. Es la regla más violada que veo en decisiones de framework en Seahawk.

Un equipo de tres ingenieros React no debería construir en WordPress. Un equipo de un ingeniero PHP más tres escritores no debería construir en Next.js. Un equipo de cero ingenieros y un diseñador freelance no debería construir en ninguno: Webflow, Framer, o WordPress alojado es la respuesta correcta.

El costo de un framework y equipo desajustados no se paga el primer día. Se paga durante años mientras el equipo trabaja contra el framework en lugar de con él. Alinea la tecnología con la realidad operativa.

Números reales de sitios que he lanzado o auditado en 2026, todos medidos en percentil 75 de datos de campo:

Astro renderizado estáticamente

LCP menor a 1.0 segundo consistentemente. JavaScript inicial menor a 30KB en la mayoría de páginas. Lighthouse 100 en todo el sitio es el resultado por defecto, no el objetivo de optimización. El nivel más difícil de superar para sitios de contenido.

Next.js renderizado estáticamente (App Router, RSC)

LCP de 1.0 a 1.5 segundos en sitios optimizados. JavaScript inicial de 80 a 150KB dependiendo de cuántos componentes cliente se envíen. Lighthouse 90+ es alcanzable pero requiere trabajo de optimización deliberado.

ISR o SSR en Next.js

LCP de 1.5 a 2.5 segundos dependiendo de la tasa de acierto de caché y el tiempo de respuesta del origen. El rendimiento cae en picada con fallos de caché en frío. Tecnología excelente para el caso de uso correcto pero requiere monitoreo activo.

WordPress en hosting administrado (Kinsta, WP Engine) más Cloudflare

LCP de 1.8 a 3.0 segundos típico. Lighthouse de 70 a 85 con esfuerzo. Aceptable para la mayoría de sitios de contenido pero materialmente peor que las opciones estáticas. El techo de rendimiento es real.

WordPress en hosting compartido

LCP de 3.5 segundos o peor. Evita para cualquier sitio donde el rendimiento sea parte del requerimiento.

Los tres pueden posicionarse al más alto nivel. La conversación SEO de 2026 ya no es sobre cuál framework es "más amigable con SEO". Es sobre la calidad de la implementación.

El renderizado estático en Astro o Next.js te da el HTML indexable más limpio y los Core Web Vitals más rápidos, ambos factores de posicionamiento. WordPress con Yoast o Rank Math te da las herramientas SEO en editor más completas, lo que ayuda materialmente a que editores no técnicos publiquen metadatos limpios. WordPress headless te da ambos, al costo de mantener doble stack.

Dónde veo desastres SEO: sitios Next.js pesados en JavaScript del cliente que renderizan contenido principal en el navegador en lugar del servidor. Google técnicamente puede indexar contenido renderizado en JavaScript pero la latencia, completitud y consistencia son todas peores que el contenido renderizado en HTML. Si SEO importa, renderiza server-side o estáticamente. Siempre.

La mayoría de los clientes hacen la pregunta equivocada sobre migración. La correcta no es "¿podemos migrar de WordPress a Next.js?" sino "¿cuál es el costo total de tres años de cada opción, incluyendo el equipo necesario para mantenerlo, y cuál entrega las métricas que realmente nos importan?".

Una migración típica de WordPress a Next.js headless que ejecutamos en Seahawk cuesta entre 25,000 y 90,000 USD dependiendo del alcance. Esa migración generalmente se paga a sí misma dentro de doce meses en tráfico donde las puntuaciones de Lighthouse influyen en los costos de publicidad o las tasas de conversión. No se paga a sí misma en un sitio institucional que recibe dos mil visitantes mensuales.

La migración que más frecuentemente tiene sentido es pasar de WordPress en hosting compartido a WordPress en Kinsta, más una capa de Cloudflare, más una dieta más estricta de plugins. Misma plataforma, realidad operacional diferente, rendimiento y seguridad materialmente mejores a una décima parte del costo de cambiar de plataforma. La respuesta correcta para la mayoría de los clientes no es "reconstruir en Next.js" sino "arreglar la instalación de WordPress que ya tienen".

Este es el árbol de decisión real que aplico en cada nueva conversación con clientes en 2026:

Si el equipo tiene cero capacidad de ingeniería y lo editorial es la única función: Webflow o WordPress hospedado.

Si el equipo está liderado por editorial con soporte técnico ligero, contenido abundante con necesidades de ecosistema de plugins: WordPress clásico en hosting administrado. Respuesta por defecto.

Si el equipo está liderado por editorial pero el rendimiento y el diseño son parte del brief: WordPress headless con frontend de Astro o Next.js.

Si el equipo está liderado por ingeniería, el producto es abundante en contenido, el lenguaje de diseño es inusual, y hay poco estado de usuario: Astro con Sanity o Supabase.

Si el equipo está liderado por ingenieros, el producto tiene estado de usuario autenticado e interactividad con estado: Next.js con Sanity o Supabase, desplegado en Vercel o Cloudflare Pages dependiendo de la sensibilidad al costo.

Si el modelo de datos es genuinamente en forma de tabla a escala (directorios, listados, SEO programático): Next.js o Astro con Supabase. HostList.io es el caso de estudio aquí.

No existe un único framework "mejor" en 2026. Existe un mejor framework para cada combinación de equipo, forma de contenido y realidad operativa. Los equipos que entregan bien son los que casan esas tres cosas honestamente. Los equipos que luchan son los que eligieron el framework primero e intentaron hacer que su realidad se ajustara a él.

Tres señales honestas de que estás a punto de elegir el framework equivocado: lo estás eligiendo porque es lo que usan tus amigos, lo estás eligiendo porque está en la lista de tendencias este trimestre, lo estás eligiendo porque la demo en la página de marketing te hizo sentir algo. Ninguna de esas son buenas razones. La razón correcta es: esto se ajusta a mi equipo, esto se ajusta a mi contenido, esto se ajusta a mi presupuesto durante tres años.

Si quieres una segunda opinión sobre cuál es la correcta para lo que estás construyendo, realizamos consultoría en Seahawk Media. La conversación es gratuita, la recomendación es honesta, y a veces te diremos que la respuesta correcta es mantener tu sitio WordPress actual y arreglar la capa de hosting porque eso es lo que las matemáticas realmente dicen.