Editas una página en WordPress, pulsas Actualizar y abres la web. El texto antiguo sigue ahí. Pruebas en una ventana privada y luego en el móvil. Nada, la misma versión. En el editor todo está bien, así que parece que la web te ignora.
Casi nunca es así. En algún punto entre tu editor y tus visitantes hay una caché que guardó la versión anterior de la página y la sigue sirviendo hasta que caduca o alguien le dice que la suelte. En una web moderna con WordPress o WooCommerce puede haber cuatro o cinco de esas cachés, y cada una se vacía de una forma distinta.
A continuación repasamos las capas en el orden en que las atraviesa una petición, cómo saber cuál está reteniendo tu página y la configuración que usamos para que los cambios guardados se publiquen solos.
Por qué las webs guardan páginas en caché
Generar una página de WordPress implica ejecutar PHP y varias consultas a la base de datos. En una tienda con tráfico eso puede costar unos cientos de milisegundos por petición. Una caché guarda el HTML ya terminado y entrega esa misma copia al siguiente visitante en pocos milisegundos. Por eso una web con caché va rápida y aguanta los picos de tráfico.
El precio es la frescura. Una caché que guarda las páginas una semana es muy rápida y, si nada la purga, va una semana por detrás. Las buenas configuraciones mantienen la duración larga y purgan exactamente las páginas que han cambiado, en el momento en que cambian.
Las capas entre tu editor y tus visitantes
1. El navegador del visitante
Los navegadores guardan imágenes, CSS y JavaScript, y a veces HTML, según las cabeceras que envía el servidor. Esta capa solo afecta a quien ya ha visitado la web antes, y por eso "en una ventana privada se ve bien" es una buena primera prueba.
2. La CDN
Servicios como Cloudflare se colocan delante del servidor y guardan ficheros en centros de datos cercanos al visitante. Por defecto, Cloudflare no guarda el HTML en caché, solo ficheros estáticos como imágenes, CSS y JavaScript. Si el texto de tu página está desactualizado y nadie ha añadido una regla de "cachear todo", lo más probable es que la CDN no sea la culpable. Si existe esa regla, es la primera sospechosa.
3. La caché del servidor (Varnish, Nginx, LiteSpeed)
Muchos paneles de alojamiento ponen una caché de página completa delante de PHP. CloudPanel, por ejemplo, incluye Varnish Cache con una duración configurable que, en las instalaciones con las que trabajamos, está en siete días. Esta es la capa que hay detrás de la mayoría de avisos de "mi cambio no se ve" que recibimos, por dos motivos:
- Necesita una purga explícita. Varnish conserva la página guardada hasta que caduca o recibe una petición PURGE. En la versión del plugin de WordPress de CloudPanel que revisamos en septiembre de 2026 (1.1.1), las purgas se lanzaban al actualizar plugins o el núcleo y al cambiar de tema, pero no al guardar una página, un producto o un bloque del maquetador.
- Puede servir una copia antigua una vez más. Con el modo gracia, el primer visitante después de la caducidad todavía puede recibir la página antigua mientras Varnish pide la nueva por detrás. La segunda petición ya recibe la versión actualizada.
Hay una segunda trampa en webs multilingües o que no están en inglés: la lista de rutas excluidas del panel usa slugs en inglés como /my-account/ y /cart/. Una tienda en español con /mi-cuenta/ o /carrito/ necesita añadir esas rutas a mano, o las páginas personales acaban en la caché compartida.
4. Plugins de caché de WordPress
Plugins como LiteSpeed Cache, WP Rocket o W3 Total Cache guardan su propia copia de cada página. La mayoría purgan al guardar, pero solo conocen el contenido que gestionan ellos. Cuando una web se muda a un servidor donde manda otra capa (Varnish, por ejemplo), las órdenes de purga del plugin pueden no llegar a ningún sitio.
5. Caché de objetos y cachés del tema o del maquetador
Redis o Memcached guardan resultados de la base de datos, y algunos temas y maquetadores conservan su propio CSS compilado o fragmentos. Rara vez ocultan un cambio de texto durante mucho tiempo, pero explican por qué un cambio de estilo a veces necesita un botón de "regenerar CSS".
Encuentra la capa que retiene tu página
No necesitas acceso al servidor para acotarlo. Las cabeceras de la respuesta dicen quién contestó y qué antigüedad tiene la copia. Abre la página, pulsa F12, ve a la pestaña Red, recarga, haz clic en la primera petición y lee las cabeceras de respuesta. Desde un terminal, curl -sI https://tuweb.com/pagina/ muestra la misma información.
| Cabecera | Qué te dice |
|---|---|
cf-cache-status | HIT significa que Cloudflare sirvió su copia. DYNAMIC significa que dejó pasar la petición y no guardó el HTML. |
age o x-cache-age | Segundos desde que se guardó la copia. Si es mayor que el tiempo que ha pasado desde que guardaste, estás viendo la versión antigua. Consulta la referencia de la cabecera Age. |
x-varnish, via | Varnish u otro proxy ha intervenido en la respuesta. |
x-litespeed-cache, x-cache | Ha respondido un plugin o una caché del servidor, con hit o miss. |
cache-control | Cuánto tiempo pueden guardar la página los navegadores y las cachés compartidas. |
Lectura rápida: si cf-cache-status es DYNAMIC y la antigüedad se mide en horas o días, la CDN está bien y es la caché del servidor la que retiene la página.
Arréglalo ahora y luego para siempre
Ahora mismo
- Purga la caché del servidor para la web desde el panel de alojamiento. En CloudPanel es la opción Purge Cache de los ajustes de Varnish del sitio, que también se puede limitar a una sola URL.
- Purga el plugin de caché de WordPress, si hay alguno.
- Purga la CDN solo si guarda HTML. Purgar ficheros estáticos que no has cambiado solo hace que los siguientes visitantes carguen más lento.
- Recarga dos veces y vuelve a mirar la cabecera de antigüedad. Por el modo gracia, la primera recarga todavía puede mostrar la página antigua.
Para siempre
Una purga manual está bien una vez. Como rutina significa que quien edite la web tiene que acordarse de un paso que nadie le ha explicado. Es mejor una configuración que purgue sola cuando cambia el contenido. En las webs con WordPress y WooCommerce que mantenemos, añadimos un pequeño plugin obligatorio (must use) que lanza la purga cada vez que cambia algo visible:
- publicar, editar o despublicar páginas, entradas y productos
- bloques del maquetador que se reutilizan dentro de otras páginas, como los pies de página
- menús, ajustes del Personalizador, categorías y etiquetas
- cambios de stock y reseñas recién aprobadas
Hay dos detalles importantes. La purga se lanza una sola vez al final de la petición, así que una edición masiva no dispara cien purgas. Y nunca se lanza con pedidos nuevos ni borradores, que no cambian nada de lo que ve un visitante. El contenido que cambia según un horario, como los horarios de apertura o las listas de eventos, recibe una duración más corta solo para esa página o fragmento, en lugar de acortar la caché de toda la web.
Las páginas siguen en caché durante días y una edición llega a todos los visitantes pocos segundos después de pulsar Actualizar.
Lista de comprobación rápida
- El cambio se ve bien en el editor pero no en la web: mira la cabecera
ageantes que nada. - Conoce las capas de caché de tu web. Si nadie sabe enumerarlas, esa es la primera tarea.
- Asegúrate de que las purgas se lanzan al guardar contenido, no solo al actualizar plugins.
- Comprueba que las exclusiones de caché coinciden con tus URL reales, sobre todo las páginas de cuenta, carrito y pago en otros idiomas.
- Después de mudarte a un servidor nuevo, confirma que el plugin de caché antiguo sigue teniendo con quién hablar.
Los problemas de caché forman parte del trabajo de rendimiento y mantenimiento que hacemos en webs con WordPress y tiendas online.
¿Siguen sin verse los cambios?
Dinos la dirección de la página y qué has cambiado. Encontraremos la capa que la retiene y configuraremos la purga para que la próxima edición se publique sola.