Migré mi blog de WordPress a Astro en un día con agentes de IA

Pagaba US$60 al mes por mantener este blog en WordPress. Hoy pago US$0. La migración completa a Astro (un generador de sitios estáticos, abajo explico qué es) la hicieron agentes de IA en un día: 368 contenidos, unos 300 redirects verificados y un Lighthouse que pasó de 72 a 100. Acá va por qué lo hice, cómo fue, y qué significa para ti si no sabes programar.

¿Por qué dejé WordPress después de 15 años?

No fue por la plata. US$720 al año duelen, pero no matan.

Fue porque WordPress se volvió el cuello de botella para operar con agentes de IA. Yo no publico a mano: tengo agentes que escriben borradores, suben imágenes, actualizan posts. Y cada automatización peleaba contra el hosting.

Ejemplos reales de mi día a día:

• Cloudflare bloqueaba los requests de mis agentes a la API de WordPress si no se hacían pasar por un navegador (error 1010). Un agente no es un navegador, así que había que disfrazarlo en cada integración.
• El acceso SSH venía con trampa: el PHP por defecto era 7.4 y mis plugins exigían 8.3, así que wp-cli (la herramienta de línea de comandos de WordPress) se rompía sin decir por qué.
• El caché de páginas tardaba horas en reflejar un cambio. Publicabas algo y el sitio seguía mostrando la versión vieja.
• Cada integración pedía su App Password, su configuración, su excepción.

Cuando tu sistema de publicación necesita más mantenimiento que tu contenido, el sistema sobra.

Y ojo con esto, porque yo no era un usuario casual de WordPress. Llegué a construir mi propia familia de plugins optimizados para sacarme de encima a los comerciales: uno de SEO que reemplazó a Rank Math, uno de redirecciones que resolvía todo con una sola consulta a la base de datos, uno de links internos por palabra clave, uno de captura de emails. Plugins livianos, sin trackers, hechos a mano. Funcionaban bien.

Pero ese era exactamente el problema: cada plugin propio es código que TÚ mantienes. Cada actualización de WordPress o de PHP podía romper algo, y el que debuggeaba era yo. El costo de WordPress no era la suscripción del hosting. Era mi tiempo defendiendo infraestructura en vez de creando.

Hoy esos plugins ya no existen porque no hay nada que parchar: las redirecciones son un archivo de texto, el SEO viene en el código del sitio, y la captura de emails es una función de 80 líneas que no se actualiza sola un martes a las 3am.

Hoy publicar es esto: un agente escribe un archivo Markdown (texto plano con formato simple), hace un git commit (guarda el cambio en el historial del proyecto) y el sitio se actualiza solo en 2-3 minutos. Sin servidor, sin base de datos, sin plugins.

¿Cómo se migra un blog completo en un día?

Apalancado en Claude Code, la herramienta de Anthropic para dirigir agentes desde la terminal. Yo no escribí el código de la migración. Dirigí a los que lo escribieron:

• Un agente exportó los 368 contenidos: 304 posts desde 2011, 45 episodios del podcast, 2 libros y las páginas.
• Un panel de agentes estresó el plan antes de ejecutarlo, cada uno buscando dónde podía fallar.
• Un revisor de UI/UX encontró 110 reglas CSS rotas que el sitio venía arrastrando.
• El resultado se auditó contra mi propio curso de SEO (MC-05), para no romper lo que ya rankeaba.

Lo crítico fue la paridad de URLs 1:1. Cada post quedó en la misma dirección exacta que tenía en WordPress, y los ~300 redirects se verificaron con scripts, no a ojo. Las 129 categorías que acumulé en 15 años se consolidaron en 6.

Tampoco partí de cero: el sitio del podcast, eslahoradeaprender.com, ya corría con este mismo stack. Ese precedente bajó el riesgo.

Y dejé red de seguridad: el WordPress quedó intacto 30 días por si algo fallaba. No falló.

Los resultados en números

Métrica	Antes (WordPress)	Después (Astro)
Hosting	US$60/mes	US$0
Lighthouse performance	72	~92-95
LCP (cuánto tarda en verse el contenido principal)	6.9s	2.7s
SEO / Accesibilidad / Best practices	mejorables	100/100/100
Publicar un post	editor + plugins + esperar caché	1 archivo + 1 commit, live en 2-3 min

El LCP de 6.9 segundos tenía un culpable concreto: una sola imagen de 873KB. Quedó en 33KB como WebP. El resto vino de fuentes self-hosted, CSS inline y variantes WebP automáticas para todas las imágenes.

También preparé el sitio para los motores de IA, no solo para Google: un llms.txt y un llms-full.txt con todo el contenido en texto plano (1.6MB), un posts.json que funciona como API estática para agentes, y un robots.txt con permiso explícito para GPTBot, ClaudeBot y PerplexityBot. Tres sitemaps: 695 URLs, 408 imágenes y video.

Un detalle que no podía fallar: la captura de email sobrevivió. El formulario ahora corre como función de Cloudflare con respaldo directo a mi servidor de correo. Si n8n, la herramienta con la que automatizo mi negocio, se cae, la suscripción no se pierde. Lo probé de punta a punta el mismo día.

¿Y si no sabes programar?

Este es el punto que más me interesa que te lleves.

Hace dos años esta migración era un proyecto de semanas con un desarrollador. Hoy es un día dirigiendo agentes. Yo puse el criterio: qué migrar, qué no se podía romper, cuándo parar a revisar. Los agentes pusieron el trabajo.

Si no eres técnico, no necesitas entender Astro ni git. Necesitas entender que ya puedes tener un sitio rápido, gratis y sin mantenimiento, con un agente haciendo el trabajo pesado mientras tú apruebas el resultado. Es el mismo método que uso para elegir modelos de IA: probar con casos reales propios antes que confiar en la teoría.

Qué revisar antes de migrar tu sitio

Si estás pensando en hacer lo mismo, este es el checklist que usé. No es teoría: cada punto viene de algo que podía salir mal hoy.

• Inventario de URLs con tráfico real. Saqué de Search Console todas las páginas con clics de los últimos 90 días. Esas son intocables: misma URL o redirect. En mi caso el 72% del tráfico vivía en 2 posts — si algo se rompía ahí, la migración era un fracaso aunque todo lo demás funcionara.
• Los redirects existentes también migran. Mi WordPress arrastraba ~190 redirects de reorganizaciones viejas. Si los pierdes, los links externos de 15 años mueren en silencio.
• Lo que captura dinero o emails no puede caer ni un día. Mi formulario de suscripción fue lo último que validé antes de cambiar el DNS y lo primero que probé después.
• Backup completo descargado ANTES de apagar nada. Base de datos y archivos, verificados en tu disco, no “en el hosting”. El hosting viejo queda vivo unas semanas como plan B.
• Monitoreo después del corte. Search Console te muestra los 404 nuevos en días. Cada uno se arregla con una línea de redirect — pero solo si estás mirando.

La lección: el riesgo real es el SEO

Migrar un sitio con 15 años de historia puede destruir tu tráfico orgánico si lo haces mal. Una URL que cambia sin redirect es tráfico que no vuelve.

La mitigación fue aburrida a propósito: mismas URLs, mismos títulos y descripciones, ~300 redirects verificados con scripts y monitoreo en Search Console. Google re-crawleó e indexó el sitio el mismo día.

La velocidad la pusieron los agentes. El checklist de qué no romper lo puse yo. Esa es la combinación que te recomiendo: deja que la IA ejecute, pero los riesgos los defines tú antes de partir.

Esto es una parte chica de cómo opero mi negocio con agentes. Si quieres ver los sistemas completos, documentados paso a paso, están en mi comunidad Cágala, Aprende, Repite. Y si quieres contexto de quién escribe esto, está en sobre mí.