# Cómo comprobar si la caché de tu web funciona > Cómo comprobar si la caché de tu web funciona: compara visitas nuevas y repetidas, lee las cabeceras y confirma que las ediciones llegan al lector. Canonical: https://www.getdexseo.com/es/blog/rendimiento-web/comprobar-cache-web/ Author: Dex SEO, Editorial team Published: Oct 24, 2026 · Updated: Oct 24, 2026 ## Key takeaways - Escribe el resultado esperado para cada tipo de página. - Separa la caché del navegador de la compartida. - Compara una visita nueva y una repetida. - Comprueba que una edición llega a la versión pública. Para comprobar si la caché de tu web funciona, compara la misma página en una visita nueva y en una visita repetida. Revisa la página y sus archivos, y confirma después que un cambio pequeño llega a la versión pública. Una recarga rápida no prueba que todas las cachés funcionen ni que los lectores vean el contenido actual. Esta guía forma parte de la guía de [rendimiento web](https://www.getdexseo.com/es/blog/rendimiento-web/). ## ¿Qué es la caché de una web? La caché guarda una copia de una respuesta para reutilizarla en la siguiente petición. Así el navegador o el servidor no tienen que volver a descargar o generar todo. Esta guía trata de la caché que acelera tu propio sitio. No trata de ver copias antiguas de una página en buscadores o archivos web, que es otra búsqueda distinta. ## Define antes el resultado que esperas Escribe el resultado esperado antes de abrir una herramienta. Una guía pública puede reutilizar una copia durante poco tiempo. Su logotipo puede quedarse igual durante meses. Una página de cuenta con sesión iniciada necesita otras reglas. No las trates como una sola prueba. Elige una URL pública de tu sitio. Anota la fecha, el navegador, el dispositivo y si hay sesión iniciada. Elige una imagen, un script y una fuente de esa página, y usa el mismo grupo en la repetición. Define también cuánto debe tardar en aparecer una edición normal, según el proceso acordado con tu desarrollador. No cambies la duración de la caché solo para subir una puntuación. ## Caché del navegador, del servidor y de la CDN Una copia puede guardarse en el navegador o en un servicio compartido entre el lector y tu servidor: la caché de página del servidor o una CDN. Una visita repetida puede usar una capa y saltarse otra. Anota qué capa revisas en lugar de escribir solo “caché activada”. La guía de MDN sobre la [caché HTTP](https://developer.mozilla.org/es/docs/Web/HTTP/Guides/Caching) explica que `no-cache` no impide guardar la respuesta: impide reutilizarla sin validarla antes. Una respuesta 304 Not Modified puede ser una comprobación correcta de que la copia guardada sigue al día. Lee las etiquetas de estado con los términos de tu proveedor. Que falte una cabecera de acierto de caché no prueba un fallo. Pregunta al desarrollador qué señal identifica la caché compartida, qué páginas pueden usarla y qué peticiones deben saltársela. ## Cómo comprobar la caché con las herramientas del navegador Abre el panel Red del navegador antes de cargar la página. Anota si la opción que desactiva la caché está marcada. Para la prueba normal de visita repetida, déjala desmarcada: una prueba con la caché desactivada responde a otra pregunta. 1. Carga la página pública y guarda la lista de peticiones. 2. Anota el documento principal y los archivos elegidos. 3. Visita la página otra vez en las mismas condiciones. 4. Compara los datos transferidos, las cabeceras de respuesta y el contenido visible. 5. Repite la pareja de pruebas para ver si el patrón se mantiene. Entra a la página siempre por el mismo camino. Una visita normal, una recarga forzada y el botón Atrás pueden comportarse distinto. Para un archivo que solo aparece al hacer scroll, sigue el mismo recorrido en las dos visitas; la guía de [lazy loading de imágenes](https://www.getdexseo.com/es/blog/rendimiento-web/lazy-loading-imagenes/) ayuda a separar una petición diferida de un fallo de caché. ## Lee la evidencia de cada URL Revisa la URL exacta de cada petición: dos nombres parecidos pueden ser versiones distintas. Anota el estado de la respuesta, el origen de la caché que muestra el navegador, las cabeceras relevantes y si se transfirieron datos. Una cabecera indica una política o describe una respuesta. La petición repetida muestra lo que pasó en esa prueba. Léelas juntas. Si esperabas un acierto en la caché compartida y ves un fallo, anota las cookies, los parámetros de la URL, la región y las reglas del proveedor que puedan explicarlo. No copies cabeceras de otro sitio como arreglo universal. ## Comprueba que una edición llega a los lectores Haz primero un cambio pequeño y seguro en una página de prueba o en staging. Anota el texto antiguo y el nuevo. Publica por el proceso habitual y abre la URL pública como un lector. Después prueba un archivo cambiado. La guía de Google sobre la [caché HTTP](https://web.dev/articles/http-cache?hl=es-419) recomienda las URL con control de versiones: el archivo nuevo tiene un nombre nuevo, así la página no depende de la copia antigua. Confirma que la página nueva pide de verdad la URL nueva. Cambiar un nombre en una carpeta no basta si la página publicada apunta al archivo antiguo. Haz lo mismo con las fuentes: revisa el archivo que piden los estilos actuales, como explica la guía para [optimizar las fuentes web](https://www.getdexseo.com/es/blog/rendimiento-web/optimizar-fuentes-web/). Si ves estilos antiguos con HTML nuevo, revisa las dos versiones antes de tocar el diseño. Si la página actual sigue moviéndose, usa la guía para [reducir el CLS](https://www.getdexseo.com/es/blog/rendimiento-web/reducir-cls-imagenes/). Un archivo antiguo y un hueco pequeño para una imagen necesitan arreglos distintos. ## Ejemplo: localizar una copia antigua _Ejemplo ficticio._ Una empresa de reparaciones cambia un aviso público de “Llama el viernes” a “Llama el lunes”. El editor muestra lunes, pero un lector sigue viendo viernes. No es un resultado medido de DEX. Quien revisa anota la URL, las dos frases y la hora. Compara un navegador limpio y una visita repetida. El desarrollador revisa el documento guardado en cada capa gestionada. El equipo cambia solo la capa ligada a la respuesta antigua y repite la misma prueba. Si interviene un plugin de caché, sigue una [prueba controlada de plugins](https://www.getdexseo.com/es/blog/rendimiento-web/plugins-lentos-wordpress/). No cambies varios plugins y ajustes de entrega a la vez: perderías la evidencia de qué resolvió el problema. ## Una caché que funciona no hace rápida toda la página Un archivo bien guardado puede hacer demasiado trabajo cuando el navegador lo ejecuta. Si los clics siguen lentos después de que llega el archivo, revisa el [tiempo de ejecución de JavaScript](https://www.getdexseo.com/es/blog/rendimiento-web/tiempo-ejecucion-javascript/). Reutilizar y ejecutar son preguntas distintas. Del mismo modo, una respuesta lenta del documento necesita un [diagnóstico del TTFB](https://www.getdexseo.com/es/blog/rendimiento-web/mejorar-ttfb/). Guarda si la petición fue un acierto o un fallo de caché, para que la revisión del servidor empiece con contexto útil. DEX conecta la investigación de búsquedas, la planificación de contenido, la redacción de artículos y la publicación en el sitio conectado. DEX Health puede revisar la calidad SEO de la página publicada, también en el plan gratuito, pero no prueba qué caché sirvió una petición. Úsalo junto a la evidencia del navegador. ## Lista de comprobación de la caché - El resultado esperado está escrito para cada tipo de página. - Se sabe qué capa se revisa: navegador, servidor o CDN. - La visita nueva y la repetida se compararon en las mismas condiciones. - Una edición de prueba llegó a la versión pública. - Los archivos cambiados usan URL nuevas y la página las pide. - Las páginas con sesión o datos personales no se sirven desde una caché compartida. - Las funciones clave de la página siguen funcionando. ## FAQ ### ¿Una recarga rápida prueba que toda la caché funciona? No. Revisa cada capa y cada archivo en las mismas condiciones. ### ¿no-cache significa que no se guarda nada? No. Permite guardar la respuesta, pero exige validarla antes de reutilizarla. ### ¿DEX Health prueba un acierto de caché en la CDN? No. Usa la evidencia del navegador y del proveedor. ## Sources - [Caché HTTP](https://developer.mozilla.org/es/docs/Web/HTTP/Guides/Caching) — MDN Web Docs - [Evita solicitudes de red innecesarias con la caché HTTP](https://web.dev/articles/http-cache?hl=es-419) — web.dev (Google)