“La caché no se vacía” no es un único tipo de error. Una respuesta de WordPress puede quedar guardada en el navegador, CDN, proxy inverso, caché de página, caché de objetos, opcode de PHP o fragmentos de la aplicación. Purgarlo todo a la vez elimina la pista que permite saber qué capa está obsoleta.
Identifica la capa obsoleta antes de purgar
Registra URL, host, estado de usuario y cabeceras. Compara la petición normal con una petición de bypass segura y, cuando sea posible, con la respuesta directa del origen.
Las cabeceras y las claves de caché son evidencia
Revisa edad, estado de caché, reglas Vary y si www, idioma, query string o dispositivo utilizan claves distintas.
Corrige el origen antes de invalidar
Si la base de datos o el archivo desplegado sigue siendo antiguo, una purga solo volverá a llenar la caché con contenido incorrecto.
Diferencia caché de página/CDN y caché de objetos
Menús u opciones antiguos con HTML nuevo pueden apuntar a caché de objetos; revisa el diagnóstico de Redis. En checkout hay otras restricciones; compara sesiones, cookies y caché de WooCommerce.
Reinicia PHP solo con evidencia
Un problema de opcode o de nodos con versiones distintas puede justificar reiniciar workers concretos, pero no es el primer paso por defecto.
Valida también la siguiente actualización
Después de corregirlo, cambia un valor controlado y confirma que la URL pública se invalida de forma previsible sin afectar páginas privadas o personalizadas.