Cambiaste algo en WordPress, pero tus visitantes siguen viendo lo anterior: cómo investigar la caché

Guardás un cambio en WordPress y lo ves al entrar como administrador. Abrís la misma página desde otro navegador y aparece la versión anterior. Borrás una caché, recargás varias veces y el resultado cambia otra vez. Antes de seguir vaciando todo, conviene identificar qué recurso está viejo y qué capa lo está entregando.

El problema puede estar en el HTML, una hoja de estilos, una imagen o un dato que utiliza la aplicación. También puede ocurrir que el cambio nunca se haya publicado en la página que estás mirando. Este diagnóstico empieza por esa diferencia y propone una secuencia para aislar la causa sin desactivar permanentemente los mecanismos que aceleran el sitio.

Confirmá que estás comparando la misma versión

Copiá la URL completa: protocolo, dominio, ruta y parámetros. Revisá si una visita termina en una redirección, una versión de idioma o una página diferente. En sitios con plantillas, una página puede usar un bloque sincronizado o un encabezado distinto del que acabás de editar.

Comprobá estado de publicación y el contenido efectivamente guardado. Una vista previa de un borrador puede mostrar cambios que todavía no existen para visitantes. Elegí una señal verificable del cambio, como una frase concreta o el nombre de un archivo, para comparar respuestas sin depender de una impresión visual.

Registrá cuándo hiciste el cambio y qué debería verse. Conservá una copia del resultado anterior si necesitás comunicarlo al hosting o a desarrollo. No agregues un cambio nuevo cada vez que una prueba falla: terminás comparando versiones distintas del mismo problema.

Separá el documento de sus recursos

Si el texto nuevo no aparece en la respuesta HTML, investigá el documento y su generación. Si el HTML contiene la frase correcta pero el diseño sigue igual, mirá las hojas de estilos que esa respuesta solicita. Si cambiaste una imagen manteniendo la misma dirección, revisá ese archivo directamente.

En las herramientas de desarrollo del navegador, abrí Network y recargá. Seleccioná primero el documento principal; después el CSS, JavaScript o archivo que corresponde al cambio. Mirá dirección solicitada, respuesta y procedencia de la copia. Una página puede combinar HTML nuevo con recursos antiguos.

Si cambia al iniciar sesión, revisá las variantes de caché

Muchos sistemas tratan de forma diferente las visitas autenticadas y anónimas. Según su configuración, pueden omitir caché para administradores o mantener copias privadas separadas. Ver el cambio con tu sesión no demuestra que la copia pública se haya renovado.

Compará una visita sin sesión, una autenticada y, cuando sea útil, otro dispositivo. El modo incógnito ofrece un entorno de navegador separado, pero sigue pasando por el mismo hosting y CDN. Si ambos reciben la versión vieja, no alcanza para culpar al navegador.

Revisá también variantes por dispositivo, idioma o cookies. No deberían mezclarse respuestas que contienen información personal. Una exclusión necesaria para contenido privado tiene un propósito diferente de la caché pública de una página editorial.

Identificá las capas que realmente existen

Navegador

Puede reutilizar archivos o respuestas que ya descargó. Su configuración no controla las copias que conservan otros servidores.

Caché de páginas

Un plugin, el servidor o un proxy puede entregar HTML ya generado, evitando ejecutar WordPress en cada visita.

CDN

Puede almacenar contenido en sus nodos. Vaciar una caché de WordPress no garantiza que la integración también invalide esas copias.

Archivos optimizados

Un sistema puede generar versiones combinadas o transformadas de CSS y JavaScript. Esos archivos pueden necesitar regeneración además de una purga.

Caché de objetos y datos

Guarda resultados utilizados por la aplicación. Es otra capa: no equivale al HTML completo ni se corrige necesariamente con el mismo botón.

No todos los sitios usan todas las capas. Identificá proveedor, panel o componente responsable de cada una. Si hay una aplicación con service worker, revisá también si intercepta recursos; no borres registros o datos de una aplicación sin entender qué función cumplen.

Desactivá la caché del navegador como prueba acotada

En Chrome DevTools podés marcar Disable cache mientras las herramientas están abiertas y volver a cargar. Esto ayuda a distinguir una copia local de una respuesta que llegó por la red. No vacía la caché del hosting ni la del CDN.

Si el recurso nuevo aparece con esa prueba, investigá su política de almacenamiento y la manera de versionarlo. Si sigue viejo, contrastá lo que responde la red. Agregar un parámetro aleatorio puede generar otra clave de caché en algunos sistemas y no en otros; que esa variante funcione es una pista, no una reparación de la URL habitual.

Un comando de ejemplo para recuperar cabeceras y HTML mediante una petición GET, sin tu sesión de navegador:

curl -sS -D cabeceras.txt -o pagina.html 'https://negocio.example/'

Buscá la señal esperada dentro de pagina.html. Esa petición todavía puede atravesar proxies y CDN. No demuestra por sí sola cómo responde el origen directo ni cómo se comportan todas las visitas.

Leé las cabeceras como evidencia parcial

Age puede indicar la antigüedad estimada de una respuesta en una caché intermediaria. Su ausencia no demuestra que ninguna capa haya almacenado contenido. Cabeceras específicas del proveedor, como un estado HIT o MISS, describen esa capa según su implementación, no todo el recorrido.

Cache-Control expresa una política HTTP. Entre sus directivas, max-age se relaciona con frescura, no-cache permite almacenar pero exige validar antes de reutilizar, y no-store indica que no debe almacenarse. Leerlas correctamente evita interpretar no-cache como un botón que elimina todas las copias existentes.

Un estado 304 responde a una validación y permite reutilizar el cuerpo almacenado; no incluye un HTML nuevo que puedas comparar como si fuera un 200. Si revisás peticiones condicionadas, registrá validadores como ETag o Last-Modified y qué recurso están validando.

Podés pedir revalidación con una cabecera de solicitud, sin tratarla como garantía de acceso directo al origen:

curl -sS -H 'Cache-Control: no-cache' \
  -D cabeceras-validacion.txt -o pagina-validacion.html \
  'https://negocio.example/'

Si el HTML público está viejo, avanzá desde la generación hacia afuera

1. Confirmá el origen del contenido. Verificá publicación, plantilla y entorno correctos. Si necesitás comparar el origen directo, utilizá el procedimiento autorizado del hosting, conservando host y HTTPS; no cambies DNS de producción para hacer esta prueba.
2. Invalidá la página en la capa que la genera o almacena. Usá el mecanismo del plugin o servidor responsable. Incluí listados y portada si también dependen del contenido modificado.
3. Revisá el CDN. Comprobá si la purga anterior se propagó mediante una integración o si necesita una acción específica sobre la URL.
4. Volvé a solicitar la dirección habitual. Compará la señal y las cabeceras, sin depender únicamente de una variante con parámetros.
5. Repetí la visita. Verificá que la copia que se vuelve a almacenar también contenga el cambio. Una primera respuesta correcta seguida por otra vieja necesita más investigación.

Si el HTML recién generado ya está viejo, vaciar el CDN no corrige la causa. Investigá qué datos o plantilla usa WordPress. Si el origen está actualizado y el borde conserva lo anterior, concentrá la revisión en invalidación y variantes del intermediario.

Si el HTML está bien y el CSS está viejo

Comprobá que el archivo modificado sea el que la página carga. En algunos constructores hay que regenerar los archivos producidos por la herramienta; editar un archivo fuente distinto no cambia el recurso final. Revisá también si otra regla CSS anula el cambio: una apariencia vieja no siempre implica caché.

Cuando publicás un recurso nuevo, utilizá una estrategia de versión coherente, como un nombre con huella de contenido o un identificador que cambie con el archivo. Confirmá que el HTML publicado solicite esa versión y que las capas intermedias no ignoren el criterio elegido.

Reemplazar una imagen conservando su URL plantea un problema parecido. Una dirección nueva puede permitir distinguir el recurso, pero actualizá también las referencias pertinentes y verificá la versión entregada. No hace falta renombrar archivos continuamente si la política de publicación y validación ya resuelve el caso.

Comprobá el arreglo con el recorrido real

Volvé a probar como visitante, con la URL habitual y las variantes relevantes. Revisá portada, artículo, listados y recursos afectados. Si hubo cambios de formulario o compra, completá un recorrido controlado; un diseño actualizado no prueba que la acción funcione.

Registrá qué capa falló y qué ajuste evita repetirlo: regla de purga, integración, regeneración o versión del recurso. En cambios de plugin o tema, el procedimiento de actualización de WordPress con pruebas permite incorporar estas comprobaciones al despliegue.

Si el cambio afecta un archivo técnico como el sitemap, comprobá su respuesta pública además de la página del administrador. La auditoría de sitemap muestra qué revisar después de que la versión correcta esté disponible.

Un pedido útil a soporte incluye URL, hora, resultado esperado, respuesta recibida y pruebas realizadas, sin compartir cookies ni credenciales. Si necesitás intervenir en generación y publicación, un trabajo de desarrollo web debería dejar una causa identificada y una comprobación repetible. Vaciar todo puede resolver una ocasión; entender la capa responsable permite mantener el sitio.