Cómo migré mi web de WordPress a Astro con IA (historia real, con cicatrices)

Esta web que estás leyendo era, hasta hace unos meses, un WordPress con más de noventa artículos, una docena de plugins y todos los tics de una instalación con años de historia. Hoy es un sitio estático generado con Astro, servido desde una CDN global, con los mismos artículos en las mismas URLs, mejor puntuación de rendimiento y un coste de hosting de exactamente cero euros. La migré yo, usando IA como copiloto de desarrollo intensivo, y este artículo es la historia completa: por qué lo hice, cómo fue de verdad — con los tropiezos que los hilos de “migré mi web en una tarde con IA” nunca cuentan —, qué gané, qué perdí y, sobre todo, para quién tiene sentido este camino y para quién es una trampa.

TL;DR

Migré esta web de WordPress a Astro conservando los ~90 artículos del blog en sus URLs exactas, usando IA como copiloto para el desarrollo y la conversión masiva de contenido. El plan original era más conservador — web nueva estática conviviendo con el blog en WordPress vía proxy — y fue precisamente el que falló: la convivencia técnica entre ambos mundos generó más problemas que la migración completa. Resultado final: hosting gratuito en CDN con ancho de banda ilimitado, carga casi instantánea, cero base de datos que mantener o atacar, y un flujo de publicación basado en Markdown y Git. Lección central: la IA cambió la economía del proyecto (hizo viable en días lo que eran semanas), pero cada decisión importante siguió siendo humana. Y no: para la mayoría de las webs, esta migración NO es el movimiento correcto.

¿Por qué salir de WordPress, si funcionaba?

Empecemos por desmontar el titular fácil: WordPress no es el problema. Mueve una parte enorme de la web mundial, tiene el mejor ecosistema de la historia para publicar sin saber código, y bien mantenido rinde de sobra. Mi blog llevaba años en WordPress y ese blog es un activo SEO que me trae clientes; cualquier decisión que lo pusiera en riesgo era mala por definición. Si diriges una web en WordPress que funciona, que nadie te meta prisa por salir: la migración por moda es de los errores más caros del marketing técnico.

Mi caso tenía tres particularidades que fueron inclinando la balanza. La primera, de posicionamiento: quería rediseñar la web corporativa de arriba abajo — otro nivel de diseño, de velocidad y de control — y hacerlo dentro del tema de WordPress existente era pelear contra la herramienta. La segunda, de perfil: yo trabajo con Git, con editor de código y con IA integrada en el flujo; el panel de WordPress, que es la gran ventaja para el 90% de los usuarios, para mí se había vuelto fricción. Y la tercera, la decisiva, no la vi venir: fue la convivencia. Mi plan inicial no era migrar todo, era lo prudente — web nueva en estático, blog quieto en WordPress, ambos bajo el mismo dominio repartidos por rutas. Sobre el papel, lo mejor de los dos mundos. En la práctica, el origen de todos mis problemas.

El plan A: convivir con WordPress (y cómo se torció)

La arquitectura del plan A era razonable y la recomendaría todavía en varios escenarios: las páginas corporativas nuevas servidas como estático desde CDN, y las rutas del blog pasando por un proxy hasta el WordPress de siempre, de forma transparente para el visitante y para Google. Mismo dominio, mismas URLs, cero riesgo SEO. Monté el proxy, ajusté el WordPress para vivir detrás de él, verifiqué que los artículos, el sitemap y el feed respondían correctamente. Todo verde. Publiqué el cambio de DNS y durante unos días aquello funcionó exactamente como estaba diseñado.

Los problemas llegaron por la puerta de atrás: el panel de administración. La combinación de proxy + capa de caché del hosting + las redirecciones internas de WordPress entró en un bucle de redirecciones que convertía entrar a escribir un artículo en una lotería. Probé todo lo razonable: desactivar la caché por configuración, aislar plugins, tocar las constantes de WordPress una a una. Cada intento arreglaba una cosa y rompía otra, y algunos ni siquiera estaban en mi mano porque la capa de caché pertenecía al hosting. Ahí está la lección que me llevo para siempre y que aplico ya en proyectos de clientes: la complejidad de un sistema no está en sus piezas, está en sus fronteras. Un WordPress solo, estable. Un estático solo, trivial. ¿Los dos cosidos por un proxy con tres capas de caché de por medio? Un generador de incidencias imposibles de depurar. Tras semanas de guerra de trincheras, tomé la decisión que había descartado al principio por prudencia: migrarlo todo.

El plan B: migración completa, con la IA en el asiento del copiloto

Migrar un blog de ~90 artículos a mano es el tipo de proyecto que se pospone eternamente: exportar cada pieza, limpiar el HTML de años de editores distintos, convertir a Markdown, revisar metadatos, mover imágenes, verificar URLs. Aquí es donde la IA cambió la economía del proyecto de forma tangible. El proceso que seguí, contado sin humo:

Uno: inventario y reglas. Antes de convertir nada, el trabajo fue definir el mapa: qué artículos migraban (todos), qué URLs debían preservarse (todas, exactas), qué excepciones había (un par de versiones en inglés duplicadas que decidí retirar con redirección a su versión en español) y qué estructura de metadatos tendría cada pieza en el nuevo sistema — título, descripción, fecha original, categorías, imagen. Esta fase es criterio puro y es humana: la IA ejecuta reglas de maravilla, pero definir las reglas correctas es el proyecto.

Dos: conversión masiva asistida. Con las reglas claras, la IA hizo el trabajo pesado: scripts de extracción y conversión del contenido, limpieza del HTML heredado, generación del frontmatter de cada artículo, descarga y reorganización de las imágenes en su nueva estructura. Lo que habría sido un mes de trabajo mecánico y propenso a errores se comprimió en días, con verificación automática detrás: cada artículo migrado se comprobaba contra su original.

Tres: la plantilla, mejor que la original. Al reconstruir las páginas de artículo desde cero salí ganando en cosas que en WordPress requerían plugins: datos estructurados de artículo, migas de pan y FAQ generados de serie; tabla de contenidos automática; imágenes optimizadas en el build; y una velocidad de carga que ningún WordPress con plugins alcanza, porque no hay base de datos ni PHP ejecutándose por visita — solo HTML servido desde el nodo de CDN más cercano al visitante.

Cuatro: la red de seguridad. Sitemap regenerado, redirecciones 301 para lo poco que cambió, verificación URL a URL de que todo respondía, y semanas de vigilancia en Search Console midiendo cobertura e impresiones. El resultado en lo que importa: cero URLs rotas, cero caída de indexación, y el activo SEO — que era la línea roja de todo el proyecto — intacto.

¿Qué gané, qué perdí y qué haría distinto?

Lo ganado, en orden de importancia real y no de marketing. Primero, simplicidad estructural: no hay base de datos, no hay panel que atacar, no hay plugins que actualizar; la superficie de fallos y de seguridad se redujo casi a cero. Segundo, coste: el hosting pasó a cero euros en una plataforma con ancho de banda ilimitado, y lo que antes era una suma de hosting + mantenimiento + horas de incidencias hoy es un push a Git. Tercero, rendimiento: carga casi instantánea desde cualquier punto, con la mejora correspondiente en experiencia de página. Y cuarto, la menos esperada: el flujo de trabajo. Escribir en Markdown, versionar cada cambio y publicar con un commit encaja de forma natural con un proceso de creación donde la IA participa — el blog se convirtió en parte del mismo entorno donde trabajo todo lo demás.

Lo perdido, porque siempre se pierde algo. La edición desde el navegador para cualquier persona sin perfil técnico: hoy, tocar esta web es tocar código, y aunque monté un CMS ligero para ediciones puntuales, el WordPress clásico sigue siendo insuperable en eso. La inmediatez del ecosistema: en WordPress cualquier necesidad tiene un plugin a un clic; en un stack estático, la tiene a un rato de desarrollo. Y unas semanas de mi vida peleando con un bucle de redirecciones que no le deseo a nadie.

Lo que haría distinto: ir antes al plan B. Mi prudencia inicial — no tocar el blog, hacerlo convivir — era la decisión correcta sobre el papel y la equivocada en la práctica, porque subestimé el coste de la frontera entre sistemas. Si volviera a empezar, evaluaría la migración completa desde el día uno en vez de tratarla como último recurso. La versión general de esta lección la aplico ahora en cada proyecto de arquitectura web que tocamos en la agencia: antes de diseñar una convivencia entre sistemas, pregúntate si de verdad necesitas los dos.

¿Para quién SÍ y para quién NO es este camino?

Cierro con la parte que le falta a casi todo el contenido sobre este tema: la honestidad de decir a quién no le conviene. No migres a un stack estático si: tu web depende de plugins de negocio (tienda, reservas, membresías, LMS); publican varias personas sin perfil técnico; tu equipo no tiene a nadie que toque código con soltura ni presupuesto para apoyo técnico recurrente; o tu WordPress simplemente funciona y tus problemas reales están en otra parte — en ese caso, tu dinero rinde más en contenido o en captación que en re-plataformar, como argumenté en cómo conseguir un buen diseño web hablando de prioridades.

Considéralo seriamente si: tu web es fundamentalmente contenido; el rendimiento, la seguridad y el coste de infraestructura te importan; tienes perfil técnico o apoyo de alguien que lo tenga; y el flujo Markdown + Git encaja con cómo trabaja tu equipo. Para agencias y consultores, añado un motivo más: hacerlo en tu propia web es el mejor laboratorio posible. Todo lo que aprendí en esta migración — los límites de la IA como copiloto, el coste real de las fronteras entre sistemas, la lista de verificación SEO de una migración — lo aplico hoy en proyectos de clientes con la seguridad del que se ha operado a sí mismo primero.

Y la reflexión final, que va más allá de WordPress y de Astro: la IA no me migró la web. La IA hizo económicamente viable que yo la migrara — comprimió semanas de trabajo mecánico en días y me dio un par de manos incansables para el código repetitivo. Pero cada decisión que determinó el resultado (qué preservar, cuándo cambiar de plan, qué era aceptable romper) fue humana, y las veces que delegué el criterio en la máquina lo pagué. Es el mismo patrón que veo en cada rincón de este sector en 2026: la IA amplifica al que sabe adónde va. Al que no, también — pero en la dirección equivocada.