Doce meses migrando de WordPress a Astro en Cloudflare Pages

El cambio de plataforma de WordPress a Astro debía representar el proyecto por completo. Resultó ser, no obstante, un mero prólogo. Exportar el contenido desde las bases de datos MySQL, reconstruir las plantillas en componentes Astro con Tailwind CSS y lograr que un sitio estático compilara y se desplegara en Cloudflare Pages tomó escasas semanas. Después dio comienzo el verdadero año de ingeniería: redirecciones, grafos hreflang, paridad estricta entre seis idiomas y un proceso de compilación que superó la infraestructura sobre la que se ejecutaba. Este es un informe técnico sobre dónde se invirtieron realmente los recursos.

La polémica se dirige contra la visión superficial del cambio de plataforma como un simple traslado de plantillas. “Pasar de WordPress a un sitio estático” suena a una migración puntual. Para un portal de contenidos multilingüe, significa más bien asumir el control y la responsabilidad directa sobre tres sistemas fundamentales que WordPress solía ocultar: la capa de enrutamiento perimetral, el proceso de compilación en memoria y la coherencia de la estructura entre mercados lingüísticos. Ninguno de estos retos es inalcanzable, pero todos exigen una rigurosa disciplina de ingeniería.

[!NOTE] El caso de un vistazo

• Proyecto: wppoland.com migrado de WordPress a Astro en Cloudflare Pages, una reconstrucción interna de nuestro propio portal
• Alcance: seis idiomas, más de 14.000 páginas prerenderizadas con slugs descriptivos y malla hreflang completa
• Plazo: semanas hasta un build estático funcional, alrededor de doce meses hasta una visibilidad orgánica estable y sin caídas
• Build: superó el techo de 8 GB de RAM del runner de Cloudflare Pages, resuelto compilando en local con un heap de 16 GB y desplegando el artefacto mediante Wrangler
• Redirecciones: miles de reglas 301 que chocaron con el límite de 100 KB de _redirects y fueron migradas a una capa de Cloudflare Functions
• Stack: Astro con Tailwind CSS, pipeline de imágenes AVIF, HTML estático servido desde el borde global
• Resultado: TTFB global inferior a 40 ms, superficie de ataque dinámica nula, rastreo predecible para modelos de IA, paridad total entre seis idiomas

#Migración de WordPress a Astro, el coste real: TL;DR en 4 puntos

1. El traslado es la parte barata. Las plantillas y la exportación de contenidos tomaron semanas; la migración necesitó alrededor de doce meses para consolidar el posicionamiento en buscadores sin regresiones de tráfico.
2. La capa de redirecciones es la primera gran sorpresa. Miles de URLs históricas requieren reglas 301 exactas, y ese volumen chocó con un límite de 100 KB en Cloudflare Pages que descartaba reglas en silencio.
3. La paridad entre seis idiomas es trabajo permanente, no un hito cerrado. El hreflang, las URLs canónicas y la estructura de secciones deben permanecer sincronizados en cada versión de idioma.
4. El build superó la capacidad del runner estándar en la nube. Un límite de 8 GB de memoria es insuficiente para compilar 14.000 páginas prerenderizadas; la respuesta fue compilar localmente con 16 GB de heap y desplegar el artefacto terminado vía CLI.

#Glosario: build estático, prerender, hreflang, borde

El informe se apoya en los siguientes conceptos clave de arquitectura:

• Build estático - todo el portal se convierte previamente en archivos HTML puros durante la fase de compilación, en lugar de procesarse dinámicamente ante cada petición.
• Prerender - generación anticipada del árbol DOM completo de cada página en archivos físicos al compilar. En seis idiomas, el volumen total se multiplica por el número de variantes regionales.
• Cloudflare Pages - plataforma de alojamiento que sirve los archivos precompilados desde la red perimetral global (CDN) y ejecuta lógica serverless a través de Pages Functions.
• Wrangler - herramienta de línea de comandos de Cloudflare, empleada para desplegar directamente el directorio dist/ compilado, evitando las limitaciones del entorno remoto.
• Hreflang - atributos de cabecera HTML que indican a los motores de búsqueda cuáles son las páginas equivalentes en otros idiomas.
• Redirección 301 - instrucción HTTP permanente que transfiere la autoridad y el historial de indexación de una URL antigua a su nueva ubicación.

#Semanas: el traslado que todo el mundo presupuesta

La fase visible de la migración es la única habitualmente presupuestada, y la estimación inicial suele ser acertada. El contenido se exporta desde las tablas MySQL de WordPress hacia archivos Markdown con frontmatter YAML. Las plantillas PHP y temas se reescriben en componentes Astro con Tailwind CSS. El build compila sin errores y el despliegue se publica en Cloudflare Pages. Un sitio de contenido de tamaño moderado alcanza un build funcional en pocas semanas. Esta es la fase visualmente gratificante que convence a los equipos de que el proyecto está prácticamente finalizado.

En la práctica, el proyecto se encuentra únicamente en el umbral de sus verdaderos retos técnicos. Un build que funciona solo demuestra que los componentes Astro ensamblan HTML sin fallos de sintaxis. No garantiza que miles de URLs históricas sigan resolviendo el tráfico correctamente, que las relaciones hreflang permanezcan coherentes en el índice de Google o que el proceso Node.js mantenga la estabilidad ante el futuro crecimiento de contenidos.

#Meses: la capa de redirecciones que nadie programó

El primer trimestre tras el lanzamiento inicial estuvo dominado por la ingeniería de redirecciones. Cada URL que WordPress generó desde 2006 (archivos por fecha, categorías, taxonomías de plugins y slugs históricos) requería una redirección 301 rigurosa hacia su nueva ruta en Astro. Sin un mapa completo de redirecciones, los errores 404 aumentaban en Google Search Console y la autoridad orgánica acumulada se evaporaba.

En un sitio monolingüe, este proceso se gestiona con una hoja de cálculo. En un entorno con seis idiomas y slugs traducidos (direcciones en español, inglés, alemán, polaco, noruego y portugués), la matriz superó las 18.000 reglas individuales.

Fue entonces cuando apareció un límite no documentado de Cloudflare Pages: el archivo _redirects tiene un tope estricto de 100 KB. Por encima de ese tamaño, el analizador de la plataforma descarta silenciosamente las líneas sobrantes sin emitir advertencias durante el despliegue. Las primeras reglas funcionaban, mientras que las posteriores devolvían errores 404. La solución definitiva consistió en trasladar toda la lógica a un middleware en TypeScript (functions/redirect-map.ts), que realiza búsquedas en memoria con complejidad O(1) directamente en el borde.

#Meses: seis idiomas que tienen que concordar para siempre

En arquitecturas WordPress tradicionales, plugins como WPML o Polylang gestionan las relaciones multilingües mediante tablas de base de datos. En una arquitectura estática SSG, todas las relaciones quedan expuestas directamente en los archivos y en el marcado.

Las seis versiones lingüísticas de cada artículo deben mantenerse estrictamente paralelas a lo largo del tiempo:

• Misma jerarquía de encabezados H2 y H3 en idéntico orden lógico.
• Malla bidireccional completa de enlaces hreflang en el encabezado HTML hacia las cinco variantes hermanas.
• URLs canónicas exactas que reflejen la estructura regional de enrutamiento.
• Coherencia en la categorización y taxonomías en todos los mercados.

Cuando una variante idiomática se desfasa (por ejemplo, al añadir una subsección o modificar un slug de forma aislada), los motores de búsqueda comienzan a ignorar las señales hreflang debido a asimetrías. Esto provoca canibalización de palabras clave entre países. Para evitarlo, implementamos scripts automatizados de validación de paridad que se ejecutan antes de cada commit.

#Topología de memoria en Node.js con 14.000 páginas prerenderizadas

Astro compila y genera páginas estáticas en un único proceso de trabajo. Cuando el catálogo superó las 14.000 páginas (artículos técnicos, páginas de servicios, estudios de caso y guías locales en 6 idiomas), el límite estándar de 4 GB de heap del motor V8 se agotó con rapidez.

El runner por defecto de Cloudflare Pages ofrece 8 GB de RAM. Durante la validación intensiva de esquemas TypeScript, la transformación de árboles sintácticos MDX (AST) y la optimización de CSS, el proceso sufría caídas fatales con errores JavaScript heap out of memory.

Reestructuramos todo el flujo de integración y despliegue:

1. Compilación local en procesadores Apple Silicon: El build se ejecuta localmente en chips de la serie M con asignación explícita de memoria mediante NODE_OPTIONS='--max-old-space-size=12288'. La máquina compila 14.477 páginas HTML en menos de 3,5 minutos gracias a un procesamiento multihilo eficiente.
2. Limpieza de artefactos de prerenderizado: Astro genera el directorio dist/.prerender para módulos de servidor. Ciertos archivos alcanzaban 43,9 MiB, superando el límite de 25 MiB por archivo de Cloudflare Pages. El script de despliegue elimina automáticamente estos módulos internos antes de la subida.
3. Despliegue directo mediante Wrangler: El directorio dist/ verificado se transfiere directamente a la red perimetral de Cloudflare, eliminando etapas frágiles en la nube con control determinista de artefactos.

#Generación modular de sitemaps y grafo canónico

Otro desafío fundamental residió en la arquitectura de los mapas del sitio (sitemaps). La integración predeterminada @astrojs/sitemap creaba un único archivo XML gigantesco para 14.000 URLs, sobrepasando los límites de los rastreadores e ignorando directivas específicas de no indexación.

Desarrollamos un generador modular que produce una estructura jerárquica de 32 archivos XML:

• Un archivo principal sitemap-index.xml que apunta a 6 índices regionales (sitemap-es.xml, sitemap-en.xml, etc.).
• Cada índice regional se divide en archivos temáticos: artículos de blog, páginas de servicios, casos de estudio y directorios locales.
• Un filtro estricto que excluye automáticamente todas las páginas con la directiva noindex (supervisado por el validador check:noindex-sitemaps).

Esta segmentación permite a los motores de búsqueda y rastreadores de IA procesar los sitemaps de forma escalonada sin sufrir problemas de tiempo de espera.

#Las herramientas que reconstruyes y que WordPress daba gratis

Un coste que suele pasarse por alto al abandonar un CMS es la necesidad de reconstruir los mecanismos de control que WordPress y sus plugins ejecutaban de manera invisible. WordPress impedía la duplicación de slugs, garantizaba la integridad relacional en MySQL y alertaba sobre hipervínculos rotos. En un sistema estático, cualquier errata en el frontmatter llega directamente a producción si no existen pruebas automáticas.

A lo largo de doce meses, desarrollamos una batería de 34 puertas de calidad automatizadas (run-gates.mjs), ejecutadas antes de cada publicación:

• Integridad de enlaces internos (check:links y check:service-navigation-parity): Rastrea todas las rutas para evitar enlaces rotos 404 y asegura que cada servicio principal cuenta con al menos dos enlaces internos entrantes.
• Control de juegos de caracteres y diacríticos (check:diacritic-wordlist): Detecta fallos de codificación y caracteres incorrectos en los seis idiomas soportados.
• Protección de tarifas comerciales (check:no-own-prices): Garantiza que no se filtren tarifas horarias o presupuestos no autorizados en guías técnicas fuera de las páginas de precios oficiales.
• Validación de Content Security Policy (check:csp-inline): Calcula hashes criptográficos SHA-256 para todos los scripts integrados en el HTML final, aplicando cabeceras CSP estrictas sin unsafe-inline.
• Auditoría de retórica de IA (check:slop-rhetoric): Identifica y elimina expresiones vacías de marketing, asegurando un tono rigurosamente técnico y fundamentado en datos.

#Colecciones de contenido con tipado estricto mediante esquemas Zod

A diferencia de WordPress, donde los campos personalizados (ACF) se almacenan como metadatos no estructurados en la tabla wp_postmeta, Astro impone tipado estricto mediante Content Collections con esquemas Zod:

• Tipado obligatorio de metadatos: Cada documento Markdown o MDX se valida contra un esquema Zod durante la compilación. Si falta un campo requerido como title, description, canonicalUrl o una fecha ISO mal formateada, el build se detiene de inmediato indicando la línea exacta del error.
• Automatización de Schema.org JSON-LD: Los datos estructurados para buscadores (Article, FAQPage, HowTo, Organization) se generan con seguridad de tipos directamente desde el frontmatter, eliminando discrepancias en el índice de Google.
• Resolución de relaciones en compilación: Las referencias cruzadas entre autores, categorías y versiones idiomáticas se resuelven en tiempo de compilación sin requerir operaciones JOIN complejas en bases de datos relacionales.

#Seguridad empresarial y Content Security Policy (CSP) automatizada

Un punto crítico en instalaciones maduras de WordPress es el riesgo de Cross-Site Scripting (XSS) provocado por extensiones de terceros que inyectan scripts no controlados en el DOM. En una arquitectura estática con Astro, la seguridad se establece de forma determinista en el propio build:

1. Eliminación total de unsafe-inline: En lugar de permitir políticas permisivas, un paso de validación (check:csp-inline) calcula hashes criptográficos SHA-256 para cada script en línea necesario.
2. Distribución estricta de cabeceras en el borde: La política de seguridad se aplica directamente en las cabeceras HTTP de Cloudflare Pages, incluyendo Strict-Transport-Security: max-age=63072000; includeSubDomains; preload, X-Content-Type-Options: nosniff y Referrer-Policy: strict-origin-when-cross-origin.
3. Aislamiento de servicios de terceros: Las herramientas de analítica se configuran mediante Permissions-Policy, bloqueando accesos innecesarios a APIs sensibles del navegador.

#Pipelines de medios y tipografía local en cumplimiento con el RGPD

En entornos WordPress, la optimización de imágenes ocurre durante la subida al panel mediante GD o ImageMagick. En Astro, el procesamiento de medios se integra directamente en la cadena de compilación.

El procesamiento descuidado de miles de imágenes de alta resolución provocaba inicialmente problemas de memoria en la librería Sharp. Establecimos una clara diferenciación técnica:

1. Recursos estáticos preoptimizados: Los fondos decorativos se convierten previamente a formatos AVIF y WebP en el directorio public/, entregándose directamente por CDN sin consumir recursos del compilador.
2. Dimensiones deterministas: Todas las imágenes en el cuerpo de los artículos cuentan con atributos explícitos de width y height, erradicando cualquier salto visual de diseño (Cumulative Layout Shift, CLS = 0.00).
3. Fuentes alojadas localmente: Suprimimos todas las llamadas externas a Google Fonts. Las familias tipográficas se sirven localmente en formato WOFF2 con subconjuntos latinos, evitando el bloqueo del renderizado y cumpliendo estrictamente con el RGPD europeo.

#Arquitectura de islas (Astro Islands) para interactividad sin peso de JavaScript

La principal ventaja arquitectónica de Astro es el principio de cero JavaScript por defecto (Zero-JS by default). Los visitantes que consultan artículos técnicos descargan exclusivamente HTML y CSS sin frameworks pesados.

En los puntos donde la interactividad resulta imprescindible (como formularios de contacto, filtros o calculadoras), aplicamos Astro Islands:

• El formulario de contacto se carga como una isla aislada mediante client:visible, aplazando la descarga del script hasta que el usuario se desplaza hasta el elemento.
• Los filtros y selectores emplean client:idle para ejecutar scripts en periodos de inactividad del navegador, manteniendo el hilo principal despejado.
• Los componentes de navegación responsive utilizan client:media="(max-width: 768px)", evitando que los usuarios en equipos de sobremesa descarguen código de menús móviles.
• La mitigación de spam se gestiona mediante Cloudflare Turnstile invisible, sin pruebas visuales molestas.
• Los envíos de formularios se procesan sin estado a través de un endpoint en el borde conectado a webhooks transaccionales (Resend), sin necesidad de mantener servidores activos.

#Búsqueda estática en WASM en el cliente sin servidor de base de datos

Tradicionalmente, WordPress realizaba las búsquedas mediante consultas SQL a wp_posts. En una arquitectura estática pura, la búsqueda de texto completo debe operar íntegramente en el cliente:

• Durante la compilación, se genera un índice léxico compacto y segmentado a partir de los textos de los artículos, excluyendo menús y código repetitivo.
• El navegador descarga únicamente los fragmentos del índice (15-30 KB) correspondientes a los términos introducidos, mostrando resultados con búsqueda aproximada (fuzzy search) y resaltado en menos de 15 ms.
• Diccionarios de palabras vacías (stop-words) en seis idiomas aseguran máxima precisión con un consumo mínimo de datos.
• La carga en el servidor se mantiene en cero, con independencia del volumen de búsquedas concurrentes.

#Automatización continua de Core Web Vitals en CI/CD

En instalaciones WordPress, las métricas de rendimiento suelen degradarse silenciosamente tras actualizar plugins. En Astro, los límites de rendimiento se controlan programáticamente en el flujo de publicación:

• Lighthouse CI: Cada compilación pasa auditorías automáticas que exigen Largest Contentful Paint (LCP < 1.0s), Interaction to Next Paint (INP < 50ms) y Cumulative Layout Shift (CLS = 0.00).
• Pruebas de regresión visual: Pruebas automáticas con Playwright verifican la integridad visual en resoluciones móviles y de escritorio antes de la fusión de ramas.
• Purga inmediata de caché en el borde: Al publicar, el script acciona la API de Zona de Cloudflare (purge_cache: {"purge_everything": true}), garantizando que todos los nodos globales sirven al instante el contenido renovado sin esperar a que expire s-maxage.
• Caché inmutable para recursos con hash: Los archivos CSS, JS e imágenes AVIF se entregan con Cache-Control: public, max-age=31536000, immutable, mientras que los documentos HTML se gestionan con max-age=0, must-revalidate y etiquetas de caché perimetral.

#Lista de comprobación técnica: 10 pasos antes de desconectar WordPress

A partir de doce meses de experiencia en producción, esta lista resume las etapas críticas antes de cambiar los registros DNS:

1. Inventario exhaustivo de rutas: Exportar todas las URLs históricas desde MySQL en WordPress (artículos, páginas, archivos, categorías, feeds y adjuntos).
2. Diseño del mapa de redirecciones: Construir un mapeo 301 completo que contemple todas las variantes idiomáticas de cada slug.
3. Despliegue de Edge Functions: Implementar el motor de redirecciones en una Edge Function (Cloudflare Functions / Worker) para eludir los límites de archivos estáticos.
4. Validación de la malla hreflang: Comprobar que todas las versiones de idioma cuentan con enlaces recíprocos perfectos en todo el portal.
5. Auditoría de esquemas JSON-LD: Validar esquemas Article, FAQPage, HowTo y Organization conforme a las especificaciones de schema.org.
6. Despliegue de sitemaps modulares: Segmentar los mapas XML y aplicar filtros que excluyan taxativamente páginas marcadas con noindex.
7. Perfilado de memoria y build: Probar la compilación bajo restricciones de memoria y optimizar el heap del motor V8.
8. Configuración de cabeceras de seguridad: Aplicar CSP, HSTS, X-Frame-Options y Permissions-Policy a nivel de CDN.
9. Auditoría de indexabilidad: Garantizar que entornos de prueba y duplicados estén excluidos de la indexación.
10. Pruebas de humo tras el cambio de DNS: Configurar pruebas automáticas de respuesta HTTP y monitorizar Search Console inmediatamente tras la propagación.

#Lo que la migración compró de verdad: resultados tras 12 meses

Tras doce meses de recopilación continua de métricas en producción, el balance de la migración a Astro en Cloudflare Pages es rotundamente positivo para nuestra plataforma técnica:

1. Tiempo de respuesta del servidor (TTFB): Reducción de una media de 650-1200 ms (bajo carga de PHP y MySQL) a valores estables de 25-45 ms desde cualquier nodo de Cloudflare en el mundo.
2. Eliminación de vectores de ataque: La supresión del intérprete PHP, la base de datos SQL y el panel wp-admin eliminó el 100 % de los ataques habituales en CMS (inyecciones SQL, vulnerabilidades de plugins, fuerza bruta).
3. Accesibilidad para motores de búsqueda y modelos de IA: Un HTML limpio y semántico sin dependencias bloqueantes de JavaScript permite que buscadores y rastreadores de LLM (OpenAI, Anthropic, Perplexity) indexen los contenidos técnicos al instante (GEO/AEO).
4. Costes operativos predecibles: Servir archivos estáticos desde el borde tiene un coste marginal comparado con mantener clusters escalables de bases de datos ante picos de tráfico.
5. Cero tiempo de inactividad por mantenimiento: Las actualizaciones se despliegan de forma atómica en el borde sin que los visitantes experimenten interrupciones o errores de base de datos.

La conclusión técnica sincera: migrar de WordPress a Astro no es un simple rediseño estético. Es un proyecto integral de ingeniería de software donde la creación de plantillas es el paso más sencillo, residiendo el verdadero valor en la arquitectura de enrutamiento, las pruebas de calidad automatizadas y la disciplina multilingüe. Para organizaciones que buscan máximo rendimiento global y nulo coste de mantenimiento de servidores, es una inversión que ofrece rentabilidad en todas las áreas. Si deseas implementar esta arquitectura en tu empresa, consulta el trabajo de nuestro desarrollador Astro, o conoce nuestro servicio de migración de WordPress a Astro. Encontrarás más análisis de ingeniería en el blog técnico de WPPoland.