Cómo portamos La Voz de Maipú a Astro

WordPress se quedó de base de datos, Astro pasó a renderizar el sitio y el cambio se hizo con una ruta de Cloudflare reversible en segundos. Los números, el método y lo que se rompió.

El punto de partida

La Voz de Maipú es un medio local con más de veinte mil notas publicadas desde 2004 y una audiencia que llega mayoritariamente desde el celular. Corría sobre WordPress con el stack habitual de un medio: constructor visual, plugin de SEO, plugin de caché, publicidad de dos servidores distintos y quince años de decisiones acumuladas.

El diagnóstico no era una sensación, era una medición. Con Lighthouse en móvil, contra el sitio en vivo:

• Portada: 68 de 100 · LCP 6,7 s · 4.514 KB transferidos · 75 requests.
• Nota individual: 66 de 100 · LCP 6,5 s · 1.860 KB · 99 requests.

Noventa y nueve peticiones para mostrar un titular, una foto y ochocientas palabras. La mayoría no era contenido: era CSS del constructor, scripts de plugins, terceros de medición y publicidad.

La decisión: headless, sin migrar contenido

La tentación en este punto es “cambiar de CMS”. No hicimos eso. WordPress se quedó exactamente donde estaba, pero cumpliendo un solo rol: guardar el contenido y exponerlo por API. Dejó de dibujar el sitio y dejó de ser el lugar donde se trabaja — la redacción hoy publica desde una webapp propia, que es tema de otra nota. Lo que se reemplazó en este proyecto fue solamente la capa que renderiza.

Eso definió tres reglas que ordenaron todo el proyecto:

• Cero migración de contenido. Las veinte mil notas no se movieron ni un byte. Astro las lee por la API de WordPress.
• Las URLs no cambian. Un medio vive de su archivo indexado. Cualquier plan que implicara redirecciones masivas quedaba descartado de entrada.
• Lo que ya funcionaba, sigue funcionando. Las herramientas internas del medio —la webapp de publicación y el sistema de suscripciones— siguen hablándole al mismo WordPress por la misma API, sin enterarse del cambio. Cero trabajo de adaptación en ese lado.

Primero el benchmark, después el sitio

Antes de comprometer un proyecto completo, reconstruimos en Astro la portada y una nota real, y las medimos contra las mismas páginas en producción. Cuatro días de trabajo para tener un argumento con números en vez de una promesa.

Resultado del ejercicio, contra el sitio en vivo:

• Portada: de 68 a 83 puntos, peso −54 %, requests de 75 a 15.
• Nota: de 66 a 95 puntos, peso de 1.860 KB a 276 KB (casi siete veces más liviana), requests de 99 a 9.
• Total Blocking Time: 0 ms en ambas. Sin JavaScript que bloquee el pintado.

El benchmark también dejó ver el techo. El punto débil era la portada, porque pedía las fotos destacadas a tamaño completo. Pedirle a WordPress los tamaños que ya genera y armar srcset —sin infraestructura nueva, sin CDN de imágenes— subió la portada de 83 a 96 y bajó el LCP a 2,7 s.

Una salvedad que dejamos escrita en el informe y que repetimos acá: WordPress corría en su servidor real y Astro corría local, así que parte de la ventaja de tiempos venía de no pagar la red. El peso y la cantidad de requests, en cambio, son independientes de dónde corra cada uno, y son los que sostienen el argumento de verdad.

El cambio en vivo, sin tocar el DNS

Esta es la parte que más miedo da y la que mejor resultó. No hubo cambio de DNS, ni subdominio nuevo, ni ventana de mantención con el sitio caído.

El dominio ya pasaba por Cloudflare. Activamos una Workers Route en el dominio completo, que hace que Cloudflare ejecute el sitio Astro en vez de ir al WordPress. La pieza clave son las rutas de exclusión: /wp-json, /graphql, /wp-content, /wp-admin y los sitemaps siguen yendo al WordPress directo. Así el sitio nuevo atiende a los lectores y el WordPress sigue respondiendo la API que consumen las herramientas internas, en el mismo dominio y al mismo tiempo.

Lo hicimos en dos fases: primero se crearon todas las exclusiones (inofensivas, porque esos paths ya iban al WordPress) y solo después se activó la ruta del sitio nuevo. Ese orden importa: al revés, la API se cae y con ella todo lo que publica.

Lo mejor del método es el rollback. Desactivar una sola ruta devuelve el sitio a WordPress en segundos, sin desplegar nada y sin esperar propagación. Con esa red bajo el pie, el cambio se hizo en ventana de bajo tráfico verificando en vivo, con la portada y una nota respondiendo desde Astro y el panel, la API y las imágenes respondiendo desde WordPress. Cinco días después del primer commit del repositorio, el dominio ya se servía con la arquitectura nueva.

Lo que se rompió

Ningún cutover sale limpio, y contarlo es más útil que el diagrama.

• Se perdió el ads.txt. Era un archivo del WordPress y nadie lo tenía versionado. Sin él, parte de la publicidad programática deja de vender. Lo recuperamos de Archive.org el mismo día.
• El www respondió 526 durante un rato, hasta que el sitio nuevo tomó también ese host y lo redirigió al dominio principal.
• Un despliegue posterior desasoció el dominio del sitio. La causa fue una lista de rutas incompleta en la configuración: la herramienta sincroniza y desconecta lo que no esté declarado. Desde entonces la lista se mantiene completa y se revisa en seco antes de desplegar.
• El servidor de WordPress quedó suspendido por un impago y el sitio se colgó esperándolo cien segundos. De ahí salieron tres arreglos que hoy son la parte más valiosa de la arquitectura: tiempo de espera máximo de 8 segundos a WordPress, copia de la última respuesta buena guardada en el borde, y HTML que se sigue sirviendo aunque el origen no responda. Hoy WordPress puede caerse y el sitio sigue en pie.

Lo que ganamos

Con datos de producción, no de laboratorio ideal:

• 97 de 100 en Lighthouse móvil, con CLS 0 y FCP 1,2 s.
• LCP de 1,5 s en usuarios reales (dato de campo, ventana de 28 días), con la evaluación de Core Web Vitals aprobada. En agosto ese mismo indicador estaba en 3,2 s.
• El <head> volvió a ser nuestro. Astro arma el 100 % del head y de los datos estructurados. Antes los inyectaba un plugin, y esa inyección fue la causa de cinco caídas del schema en una sola semana. El cambio se validó con un test de paridad etiqueta por etiqueta sobre 38 URLs antes de encender nada.
• Configuración que cambia sin desplegar. El sitio lee su configuración de publicidad del borde en tiempo de ejecución, así que mover una posición ya no es un commit más un despliegue completo.
• Secciones que en el WordPress anterior no eran viables: un directorio de comercios del barrio, un buscador de compras públicas municipales y una versión en Markdown de cada nota para los agentes de IA que hoy leen el sitio.
• 68 archivos de test y 428 pruebas corriendo en cada cambio, más un smoke test contra el sitio real después de cada despliegue y un chequeo de salud cada 15 minutos.

Lo que no ganamos

Esta parte suele faltar en los casos de éxito, así que va explícita.

• El tráfico no subió por la migración, y no lo vendemos así. En un medio local el tráfico lo mandan Discover y los cambios de algoritmo de Google. Al revisar las fechas, la caída de clics de búsqueda había empezado once días antes del cutover, y el bajón grande del año era de marzo, meses antes de que existiera Astro. Rendimiento y datos estructurados sanos son condiciones necesarias; no son una palanca de tráfico.
• Seguimos dependiendo de WordPress. La portada dispara 21 consultas a la API, y cuando la caché del borde está fría en Chile, el lector paga esa espera. Es el pendiente número uno.
• Las rutas de exclusión solo se validan el día del cambio, porque antes esos paths ya iban a WordPress igual. Se compensa con ventana de bajo tráfico y rollback listo, pero es un riesgo real, no cero.
• Ahora hay que operar Cloudflare. Se cambió el problema de “plugins que se pelean” por el de “rutas, caché y despliegues”. Es un mejor problema, pero es un problema.

El método que nos llevamos

Cuatro cosas de este proyecto se volvieron la forma en que trabajamos:

• Medir antes de proponer. El benchmark de cuatro días fue más convincente que cualquier presentación, y además mostró dónde estaba el techo.
• Que el cambio sea reversible. Si el rollback toma segundos y no requiere desplegar, el cutover deja de ser un evento y pasa a ser una prueba.
• Nada está listo hasta verlo en la URL real. Desktop y móvil, con evidencia. El “funciona en local” no cuenta.
• Escribir lo que se rompió. El archivo perdido, el dominio desasociado y el servidor caído enseñaron más que las partes que salieron bien.

Si estás mirando esta misma decisión para tu medio, el resumen es corto: no tienes que migrar el contenido ni cambiar de CMS para dejar de arrastrar cuatro megabytes por portada. Tienes que separar quién guarda el contenido de quién lo dibuja.