Migrar de WordPress a Astro: guía práctica para equipos técnicos

Migrar de WordPress a Astro: guía práctica para equipos técnicos

WordPress alimenta más del 40% de la web, pero muchos equipos técnicos se encuentran en algún momento frente a la misma decisión: el sitio ha crecido, el rendimiento es mediocre, el mantenimiento de plugins es una fuente continua de fricciones, y el tiempo de carga empieza a afectar al SEO y las conversiones.

Astro es una alternativa seria para sitios de contenido — webs corporativas, blogs técnicos, landings de producto — donde el rendimiento importa y el contenido no cambia en tiempo real. Esta guía explica cómo evaluarlo y cómo hacer la migración sin perder posicionamiento.

Cuándo tiene sentido migrar a Astro

Astro no es la respuesta correcta para todo. Antes de decidir, conviene preguntarse:

Migrar a Astro tiene sentido si:

• El sitio es principalmente de contenido estático o semistático (marketing, blog, documentación, portfolio)
• El rendimiento web es una prioridad medible: LCP < 2.5s, Lighthouse 90+, Core Web Vitals en verde
• El equipo quiere gestionar contenido como código o vía un CMS headless (Contentful, Sanity, Notion)
• La deuda de plugins y themes de WordPress se ha vuelto costosa de mantener

No migrar a Astro si:

• El sitio depende de WooCommerce con lógica de carrito compleja
• El cliente no técnico gestiona el contenido directamente desde el editor de WordPress y no quiere cambiar
• Se necesita lógica de servidor dinámica por defecto (sesiones, personalización en tiempo real)

Arquitectura de referencia post-migración

Una migración típica de WordPress a Astro tiene esta estructura:

src/
  content/
    blog/       ← posts en Markdown/MDX
    pages/      ← páginas estáticas
  components/   ← UI reutilizable
  layouts/      ← plantillas de página
  pages/        ← rutas automáticas por archivo
public/         ← assets estáticos

El contenido puede vivir en ficheros Markdown dentro del repositorio, o conectarse a un CMS headless. La segunda opción es mejor cuando el equipo de contenido no tiene acceso al repositorio.

Proceso de migración en 5 pasos

1. Inventario y priorización

Antes de escribir código, mapea todo el sitio:

• ¿Cuántas páginas únicas existen?
• ¿Cuántos posts de blog activos con tráfico real?
• ¿Qué plugins son funcionalidad y cuáles son solo parches estéticos?
• ¿Qué páginas generan el 90% del tráfico orgánico?

Herramientas: Screaming Frog o una exportación de GSC filtrada por impresiones.

2. Preservar el SEO técnico desde el primer día

El mayor riesgo de una migración es perder posicionamiento. Las reglas básicas:

• Mantén todas las URLs que tienen tráfico o backlinks. Si la estructura de URLs cambia, implementa redirecciones 301 permanentes.
• Conserva los metadatos: title, description, canonical, hreflang si el sitio es multilingüe.
• Recrea el sitemap con las mismas URLs o actualizado si la estructura mejora.
• Migra el contenido exacto de las páginas con tráfico antes de publicar — no reescribas mientras migras.

3. Migración incremental, no big bang

La migración big bang (pasar todo en un día) es la más arriesgada. Una estrategia incremental es más segura:

1. Migra primero las páginas con menos tráfico (páginas de política, legales, contacto)
2. Migra las páginas de servicios/producto con tráfico medio
3. Migra los posts del blog de más a menos tráfico
4. La home queda para el final — es la más visible y la que más backlinks recibe

Mientras tanto, WordPress sigue en producción. Cuando una ruta migrada pasa las pruebas de humo, se despliega y se añade el 301 en el servidor anterior.

4. Configurar el rendimiento correctamente

Astro ofrece rendimiento excelente por defecto, pero hay que configurarlo:

// astro.config.mjs
export default defineConfig({
  output: 'static',
  integrations: [
    sitemap(),
    mdx(),
  ],
  image: {
    service: sharpImageService(),
  },
});

Aspectos críticos para el rendimiento:

• Imágenes con loading="lazy" excepto la imagen above-the-fold (LCP candidate), que va con loading="eager"
• Fuentes con font-display: swap o optional
• CSS crítico inlined en el <head>, resto diferido
• Sin JavaScript innecesario — Astro envía 0 KB de JS por defecto a menos que lo actives explícitamente

5. Validación antes del go-live

Lista de comprobación antes de poner en producción:

• Lighthouse Performance ≥ 90 en móvil
• Todas las URLs con tráfico responden 200 o tienen 301 correcto
• Sitemap generado y accesible
• Meta tags (title, description, og:image) en todas las páginas
• Formularios de contacto funcionando
• Google Analytics / Tag Manager configurado
• Search Console actualizado con el nuevo sitemap

Qué esperar en GSC tras la migración

Si la migración está bien ejecutada, en las primeras 2-4 semanas Google re-crawlea las URLs migradas. Es normal ver una caída temporal de impresiones mientras el índice se actualiza. Si las URLs se preservaron y los 301 están bien implementados, el tráfico se recupera en 4-8 semanas.

Lo que no es normal: pérdidas permanentes de posición en las mismas URLs. Si eso ocurre, revisar si el contenido fue alterado, si los canonical están correctos, o si hay un problema de indexación.

Conclusión

Migrar de WordPress a Astro es una inversión técnica que vale la pena para sitios de contenido con objetivos claros de rendimiento y mantenibilidad. La clave es hacerlo de forma incremental, preservar el SEO desde el primer día, y validar antes de hacer cada cambio visible.

Para sitios más complejos o con equipos no técnicos gestionando el contenido, un CMS headless conectado a Astro puede ser el punto medio ideal.

¿Evaluando si la migración tiene sentido para tu proyecto? El equipo de desarrollo web de Alken ha ejecutado migraciones desde WordPress, PHP legacy y jQuery a stacks modernos — el proceso siempre empieza con una auditoría técnica del sitio actual.