Invalidación cache CDN: purga y TTL explicados
La invalidación de caché CDN es el proceso de forzar a una red de distribución de contenido a descartar versiones cacheadas de URLs para que los usuarios reciban contenido actualizado desde el servidor de origen. Cuando eliminás una URL o cambiás un redirect, si el CDN no invalida su caché, los usuarios siguen viendo la versión vieja durante horas o días.
En 30 segundos
- Un CDN cachea contenido en nodos geográficos distribuidos; si eliminás una URL sin invalidar el caché, los usuarios siguen siendo redirigidos a contenido inexistente.
- Hay dos métodos principales: purga hard (borrado inmediato por URL o wildcard) y purga soft (marca como desactualizado, revalida en la próxima solicitud).
- El TTL (Time To Live) determina cuánto tiempo vive el contenido en caché; un TTL alto acelera el sitio pero complica actualizaciones urgentes.
- Cloudflare, Google Cloud CDN y Adobe Experience Manager tienen APIs de purga; la mayoría acepta URLs individuales, patrones glob y cache tags.
- El error más común: limpiar el caché en el CMS pero olvidarse de purgarlo también en el CDN, que opera como capa separada.
Qué es la invalidación de caché CDN
Un CDN distribuye copias de tu contenido en decenas o cientos de servidores edge repartidos por el mundo. Cuando alguien en Buenos Aires pide una página de tu sitio, el nodo más cercano devuelve una copia cacheada sin tocar tu servidor de origen. Eso es exactamente lo que lo hace rápido.
El problema aparece cuando esa copia ya no refleja la realidad. Eliminaste una URL, cambiaste un redirect 301, actualizaste el precio de un producto, o simplemente reescribiste un artículo. Tu servidor de origen ya tiene la versión correcta, pero el nodo de São Paulo sigue sirviendo la versión vieja porque nadie le avisó.
La invalidación de caché es exactamente ese aviso: la instrucción que le dice al CDN “esto ya no sirve, tiralo y pedile la versión nueva al origen”. Sin esa instrucción, el contenido desactualizado vive en el edge hasta que el TTL expire por sí solo.
Ojo: invalidar y purgar no son exactamente lo mismo, aunque se usan como sinónimos. Purgar es el borrado activo e inmediato. Invalidar puede incluir también marcar el contenido como stale para que sea revalidado en la próxima solicitud, sin borrarlo de inmediato. Para más detalles técnicos sobre cómo esto impacta en SEO multiidioma, consultá nuestra guía de hreflang y SEO internacional.
Por qué esto importa para SEO y para los usuarios
Ponele que eliminaste veinte URLs antiguas de tu sitio y configuraste redirects 301 hacia las páginas reemplazantes. Tu servidor responde perfecto. Pero el CDN tiene cacheada la cadena de redirects anterior y sigue enviando a los usuarios por un camino que ya no existe.
Según el caso documentado por NovikTech, esto ocurre incluso cuando las URLs fueron eliminadas de Redis: el CDN opera como capa independiente y no se entera del cambio hasta que alguien lo fuerza. Los usuarios se topan con errores 404, bucles de redirect o respuestas 410 que deberían haber desaparecido hace tiempo.
Tres consecuencias concretas:
- Frustración del usuario: un enlace que debería llegar a una página relevante termina en error. Tasa de rebote sube, conversiones bajan.
- Señales negativas para Google: Googlebot rastrea URLs regularmente. Si detecta que una URL devuelve redirects inconsistentes dependiendo de si la solicitud viene del origen o del edge, el comportamiento es impredecible para el índice.
- Deuda técnica acumulada: cada redirect o 404 que sobrevive en caché complica las siguientes migraciones. Con el tiempo, el grafo de redirects se vuelve un desastre que nadie quiere tocar.
Cómo funciona la arquitectura de caché en un CDN
La cadena es: navegador → nodo edge del CDN → servidor de origen (solo si el edge no tiene la respuesta o esta expiró).
Cada respuesta que el CDN cachea tiene un TTL definido por los headers HTTP que manda el servidor de origen, principalmente Cache-Control y Expires. Según la documentación de MDN, el header Cache-Control: max-age=3600 indica que ese recurso puede vivir en caché hasta una hora. Pasada esa hora, el edge lo descarta o lo revalida.
El problema con depender solo del TTL: si configuraste max-age=86400 (24 horas) para HTML y eliminás una URL a las 9 de la mañana, el CDN puede seguir sirviendo esa URL hasta las 9 del día siguiente. Para noticias o e-commerce, eso es intolerable.
La invalidación manual o por API corta ese ciclo antes de que el TTL expire.
Mecanismos de invalidación: purga hard, soft y por tags
Purga hard (inmediata)
Borra la entrada del caché en todos los nodos edge de inmediato. La próxima solicitud va directamente al servidor de origen. Es la opción más agresiva y la más garantizada: después de ejecutarla, nadie ve contenido viejo.
El costo es que genera carga en el origen si purgás muchas URLs al mismo tiempo. Si tu sitio tiene picos de tráfico justo cuando ejecutás una purga masiva, el origen puede saturarse. En rendimiento y velocidad de carga profundizamos sobre esto.
Purga soft (stale-while-revalidate)
Marca el contenido como stale pero lo mantiene disponible. El primer usuario que pide la URL después de la marca recibe la versión vieja mientras el CDN va a buscar la nueva al origen en segundo plano. Los siguientes usuarios ya reciben la versión actualizada.
Es más suave con el origen y transparente para el usuario, pero hay una ventana donde alguien puede ver contenido desactualizado. Para noticias de último momento o cambios de precio, la purga hard es la opción correcta.
Invalidación por tags (cache tags)
Algunos CDNs permiten etiquetar respuestas con tags personalizados en los headers. Cuando querés invalidar todo el contenido relacionado a “producto-123”, mandás una sola instrucción de purga por tag y el CDN borra todas las URLs que tengan esa etiqueta, sin importar cuántas sean.
Adobe Experience Manager usa exactamente este mecanismo con Dynamic Media: según su documentación oficial, los assets de Dynamic Media pueden invalidarse masivamente desde la interfaz de AEM enviando una lista de URLs al CDN asociado, con soporte para invalidación selectiva por carpeta o asset individual.
Herramientas y métodos por proveedor
| CDN | Método de purga | Granularidad | API disponible |
|---|---|---|---|
| Cloudflare | Dashboard > Caché > Depurar Caché | URL individual, wildcard, todo | Sí (REST) |
| Google Cloud CDN | CLI gcloud / Console | URL o key prefix | Sí |
| Azure CDN | Portal + HTTP Overrides | URL o ruta | Sí |
| Adobe Experience Manager | Interfaz AEM + Dynamic Media | Asset, carpeta, todo | Sí |
Cloudflare: la purga personalizada
Según la documentación de Cloudflare, tenés tres opciones: purgar todo (nuclear, genera carga en el origen), purgar por URLs individuales (hasta 30 por request en la API), o purgar por prefijos y tags si tenés plan Enterprise. Desde el dashboard es directo: Inicio > tu dominio > Caché > Configuración > Depurar Caché.
Google Cloud CDN: invalidación por key prefix
La documentación de Google Cloud describe la invalidación por path prefix: podés invalidar /blog/* con un solo comando y afectar todas las URLs bajo esa ruta. La propagación tarda hasta 5 minutos en completarse en todos los puntos de presencia.
Azure CDN: HTTP Overrides
Azure permite configurar reglas de override para headers HTTP desde el portal, lo que incluye forzar comportamientos de caché específicos por ruta. Microsoft documenta el proceso en Azure Friday, cubriendo cómo usar estas reglas para controlar el TTL por tipo de contenido.
WordPress y plugins de caché
Si usás WordPress con algún plugin de caché y un CDN externo, la invalidación tiene que ocurrir en ambas capas. Varios plugins tienen integración nativa con CDNs populares para disparar la purga automáticamente cuando publicás o actualizás una entrada. Eso sí, configurarlo bien requiere que el plugin sepa qué CDN está en uso y tenga las credenciales de API correctas. Si tu sitio está alojado en un plan que ya incluye CDN integrado, como los que ofrece donweb.com, la capa de caché y la invalidación suelen estar centralizadas, lo que simplifica bastante el proceso.
Errores frecuentes que prolongan el problema
El más común: limpiar el caché del CMS y dar el problema por solucionado. El CMS y el CDN son capas distintas. Limpiar el caché de WordPress no toca para nada el caché de Cloudflare o del CDN que uses.
Segundo error frecuente: TTL demasiado alto para HTML. Cachear imágenes y CSS por 7 días tiene sentido si usás cache busting con hashes en los nombres de archivo. Cachear HTML por 24 horas cuando tu sitio publica noticias es un problema esperando pasar. La recomendación estándar para HTML dinámico es TTL entre 0 y 60 minutos, dependiendo de qué tan frecuentes sean los cambios. Más contexto en fundamentos de SEO técnico.
Tercer error: olvidar los subdominios. Si tu CDN está configurado en www.sitio.com pero también servís contenido desde cdn.sitio.com o static.sitio.com, la purga del dominio principal no afecta a los subdominios. Cada CNAME tiene su propia capa de caché.
Cuarto: no versionar assets estáticos. Si cambiás estilos.css sin cambiar su nombre, el CDN sigue sirviendo la versión vieja porque la URL es idéntica y el TTL no expiró. El cache busting es agregar un hash o query string al nombre (estilos.a3f9b2.css o estilos.css?v=1.2.3), forzando al CDN a tratarlo como un recurso nuevo.
Quinto error, más sutil: cachear respuestas 301 durante demasiado tiempo. Los navegadores también cachean redirects 301 según el Cache-Control que reciben. Si un redirect fue configurado incorrectamente y lo corregís después, los usuarios que ya recibieron el 301 van a seguir siendo redirigidos por el header que el navegador guardó en local, independientemente de lo que hagas en el servidor o en el CDN. ¿Y qué pasa cuando eso ocurre a escala? Exacto: soporte recibe tickets que nadie puede reproducir en su máquina.
Estrategia práctica para gestionar invalidaciones
Antes de tocar cualquier cosa, documentá qué URLs vas a eliminar o cambiar y en qué CDN están cacheadas. No es dramático, pero tener esa lista evita sorpresas.
El flujo que funciona en la práctica:
- Realizás el cambio en el servidor de origen (actualizás redirect, eliminás URL, editás contenido).
- Inmediatamente después, disparás la purga en el CDN, ya sea por URL individual si son pocas, o por prefix si son muchas bajo la misma ruta.
- Si usás tags de caché, es el momento para invalidar por tag en vez de por URL.
- Esperás la propagación (entre 30 segundos y 5 minutos según el CDN) y verificás desde una herramienta externa o desde una IP distinta a la tuya que el contenido actualizado está llegando.
- Si el cambio afecta SEO (eliminación de URLs indexadas, cambio de canonicals), notificás a Google Search Console usando la herramienta de inspección de URLs.
Para assets estáticos, implementar cache busting por hash es la solución más robusta porque elimina la necesidad de purgar: cada versión nueva tiene una URL nueva, el CDN la trata como recurso inexistente y va al origen automáticamente. Cubrimos ese tema en detalle en automatizar la invalidación de cache.
Subís el archivo, el build genera el hash, el HTML referencia la URL nueva, el CDN cachea esa URL nueva sin que nadie tenga que acordarse de nada (y la URL vieja expira sola por TTL sin que importe).
Preguntas Frecuentes
¿Cómo invalidar caché en CDN después de eliminar una URL?
Usás la función de purga del CDN con la URL exacta que eliminaste. En Cloudflare es Dashboard > Caché > Depurar Caché > URLs personalizadas. En Google Cloud CDN usás el comando gcloud compute url-maps invalidate-cdn-cache con el path. Si el CDN soporta cache tags y la URL estaba etiquetada, podés invalidar por tag. Después de la purga, verificá desde una IP externa o usando herramientas como el Inspector de URLs de Google Search Console.
¿Por qué sigo viendo redirecciones después de limpiar la caché?
Hay tres capas que pueden estar sirviendo el redirect viejo: el CDN (hay que purgar vía API o dashboard, no desde el CMS), el caché del navegador (el 301 puede estar guardado localmente; probar en modo incógnito o desde otro dispositivo lo confirma), y el caché del propio CMS si estás en WordPress u otro sistema con caché de objeto. Limpiar solo una capa mientras las otras siguen cacheadas da exactamente ese síntoma.
¿Cuál es la diferencia entre purga hard y soft en CDN?
La purga hard borra el contenido del edge inmediatamente; la siguiente solicitud va al servidor de origen sin importar nada. La purga soft (o stale-while-revalidate) marca el contenido como desactualizado pero lo mantiene disponible: el primer usuario recibe la versión vieja mientras el CDN busca la nueva en segundo plano. Hard garantiza consistencia inmediata pero genera carga en el origen; soft es más gentil con el origen pero tolera una ventana de contenido desactualizado.
¿Qué es TTL en caché y cómo afecta la invalidación?
TTL (Time To Live) es el tiempo en segundos que el CDN mantiene un recurso en caché antes de descartarlo o revalidarlo. Se define con el header Cache-Control: max-age=X que manda el servidor de origen. Un TTL alto (86400 = 24 horas) significa que sin invalidación manual, los usuarios pueden ver contenido desactualizado hasta un día entero. Un TTL bajo (300 = 5 minutos) reduce el problema pero también reduce el beneficio de rendimiento del CDN.
¿Cómo evitar que usuarios vean contenido desactualizado?
La estrategia más efectiva combina tres cosas: cache busting con hash en el nombre de archivos estáticos (para que cada versión tenga URL única), TTL bajo o cero para HTML dinámico, y un proceso de purga automática en el CDN cada vez que publicás cambios. Para implementaciones serias, la purga automática se configura vía webhook o en el pipeline de deploy, de modo que después de cada deploy el CDN recibe la instrucción de purgar las URLs afectadas sin intervención manual.
Conclusión
La invalidación de caché CDN es uno de esos problemas que parecen simples hasta que te encontrás con usuarios reportando errores que vos no podés reproducir porque tu IP ya recibe la versión actualizada. La raíz casi siempre es la misma: el CDN y el servidor de origen son capas independientes, y limpiar una no limpia la otra.
Si administrás un sitio con CDN, lo mínimo es tener claro cómo purgar por URL en el proveedor que usás y agregar ese paso al proceso estándar de publicación o de eliminación de contenido. Para sitios con volumen, la purga automática vía API en el pipeline de deploy elimina el error humano del todo.
Los headers Cache-Control bien configurados son la base, pero no alcanzan solos cuando necesitás cambios inmediatos. Para eso existe la purga.
