Actualizar WordPress con una CDN puede hacer que distintos usuarios reciban versiones diferentes durante un tiempo si la invalidación no alcanza todas las capas y regiones. La forma segura de evitarlo combina purgas selectivas, versionado de archivos, reglas para páginas dinámicas, comprobación desde varias ubicaciones y un rollback preparado. Así reduces errores visibles, ventas perdidas y tiempos de soporte.
Índice
Anuncio
Riesgos reales de la caché global
Una CDN guarda copias de la web en puntos de presencia, o PoP, que son servidores repartidos por distintas ciudades.
Una purga no borra todas las capas
Una purga de caché elimina copias guardadas en la CDN, pero no siempre elimina las del navegador, el servidor o un proxy como Varnish Cache. Por eso un visitante puede recibir HTML nuevo con un CSS antiguo, como si una tienda cambiara el precio pero mantuviera el escaparate anterior.
Localiza la copia que responde
Las cabeceras HTTP permiten saber qué capa entrega el contenido antiguo sin hacer cambios a ciegas. En Cloudflare, CF-Cache-Status: HIT significa que la respuesta salió de su caché perimetral; MISS indica que tuvo que pedirla al origen.
Decide qué invalidar tras cada cambio
La invalidación debe seguir el tipo de cambio y las URL que dependen de él.
Matriz para elegir el alcance
| Cambio | Qué invalidar | Comprobación |
|---|---|---|
| Texto o precio | Ficha, categoría, buscador y feed | Precio en sesión anónima |
| CSS o JavaScript | Archivo nuevo versionado, no toda la web | Hash y consola del navegador |
| Redirección | URL de origen y variantes HTTP/HTTPS | Código 301, 302 o 308 |
| API o cabeceras | Endpoint y regla de caché | ETag y Cache-Control |
Elige purga, etiqueta o TTL
La purga por URL tiene sentido cuando el cambio afecta entre 1 y 20 páginas bien identificadas. La purga total encaja en una incidencia amplia, pero puede provocar entre 5 y 15 minutos de más carga en el origen mientras se vuelve a llenar la caché.
Versiona los archivos estáticos
Una llave USB de seguridad puede guardar una copia cifrada de emergencia y códigos de recuperación fuera del servidor. No sustituye las copias verificadas, pero ayuda durante un rollback con acceso limitado.
- Permite conservar códigos de recuperación de Cloudflare separados del equipo habitual
- Facilita transportar una copia cifrada de archivos críticos del despliegue
- Reduce el riesgo de perder credenciales si falla el ordenador de administración
La invalidación por URL es la opción más precisa cuando se conocen las páginas afectadas, pero obliga a incluir variantes como paginaciones, categorías, feeds, versiones con parámetros relevantes y rutas que reutilizan el mismo bloque. La purga por etiqueta, surrogate key o etiqueta de caché resulta más útil cuando un mismo producto, autor o bloque editorial aparece en decenas de URL: se invalida el grupo lógico sin vaciar toda la CDN. La purga total debe reservarse para cambios transversales, porque reduce temporalmente la tasa de aciertos y puede trasladar mucha carga al origen.
Un TTL de caché corto sirve como medida preventiva durante una publicación sensible, pero no sustituye una purga: los objetos ya almacenados pueden seguir respondiendo hasta caducar.
Despliega sin servir dos versiones
Un despliegue controlado evita que la CDN muestre una mezcla de tema nuevo, plugin antiguo y datos de caché previos.
Orden seguro para publicar
El consenso entre administradores de WordPress con experiencia es preparar el rollback antes de tocar producción. Esto incluye la versión anterior de plugins y tema, una copia comprobada y el acceso a la CDN para invalidar el contenido erróneo.
Calienta y comprueba la caché
La práctica demuestra que validar desde un único ordenador no confirma una propagación global. Comprueba al menos entre 2 y 3 regiones relevantes, una sesión anónima, una sesión autenticada y un móvil, anotando hora, URL, cabeceras y resultado.
Para reducir el riesgo de downtime, separa la subida de archivos de la activación del cambio. Publica primero CSS, JavaScript e imágenes con versionado de archivos o hash en el nombre, de modo que los navegadores y la CDN puedan conservar los recursos anteriores sin mezclar versiones. Después, calienta las URL públicas más visitadas y activa el nuevo tema, plugin o regla para una parte limitada del tráfico si el proveedor, el balanceador o la aplicación permiten una liberación gradual.
Comprueba formularios, búsqueda, compra y API antes de extender el cambio. Si aparece un error, vuelve a apuntar el HTML o la configuración a la versión anterior; los assets con hash permiten hacer ese rollback sin depender de que cada navegador haya vaciado su caché.
Evita fallos que afectan a ventas
Los fallos de caché no son solo un problema visual cuando una web vende.
No trates todas las rutas igual
Una regla de CDN válida para una página corporativa puede ser peligrosa para una tienda. Excluye de caché las rutas dinámicas y revisa cookies de sesión, cabeceras de autorización y contenido personalizado antes de activar reglas de tipo “cache everything”.
Revierte con un plan concreto
La recomendación accionable es clara: publica primero con assets versionados, purga solo el conjunto afectado, precalienta las rutas públicas y valida cabeceras desde varias ubicaciones. Si el cambio toca pagos, sesiones o permisos, limita la activación hasta confirmar el flujo completo.
Resuelve tus dudas
¿Debo purgar la CDN tras actualizar WordPress?
Sí, pero purga solo las URL, etiquetas o recursos afectados cuando puedas identificarlos. Haz una purga total solo ante un cambio amplio o una incidencia que afecte a muchas rutas.
¿Qué pasa si actualizo plugins sin invalidar la CDN?
Puedes servir HTML nuevo con JavaScript o CSS antiguo durante un tiempo. El riesgo aumenta si el plugin cambia formularios, pagos, bloques o recursos cargados en portada.
¿Por qué no se ven cambios igual para todos?
Cada usuario puede llegar a un PoP distinto y conservar recursos en su navegador. Revisa Age, Cache-Control y la cabecera del proveedor desde entre 2 y 3 regiones.
¿Qué páginas de WooCommerce no debo cachear?
Carrito, checkout, mi cuenta y rutas con sesión o cookies de compra no deben tener caché pública. Tampoco deben cachearse respuestas que cambian por usuario, stock reservado o permisos.
¿Es mejor bajar el TTL que hacer una purga?
Un TTL de entre 5 y 15 minutos ayuda durante cambios sensibles, pero no borra de inmediato objetos existentes. La purga selectiva corrige un cambio concreto con menos espera.
¿Cómo sé si Cloudflare sirve una versión antigua?
Mira CF-Cache-Status, Age, ETag y la fecha de la respuesta en las herramientas del navegador o con una consulta HTTP. Un HIT con un ETag previo apunta a una copia guardada en edge.
¿Sirve el modo mantenimiento con una CDN?
Sirve si se excluye de caché o se controla con cuidado. Si la CDN guarda esa página, puede seguir mostrándola después de reabrir la web.
¿Cuánto debo conservar para poder hacer rollback?
Conserva al menos la copia inmediatamente anterior y una copia completa verificable de base de datos y archivos. En tiendas con pedidos, coordina la restauración para no perder cambios legítimos ocurridos durante la incidencia.
Anuncio
Qué hacer antes de la próxima actualización
Prepara una lista de URL críticas, reglas de exclusión para contenido dinámico y una copia restaurable antes de actualizar. Después, versiona los recursos estáticos, purga de forma proporcional y registra las cabeceras que confirman la versión publicada.
Para saber más
Si deseas profundizar, aquí tienes algunos recursos de interés:
- Errores al actualizar WordPress (y cómo evitarlos) — kamalyon.com
- Red de distribución de contenidos | CDN de WordPress — cloudflare.com
- LiteSpeed Cache: parche urgente CVE-2026-3375 — seguridadenwordpress.com
- La CDN suele ocultar el fallo real al activar SSL
- El WAF gratis de Cloudflare no cubre todo en WordPress
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.