El cambio de plataforma de WordPress a Astro se suponía que era el proyecto. Resultó ser el prólogo. Exportar el contenido, reconstruir las plantillas, conseguir que un sitio estático compilara y se desplegara en Cloudflare Pages tomó semanas. Luego empezó el año de verdad: redirecciones, hreflang, paridad entre seis idiomas y un build que superó a la plataforma en la que se desplegaba. Este es un informe sobre dónde se fue el tiempo, porque el tiempo no se fue a donde decía la planificación.
La polémica, si la hay, es con el planteamiento del cambio de plataforma como un traslado. “Salir de WordPress hacia un sitio estático” suena a una migración única. Para un sitio de contenido multilingüe se parece más a asumir la responsabilidad de tres sistemas que WordPress solía ocultar: la capa de enrutamiento, el build y la estructura entre idiomas. Ninguno de ellos es difícil. Todos son continuos.
Migración de WordPress a Astro, el coste real: TL;DR en 4 puntos
- El traslado es la parte barata. Las plantillas y la exportación de contenido tomaron semanas; la migración necesitó alrededor de doce meses para alcanzar un rendimiento de búsqueda estable y sin regresiones.
- La capa de redirecciones es la primera sorpresa. Miles de URLs previamente indexadas necesitan cada una un 301, y el volumen chocó con un límite de tamaño de archivo de Cloudflare Pages que descartaba reglas en silencio.
- La paridad entre seis idiomas es trabajo continuo, no una tarea. El hreflang, las URLs canónicas y la estructura de secciones tienen que mantenerse alineados en cada versión de idioma, para siempre.
- El build superó al propio runner de Cloudflare. Un techo de build de 8 GB no basta para miles de páginas prerenderizadas; la respuesta fue construir localmente con un heap de 16 GB y desplegar el artefacto terminado.
Glosario: build estático, prerender, hreflang, borde
El informe se apoya en unos cuantos términos de plataforma.
- Build estático - todo el sitio se renderiza a archivos HTML simples de antemano, durante un paso de build, en lugar de por petición.
- Prerender - generar el HTML de cada página en tiempo de build. Un sitio con seis idiomas multiplica el número de páginas por el número de idiomas, así que el build escala con contenido por idiomas.
- Cloudflare Pages - el alojamiento. Sirve los archivos preconstruidos desde el borde de la red y también puede ejecutar el build, dentro de los límites de memoria.
- Wrangler - la herramienta de línea de comandos de Cloudflare, usada aquí para desplegar directamente un artefacto construido localmente, evitando el paso de build de la plataforma.
- Hreflang - los enlaces que indican a los motores de búsqueda qué página es la versión alemana, polaca o española del mismo artículo.
- Redirección 301 - una redirección permanente que traslada la señal de posicionamiento de una URL movida a su nueva dirección.
Semanas: el traslado que todo el mundo presupuesta
La migración visible es la parte que se estima, y la estimación es más o menos correcta. El contenido sale de WordPress, las plantillas se reconstruyen en Astro con Tailwind, un build compila, un despliegue aterriza en Cloudflare Pages. Un sitio de contenido de tamaño moderado alcanza un build estático que funciona en semanas. Esta es la fase que se demuestra bien y convence a todos de que el proyecto está casi terminado.
No está casi terminado. Está más allá de la parte que era fácil de predecir y llegando a la parte que nadie programó. El build que funciona prueba que las plantillas se renderizan; no prueba nada sobre si las URLs antiguas resuelven, si los idiomas concuerdan entre sí o si el build seguirá terminando cuando el contenido se triplique.
Meses: la capa de redirecciones que nadie programó
El primer mes de la cola larga se fue en redirecciones. Cada URL que WordPress hubiera expuesto alguna vez y que Google hubiera indexado alguna vez necesitaba un 301 a su nueva dirección de Astro, o se convertía en un 404 y la señal de posicionamiento se evaporaba. En un blog de un solo idioma eso es una lista larga. En un sitio con seis idiomas y slugs descriptivos llega a miles.
Ese volumen chocó contra un muro que tiene su propio informe de campo: Cloudflare Pages descarta en silencio las reglas de _redirects por encima de un límite de tamaño de archivo de 100 KB, sin ningún aviso, de modo que una parte del mapa de redirecciones se desplegó en verde y nunca se aplicó. El síntoma apareció meses después como errores 404 en Search Console y páginas de producto no disponibles en Merchant Center, mucho después de que la migración pareciera terminada. La lección se generaliza más allá de Cloudflare: en un cambio de plataforma, el mapa de redirecciones no es un punto de una lista de comprobación que se completa; es un sistema que se opera, con sus propios modos de fallo y su propia monitorización.
Meses: seis idiomas que tienen que concordar para siempre
WordPress, con los plugins adecuados, oculta la estructura multilingüe tras un panel de administración. Un build estático la deja al descubierto. Seis versiones de idioma de cada artículo tienen que mantenerse estructuralmente paralelas: los mismos encabezados de sección en el mismo orden, enlaces hreflang que de verdad resuelvan a cada versión hermana, URLs canónicas que apunten a donde deben, y URLs de taxonomía que coincidan entre idiomas. Cuando un idioma se desvía, el grafo de enlaces entre idiomas se agrieta en la capa de indexación mientras cada página sigue renderizando sin problemas.
Esto conecta directamente con un modo de fallo aparte en cómo la traducción por IA rompe el SEO multilingüe: las herramientas de traducción que tocan campos estructurales producen una deriva entre idiomas que es invisible en la página y cara en el índice. Tras la migración, la paridad dejó de ser un hito y pasó a ser una comprobación permanente, ejecutada en cada cambio de contenido, porque seis idiomas no se mantienen alineados por sí solos.
Las herramientas que reconstruyes y que WordPress daba gratis
Un coste más silencioso de dejar WordPress es que heredas la responsabilidad de comprobaciones que la plataforma y sus plugins solían realizar de forma invisible. WordPress validaba los enlaces internos a través de su editor, mantenía un sitemap actualizado a través de un plugin y avisaba sobre referencias rotas en el panel. Un build estático no hace nada de eso por sí mismo; o lo reconstruyes, o publicas regresiones.
A lo largo del año eso significó una pequeña biblioteca de validadores conectada al despliegue: validación de enlaces internos contra la superficie real de rutas para que un slug renombrado no pueda dejar enlaces colgantes, comprobaciones de datos estructurados para que el esquema del frontmatter se mantenga bien formado entre idiomas, comprobaciones de paridad que comparan las versiones hermanas en busca de secciones que falten, y un generador de sitemap y hreflang en tiempo de build. Cada una reemplaza algo que WordPress hacía en silencio. El saldo es más control y más confianza (las comprobaciones son explícitas, versionadas y se ejecutan en CI), pero es ingeniería real que la palabra migración no menciona. Quien dimensione un cambio de plataforma debería añadir esta partida: no solo estás moviendo el contenido, estás reimplementando las barreras de protección que la antigua plataforma aplicaba gratis.
Meses: el build que superó a su alojamiento
La última sorpresa fue mecánica. Cloudflare Pages sirve un sitio estático grande sin esfuerzo, pero construir uno está limitado por la memoria, y el propio runner de build de la plataforma topa en 8 GB. Un sitio Astro multilingüe con miles de páginas prerenderizadas, donde cada idioma multiplica la cuenta, necesita más heap que eso, y el build de la plataforma empezó a fallar con errores de falta de memoria que costó un tiempo reconocer por lo que eran.
La solución fue dejar de construir en la plataforma. El sitio ahora se construye localmente con un heap de 16 GB y el resultado terminado se envía a Cloudflare Pages con Wrangler, que despliega un artefacto sin reconstruirlo. Una máquina local de la serie M termina el build de forma fiable en minutos donde el runner limitado no podía terminarlo en absoluto. Las imágenes forzaron una disciplina relacionada: todo lo que pasa por el pipeline de assets de Astro se optimiza en tiempo de build, lo cual es excelente pero exigente en memoria, así que los fondos preoptimizados se sirven tal cual desde la carpeta public y solo las imágenes que se benefician del procesamiento se quedan en el pipeline, con un tamaño razonable para mantener el build por debajo de su techo.
Lo que la migración compró de verdad
Dicho sin rodeos para que el año no se lea como arrepentimiento: el cambio valió la pena. Las páginas se renderizan desde el borde como archivos estáticos, lo cual es más rápido y más estable que renderizar a petición, la superficie de ataque se redujo a aproximadamente nada dinámico, y el acceso de los rastreadores se volvió predecible en lugar de depender del comportamiento de los plugins. Para un sitio de contenido donde la velocidad, la estabilidad y ser legible de forma fiable por los rastreadores de búsqueda y de IA son el objetivo, ese es el intercambio correcto.
La salvedad honesta es la misma que debería preceder a cualquier cambio de plataforma: es el intercambio correcto para un sitio de contenido, y el equivocado para un sitio que vive de funcionalidad dinámica con sesión iniciada, donde la renderización a petición y el ecosistema de WordPress son la característica, no la carga. La decisión no es “lo estático es mejor”. Es “lo estático es mejor para esta forma de sitio, y aquí está el año de trabajo de cola que la palabra migración oculta”. Hay más informes de ingeniería de esta reconstrucción en el blog de wppoland.
