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 predeterminada de WordPress es incorrecta de otro modo, headless añade complejidad de ingeniería y no deberías pagarlo 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 experiencia de ingeniería sin perder el equipo editorial. Los ingenieros que escriben TypeScript a diario se frustran con el stack front-end de WordPress. Plantillas PHP, jQuery, shortcodes de page builder, el lenguaje es incorrecto, las herramientas son incorrectas, la historia de deployment es incorrecta. Headless permite al equipo de ingeniería trabajar en una base de código Next.js o Astro con control de versiones, type checking, deployment en edge, y diseño orientado a 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 front-end suele ser Next.js con App Router para sitios de marketing y aplicaciones con autenticación o interactividad. Astro es la ruta 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 usa Vue. Preferimos Next.js más WPGraphQL más un scaffolding personalizado pequeño 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 según la preferencia del equipo. Back-end en Cloudways, Kinsta o WP Engine en un subdominio no público, cms.tudominio.com, bloqueado detrás de Cloudflare Access o una lista de IP. El tráfico público nunca llega directamente a WordPress. 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 ACF, obtenido via WPGraphQL en build o revalidation. 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 Yoast o Rank Math conectados via 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 hacen incorrectamente. Reemplazamos JSON-LD emitido por plugins con plantillas escritas 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 page builders se rompen primero. Elementor y Divi inyectan CSS e HTML pesados en el front-end. Nada de eso se ejecuta en un front-end headless. La mayoría de las migraciones incluyen una reescritura de contenido como parte del proyecto, extraemos el contenido, lo reformateamos para que coincida con la librería de componentes del nuevo front-end, y saltamos la importación de la capa del visual builder por completo. Los editores obtienen una UX de edición nueva y más simple basada en bloques Gutenberg más contenido flexible ACF. El contenido sobrevive, el visual builder no, y el peso de 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 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 caching, plugins de schema, plugins de social-share. Cada uno se reemplaza por código en el front-end o por un servicio gestionado. El conteo de plugins típicamente cae setenta a ochenta por ciento post-migración. Eso es parte de la ganancia, no una regresión.