WordPress headless con Astro separa la gestión del contenido de la web que ve el visitante. WordPress mantiene el panel, los usuarios, las revisiones y los plugins; Astro genera el frontend y obtiene los datos a través de la API. El resultado puede ser rápido y ligero, pero exige decidir bien cómo se actualiza el contenido, cómo se resuelven las imágenes y quién protege el acceso al CMS.
Este enfoque encaja sobre todo en medios, proyectos con mucho tráfico y equipos que quieren conservar WordPress como herramienta editorial mientras construyen una interfaz propia. No es una mejora automática para cualquier sitio: añade una aplicación más que hay que desplegar y mantener.
En una instalación convencional, WordPress guarda el contenido y también compone cada página que recibe el navegador. En una arquitectura headless, WordPress sigue guardando entradas, páginas, usuarios, categorías, etiquetas, medios y revisiones, pero otro sistema se encarga de dibujar la web.
Astro consulta la API de WordPress, recibe los datos y los convierte en páginas del frontend. El redactor continúa trabajando en WordPress, mientras que la parte pública puede publicarse como HTML estático en una CDN o generarse en el servidor cuando llega una visita.
La REST API de WordPress está disponible de serie para consultar contenido público. Sus endpoints más habituales son /wp-json/wp/v2/posts, /wp-json/wp/v2/pages, /wp-json/wp/v2/categories y /wp-json/wp/v2/media. Para contenido privado, borradores o previsualizaciones hace falta autenticación y una ruta controlada.
Astro está pensado para enviar HTML y cargar JavaScript solo donde hace falta. En un blog o un medio, esa característica permite que la mayoría de las páginas lleguen al navegador con poco código de cliente. Las partes interactivas, como una búsqueda avanzada o un formulario, pueden añadirse como componentes aislados.
El modo de generación depende del proyecto:
La elección tiene consecuencias. La generación estática suele simplificar la caché y reducir el trabajo del servidor, pero necesita reconstruir las rutas cuando se publica algo. El renderizado bajo demanda evita algunos builds completos, aunque obliga a cuidar más la caché y el tiempo de respuesta.
Un listado sencillo puede consultar solo los campos que necesita. Reducir la respuesta evita enviar datos innecesarios y hace más fácil mantener el código:
---
const endpoint =
"https://cms.midominio.com/wp-json/wp/v2/posts" +
"?_fields=id,slug,title,excerpt,date,featured_media" +
"&per_page=10";
const response = await fetch(endpoint);
if (!response.ok) {
throw new Error("No se pudo cargar el contenido");
}
const posts = await response.json();
---
<ul>
{posts.map((post) => (
<li>
<a href={`/noticias/${post.slug}/`}>
{post.title.rendered}
</a>
</li>
))}
</ul>Lenguaje del código: JavaScript (javascript)Si necesitas la imagen destacada, puedes pedir _embed o consultar el endpoint de medios con el identificador recibido. Para un proyecto grande conviene definir una función de acceso a la API y centralizar ahí los errores, los tiempos de espera y la caché.
El contenido HTML que devuelve WordPress no debe insertarse sin pensar. Si utilizas set:html, valida que la fuente sea de confianza y revisa cómo se filtran los campos personalizados. El frontend no sustituye la limpieza que debe hacer el CMS.
La ruta de una noticia suele basarse en el slug. Para generar las páginas estáticas hay que obtener los slugs desde WordPress y convertirlos en rutas de Astro. Si el sitio tiene miles de entradas, descargar todo en un único paso no es una buena idea: usa paginación y procesa las respuestas por lotes.
?page=2&per_page=20 permite pedir otra página de resultados.X-WP-TotalPages indica cuántas páginas hay disponibles.?categories=ID filtra las entradas por categoría.?tags=ID filtra por etiqueta.?after= y ?before= permiten acotar por fecha.Antes de cambiar de WordPress a un frontend independiente, conserva los slugs que ya reciben visitas. Si alguna URL debe cambiar, prepara redirecciones permanentes y actualiza el sitemap. En una web editorial, perder las rutas antiguas suele ser más costoso que el propio trabajo de migración.
Los campos personalizados no aparecen siempre en la REST API. Puedes exponerlos mediante la configuración del plugin, un endpoint propio o una extensión que los registre de forma explícita. Revisa cada campo y publica solo los datos que realmente necesite el frontend.
WPGraphQL es una alternativa si el proyecto necesita consultas con una forma muy concreta o trabaja con muchos tipos de contenido relacionados. Requiere instalar y mantener el plugin correspondiente en WordPress, además de definir qué tipos y campos quedan disponibles.
Para un blog sencillo, REST suele bastar. Si el modelo de datos crece, lo importante no es elegir la tecnología de moda, sino tener un contrato claro entre WordPress y Astro: nombres de campos, formatos, errores y reglas de publicación.
Una instalación headless necesita una ruta específica para que el redactor vea un borrador antes de publicarlo. Esa ruta debe comprobar un token o una sesión, pedir el contenido con permisos y mostrarlo en Astro sin dejar los datos privados en una página pública o en una caché compartida.
El mismo cuidado se aplica a zonas para usuarios registrados. La página pública puede generarse con Astro, pero la información restringida debe solicitarse después de validar la sesión. No basta con ocultar un bloque mediante CSS o JavaScript.
Con generación estática, lo normal es lanzar un nuevo despliegue cuando se publica o modifica contenido. WordPress puede enviar un webhook a la plataforma de alojamiento o a un servicio intermedio que inicie el build. Antes de activarlo en producción, limita el endpoint y valida la petición.
También debes decidir qué ocurre si WordPress no responde. Mantén una caché razonable, muestra una página de error controlada y registra el fallo. Un frontend independiente no debe quedarse sin contenido porque el CMS tenga una caída breve.
Pasar a headless no mejora el SEO por sí solo. Astro debe generar un título, una descripción, etiquetas Open Graph, datos estructurados, enlaces canónicos y un sitemap coherentes con cada URL. También debe conservar la fecha, el autor y la imagen que WordPress entrega para cada entrada.
Las imágenes necesitan un plan propio. Puedes servir las URL de la biblioteca de WordPress, pedir un tamaño concreto o copiar los medios a un servicio de imágenes. En todos los casos, define el atributo alt, usa tamaños responsive y evita cargar la imagen original cuando no haga falta.
El beneficio de Astro se nota cuando el proyecto entrega HTML con poco JavaScript, imágenes ajustadas al dispositivo y una caché bien configurada. Mide el resultado con los datos reales de tu web y comprueba el tiempo de respuesta del CMS, el servidor del frontend y la CDN.
Si quieres relacionar esta arquitectura con la evolución reciente de WordPress, puedes consultar nuestro análisis de los cambios del editor y las imágenes en WordPress 7.1 y la guía sobre los requisitos de PHP de WordPress 7.
Los encabezados de seguridad, la política CSP y la configuración HTTPS pertenecen a la publicación del frontend, pero no sustituyen la protección de WordPress. Hay dos superficies que revisar: el CMS y la aplicación que sirve las páginas.
Headless con Astro puede encajar en un medio con mucho tráfico, un producto que necesita una interfaz a medida o una organización que quiere separar el trabajo editorial del desarrollo del frontend. También es útil cuando la web pública debe tener una salida muy controlada y el equipo ya sabe trabajar con despliegues y APIs.
Para una web corporativa pequeña, un blog sin necesidades especiales o un equipo que no quiere mantener otra aplicación, WordPress tradicional suele ser más sencillo. La arquitectura headless añade decisiones, pruebas y puntos de fallo. El rendimiento debe compensar ese trabajo.
La mejor forma de probarlo es migrar primero una sección acotada, conservar las URLs y medir antes y después. Si la edición, el SEO, las imágenes y el despliegue funcionan bien, ya tendrás una base para ampliar el proyecto.
Sí. WordPress conserva el panel, los roles, las revisiones y el flujo editorial. Astro se ocupa de mostrar el contenido en la parte pública.
REST suele ser suficiente para un blog y viene disponible en WordPress. WPGraphQL puede resultar más cómodo cuando hay muchos tipos de contenido y relaciones entre campos, pero añade otro plugin que debes mantener.
No necesariamente. Puede reducir el JavaScript y servir HTML muy ligero, pero el resultado depende de las imágenes, la caché, el alojamiento, las consultas a la API y el diseño del frontend.
Con un webhook que lance un nuevo build, con renderizado en servidor o mediante revalidación. La opción adecuada depende de cuánto tarde en reflejarse el cambio y del volumen de contenido.
Puede vivir en un subdominio como cms.midominio.com y el frontend ocupar el dominio principal. Si el CMS no debe ser público, protégelo con controles de acceso adicionales sin romper las conexiones que necesite Astro.
Fuentes: REST API de WordPress, documentación de la API REST y documentación oficial de Astro.
