Si has corregido una oferta en la web y un cliente sigue viendo la versión anterior, comprueba qué contenido devuelve el servidor y qué capas reutilizan una copia. El editor puede mostrar el cambio mientras el navegador o un servicio intermedio conserva otra respuesta. Publicar y verificar lo visible son pasos diferentes.

Antes de vaciar todas las cachés, identifica qué dato discrepa y en qué recorrido aparece. Un importe antiguo, una imagen sin actualizar y una sesión que conserva una pantalla pueden tener causas distintas. Una intervención indiscriminada dificulta explicar qué falló y puede afectar al rendimiento.

La versión del editor no es la versión del comprador

Anota el texto anterior y el nuevo, la URL y el momento de publicación. Si hay contenido dinámico, describe también las condiciones que determinan la oferta. Comparar dos capturas sin esos datos puede confundir una copia antigua con una variación legítima.

Comprueba la página pública fuera del editor. Después revisa el recorrido de alguien que ya la había visitado. Una sesión privada puede ayudar a contrastar una primera entrada, pero no reproduce necesariamente el estado de un visitante recurrente ni todas las capas intermedias.

Evita pedir a cada cliente que limpie su navegador como solución estable. Puede servir para diagnosticar un caso, pero traslada al comprador un problema de publicación. La empresa necesita una política que indique cuándo una condición debe volver a comprobarse.

Qué explica realmente la caché HTTP

La guía de caché de MDN describe reutilización y validación de respuestas. Aclara que no-cache obliga a validar antes de reutilizar en el flujo HTTP correspondiente, mientras no-store impide almacenar la respuesta. Son instrucciones distintas, no sinónimos de «mostrar siempre lo nuevo» en cualquier recorrido.

La misma guía distingue la navegación histórica: volver con el botón atrás puede restaurar una pantalla previa. Por eso una política HTTP no sustituye la prueba del recorrido real. La configuración apropiada depende del recurso y de las capas que lo sirven.

No conviertas esa explicación en una receta universal. Un archivo de estilo con nombre ligado a su contenido y una oferta que cambia de condiciones tienen necesidades diferentes. El equipo técnico debe revisar cabeceras, validadores y reglas del proveedor, comprobando su respuesta efectiva.

Elige la frescura según la consecuencia del dato

Clasifica contenido por lo que ocurre si una copia se retrasa. Una foto editorial suele tolerar más demora que una condición comercial. El criterio no debería ser solo la frecuencia con que alguien pulsa «actualizar» en el gestor.

  • Identidad visual estable: optimización y reutilización con versión controlada.
  • Información de servicio: actualización prevista y validación coherente.
  • Condiciones cambiantes: límite de antigüedad acorde con su uso.
  • Información privada: política específica de acceso y almacenamiento.

Estas categorías son una propuesta de revisión, no una configuración lista para pegar. Incluye a quien conoce la oferta: solo negocio puede explicar qué discrepancia produciría una promesa incorrecta y en qué momento debe detenerse una operación.

La fecha visible debe tener una función

Una fecha de actualización puede orientar al comprador, pero no corrige una copia vieja. Si se genera automáticamente en cada build sin revisión del contenido, puede dar una impresión de frescura que no corresponde al dato. Muestra lo que puedas justificar.

Recurso práctico: presupuesto de antigüedad

Propongo un presupuesto de antigüedad por tipo de información. Registra el dato, quién lo confirma, qué demora es aceptable, dónde podría persistir una copia y qué prueba demuestra la actualización. «Aceptable» debe definirse por consecuencia, no por comodidad técnica.

Para una oferta, la ficha puede indicar: responsable comercial, cambio confirmado, URL afectada, caché intermedia revisada y prueba desde una sesión previa. Si aparece otra versión, identifica la capa antes de aprobar la publicación. Guarda la evidencia sin incluir datos del cliente.

Añade un procedimiento de corrección urgente separado del cambio ordinario. Debe decir quién puede invalidar una copia y cómo comprobar el resultado. Invalidar un servicio intermedio no borra automáticamente todas las copias que un navegador o un documento ya conservaron.

Caso hipotético: una condición corregida sigue circulando

Una empresa ficticia cambia el alcance incluido en un servicio. El gestor muestra el texto nuevo, pero una persona que vuelve desde una pestaña abierta conserva la explicación anterior. Comercial recibe una consulta basada en una condición que ya no pretende ofrecer.

El equipo comprueba que el servidor sirve la versión correcta, reproduce la vuelta desde una sesión previa y revisa cómo se valida el dato al iniciar una solicitud. Ajusta la política correspondiente y comunica el alcance actual antes de que se confirme el encargo.

El caso hipotético no atribuye pérdidas ni mejoras. La aceptación requiere documentar los recorridos probados y sus límites. Una captura nueva puede confirmar una respuesta, pero no demostrar que todas las sesiones existentes hayan actualizado su contenido.

Una hipótesis sobre webs que publican más deprisa

Si la generación y revisión de contenido aceleran los cambios, mi hipótesis es que la antigüedad tolerable deberá formar parte del brief. La velocidad de edición servirá de poco si la distribución tarda más de lo que admite la decisión comercial.

La apoyarían discrepancias repetidas entre contenido aprobado y condiciones vistas por compradores. La debilitaría una web estable donde las copias retrasadas no afectan a ninguna decisión. No justificaría desactivar la caché de todo el sitio ni sacrificar rendimiento sin evidencia.

Comprueba lo que puede ver quien ya estuvo aquí

Elige un dato comercial y prueba tanto una primera entrada como una vuelta desde una sesión previa. Relaciona su frescura con la consecuencia de equivocarse. Esa revisión permite conservar rendimiento y publicar con una evidencia más precisa que «ya aparece en el editor».

Para completar esta decisión, consulta Cómo revisar versiones de documentos técnicos.