Next.js, Astro O WordPress EN 2026

Next.js, Astro o WordPress: esa es la pregunta que más me hacen los fundadores y los clientes de las agencias. La respuesta casi nunca es la que esperan. La decisión no se reduce a elegir entre un marco de trabajo y otro. La decisión depende de la intención: qué es lo que realmente estás creando, quién se encargará de su mantenimiento tras el lanzamiento y cuál es el tipo de fallo que menos te puedes permitir. Una vez que se analizan con sinceridad estos tres aspectos, la elección del marco de trabajo suele surgir por sí sola.

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

Next.js

Next.js es un marco de trabajo de React con una capa de renderizado en servidor, enrutamiento basado en el sistema de archivos y un sistema de compilación que genera HTML estático, HTML renderizado en servidor o cualquier variante intermedia. El modelo del enrutador de aplicaciones se ha estabilizado desde la versión 15, los componentes de servidor de React son la opción predeterminada y el marco de trabajo es la opción predominante para los proyectos nuevos de React. Vercel lo incluye, Netlify y Cloudflare lo ejecutan, y el ecosistema es muy amplio.

Astro

Astro es un marco de trabajo centrado en el contenido que, por defecto, no incluye ningún código JavaScript y te permite incorporar componentes de React, Vue, Svelte o Solid únicamente donde necesites interactividad. Su punto fuerte son los sitios web de contenido: páginas de marketing, blogs, documentación y sitios web de presentación. El modelo mental es «HTML por defecto, JS donde sea necesario», lo que invierte la premisa de React de que todo es JavaScript hasta que se demuestre lo contrario.

WordPress (clásico y Headless)

WordPress funciona con PHP, se aloja en una base de datos MySQL y cuenta con el mayor ecosistema de plugins de la web. En 2026 tendrá dos modos de funcionamiento: el clásico (WordPress se encarga de la representación tanto del backend como del frontend) y el Headless (WordPress actúa como API y CMS, mientras que Next.js, Astro o Nuxt se encargan de la representación). El WordPress «Headless» es el puente entre el mundo de WordPress con editores y el mundo de Next.js con ingenieros.

Next.js es la mejor opción para sitios web orientados al producto. En concreto: el equipo domina React, el producto cuenta con una interactividad basada en el estado que va más allá de la de un sitio web de marketing típico, el modelo de datos es personalizado (no se trata de un blog genérico ni de un CMS) y el equipo de ingeniería se encargará del código durante años.

Ejemplos concretos de proyectos que he lanzado: un panel de control SaaS con una página de inicio dedicada al marketing, un mercado online con inicio de sesión y contenido personalizado, la web de una empresa de herramientas para desarrolladores con demostraciones muy personalizadas y una plataforma de directorio multitenant como HostList.io. Todos ellos se benefician de los componentes de servidor de React, las funciones básicas de obtención de datos de Next.js y la transición fluida entre páginas estáticas de marketing y interfaces de aplicación autenticadas dentro del mismo marco de trabajo.

Donde Next.js se vuelve rápidamente costoso es en los sitios web con gran volumen de contenido y editores sin conocimientos técnicos. La integración con el CMS siempre es a medida, el flujo de trabajo editorial siempre hay que rediseñarlo y el equipo que lo mantiene debe contar permanentemente con personal de ingeniería. Si tu equipo editorial está formado por tres redactores y quieres que publiquen sin la intervención de los ingenieros, Next.js no es la solución adecuada.

Conclusión clave: Next.js es la mejor opción cuando el producto tiene un estado real y cuenta con un equipo de ingeniería que se hará cargo de él durante años.

Astro es ideal para sitios web centrados en el contenido, con un lenguaje de diseño sólido y la capacidad técnica necesaria para ofrecer componentes limpios. En concreto: un sitio web de marketing, un centro de documentación, un sitio web de presentación, un portafolio, un sitio web de agencia y un blog en el que el rendimiento forma parte de la marca. El tipo de sitio web en el que la experiencia del visitante consiste en leer o echar un vistazo al contenido, y no en interactuar con flujos que dependen del estado.

Esta web, gautamkhorana.com, está desarrollada con Astro. Lo mismo ocurre con las webs de marketing de muchas agencias centradas en el diseño y los lanzamientos de productos independientes en 2026. El razonamiento es sencillo: al no haber JavaScript predeterminado, las puntuaciones de Lighthouse alcanzan el 100 sin esfuerzo; el modelo de contenido es Markdown sin formato, Sanity o Supabase; y el proceso de compilación genera HTML estático capaz de soportar un tráfico ilimitado en cualquier CDN. Los sitios web que he publicado en Astro no han sufrido, en conjunto, ninguna regresión en el rendimiento desde su lanzamiento. No unas pocas. Ninguna.

En qué casos Astro no es la opción adecuada: cualquier proyecto con un estado de usuario autenticado significativo, cualquier proyecto en el que la complejidad de la interfaz de usuario supere con creces la del contenido, cualquier proyecto en el que el equipo necesite trabajar con las convenciones de React en toda la base de código. Astro destaca por su ligereza; no es la herramienta adecuada para desarrollar un producto complejo.

Conclusión clave: Astro sale ganando cuando la tarea del visitante es la lectura y el uso de JavaScript por defecto es nulo forma parte de la identidad de la marca.

WordPress es la mejor opción para los sitios web centrados en el contenido en los que la experiencia de los editores es más importante que el rendimiento de la visualización, en los que el ecosistema de plugins resuelve un problema real y en los que el equipo no va a contar con personal de ingeniería de forma permanente. La sección /guides/wordpress/ trata este tema con todo detalle; en resumen: si cuentas con editores sin conocimientos técnicos, el uso de plugins es importante y el coste total de propiedad a lo largo de tres años es el factor decisivo, WordPress sigue siendo la respuesta adecuada para la mayoría de los sitios web centrados en el contenido.

En concreto: sitios web de tipo «folleto» con actualizaciones editoriales periódicas; sitios de comercio electrónico en los que WooCommerce resuelve la complejidad real de los impuestos regionales; sitios de membresía en los que MemberPress o Restrict Content Pro ofrecen un flujo de trabajo listo para usar; sitios inmobiliarios o de ofertas de empleo en los que un plugin especializado se encarga del noventa por ciento del modelo; y sitios en los que el cliente no desea, de forma explícita, contratar a un desarrollador para realizar cambios continuos.

Conclusión clave: WordPress sigue siendo la mejor opción cuando la facilidad de uso de los editores y los complementos es más importante que el simple hecho de poder presumir de rendimiento.

WordPress «Headless» es una arquitectura puente: se mantiene WordPress para la experiencia de edición y el ecosistema de plugins, pero la interfaz de usuario se genera con Next.js o Astro para mejorar el rendimiento y controlar el diseño. Resulta útil en un conjunto de casos limitado, pero real.

Merece la pena cuando: el equipo editorial está comprometido con WordPress y no tiene intención de cambiarlo, pero el rendimiento del sitio web de marketing es fundamental (alto tráfico, anuncios caros, puntuaciones de Lighthouse sensibles para la marca). Merece la pena cuando el lenguaje de diseño es lo suficientemente inusual como para que la capa de temas de WordPress no pueda dar la talla, pero el modelo de contenido se adapta perfectamente a WordPress (entradas, páginas, tipos de entrada personalizados, campos ACF). Merece la pena cuando la empresa cuenta con madurez tanto editorial como de ingeniería y puede permitirse contratar personal para ambas áreas.

No sale a cuenta cuando: el equipo carece tanto de madurez editorial como de capacidad técnica (al final acabas pagando el doble), el proyecto es, en realidad, una página web de presentación que se actualiza mensualmente, o el presupuesto es tan reducido que el mantenimiento de una arquitectura de doble capa resulta inasequible. El coste real de mantener un WordPress «Headless» en 2026 es, aproximadamente, entre 1,5 y 2 veces superior al de mantener un WordPress clásico durante doce meses. Asegúrate de que las ventajas en cuanto a rendimiento y diseño lo justifiquen.

En el caso concreto de Next.js, la elección de la estrategia de renderizado tiene más implicaciones en cuanto a costes que la propia elección del marco de trabajo. Las cuatro opciones son:

Generación de sitios web estáticos (SSG)

Todas las páginas se generan en el momento de la compilación y se sirven como HTML sin formato desde la CDN. Es la opción más económica, rápida y segura. La configuración predeterminada ideal para sitios web de marketing y blogs. La limitación es que cualquier cambio en el contenido requiere una recompilación y una nueva implementación completas. Para sitios web con menos de unos pocos miles de páginas, esto no supone ningún problema. Sin embargo, en el caso de sitios web con decenas de miles de páginas, los tiempos de compilación se convierten en el cuello de botella.

Regeneración estática incremental (ISR)

Las páginas se generan de forma estática en el momento de la compilación y, posteriormente, se revalidan bajo demanda o según una programación. Es la solución intermedia ideal para sitios web de contenido a gran escala. El problema al que se enfrentan la mayoría de los equipos es que la facturación de ISR en Vercel se realiza por invocación, y con 91 000 páginas y revalidaciones frecuentes, hemos llegado a registrar meses con varios millones de eventos. Tenemos una norma explícita de «dos fusiones de producción a la semana» en el sitio web de Deluxe Astrology precisamente porque cada fusión genera aproximadamente seis millones de eventos de escritura de ISR. ISR es una tecnología excelente con una curva de costes real a gran escala.

Renderización del lado del servidor (SSR)

Páginas generadas en cada solicitud. La solución ideal para paneles de control con autenticación, contenido personalizado y cualquier situación en la que el contenido de la página dependa del usuario que realiza la solicitud. El modelo de costes se basa en el uso de la CPU por solicitud, lo que puede resultar muy caro rápidamente en páginas públicas con mucho tráfico. Evita el SSR para las páginas de marketing.

Componentes de servidor de React (RSC)

La configuración predeterminada de Next.js 15, que suele utilizarse junto con lo anterior. RSC traslada la recuperación de datos al servidor y envía menos código JavaScript al cliente. El modelo mental requiere un cierto periodo de adaptación, pero las ventajas en cuanto a rendimiento y experiencia de desarrollo son reales. La mayor parte de los nuevos proyectos de Next.js en 2026 deberían utilizar RSC de forma predeterminada.

Si vas a utilizar Next.js o Astro en modo «Headless», la elección de la capa de CMS es la segunda decisión más importante después del marco de trabajo. Estas son las cinco opciones viables que evalúo en cada proyecto:

Sanity

Mi recomendación habitual para nuevos proyectos «Headless». El enfoque «esquema como código» es el modelo de contenido más limpio del mercado, la experiencia de edición es realmente buena para los editores sin conocimientos técnicos y el lenguaje de consulta GROQ es más flexible que GraphQL para la mayoría de los formatos de contenido. Los precios se adaptan de forma razonable. Inconvenientes: un ecosistema de plugins más limitado que el de WordPress y algunas dificultades ocasionales en los flujos de trabajo editoriales personalizados.

Headless WordPress (a través de WPGraphQL o REST)

La respuesta adecuada cuando la principal limitación es el nivel de familiaridad de los editores con WordPress. WPGraphQL habrá alcanzado su madurez en 2026 y la pila de Faust.js facilita la integración con Next.js. Coste: hay que mantener WordPress Y el frontend, lo que supone la sobrecarga inherente a la conexión entre ambos mundos.

Supabase

Es mi opción preferida cuando el modelo de contenido se basa más en datos estructurados que en textos largos: directorios, listados, sitios web de SEO programático, cualquier cosa que tenga forma de tabla. HostList.io funciona con Supabase. Coste: Supabase es una base de datos con funcionalidades propias de una capa de contenido, no un CMS en el sentido editorial. A los editores no les entusiasma.

Contentful

Una opción de nivel empresarial con potentes funciones de flujo de trabajo y compatibilidad con diferentes configuraciones regionales. Los precios aumentan rápidamente en los niveles superiores. Ideal para cuando el equipo cuenta con una gestión formal de contenidos y un presupuesto acorde.

Payload, Strapi

Opciones de autoalojamiento cuando la residencia de los datos o el control de costes son la principal preocupación. Ambas han madurado considerablemente en 2025. Son adecuadas para equipos con capacidad de ingeniería que deseen tener el control de la capa CMS.

El lugar donde se realiza la implementación es la tercera decisión que tiene repercusiones a largo plazo. Las tres opciones viables de alojamiento son:

Vercel

Alojamiento propio de Next.js, la experiencia de desarrollo más fluida y el nivel de precios más alto. El ancho de banda y las invocaciones de ISR son los factores de coste que la mayoría de los equipos pasan por alto hasta que llega la factura. Nosotros realmente alojamos sitios web en Vercel porque la experiencia de desarrollo es inmejorable, pero la curva de costes es más pronunciada de lo que la gente espera. Calcula un presupuesto de al menos el doble de tu estimación inicial en cualquier escala en la que se haga un uso intensivo de ISR.

Netlify

Es excelente para Astro y Next.js con renderizado estático, aunque algo menos pulido para Next.js App Router con RSC completo. Los precios son más predecibles que los de Vercel. El modelo de precios por minuto de compilación es el aspecto clave a tener en cuenta. Esta web funciona con Netlify.

Cloudflare Pages y Workers

La mejor relación calidad-precio en 2026; considerablemente más barato que los otros dos a gran escala; la red subyacente no tiene rival en cuanto a la distribución global. Inconveniente: el modelo de implementación y la integración con Next.js están menos pulidos que en Vercel. Merece la pena elegirlo para proyectos en los que el coste sea un factor determinante y se cuente con la capacidad técnica necesaria para sortear las dificultades.

Elige el framework que se ajuste al equipo que lo mantendrá. Suena obvio. Es la regla más violada en decisiones de framework que vi en Seahawk.

Un equipo formado por tres ingenieros de React no debería desarrollar en WordPress. Un equipo compuesto por un ingeniero de PHP y tres redactores no debería desarrollar en Next.js. Un equipo sin ingenieros y con un diseñador autónomo tampoco debería desarrollar en ninguna de las dos: la respuesta correcta es Webflow, Framer o WordPress alojado.

El coste de un marco y un equipo que no encajan no se paga el primer día. Se paga durante años, a medida que el equipo trabaja en contra del marco en lugar de con él. Adapta la tecnología a la realidad operativa.

Cifras reales de las instalaciones en las que he realizado envíos o auditorías en 2026, todas ellas medidas según los datos de campo del percentil 75:

Astro con renderizado estático

LCP por debajo de 1,0 segundo de forma constante. Código JavaScript inicial por debajo de 30 KB en la mayoría de las páginas. Una puntuación de 100 en Lighthouse en todos los aspectos es el resultado por defecto, no el objetivo de optimización. El nivel más difícil de superar para los sitios web de contenido.

Next.js con generación estática (App Router, RSC)

LCP de 1,0 a 1,5 segundos en sitios web optimizados. JavaScript inicial de 80 a 150 KB, dependiendo del número de componentes de cliente que se incluyan. Se puede alcanzar una puntuación de Lighthouse superior a 90, pero requiere un trabajo de optimización específico.

ISR o SSR en Next.js

LCP: entre 1,5 y 2,5 segundos, dependiendo de la tasa de aciertos de la caché y del tiempo de respuesta del servidor de origen. El rendimiento se desploma cuando se producen fallos de caché en condiciones de caché fría. Es una tecnología excelente para el caso de uso adecuado, pero requiere una supervisión activa.

WordPress en un alojamiento gestionado (Kinsta, WP Engine) más Cloudflare

LCP: entre 1,8 y 3,0 segundos, por lo general. Lighthouse: entre 70 y 85 con cierto esfuerzo. Aceptable para la mayoría de los sitios web de contenido, pero notablemente peor que las opciones estáticas. El límite máximo de rendimiento es una realidad.

WordPress en un alojamiento compartido

LCP de 3,5 segundos o más. Evítalo para cualquier sitio web en el que el rendimiento sea parte de los requisitos.

Los tres pueden situarse al más alto nivel. El debate sobre el SEO en 2026 ya no gira en torno a qué marco es «más compatible con el SEO», sino en torno a la calidad de la implementación.

La generación estática con Astro o Next.js te ofrece un código HTML indexable más limpio y los valores más rápidos en Core Web Vitals, ambos factores que influyen en el posicionamiento. WordPress con Yoast o Rank Math te ofrece las herramientas de SEO más completas directamente en el editor, lo que ayuda de forma significativa a los editores sin conocimientos técnicos a publicar metadatos limpios. WordPress «Headless» te ofrece ambas cosas, a costa de un mantenimiento de doble pila.

Dónde veo desastres de SEO: sitios web de clientes creados con Next.js que contienen mucho JavaScript y que representan el contenido principal en el navegador en lugar de hacerlo en el servidor. Técnicamente, Google puede indexar el contenido representado mediante JavaScript, pero la latencia, la exhaustividad y la coherencia son peores que las del contenido representado en HTML. Si el SEO es importante, hay que representar el contenido del lado del servidor o de forma estática. Siempre.

La mayoría de los clientes plantean la pregunta equivocada sobre la migración. La pregunta correcta no es «¿podemos migrar de WordPress a Next.js?», sino «¿cuál es el coste total a tres años de cada opción, incluyendo el equipo necesario para su mantenimiento, y cuál nos ofrece los indicadores que realmente nos importan?».

Una migración típica de WordPress a Next.js headless que corrimos en Seahawk comenzaba desde $10k, con la cifra final establecida por alcance. Esa migración generalmente se paga sola en doce meses en tráfico donde las puntuaciones de Lighthouse influyen en costos de publicidad o tasas de conversión. No se paga sola en un sitio informativo que recibe dos mil visitantes mensuales.

La migración que suele tener más sentido es pasar de WordPress en un alojamiento compartido a WordPress en Kinsta, añadiendo una capa de Cloudflare y reduciendo al mínimo el uso de plugins. La misma plataforma, una realidad operativa diferente, un rendimiento y una seguridad sustancialmente mejores a una décima parte del coste que supondría cambiar de plataforma. La respuesta adecuada para la mayoría de los clientes no es «reconstruir con Next.js», sino «optimizar la instalación de WordPress que ya tienen».

Este es el árbol de decisión que utilizo en cada conversación con un nuevo cliente en 2026:

Si el equipo no cuenta con recursos técnicos y la única función es la editorial: Webflow o WordPress alojado.

Si el equipo se centra en la edición y cuenta con un soporte técnico mínimo, y el contenido es muy extenso y requiere un ecosistema de plugins: WordPress clásico en un alojamiento gestionado. La respuesta habitual.

Si el equipo se centra en la redacción, pero el rendimiento y el diseño forman parte del encargo: un WordPress «Headless» con una interfaz de usuario basada en Astro o Next.js.

Si el equipo está dirigido por ingenieros, el producto tiene un gran volumen de contenido, el lenguaje de diseño es poco habitual y hay pocos datos sobre el estado del usuario: Astro con Sanity o Supabase.

Si el equipo está dirigido por ingenieros, el producto cuenta con un estado de usuario autenticado e interactividad con estado: Next.js con Sanity o Supabase, implementado en Vercel o Cloudflare Pages en función de la sensibilidad al coste.

Si el modelo de datos tiene realmente una estructura de tablas a gran escala (directorios, listados, SEO programático): Next.js o Astro con Supabase. HostList.io es el caso práctico en este contexto.

Conclusión clave: Adapta el marco de trabajo al equipo, al formato del contenido y al presupuesto trienal; nunca al vídeo de demostración que te emocionó.

En 2026 no existe un único marco de trabajo «óptimo». Hay un marco óptimo para cada combinación de equipo, tipo de contenido y realidad operativa. Los equipos que obtienen buenos resultados son aquellos que se ajustan a esos tres factores con sinceridad. Los equipos que tienen dificultades son aquellos que eligieron primero el marco de trabajo e intentaron adaptar su realidad a él.

Tres señales claras de que estás a punto de elegir el marco de trabajo equivocado: lo eliges porque es el que usan tus amigos, lo eliges porque está en la lista de tendencias de este trimestre, lo eliges porque la demostración de la página de marketing te ha causado alguna impresión. Ninguna de esas es una buena razón. La razón correcta es: esto se adapta a mi equipo, esto se adapta a mi contenido, esto se adapta a mi presupuesto para los próximos tres años.

Si quieres una segunda opinión sobre qué es correcto para lo que estás construyendo, corro consultas directamente. La conversación es gratuita, la recomendación es honesta, y a veces te diré que la respuesta correcta es mantener tu sitio WordPress actual y corregir la capa de hosting porque eso es lo que las matemáticas realmente dicen.