IFM Noticias es un portal de noticias colombiano con tráfico orgánico significativo y monetización principal por AdSense. El reto: salir del WordPress legacy (lento, frágil, caro de mantener) sin perder posicionamiento SEO ni ingresos publicitarios. Lo resolvimos con un Express en Cloud Run que renderiza el sitio público, un WordPress reducido a solo redacción interna que sincroniza a Firestore, y una integración cuidadosa con AdSense Auto Ads + slots in-article server-side.
El problema: WordPress es ideal hasta que deja de serlo
Un portal de noticias activo en WordPress empieza siendo cómodo: cualquier redactor edita y publica, los plugins resuelven SEO y AdSense, el tema cubre el frontend. Después de unos años el costo aparece: el sitio se vuelve lento (Core Web Vitals reprobados, LCP alto), los plugins entran en conflicto, las actualizaciones rompen cosas, el hosting compartido aguanta cada vez peor los picos de tráfico, y AdSense pierde optimización porque el render está fragmentado.
Cambiar el sitio entero es riesgoso: si pierdes posiciones en Google o si AdSense se cae por mal render, el negocio se ve afectado al día siguiente. El equipo editorial tampoco quiere aprender un CMS nuevo.
La solución: WordPress como editor, Express como sitio público
Diseñamos una arquitectura en dos capas. La capa pública — lo que ve el lector y rastrea Google — es Express + Tailwind corriendo en Cloud Run, con un cache de artículos en Firestore. Es rápida, está al día con Core Web Vitals y soporta picos sin escalar manualmente.
La capa editorial — donde escriben los periodistas — sigue siendo WordPress, ahora en un subdominio interno (`wp.ifmnoticias.com`). Un job sincroniza los artículos publicados desde WP a Firestore, y desde ahí los lee Cloud Run. El redactor abre WordPress como siempre, escribe, publica, y el artículo aparece en el sitio público en minutos. Cero fricción para el equipo.
Stack técnico desplegado en GCP
Cloud Run en us-central1 servido por Cloudflare (grey cloud en root, para no perder atributos como geolocalización). Firebase Hosting como capa de cache adicional para assets estáticos. Vertex AI Gemini para tareas internas (resumen, sugerencias de title, categorización).
AdSense se reinstaló con Auto Ads activos y slots in-article server-side específicos para el formato editorial. Esto fue clave para recuperar RPM después de la migración (ver siguiente sección). Server-side rendering completo para todos los artículos: el HTML llega listo, sin JavaScript bloqueando el LCP, AdSense puede inyectar sin pelear con hidratación.
Cómo Claude Code aceleró el desarrollo
La migración tenía dos riesgos grandes: perder URLs (Google se confunde, posiciones bajan) y romper AdSense (RPM se desploma). Claude Code abordó ambos con cuidado quirúrgico. Para URLs, escribimos un middleware que mapea cada slug viejo a su artículo nuevo con 301; lo testeamos con la lista completa de URLs históricas antes del cutover.
Para AdSense — donde efectivamente hubo un colapso transitorio de RPM post-migración — Claude Code identificó el problema en el primer log: los slots `` no se renderizaban porque el HTML server-side no incluía los meta tags de AdSense ni cargaba `adsbygoogle.js` antes del DOMContentLoaded. La solución fue añadir Auto Ads + slots in-article con fallback de zonas con slot ID. RPM se recuperó.
La memoria documentada de este incidente (cómo no romper AdSense en migraciones WP → Express) es ahora un patrón reutilizable que aplicamos a otros clientes editoriales.
Resultados
IFM Noticias corre hoy en Cloud Run, Core Web Vitals en verde, tráfico orgánico estable post-migración (sin caída sostenida), AdSense entregando RPM en rangos esperados. El equipo editorial publica desde WordPress como siempre — la migración no cambió su workflow.
La factura de hosting bajó: Cloud Run cobra por uso, en horas bajas escala a cero. WordPress quedó en un subdominio mínimo, sin tráfico público, lo que reduce su superficie de ataque y necesidad de plugins de caché.
¿Qué replicamos a clientes?
Si tu medio o blog está en WordPress y la velocidad o los costos te están limitando, podemos migrarlo a un stack moderno sin que el equipo editorial cambie su forma de trabajar. La clave es separar el editor (WP) del sitio público (Cloud Run o similar) y manejar la sincronización en el medio. Hablemos.