WordPress no actualiza los cambios: 7 capas de caché y cómo purgarlas

Editas una página, pulsas «Actualizar», el botón cambia a «Actualizado» y todo parece haber ido bien. Pero cuando vas a ver la web desde el navegador… los cambios no están. El texto antiguo sigue ahí, las imágenes nuevas no aparecen, los colores que tocaste en el editor no se reflejan. Si WordPress no actualiza los cambios en tu sitio en producción, la culpa casi nunca es del editor: hay una capa de caché o de configuración en medio que está sirviendo la versión vieja. La buena noticia es que las capas que pueden estar interfiriendo son contadas y todas se purgan en minutos.

En esta guía te explicamos por qué pasa, cómo localizar exactamente dónde está retenida la versión antigua y cómo forzar que el cambio se vea inmediatamente.

Por qué WordPress no muestra los cambios que acabas de hacer

Cuando guardas un cambio en WordPress, ese cambio entra en la base de datos casi al instante. Lo que el visitante ve en su navegador no se genera «en vivo» cada vez: pasa por varias capas que pueden quedarse con una copia antigua. Si una de ellas no se entera del cambio, sigue sirviendo lo que tenía guardado.

Las capas habituales que pueden estar interfiriendo son seis: caché del navegador, plugin de caché del sitio, CDN delante de tu web, caché de objetos del servidor (Redis o Memcached), caché de OPcache de PHP y, en menor medida, caché del propio editor o page builder (Elementor, Divi, WPBakery). Atacarlas en orden te lleva al problema en pocos minutos.

Síntomas habituales y cómo identificar dónde está el problema

Antes de purgar a ciegas, identifica el escenario más parecido al tuyo:

• Tú no ves el cambio pero tus compañeros sí. Es caché del navegador o de tu sesión. Solución en 5 segundos.
• Nadie ve el cambio, pero el dashboard de WordPress muestra el contenido nuevo. Es caché del sitio (plugin, CDN u objetos). El cambio está guardado, alguna capa retiene la versión vieja.
• Cambios de Elementor o Divi que no se aplican. El page builder genera CSS en archivos estáticos que hay que regenerar.
• Cambios solo a veces. Caché parcial: un servidor o nodo del CDN está desincronizado.
• Después de cambiar de hosting, los cambios no se reflejan. Probable que el DNS aún apunte al servidor antiguo.

Solución 1: caché del navegador (prueba siempre primero)

El 40 % de los casos son simplemente caché del navegador del que está editando. Antes de tocar nada en el sitio, descarta esto:

1. Abre una ventana de incógnito (Ctrl+Shift+N en Chrome) y carga la URL.
2. Si el cambio sí aparece en incógnito, era tu navegador. Limpia la caché del navegador habitual (Ctrl+Shift+Del → caché de imágenes y archivos → Borrar) y listo.
3. Si en incógnito tampoco aparece, el problema no es tu navegador. Sigue bajando por la lista.

Solución 2: purgar el plugin de caché del sitio

Si tienes instalado un plugin de caché (es lo más probable, lo lleva el 80 % de los WordPress de empresa), ese plugin está sirviendo páginas pregeneradas. Los más habituales:

• WP Rocket: en la barra superior del admin, «WP Rocket → Vaciar caché».
• W3 Total Cache: «Rendimiento → Dashboard → empty all caches».
• LiteSpeed Cache: «LiteSpeed Cache → Toolbox → Purge All».
• WP Super Cache: «Ajustes → WP Super Cache → Delete Cache».
• Cache Enabler / Hummingbird / Autoptimize: misma lógica, buscar la opción «purgar» o «vaciar».

Si tu hosting usa caché propia (SiteGround SuperCacher, Kinsta Cache, WP Engine, etc.), tienes el botón de purgar en el panel del hosting o en una barra superior dentro del admin de WordPress. Búscalo siempre que toques un plugin de caché normal: las dos capas conviven.

Solución 3: purgar la caché del CDN (Cloudflare y similares)

Si tu web pasa por un CDN (Cloudflare es el más habitual), hay otra capa entre tu servidor y el visitante. Aunque el plugin de caché del sitio esté limpio, el CDN puede seguir sirviendo la versión antigua durante horas.

En Cloudflare, entra al panel → tu dominio → Caching → Configuration → Purge Everything. Confirma y espera 30 segundos. Si solo cambió una URL concreta, usa Custom Purge con la URL específica para no resetear toda la caché. Los hostings tipo Kinsta y WP Engine también usan CDN integrado, donde la opción se llama habitualmente «Clear cache» o «Flush cache».

Solución 4: caché de objetos (Redis o Memcached)

Algunos hostings de alto rendimiento usan caché de objetos en memoria para almacenar consultas a la base de datos. Si tu hosting la tiene activa y un cambio no se refleja, esa caché puede estar reteniendo el dato antiguo. Suele indicarlo el panel del hosting con un botón «Flush Object Cache» o «Restart Redis».

Si tienes acceso SSH y Redis instalado, puedes purgarla con redis-cli FLUSHALL. En la mayoría de casos, el botón del panel de hosting es suficiente. Si no encuentras la opción, pídeselo al soporte: lo hacen en 30 segundos.

Solución 5: regenerar el CSS de Elementor, Divi o WPBakery

Los page builders generan archivos CSS estáticos para acelerar el front-end. Si cambias un color, una tipografía o una clase, el CSS no se actualiza automáticamente: hay que regenerarlo.

• Elementor: ve a «Elementor → Herramientas → Regenerar CSS y datos».
• Divi: «Divi → Opciones del tema → Builder → pestaña Performance → «Borrar caché estática del CSS».
• WPBakery: «WPBakery → Configuración del Page Builder → Eliminar caché».

Después de regenerar, vacía también el plugin de caché del sitio y el CDN. Es la combinación que resuelve casi todos los problemas de «no se ven los cambios» relacionados con builders visuales.

Solución 6: OPcache de PHP y caché del servidor

Menos habitual pero pasa: OPcache de PHP guarda los archivos PHP compilados para acelerar la ejecución. Si haces cambios en código (un tema hijo, un fragmento en functions.php) y no se reflejan, OPcache puede estar la causa. La solución es reiniciar PHP en el panel del hosting (en cPanel: «Software → Seleccionar versión de PHP → Reload») o pedir al hosting que reinicie el servicio.

En hostings modernos esto pasa raramente porque OPcache se invalida automáticamente al detectar el cambio. Si te toca lidiar con ello, normalmente es síntoma de que tu hosting es de calidad limitada.

Solución 7: el DNS aún apunta al servidor antiguo

Si has migrado de hosting recientemente y los cambios que haces en el servidor nuevo no se ven, comprueba primero si estás cargando desde el servidor nuevo o desde el antiguo. Entra a una herramienta como dnschecker.org, mete tu dominio y mira a qué IP está respondiendo. Si la IP no coincide con la del nuevo hosting, los cambios estás haciéndolos en un sitio pero los visitantes (y tú) ven el sitio antiguo.

La propagación de DNS puede tardar hasta 48 horas. Hasta entonces, fuerza la resolución local editando tu archivo hosts (en macOS y Linux, /etc/hosts; en Windows, C:\Windows\System32\drivers\etc\hosts) y añadiendo la IP nueva con tu dominio. Así fuerzas que tu navegador resuelva al servidor correcto sin esperar al DNS.

Preguntas frecuentes

¿Cuál es la diferencia entre la caché del navegador y la caché de la web?

La caché del navegador es local en tu ordenador: solo te afecta a ti. La caché de la web (plugin de caché, CDN, Redis) afecta a todos los visitantes. Si solo tú no ves el cambio, es la del navegador. Si nadie lo ve, es de la web.

¿Cada cuánto debería vaciar la caché de mi web?

Solo cuando hagas cambios importantes y necesites que se vean inmediatamente. Un sitio en producción no necesita vaciar caché a diario: si lo haces, pierdes precisamente la ventaja del cacheo (que el sitio sea rápido).

Tengo Cloudflare activo. ¿Sigue siendo necesario el plugin de caché del sitio?

Sí, conviene tener los dos. Cloudflare cachea estáticos (imágenes, CSS, JS) globalmente, pero el HTML lo regenera tu servidor. El plugin de caché del sitio reduce la carga del servidor sirviendo el HTML cacheado. Las dos capas se complementan.

¿Es seguro vaciar toda la caché de Cloudflare?

Sí, no rompe nada. Lo único que pasa es que durante unos minutos el sitio va un poco más lento porque Cloudflare tiene que volver a generar la caché desde tu servidor. En sitios grandes con mucho tráfico, mejor purgar solo URLs concretas para no estresar el origen.

Hago el cambio, vacío todo, y aun así sigue viéndose la versión antigua. ¿Qué me queda?

Probablemente sea OPcache de PHP o caché de objetos del hosting. Pide al soporte del hosting que reinicie PHP y purgue object cache. Si el hosting no permite hacerlo, valora cambiarte: ese tipo de restricción no es propia de hosting profesional.

Ataca las capas de caché en orden y nunca purgues todo a ciegas

El error más común al pelearse con este problema es purgar todas las capas de caché de golpe sin saber en cuál estaba el problema. Funciona, pero no aprendes nada y la próxima vez que pase volverás al mismo punto sin pistas. El método correcto es ir capa a capa: empezar por el navegador, subir al plugin de caché del sitio, luego al CDN, después a la caché de objetos del servidor y solo al final a OPcache y DNS. Con esa secuencia, en la mayoría de casos identificas la capa culpable en menos de cinco minutos y aprendes a evitarla la próxima vez. Y, sobre todo, te ahorras tener que purgar toda la caché del sitio cuando bastaba con un Ctrl+F5 en tu navegador.