Todos hemos estado ahí: El cliente quiere la facilidad de edición de WordPress, pero tú, como desarrollador, quieres la experiencia de desarrollo (DX) y el rendimiento de un framework moderno como Astro.
¿La solución? Headless WordPress.
En este artículo, vamos a “cortarle la cabeza” a WordPress (desacoplar el frontend) y usar Astro para renderizar el contenido. El resultado es un sitio estático que carga instantáneamente, con una puntuación de Lighthouse perfecta, manteniendo el panel de administración que tu cliente ya conoce.
¿Por qué esta combinación?
- WordPress (Backend): Es el CMS más usado del mundo. Gestión de usuarios, medios y contenidos imbatible.
- Astro (Frontend): Es un framework “Islands Architecture”. Por defecto envía 0kb de JavaScript al cliente. Es absurdamente rápido.
Paso 1: Configurando el Backend (WordPress)
No necesitas un servidor complejo. Para este tutorial usaremos LocalWP en tu máquina.
- Crea un sitio nuevo en LocalWP.
- Ve a Plugins > Añadir nuevo e instala:
- WPGraphQL: (Esencial) Convierte tu sitio en una API GraphQL. Mucho más limpio y rápido que la REST API.
- WPGraphQL CORS: (Recomendado) Para evitar problemas de bloqueo cuando tu frontend pida datos.
Una vez activado, verás una pestaña “GraphQL” en tu barra lateral. ¡Listo! Tu endpoint suele ser: http://tusitio.local/graphql.
Paso 2: Inicializando Astro
Abre tu terminal y crea tu proyecto:
npm create astro@latest mi-blog-headless
cd mi-blog-headless
npm install
Elige la plantilla “Empty” (Vacía) para que entendamos mejor qué está pasando.
Paso 3: Obteniendo los Posts (La Home)
En Astro, la magia ocurre dentro de las “vallas de código” (---) en la parte superior del archivo. Todo lo que escribas ahí se ejecuta en el servidor (o en tiempo de compilación).
Abre src/pages/index.astro y reemplaza el contenido:
---
// 1. Definimos nuestra consulta GraphQL
// Pedimos solo lo que necesitamos: título, slug y un extracto.
const query = `
query GetPosts {
posts {
nodes {
databaseId
title
slug
excerpt
}
}
}
`;
// 2. Hacemos el fetch a nuestro WordPress Local
const response = await fetch("http://tusitio.local/graphql", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ query }),
});
const json = await response.json();
const posts = json.data.posts.nodes;
---
<html lang="es">
<head>
<title>Mi Blog Headless</title>
</head>
<body>
<main>
<h1>Últimas Entradas 🚀</h1>
<div class="posts-grid">
{posts.map((post) => (
<article class="card">
<h2>{post.title}</h2>
<div set:html={post.excerpt} />
<a href={`/post/${post.slug}`}>Leer más →</a>
</article>
))}
</div>
</main>
</body>
</html>
Nota: Asegúrate de cambiar http://tusitio.local/graphql por tu URL real de LocalWP.
Paso 4: Rutas Dinámicas (El detalle del post)
Ahora viene la parte interesante. ¿Cómo generamos una página para cada post automáticamente? Usando Rutas Dinámicas de Astro.
Crea un archivo en esta ruta exacta: src/pages/post/[slug].astro.
El nombre entre corchetes [slug] le dice a Astro que esta es una ruta dinámica. Dentro, necesitamos exportar una función getStaticPaths() obligatoriamente (si estamos en modo estático/SSG) para decirle a Astro qué páginas existen.
---
// src/pages/post/[slug].astro
export async function getStaticPaths() {
// 1. Primero, pedimos TODOS los slugs a WordPress
const response = await fetch("http://tusitio.local/graphql", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
query: `
query GetSlugs {
posts {
nodes {
slug
}
}
}
`,
}),
});
const json = await response.json();
const posts = json.data.posts.nodes;
// 2. Retornamos un array de objetos con 'params'
// Esto le dice a Astro: "Genera una página para cada uno de estos slugs"
return posts.map((post) => ({
params: { slug: post.slug },
}));
}
// 3. Ahora recuperamos el slug actual para pedir el contenido completo
const { slug } = Astro.params;
const response = await fetch("http://tusitio.local/graphql", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
query: `
query GetPostBySlug($slug: ID!) {
post(id: $slug, idType: SLUG) {
title
content
date
}
}
`,
variables: { slug },
}),
});
const json = await response.json();
const post = json.data.post;
---
<html>
<head>
<title>{post.title}</title>
</head>
<body>
<article>
<a href="/">← Volver al inicio</a>
<h1>{post.title}</h1>
<p><small>Publicado el: {new Date(post.date).toLocaleDateString()}</small>p>
<div class="content" set:html={post.content} />
</article>
</body>
</html>
El Resultado
Si ejecutas npm run dev, verás tu lista de posts. Al hacer clic, navegarás instantáneamente al detalle.
Cuando estés listo para producción, ejecuta npm run build. Astro generará archivos .html estáticos para cada uno de tus posts de WordPress. Puedes subir esa carpeta dist/ a Vercel, Netlify o cualquier hosting barato.
Ventajas de esta arquitectura:
- Seguridad: Tu WordPress puede estar oculto, protegido por contraseña o en una red privada. Solo el proceso de build necesita acceso.
- Velocidad: Sirves HTML puro. No hay base de datos que consultar cuando el usuario visita la web.
- Escalabilidad: Un sitio estático aguanta millones de visitas sin caerse.
¿Qué sigue?
Este es un ejemplo básico. Para llevarlo al siguiente nivel:
- Usa ACF para añadir campos personalizados a tu API.
- Instala
@astrojs/imagepara optimizar las imágenes que vienen de WP. - Configura Webhooks en WordPress para que Vercel reconstruya el sitio cada vez que publiques un post nuevo.
Digo yo que sentido tiene alojar astro en un servidor economico y wordpress nesesitas un hosting de pago para mantenerlo?
Esa es una excelente pregunta y es, de hecho, el punto de dolor número uno cuando alguien empieza con arquitectura Headless. A primera vista, parece que estás duplicando la infraestructura y el costo.
Pero la respuesta corta es: No necesitas un hosting de pago caro para el WordPress en modo Headless. De hecho, puedes ahorrar mucho dinero si tienes tráfico alto.
Aquí te explico la lógica económica detrás de esto:
1. El concepto de “Tráfico Desacoplado”
En un WordPress tradicional (monolítico), cada visita que entra a tu web golpea el servidor, ejecuta PHP y consulta la base de datos.
- 10 visitas/segundo: Tu hosting de 5€ aguanta.
- 100 visitas/segundo: Tu servidor se cae. Necesitas pagar un VPS de 50€/mes o más.
En Headless (Astro):
- Las 100 visitas golpean a Vercel/Netlify/Cloudflare (que son CDNs globales y gratuitos para sitios estáticos).
- ¿Cuántas visitas recibe tu WordPress? Cero.
Tu WordPress solo trabaja en dos momentos:
- Cuando tú entras a escribir.
- Cuando le das a “Publicar” y se genera el sitio estático (Build).
2. Puedes usar el hosting más barato (y basura) del mundo
Como tu WordPress ya no recibe tráfico público, no necesitas un servidor con Nginx optimizado, ni Redis, ni mucha RAM.
- Puedes alojar ese WordPress en el hosting compartido más barato que encuentres (tipo 2€/mes).
- Incluso si ese servidor es lento y tarda 2 segundos en cargar el admin, da igual, porque tus usuarios en el frontend (Astro) están viendo archivos HTML estáticos que cargan en milisegundos.
La matemática del ahorro:
- WordPress Tradicional con mucho tráfico: Hosting Dedicado/VPS optimizado = $30 – $100 / mes.
- Headless: Frontend (Vercel Free Tier = $0) + Backend (Shared Hosting barato = $3 – $5 / mes) = $5 / mes.
3. La opción “Gratis Total”: WordPress Local o Temporal
Si es un proyecto personal o un blog que actualizas poco, puedes llevar el “ahorro” al extremo:
Estrategia “Local Build”:
- Tienes WordPress instalado en tu PC (LocalWP). Es gratis.
- Escribes tu post en tu ordenador.
- Ejecutas
npm run builden tu ordenador. Astro saca los datos de tu WP local y genera los archivos HTML. - Subes solo la carpeta
dist/(los HTML) a Netlify o GitHub Pages. - Apagas tu ordenador.
Resultado: Tu web está online, es rapidísima, y te ha costado $0.00 en hosting de backend y frontend.
4. La seguridad (ahorro indirecto)
Mantener un WordPress público seguro cuesta dinero (plugins de seguridad premium, firewalls, tiempo de limpieza si te hackean).
Si tu WordPress está oculto (protegido con contraseña básica htaccess o en una IP privada) o solo corre en local, es casi imposible que te lo hackeen mediante bots automáticos.
En resumen: ¿Cuándo tiene sentido?
- Si tienes poco tráfico: Tienes razón, tener dos entornos puede ser una complicación innecesaria. Un WP normal barato funciona bien.
- Si tienes MUCHO tráfico: Headless es mucho más barato porque el tráfico se lo come el CDN (gratis o barato), no tu servidor de base de datos.
- Si quieres $0 costes: Usas WP en Local + Astro estático en Netlify.
El “Hosting de pago” para el backend solo es necesario si necesitas que múltiples editores accedan al panel de administración desde diferentes lugares del mundo simultáneamente. Y aun así, serviría un hosting compartido muy básico.
WooCommerce Headless, puede que no interese tanto
Pasar de un Blog Headless a un WooCommerce Headless no es un paso pequeño, es un salto al vacío.
Es un arma de doble filo: Consigues una tienda que vuela, pero la complejidad de desarrollo se multiplica por 10. Te explico por qué y cómo se hace para que realmente valga la pena.
1. La ventaja brutal: El Catálogo Instantáneo ⚡
En una tienda normal, cada vez que alguien filtra por “Camisetas rojas talla M”, WooCommerce hace una consulta pesada a la base de datos.
En Headless (Astro/Next.js):
- Generas todas las páginas de productos como HTML estático.
- Navegar entre productos es instantáneo (0.1 segundos).
- Resultado: La tasa de conversión suele subir porque la gente no se aburre esperando que carguen las fotos.
2. El problema grave: La parte dinámica (Carrito y Checkout) 🛒
Un blog es “Solo Lectura”. Una tienda es “Lectura y Escritura”.
- El Carrito: Ya no puedes usar cookies de sesión de PHP normales fácilmente. Tienes que gestionar el estado del carrito en el navegador (React Context / Nano Stores en Astro) y sincronizarlo vía API con WooCommerce en cada clic.
- El Checkout: Esta es la pesadilla. Replicar un formulario de pago (validación de tarjetas, cálculo de impuestos, envíos en tiempo real) desde cero en JavaScript es dificilísimo y arriesgado por temas de seguridad.
3. El drama de los Plugins 🧩
Este es el punto donde la mayoría de proyectos Headless WooCommerce fracasan.
- ¿Usas un plugin de “Reglas de Descuento Dinámico”?
- ¿Usas un plugin de “Gift Cards”?
- ¿Usas un plugin para calcular envíos con Correos/FedEx?
Ninguno de esos plugins funcionará en tu frontend Headless. Esos plugins están hechos para inyectar código en temas PHP clásicos. En Headless, tú eres responsable de reprogramar esa lógica en JavaScript o buscar plugins que expongan esa lógica vía API (que son pocos).
La Estrategia Ganadora: El “Hybrid Headless”
Si quieres hacerlo, no intentes hacerlo todo Headless. La arquitectura que usan las grandes marcas con WooCommerce es esta:
-
Headless (Astro/Next.js) para el descubrimiento:
- Home, Categorías, Buscador, Fichas de producto.
- Todo esto es estático y ultrarrápido. Se lleva el 90% del tráfico.
-
Tradicional para la compra:
- Cuando el usuario pulsa “Añadir al carrito” o “Pagar”, tienes dos opciones:
- Opción A (Difícil): Usar la API para el carrito y solo redirigir a WP para el pago final.
- Opción B (Inteligente): Al hacer clic en “Comprar”, rediriges al usuario al dominio del backend (ej:
checkout.mitienda.com) que es un WordPress normal con un tema minimalista que visualmente se parece a tu Headless.
- Cuando el usuario pulsa “Añadir al carrito” o “Pagar”, tienes dos opciones:
¿Por qué hacer esto?
Porque delegas la seguridad de los pagos y la complejidad de los plugins de envío al WordPress de toda la vida, pero mantienes la velocidad extrema en la navegación del catálogo.
¿Cuándo compensa económicamente?
A diferencia del blog, aquí SÍ necesitas un buen hosting para el Backend.
¿Por qué? Porque aunque el catálogo sea estático, cada vez que alguien añade algo al carrito, tu API de WooCommerce recibe una petición. Si tienes 100 usuarios comprando a la vez, tienes 100 peticiones dinámicas que no se pueden cachear.
Resumen para WooCommerce:
- ¿Es más rápido? Sí, mucho más.
- ¿Es más barato? No. El desarrollo es más caro (necesitas programadores JS senior) y el mantenimiento es más complejo.
- ¿Vale la pena? Solo si facturas lo suficiente como para que una mejora del 10-20% en velocidad (y conversión) justifique invertir miles de euros/horas en desarrollo personalizado.
Para empezar “gratis” o barato con una tienda, el WooCommerce estándar con un buen sistema de caché (Redis + Caché de página) sigue siendo imbatible.
