Para actualizar una página pública en caché, publica el documento actualizado, purga cualquier caché compartida que lo sirva y verifica el resultado en el navegador de tu Mac. Si Google sigue mostrando contenido antiguo, solicita un nuevo rastreo por separado; actualizar el navegador no modifica el índice de Google.

Esta guía está dirigida a quien mantiene un documento público y necesita que los lectores reciban su contenido revisado en la URL existente. Los pasos de escritorio usan Chrome en macOS. Un «Paper Shapes Guide» ficticio, que cambia de «Revision A: circles» a «Revision B: circles and squares», permite distinguir las versiones fácilmente durante todo el proceso.

¿Por qué editar la fuente no actualiza todas las páginas en caché?

La invalidación HTTP elimina una respuesta almacenada o exige validarla antes de volver a usarla. La RFC 9111 exige que una caché invalide el URI de destino después de una solicitud que cambia el estado y que haya pasado correctamente por esa caché, pero especifica que esto no invalida las copias de forma global. Por eso, un flujo de publicación debe tener en cuenta las cachés que no forman parte de la ruta de la solicitud de edición. RFC 9111: Invalidating Stored Responses.

Para el Paper Shapes Guide, prepara una breve lista de verificación de los resultados afectados por la edición. Si el texto revisado también aparece en una página de colección, inclúyela. Si solo cambia la guía, limita la lista a ese documento. Esta lista de dependencias es una ayuda editorial: empieza por la fuente modificada e identifica cada documento publicado que ahora debería mostrar algo distinto.

Usa la siguiente secuencia para elegir el próximo paso. Considera cada resultado una pista de diagnóstico, no una prueba de que todos los lectores reciben la misma respuesta.

Lo que observas Qué comprobar después
El sistema de publicación sigue mostrando la Revision A en el contenido publicado Confirma que la Revision B se publicó o se generó correctamente.
El contenido publicado es la Revision B, pero al recargar la página desde la red el navegador recibe la Revision A Investiga la caché compartida o el documento que sirve el host.
Al recargar desde la red aparece la Revision B, pero al recargar normalmente aparece la Revision A Investiga la caché local del navegador y la política de caché de la respuesta.
La página pública muestra la Revision B, pero la información indexada de Google sigue siendo antigua Usa la prueba en vivo de Search Console y luego considera solicitar la indexación.

Google documenta la distinción que explica la última fila: el informe inicial de Inspección de URLs describe la versión indexada, mientras que la prueba en vivo obtiene la página actual. Por lo tanto, un informe de indexación antiguo puede coexistir con un documento público corregido. Herramienta de Inspección de URLs.

Publica el documento modificado antes de purgar su caché

Primero, anota la URL pública exacta y el cambio esperado. En este ejemplo ficticio, la frase esperada es «Revision B: circles and squares». Usa una frase distintiva que ya sea apropiada para el documento; así podrás reconocer el contenido nuevo sin depender de cuándo se abrió una pestaña.

Publica la edición mediante tu sistema de publicación actual. Si ese sistema genera documentos a partir de archivos fuente, confirma que el resultado publicado incluya la frase revisada. En este flujo, guardar el contenido fuente y generar el documento público son dos puntos de control distintos; sigue el procedimiento de publicación documentado de tu plataforma.

Después, invalida la caché compartida, si la hay. El orden importa: por ejemplo, Cloudflare documenta que, tras una purga, las solicitudes obtienen el recurso del origen y lo vuelven a añadir a la caché de la CDN. Si purgas mientras el origen todavía sirve el documento antiguo, ese documento puede volver a llenar la caché. Purgar un solo archivo.

Ejemplo documentado en el panel de control de Cloudflare

Si tu página pública usa la caché de Cloudflare, su purga documentada de un solo archivo ofrece un procedimiento concreto que puedes seguir en el navegador:

  1. Abre el panel de control de Cloudflare del sitio correspondiente y ve a Configuration.
  2. En Purge Cache, selecciona Custom Purge.
  3. En Purge by, elige URL.
  4. Introduce la URL pública exacta de cada documento afectado.
  5. Revisa las entradas y selecciona Purge.

Estas etiquetas y pasos proceden de las instrucciones de Cloudflare para purgar un solo archivo.

Consulta los límites documentados antes de repetir una purga. Purgar una redirección elimina la respuesta de redirección, así que purga la URL de destino para actualizar su contenido. Algunas claves de caché personalizadas no se pueden borrar mediante el formulario de URL del panel; Cloudflare documenta como alternativas las purgas por prefijo o por etiqueta. La purga de un solo archivo tampoco admite comodines. Límites y alternativas de purga.

Si usas otro host o una CDN, utiliza el control de invalidación documentado por ese proveedor. El procedimiento de Cloudflare es un ejemplo condicional, no una interfaz universal. Si tu servicio de publicación no ofrece una operación de purga, consulta la duración de la caché y el comportamiento de actualización que documenta, en lugar de inventar una URL de purga o asumir que un botón del navegador controla sus servidores.

Verifica la respuesta pública en tu Mac

Abre la URL pública existente de la página en Chrome. Pulsa Command–Option–I para abrir DevTools y selecciona Network. Chrome documenta este atajo para Mac y distingue entre recargas normales, recargas forzadas y recargas que vacían la caché. Abrir Chrome DevTools.

Con DevTools abierto, selecciona Disable cache en el panel Network y vuelve a cargar la página. Chrome documenta que este ajuste hace que las recargas normales eviten su caché. Mantén DevTools abierto durante la comprobación. Recargar con o sin caché.

Selecciona la solicitud del documento principal en la lista de red. Abre Headers para inspeccionar los encabezados de respuesta y Response para examinar el contenido recibido. Busca en ese documento la frase esperada de la Revision B. El tutorial de red de Chrome explica cómo inspeccionar solicitudes, encabezados y contenido de respuesta individuales. Inspeccionar la actividad de red.

Anota tres observaciones: la URL solicitada, si el documento recibido contiene la Revision B y los encabezados de caché que lo acompañan. Así tendrás una comparación útil después de la purga. Que la operación en el panel de control haya terminado correctamente es un punto de control; recibir el documento previsto es el punto de control que resuelve la necesidad inmediata del lector.

Luego desactiva Disable cache y vuelve a cargar la página. Compara el resultado con la prueba de red. Si no coinciden, conserva ambas observaciones al revisar la política de respuesta. Borrar la caché del navegador repetidamente sin anotar la diferencia dificulta identificar la causa.

El estándar Fetch de WHATWG explica por qué importan los modos de solicitud del navegador. El modo reload omite la caché HTTP del navegador al acceder a la red y actualiza esa caché con la respuesta. El modo no-cache realiza una solicitud condicional cuando existe una respuesta en caché. Estos son comportamientos de solicitud, así que ninguno equivale a purgar globalmente las páginas almacenadas en cachés compartidas. Estándar Fetch: modos de caché de solicitudes.

Elige una política de caché adecuada para futuras ediciones

Para un documento público que debería comprobarse antes de cada reutilización, considera la directiva de respuesta Cache-Control: no-cache. Permite el almacenamiento, pero exige una validación correcta antes de volver a usar el contenido. Cache-Control: no-store prohíbe el almacenamiento. max-age de una respuesta especifica su período de frescura; must-revalidate se aplica después de que deja de estar fresca. Estas directivas responden a necesidades distintas. RFC 9111: Directivas Cache-Control de respuesta.

Como ejemplo de decisión, supongamos que el Paper Shapes Guide cambia ocasionalmente y que es aceptable comprobar si hay actualizaciones en cada visita. La revalidación es una política razonable para analizar con la persona que configura el host. Si se prefiere reutilizar el contenido sin una comprobación de red, elige un período de frescura que se ajuste al tiempo durante el cual una versión antigua todavía sea aceptable y mantén un procedimiento de purga documentado para las actualizaciones anticipadas.

Cambiar la política en una respuesta recién publicada no puede avisar a un navegador que sigue reutilizando una respuesta antigua todavía fresca sin ponerse en contacto con el servidor. Por lo tanto, las copias almacenadas existentes también forman parte de la transición. Esto se desprende de las reglas HTTP de frescura y reutilización; por eso, al establecer un nuevo encabezado conviene definir también un plan explícito para las copias existentes. RFC 9111: Construcción de respuestas a partir de cachés.

Asegúrate de que la validación reconozca la revisión

Un ETag identifica una representación para validarla. Last-Modified indica cuándo se modificó. Pide al servidor que genere validadores que reflejen la representación publicada, incluidos los cambios pertinentes en contenido compuesto a partir de otras fuentes. La RFC 9110 describe ambos validadores y explica que, en algunos casos, las etiquetas de entidad pueden distinguir las representaciones con más fiabilidad que las fechas de modificación. RFC 9110: Campos de validación.

Una respuesta 304 Not Modified indica al destinatario que reutilice una representación almacenada válida en lugar de transferir el documento otra vez. Es normal cuando la versión almacenada sigue siendo la actual. Si recibes ese resultado y sigues viendo la Revision A después de confirmar un cambio de contenido, investiga qué representación y qué validador evaluó el servidor. RFC 9110: 304 Not Modified.

Pide a Google que vuelva a visitar la página corregida

Cuando el documento público sirva la Revision B de forma coherente, inspecciona su URL completa en la propiedad correspondiente de Search Console. Selecciona Test live URL para examinar la página actual. Compara ese resultado con el informe de indexación, que puede describir un rastreo anterior. La prueba en vivo comprueba la página actual; por sí sola no demuestra que el índice de Google se haya actualizado. Herramienta de Inspección de URLs.

Para una página actualizada concreta, selecciona Request indexing en el resultado de inspección. Debes ser propietario o usuario con permisos completos de la propiedad de Search Console. Google indica que el rastreo puede tardar desde unos días hasta unas semanas, que las solicitudes repetidas no lo aceleran y que solicitar un rastreo no garantiza la inclusión en los resultados de búsqueda. Pide a Google que vuelva a rastrear tus URLs.

Para muchas páginas actualizadas, Google recomienda enviar un sitemap. Mantén precisos los valores <lastmod>: Google indica que deberían reflejar cambios significativos, como actualizaciones del contenido principal, en lugar de cambios rutinarios en la fecha de copyright. Un sitemap ayuda a comunicar qué documentos han cambiado; no purga las copias del navegador ni las de la CDN. Crear y enviar un sitemap.

Termina con un breve registro de publicación: las URL afectadas, la frase de revisión esperada, la comprobación del contenido publicado, la acción sobre la caché compartida y el resultado de la verificación en el navegador. Registra por separado cualquier solicitud de nuevo rastreo de Google. Así podrás comprobar el objetivo inmediato —servir el documento público revisado— y tendrás claro cuál es el siguiente paso si todavía aparece una versión antigua.

Fuentes