Publicas una corrección, la vista previa del editor es correcta, pero los visitantes aún ven la versión anterior. Purgar cada caché puede ocultar qué capa falló y crear una gran ráfaga de tráfico no almacenado en caché.
Siga el contenido desde el almacenamiento de WordPress hasta la respuesta pública y borre solo la capa propietaria de la copia obsoleta.
Confirma que la actualización existe en WordPress
Vea la página guardada en el editor y verifique el historial de revisiones. Luego use la vista previa de WordPress mientras está conectado. Si el propio editor muestra contenido antiguo, el problema puede ser una revisión no guardada, una traducción, un bloque reutilizable o una plantilla de creación de páginas, no un caché de página completa.
Verifique que haya editado el mismo idioma y la URL canónica que usan los visitantes. Una página de servicio puede heredar texto de una plantilla global mientras su editor contiene solo un código corto o marcador de posición.
Comparar respuestas privadas y registradas
Abra la URL pública en una nueva sesión privada e inspeccione la fuente de su página. Busque una frase modificada distintiva.
Si la página de inicio de sesión es actual pero el HTML privado es antiguo, es probable que se almacene en caché la página o el CDN. Si el HTML está actualizado pero la página visible del navegador es antigua, el CSS generado, JavaScript, el almacenamiento del cliente o un trabajador del servicio pueden ser los responsables.
Agregue configuraciones de desarrollador sin caché solo para diagnóstico; Los visitantes comunes todavía necesitan ser probados a través de la ruta de entrega real.
Identificar la capa obsoleta de los encabezados
Registre los encabezados de respuesta para la URL canónica. Busque antigüedad de CDN y estado de acceso, marcadores de caché de hosting y directivas de control de caché.
Primero borre la página específica en el caché de WordPress y luego solicítela nuevamente. Si la CDN continúa entregando una respuesta antigua con una antigüedad alta, elimine esa URL pública exacta.
No purgue una zona CDN completa para un cambio de texto a menos que el proveedor no pueda apuntar al recurso y el impacto comercial lo justifique.
Verifique las claves de URL alternativas
La caché puede contener entradas separadas para:
- barra diagonal y sin barra diagonal;
wwwy host principal;
-HTTP y HTTPS;
- prefijos de idioma;
- variantes móviles;
- parámetros de consulta.
Corrija las redirecciones para que los visitantes converjan en una forma canónica. Purgue tanto el origen como el destino solo cuando el origen mismo pueda servir HTML almacenado en caché en lugar de una simple redirección.
No configure todas las cadenas de consulta como equivalentes sin verificar la búsqueda, la vista previa, la moneda y el comportamiento de la campaña.
Inspeccionar los recursos generados del constructor visual
Si el texto es correcto pero el espaciado, los colores o las imágenes de fondo son antiguos, regenere el CSS del constructor a través de su herramienta compatible. La caché HTML y la caché CSS son objetos diferentes.
Una hoja de estilo generada puede tener un nuevo nombre de archivo mientras que el HTML almacenado en caché aún hace referencia al anterior, o la CDN puede contener el archivo antiguo en una URL estable.
Evite eliminar manualmente los directorios del constructor. Esto puede dejar páginas sin estilo durante la regeneración y puede eliminar archivos propiedad de otro proceso.
Distinguir el caché de objetos del caché de página completa
La caché de objetos persistente almacena resultados de consultas de bases de datos y valores calculados. WordPress normalmente invalida los objetos relevantes cuando se actualiza una publicación, pero el código personalizado puede usar su propia clave de caché sin caducidad adecuada.
Si un widget dinámico permanece obsoleto después de omitir los cachés de página completa, inspeccione su plugin o su comportamiento transitorio. Vaciar toda la caché de objetos puede afectar a otras aplicaciones y crear un pico en la base de datos.
Elimine un grupo transitorio o de caché específico solo cuando se comprenda la propiedad y haya una reversión disponible.
Prueba de invalidación automática
Después de restaurar la página actual, realice un cambio inofensivo en la preparación y publíquela. Confirme qué entradas de caché se borran automáticamente y cuánto tiempo lleva la propagación pública.
Pruebe archivos relacionados si la edición cambia un título, una imagen destacada o datos del producto. La página individual, el listado de categorías y la tarjeta de la página de inicio pueden tener entradas de caché independientes.
Documente la ruta de actualización normal para los editores para que no purguen repetidamente todos los cachés.
Cuando el contenido obsoleto necesita reparación
Solicite una evaluación cuando solo un idioma o variante de dispositivo permanezca obsoleto, los encabezados de la caché entren en conflicto o las actualizaciones requieran una limpieza manual repetida. Comparta las URL públicas, la frase esperada y las marcas de tiempo; no envíe credenciales en la primera consulta.
Una reparación duradera alinea la invalidación en WordPress, los recursos del creador y la CDN, al tiempo que mantiene la caché efectiva para los visitantes.