Diez 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 llegaron los verdaderos meses 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 mi propio portal
• Alcance: seis idiomas, 15.718 páginas prerenderizadas y 8180 direcciones en el mapa del sitio (build del 20.10.2026), con malla hreflang completa
• Plazo: inicio en diciembre de 2025 (el 2 de diciembre el sitio todavía funcionaba con WordPress, WPML y WP Rocket, según Wayback Machine; el repositorio de Astro se creó el 21 de diciembre), semanas hasta un build funcional, primera versión de este informe a los cinco meses, esta actualización a los diez
• 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: reglas 301 que chocaron con el límite de 100 KB de _redirects; hoy 3619 de ellas están en un mapa en Cloudflare Functions y 249 en _redirects
• Stack: Astro con Tailwind CSS, pipeline de imágenes AVIF, HTML estático servido desde el borde global
• Resultado: PageSpeed (laboratorio, móvil, 20.10.2026) 94 para la portada polaca y 98 para la página del servicio de Astro, sin PHP ni base de datos en producción, paridad total entre seis idiomas

#Cuánto cuesta migrar de WordPress a Astro

1. El traslado es la parte barata. Las plantillas y la exportación de contenidos tomaron semanas; tras diez meses, la cola larga de la migración todavía necesita correcciones.
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 más de 15.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.

#Cuánto se tarda en pasar de WordPress a Astro

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.

#Redirecciones 301 al migrar de WordPress a Astro

Cuando el build ya funcionaba, llegó el turno de 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 llegó rápido a miles de reglas. En octubre de 2026 el mapa en Cloudflare Functions tiene 3619 reglas y el archivo _redirects 249.

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.

#Cómo mantener hreflang sincronizado en seis idiomas

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, implementé scripts automatizados de validación de paridad que se ejecutan antes de cada commit.

#Error JavaScript heap out of memory en el build de Astro

Astro compila y genera páginas estáticas en un único proceso de trabajo. Cuando el catálogo superó las 14.000 páginas (en octubre de 2026 son 15.718) (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.

Reestructuré 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 un heap fijado de forma explícita (--max-old-space-size, 16 GB en el perfil de producción). El 20 de octubre de 2026, el paso astro build generó 15.718 páginas en 5 minutos y 30 segundos, y la subida con Wrangler tardó otros 338 segundos.
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.

#Cómo dividir el sitemap de Astro en varios archivos

Otro desafío fundamental residió en la arquitectura de los mapas del sitio (sitemaps). La integración predeterminada @astrojs/sitemap no conoce las reglas de indexación que aplico en cada colección (noindex, umbrales de extensión, páginas de ciudades).

Desarrollé un generador propio. En octubre de 2026 produce esta estructura:

• Un archivo principal sitemap-index.xml que enumera 24 mapas, cuatro por cada uno de los seis idiomas.
• Cada idioma tiene archivos propios para las páginas de servicios (sitemap-pages.xml), el blog, el portafolio y las páginas de ciudades (sitemap-locations.xml), 8180 direcciones en total.
• 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.

#Validaciones automáticas antes de desplegar un sitio Astro

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.

Hasta mayo de 2026 desarrollé 34 puertas de calidad automatizadas (run-gates.mjs); en octubre de 2026, npm run gates enumera más de 120. Algunos ejemplos:

• Integridad de enlaces internos (check:incoming-internal-links y check:service-navigation-parity): Comprueba que cada servicio recibe enlaces internos entrantes y que la navegación coincide en todos los idiomas.
• 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.

#Content collections de Astro con 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.

#Cómo configurar Content Security Policy sin unsafe-inline

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=31536000; 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.

#Optimizar imágenes y alojar fuentes en local con Astro

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. Establecí 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, lo que evita saltos de diseño (Cumulative Layout Shift).
3. Fuentes alojadas localmente: Suprimí todas las llamadas externas a Google Fonts. La fuente Geist se sirve desde mi propio dominio en archivos WOFF2 con el subconjunto latino (paquete @fontsource/geist), evitando el bloqueo del renderizado y cumpliendo estrictamente con el RGPD europeo.

#Cómo añadir JavaScript a formularios en un sitio estático con Astro

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 (el formulario de contacto, el buscador, las calculadoras), añadí un script pequeño solo en esa página:

• El formulario de contacto es HTML sencillo con un script breve en el componente, sin framework en el navegador.
• La mitigación de spam se gestiona con Cloudflare Turnstile, sin pruebas visuales.
• Los datos llegan a un endpoint en Cloudflare Pages Functions (functions/api/enquiry.ts), que envía el mensaje a través de Resend y, si Resend falla, a través de Web3Forms. No hay servidor de aplicación que mantener.

#Buscador en un sitio estático con Astro

Tradicionalmente, WordPress realizaba las búsquedas mediante consultas SQL a wp_posts. En una arquitectura estática pura, la búsqueda usa un índice generado en la compilación y se ejecuta en el navegador:

• Cada idioma tiene su propio archivo JSON (/api/search/<idioma>.json). La división por idiomas fue necesaria porque un único archivo compartido superaba el límite de 25 MiB por archivo de Cloudflare Pages.
• La página del buscador descarga el índice de su idioma y lo recorre en el navegador con la biblioteca Fuse.js. Cada archivo pesa hoy entre 7,7 y 9,4 MB, así que solo lo descarga quien abre el buscador, no cada lector.
• El servidor no hace ningún trabajo en las búsquedas, sea cual sea el número de usuarios. El coste es el tamaño del índice, que crece junto con el blog.

#Cómo medir Core Web Vitals tras migrar de WordPress a Astro

En instalaciones WordPress, las métricas de rendimiento suelen degradarse silenciosamente tras actualizar plugins. En Astro, vigilo el rendimiento así:

• Lighthouse en GitHub Actions: el flujo lighthouse.yml se lanza a mano o con una etiqueta en el pull request cuando cambian las plantillas o el diseño. No se ejecuta en cada commit, porque los minutos de Actions son limitados.
• Medición con PageSpeed Insights: el 20 de octubre de 2026, la puntuación de laboratorio en móvil fue 94 para /pl/ (LCP 2,7 s) y 98 para /en/astro-developer/ (LCP 2,3 s). Google todavía no muestra datos de campo de CrUX para estas direcciones, así que es una medición de laboratorio, no una evaluación de Core Web Vitals.
• 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.

#Checklist para migrar de WordPress a Astro

A partir de esta migració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.

#¿Debo pasar de WordPress a un sitio estático después de PHP2Shell?

El 21 de octubre de 2026 el proyecto PHP publicó correcciones para PHP2Shell, dos vulnerabilidades críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619). Según php.net, está en riesgo cualquier instalación de PHP que atienda peticiones web, y para la configuración de mayor riesgo existe un exploit demostrado que actúa antes de que arranque cualquier código de la aplicación (php.net). Wiz Research añade que incluso una simple aplicación “Hello World” en una versión afectada de PHP puede ser vulnerable (Wiz). Un sitio generado en archivos HTML y servido sin PHP queda fuera de ese aviso. Este sitio es uno de ellos: esa semana aquí no había PHP que actualizar. Qué hacer en un sitio que sigue funcionando con PHP lo explico en mi guía sobre PHP2Shell.

Esa misma semana, en r/webdev, el autor de una publicación técnica que pasó de WordPress a Hugo en Cloudflare Pages describió así lo que ganó en seguridad:

Para mí, lo que más gano es no tener un portal /wp-admin/ conocido por todos, expuesto y sondeado constantemente, y no tener que preocuparme después por las vulnerabilidades del stack que hay debajo.

(traducción propia, u/Select_From, r/webdev)

En otro hilo, un desarrollador contó que después de PHP2Shell había convertido 45 sitios WordPress de clientes a Astro en 36 horas con un agente de IA. Una de las primeras respuestas preguntó por la parte que un build estático deja sin resolver:

No paras de mencionar archivos estáticos en el README de GitHub, pero ¿qué pasa con las entradas nuevas? ¿Qué usas para que los clientes puedan añadir datos nuevos o editar los que ya existen?

(traducción propia, u/Lower_Rabbit_5412, r/webdev)

El autor respondió que había creado un CMS basado en Git para los 2 o 3 clientes que querían editar su sitio. La superficie de ataque de PHP desaparece, y cada tarea dinámica que WordPress resolvía en un solo lugar se va a otro sitio y necesita su propio responsable:

Una respuesta en el hilo de Hugo ordenó los problemas tal como me los encontré yo:

El mayor obstáculo suelen ser los permalinks, cada URL antigua necesita un 301 o pierdes posiciones. Luego las partes dinámicas: comentarios, búsqueda, formularios.

(traducción propia, u/ResidentPomegranate6, r/webdev)

Portar las plantillas me llevó semanas, y los meses siguientes se fueron en redirecciones, hreflang y las comprobaciones descritas arriba. Migrar significa reconstruir el sitio.

Las actualizaciones y el mantenimiento continuo suelen ser la mejor respuesta. PHP2Shell se cerró con una actualización de PHP, y una migración que dura semanas no ayuda a un servidor que hoy sigue sin parchear. Quédate con WordPress, WooCommerce, Magento u otro stack PHP y mantenlo al día si tu equipo edita en el panel cada día, si tu negocio depende de plugins con lógica real (tienda, reservas, membresías, cursos) o si nadie del equipo va a hacerse cargo de un flujo de trabajo con Git. Un build estático encaja cuando el contenido cambia poco, lo editan pocas personas y la parte dinámica se reduce a un formulario y un buscador. Un sitio en PHP necesita mantenimiento de WordPress periódico con actualizaciones de PHP; la reconstrucción como sitio estático es trabajo de un desarrollador Astro.

Actualización del 24 de octubre de 2026, un camino intermedio: quedarse en WordPress o rehacer la web en Astro no son las dos únicas opciones. Matt Cromwell contó el 14 de octubre de 2026 cómo rehízo la web de su empresa sin una instalación pública de WordPress. WordPress funciona solo en su ordenador, en WordPress Studio; un compilador convierte su sistema de diseño en theme.json y patrones de bloques reutilizables; el plugin Simply Static exporta la web a archivos estáticos, y Cloudflare Pages los sirve. Conserva el editor de bloques, y la web pública ya no tiene PHP que parchear. El trabajo extra está en los formularios: un plugin de formularios que envía por PHP no funciona en páginas exportadas, así que escribió un endpoint aparte que manda las altas del boletín a MailerLite por su API. También advierte que una web estática tiene límites propios, ajenos al plugin. Encaja en una web corporativa que se edita desde un solo ordenador. Una tienda, una zona de socios o un equipo que publica a diario siguen necesitando un servidor. Si la edición tiene que estar en línea y la parte pública debe funcionar sin PHP, eso ya es un montaje de CMS headless.

#¿Qué resultados da migrar a Astro tras diez meses?

Tras diez meses, el balance de la migración a Astro en Cloudflare Pages es positivo para mi plataforma técnica:

1. Tiempo de respuesta del servidor (TTFB): Una página servida desde la caché perimetral de Cloudflare responde desde Gdynia en unos 0,21 a 0,26 s, incluida la conexión TLS (curl, 20.10.2026). No tengo una medición comparable de la época de WordPress, así que no doy un porcentaje de mejora.
2. Menor superficie de ataque: Sin PHP, base de datos SQL ni wp-admin desaparecen clases enteras de ataques típicos de WordPress: inyección SQL, ejecución de código a través de un plugin vulnerable, fuerza bruta contra el inicio de sesión. Queda una superficie menor que vigilar: los endpoints en Cloudflare Functions (formulario, API) y las cabeceras de seguridad.
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 sitios de contenido que valoran la velocidad y el alcance en varios idiomas, este trabajo compensa. Si deseas implementar esta arquitectura en tu empresa, consulta mi trabajo como desarrollador Astro, o conoce mi servicio de migración de WordPress a Astro. Encontrarás más análisis de ingeniería en el blog técnico de WPPoland.