WordPress Headless en Next.js o Astro — mantén wp-admin, elimina el impuesto de plugins.

WordPress Headless es correcto cuando una de tres cosas es verdadera. La configuración clásica de WordPress predeterminada es incorrecta de otro modo — headless agrega sobrecarga de ingeniería y no deberías pagarla sin una razón real.

La primera razón es el rendimiento. Un sitio WordPress vanilla con cinco o seis plugins envía alrededor de setecientos kilobytes de JavaScript antes de que se renderice el H1, y con Elementor o Divi más un stack típico de addons, los sitios en el mundo real envían dos a tres megabytes en la primera carga. Hay un límite máximo en Lighthouse y en los datos de campo de CrUX incluso con el mejor plugin de caché delante. Headless en un front-end Next.js o Astro estático o ISR logra consistentemente más de noventa y cinco en Lighthouse en hosting compartido y los datos de campo lo siguen.

La segunda razón es la experiencia de ingeniería sin perder el equipo editorial. Los ingenieros que escriben TypeScript a diario se sienten frustrados por el stack del front-end de WordPress. Templates en PHP, jQuery, shortcodes de page builder — el lenguaje es incorrecto, las herramientas son incorrectas, la historia del deploy es incorrecta. Headless permite que el equipo de ingeniería trabaje en una base de código Next.js o Astro con control de versiones, type checking, edge deployment, y diseño dirigido por componentes mientras los editores mantienen wp-admin, Yoast, y ACF sin cambios.

La tercera razón es multi-destino. Un sitio de marketing, una app móvil, un portal interno, y un portal de partners leyendo todos de la misma fuente de contenido. El WordPress clásico es un CMS, un front-end. WordPress headless se convierte en el back-end editorial para los destinos que necesites, cada uno con su propio framework de front-end optimizado para su superficie.

Tres decisiones definen la mayor parte de la historia de ingeniería.

El framework del front-end es usualmente Next.js con App Router para sitios de marketing y apps con autenticación o interactividad. Astro es el camino más simple para sitios pesados en contenido que se benefician de generación estática y necesitan hidratación parcial solo en componentes específicos. Nuxt es la opción correcta cuando el equipo ya utiliza Vue. Por defecto usamos Next.js más WPGraphQL más un pequeño scaffolding personalizado en lugar de Faust.js porque Faust envía opiniones con las que a veces no estamos de acuerdo — pero Faust es excelente si quieres que el framework tome las decisiones por ti.

La capa de API es WPGraphQL por defecto. API tipada de query-by-shape, soporte de ACF vía WPGraphQL for ACF, soporte de Yoast vía Yoast SEO for WPGraphQL, equivalente de RankMath. WP REST funciona sin plugin y está bien para sitios simples, pero obtienes más datos de los que necesitas y no hay schema introspection en el front-end. Recurre a REST solo cuando WPGraphQL está bloqueado por política de hosting o cuando tienes un conjunto de datos muy pequeño.

El hosting separa el front-end del back-end. Front-end en Vercel, Netlify, o Cloudflare Pages dependiendo de la preferencia del equipo. Back-end en Cloudways, Kinsta, o WP Engine en un subdominio no público — cms.tudominio.com — protegido por Cloudflare Access o una lista blanca de IP. El tráfico público nunca golpea WordPress directamente. WordPress se vuelve invisible desde la web pública; solo tus editores saben que está ahí.

Un build headless WordPress exitoso transporta cinco cosas desde el lado de WordPress al front-end público sin perder fidelidad en el camino.

El contenido es lo obvio — cada post, página, tipo de post personalizado, taxonomía, y campo de ACF, obtenido vía WPGraphQL en build o revalidación. Los medios siguen: cada imagen subida, con optimización WebP del lado de WordPress si está disponible u optimización de imagen del lado del front-end en caso contrario. Los metadatos SEO son el tercero — campos de Yoast o Rank Math conectados vía esquemas GraphQL de complemento-compañero, renderizados como canonical, title, description, OG, y Twitter card desde la respuesta tipada.

El schema es el cuarto y la mayoría de los equipos lo manejan mal. Reemplazamos JSON-LD emitido por plugins con templates escritos a mano en el front-end para una salida más limpia. Article, BlogPosting, Service, Product, BreadcrumbList — todos generados desde datos tipados, validados en tiempo de build. Los redirects son el quinto: cualquier cosa en Yoast Redirect Manager o el plugin Redirection se exporta y se envía como 301s en vercel.json o _redirects en Netlify, nunca como redirects de JavaScript que pierden señal de ranking en tránsito.

El transporte es automatizado. No construimos manualmente ninguna de estas capas por sitio. El mismo scaffolding se envía en cada build headless que hacemos, razón por la cual el costo por sitio ha bajado con el tiempo incluso cuando la superficie de ingeniería ha crecido.

Los constructores de páginas se rompen primero. Elementor y Divi inyectan CSS y HTML pesados en el front-end. Nada de eso se ejecuta en un front-end headless. La mayoría de migraciones incluyen una reescritura de contenido como parte del proyecto — extraemos el contenido, lo reformateamos para que coincida con la biblioteca de componentes del nuevo front-end, y omitimos importar la capa del constructor visual por completo. Los editores obtienen una UX de edición nueva y más simple basada en bloques de Gutenberg más contenido flexible de ACF. El contenido sobrevive, el constructor visual no, y el peso de la página disminuye significativamente como efecto secundario.

Los comentarios y formularios también necesitan repensarse. Los comentarios nativos de WordPress no se renderizan en headless sin intermediar la renderización. La mayoría de equipos los reemplazan con Disqus, Giscus, o un sistema de comentarios personalizado en el front-end. Los formularios típicamente migran a ConvertKit, HubSpot Forms, o un endpoint personalizado de Next.js que envía a un servicio de envío de correos. Contact Form 7 y Gravity Forms tienen versiones amigables con headless pero requieren integración explícita de GraphQL que añade trabajo.

Los plugins de front-end son la tercera cosa que se rompe. Cualquier cosa que inyecte HTML o JavaScript en el front-end de WordPress deja de funcionar — plugins de seguridad, plugins de caché, plugins de schema, plugins de compartir en redes. Cada uno se reemplaza ya sea por código en el front-end o por un servicio gestionado. El número de plugins típicamente cae entre setenta y ochenta por ciento después de la migración. Eso es parte de la victoria, no una regresión.