Cómo migré jaime.digital de WordPress a Astro headless: el caso real (98/100 PageSpeed)

Cuando empecé a vender WordPress headless como servicio, tenía un problema incómodo: mi propia web estaba en WordPress tradicional. Iba lenta, me daba problemas de plugins, y cada vez que un cliente me preguntaba "¿pero tu web es headless?" me tocaba dar explicaciones.

Así que en febrero de 2026 decidí migrarla. Y como cuento las cosas como son, aquí va el making-of completo: lo que hice, cuánto tardé, qué cifras tenía antes y después, qué decisiones tomé y qué errores cometí en el camino.

Si estás pensando en hacer lo mismo, este artículo es lo más cercano a un mapa real que vas a encontrar.

Punto de partida: WordPress tradicional con todo el dolor

Antes de la migración, jaime.digital era un WordPress estándar:

• WordPress 6.4 sobre PHP 8.1.

• Hosting compartido en un proveedor decente: 18 € / mes.

• Tema premium personalizado con un constructor visual.

• 14 plugins activos (Yoast SEO, ACF, WPML, WPForms, plugins de caché, plugin de optimización de imágenes, varios más).

• 32 páginas + 18 posts de blog + 4 idiomas = ~200 URLs totales contando traducciones.

Las cifras que me dolían:

Métrica

Valor antes

LCP móvil (PageSpeed Insights)

3,5 s

FCP móvil

3,0 s

Puntuación PageSpeed móvil

62 / 100

Puntuación PageSpeed escritorio

84 / 100

TTFB medio

850 ms

Peso medio de página

2,1 MB

Requests por página

78

Por contexto: el LCP por encima de 2,5 segundos es "deficiente" según Google. El mío estaba en 3,5. Cada visita a mi web era una mancha en mi reputación profesional.

El detonante final fue ver en Search Console el aviso "Más allá del umbral aceptable" en LCP móvil. Llevaba meses pensando en migrar. Esa semana lo hice.

Decisión 1: ¿Astro, Next.js o Faust.js?

Lo primero fue elegir el stack frontend. Tenía los tres como opción real porque domino los tres. La decisión la tomé en base a estos criterios:

• Mi web es 95% contenido editorial: páginas de servicios, blog, portfolio, formulario de contacto. No tengo dashboard, ni configurador, ni nada altamente interactivo.

• Quiero el máximo control sobre el rendimiento: cada milisegundo cuenta porque vendo velocidad.

• Quiero coste de hosting mínimo: si tengo que pagar 50 € al mes en Vercel, mi diferencial competitivo se va al traste.

• Quiero poder mantenerlo yo solo durante años: nada de ataduras a frameworks que cambian de API cada 6 meses.

Astro ganó los cuatro puntos. Decisión tomada en 20 minutos.

(Si quieres ver la comparativa larga, la tengo en Astro vs Next.js vs Faust.js para WordPress headless.)

Decisión 2: ¿WordPress como backend o Storyblok?

Aquí la cosa se puso más interesante. La opción "purista" del headless WordPress es mantener WordPress como backend en privado. Pero me planteé una alternativa: ¿y si voy un paso más allá y elimino WordPress también del backend?

Pros de WordPress como backend headless:

• Mi equipo (yo solo) ya conoce el panel.

• WPGraphQL y la REST API funcionan bien.

• Mantengo años de plugins y configuraciones.

Pros de Storyblok como backend (la opción que finalmente elegí):

• Nada de PHP. Nada de base de datos propia. Nada de actualizaciones de seguridad.

• Visual editor para los componentes Astro directamente.

• API muy rápida y bien documentada.

• Plan gratuito generoso (el mío está en gratuito y me sobra).

Me la jugué con Storyblok. Era más radical pero también más coherente con mi posicionamiento: vendo arquitecturas modernas, así que mi propia web tenía que llevar la arquitectura más moderna que pudiera defender.

Importante: para clientes, sigo recomendando WordPress como backend en la inmensa mayoría de los casos, porque la curva de aprendizaje del CMS es cero. Mi web es un caso especial porque solo edito yo. No proyectes mi decisión a tu situación sin pensarlo.

El plan de migración paso a paso

Una vez elegida la arquitectura (Astro frontend + Storyblok backend), el plan fue así:

Semana 1: Inventario y diseño

• Listé las 200 URLs de la web vieja una a una.

• Mapeé qué tenía que conservarse, qué refactorizar, qué se eliminaba.

• Definí las "categorías" de contenido en Storyblok: páginas, posts, servicios, testimonios, FAQs, proyectos.

• Diseñé los nuevos componentes en Figma. Aproveché para limpiar UI inconsistencias del WordPress viejo.

Tiempo invertido: ~12 horas.

Semana 2: Setup técnico

• Creé el proyecto Astro nuevo (npm create astro@latest).

• Configuré Tailwind CSS, TypeScript estricto, ESLint, Prettier.

• Conecté Storyblok con @storyblok/astro.

• Monté la integración de previsualización en vivo (importante: que pueda ver borradores antes de publicar).

• Configuré Cloudflare Pages como hosting + dominio + redirects.

Tiempo invertido: ~10 horas.

Semanas 3 y 4: Componentes y plantillas

• Construí los componentes Astro reutilizables: Hero, Card, Grid, Testimonial, FAQ, CTAs.

• Cada componente con su versión móvil y escritorio.

• Plantillas para los tipos de contenido: home, página, post, servicio, listado de blog, ficha de proyecto.

• Implementé el header (con el mega menú responsive) y el footer.

• JSON-LD estructurado en cada plantilla.

Tiempo invertido: ~28 horas.

Semana 5: Migración de contenido

• Importé los posts del blog desde el export XML de WordPress a Storyblok (con un script Node.js que escribí en un par de horas).

• Reescribí las páginas estáticas (servicios, sobre mí, casos) directamente en Storyblok aprovechando para mejorar copy.

• Migré las imágenes a Cloudflare Images (las viejas pesaban demasiado, aproveché para reoptimizar).

• Reconstruí las traducciones (en el WP viejo usaba WPML; ahora cada idioma es una rama de contenido en Storyblok).

Tiempo invertido: ~22 horas.

Semana 6: QA, redirects y switch

• Lista de redirects 301 desde las URLs viejas a las nuevas (las que cambiaron).

• Test de cada página: enlaces, formularios, imágenes, fonts, JS interactivo.

• Test de Core Web Vitals en cada plantilla.

• Configuración de Google Analytics 4 nuevo.

• Verificación en Search Console de la nueva versión.

• Cambio de DNS para que jaime.digital apunte al frontend Astro.

• Monitorización 48h.

Tiempo invertido: ~14 horas.

Total: 86 horas de trabajo real, distribuidas en 6 semanas calendario. Trabajando "en huecos" entre proyectos de cliente, sin parar mi facturación normal.

Errores que cometí (porque también pasan)

Para que no caigas en lo mismo:

Error 1: No pensé en los redirects con suficiente detalle

Pasé varios días en producción con algunos posts antiguos devolviendo 404 porque cambié la estructura de URLs del blog (de /2024/03/titulo/ a /blog/titulo/). Search Console me lo cantó y tuve que añadir unos 60 redirects 301 a posteriori. Lección: lista TODOS los redirects ANTES del switch, no después.

Error 2: Olvidé el archivo robots.txt durante 3 días

Mi robots.txt de Astro tenía un Disallow: / heredado del entorno de staging. Resultado: Google no indexó nada durante 72 horas. Cuando lo detecté, lo arreglé y solicité re-crawl, pero perdí algo de visibilidad temporal. Lección: el robots.txt es lo PRIMERO que hay que verificar tras el switch.

Error 3: Las imágenes Open Graph no se actualizaron en el caché de redes sociales

LinkedIn y Twitter cachean las miniaturas de OG image agresivamente. Cuando publicaba un post nuevo, salía la imagen vieja del WP. Tuve que usar las herramientas de "scrape" de cada red social para forzar la actualización. Lección: al migrar, fuerza el re-scrape de OG en LinkedIn, Twitter y Facebook desde el principio.

Error 4: No precarga de fonts

En la primera versión post-migración mi LCP móvil bajó de 3,5 s a 1,4 s. Bien. Pero los textos pegaban un "FOIT" feo (Flash of Invisible Text) durante el primer paint. Tuve que añadir <link rel="preload"> para Manrope y PT Sans, y un par de pequeños ajustes en el font-display. Lección: font loading es el detalle final que separa una migración buena de una excelente.

Las cifras después de la migración

Aquí va la parte que te interesa: los números antes y después, sin maquillaje.

Métrica

Antes (WP)

Después (Astro headless)

Mejora

LCP móvil

3,5 s

0,8 s

-77%

FCP móvil

3,0 s

0,7 s

-77%

Puntuación PageSpeed móvil

62 / 100

98 / 100

+58%

Puntuación PageSpeed escritorio

84 / 100

100 / 100

+19%

TTFB medio

850 ms

95 ms

-89%

Peso medio de página

2,1 MB

380 KB

-82%

Requests por página

78

14

-82%

Coste mensual hosting

18 €

0 €

-100%

Coste anual ahorrado

—

216 €

—

Cifras reales. Verificables ahora mismo en PageSpeed Insights si pones jaime.digital. No hay trampa: la web entera es Astro estático servido desde Cloudflare Pages.

Lo más importante para mí: las visitas pasaron a comportarse mejor. Bounce rate bajó del 58% al 41% en los dos meses siguientes. Tiempo medio en página subió un 22%. No tengo evidencia causal directa (correlación no es causalidad), pero es lo que pasó cuando lo único que cambié fue la velocidad.

El hosting: el dato más loco

Antes pagaba 18 € al mes por hosting WordPress decente. Ahora pago cero euros al mes por hosting frontend, porque Cloudflare Pages tiene un plan gratuito muy generoso (bandwidth ilimitado, builds rápidos, edge global en 300+ ciudades).

Lo único que pago hoy:

• Dominio: 11 € al año (igual que antes).

• Storyblok: 0 € (plan gratuito).

• Cloudflare Pages: 0 €.

• Total mensual: 0,92 €.

Eso es menos del 6% de lo que pagaba antes. Y tengo más velocidad, más estabilidad, más seguridad. Sin perder nada.

¿Y si tu web es WordPress y quieres lo mismo?

Muy importante: mi caso es un extremo. Yo migré a Storyblok porque solo edito yo y quería el setup más radical posible. Para el 95% de empresas, lo correcto es mantener WordPress como backend y conectarlo a un frontend Astro (o Next.js o Faust.js según el caso). El equipo de contenido no nota nada y los beneficios técnicos son los mismos.

Si esto te encaja, en mi servicio de WordPress headless hago exactamente este proceso para clientes. Sin sorpresas, con cifras antes/después medibles, y con una metodología en 5 fases que ya te he contado por encima.

Lecturas recomendadas para profundizar

• ¿Qué es WordPress headless? Guía sin jerga técnica para empresas — empieza aquí si todavía no tienes claro el concepto.

• Astro vs Next.js vs Faust.js para WordPress headless — la comparativa técnica de los tres stacks.

• Core Web Vitals en WordPress: por qué los plugins de caché ya no son suficientes — si tu LCP también está disparado, mira esto antes de tomar la decisión.

• WordPress headless vs WordPress tradicional: 8 diferencias reales con costes — comparativa cuantitativa con cifras.

Resumen rápido

• Migré jaime.digital de WordPress tradicional a Astro headless con Storyblok como CMS en febrero de 2026.

• 86 horas de trabajo real distribuidas en 6 semanas.

• LCP móvil bajó de 3,5 s a 0,8 s (-77%). PageSpeed pasó de 62 a 98.

• Coste de hosting frontend: de 18 €/mes a 0 €/mes.

• Cometí 4 errores típicos que te he listado para que no los repitas.

• Lo mismo se puede hacer manteniendo WordPress como backend (lo que recomiendo para 95% de empresas).

¿Quieres ver tu caso? Pídeme una llamada gratuita y te digo en 30 minutos si tu web puede mejorar así o si no merece la pena.