Idiomas

Caché para SEO

Cómo la caché del navegador y del servidor, con Cache-Control, ETags y CDN, mejora el rendimiento y los Core Web Vitals, y qué errores de caché afectan al rastreo.

Publicado por primera vez: 2 jul 2026 · Última actualización: 8 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

La caché guarda una copia de una página o recurso —en el navegador, en el edge de una CDN o en la caché del propio rastreador— para no tener que regenerarlo o descargarlo. No es un factor directo de posicionamiento, pero alimenta la velocidad de página/Core Web Vitals (mediante TTFB y LCP) y la eficiencia de rastreo. El rastreador de Google solo respeta ETag y Last-Modified (además de max-age como sugerencia de nuevo rastreo), prefiere ETag y dice que «no se admiten otras directivas de caché HTTP». Los errores más arriesgados no son las duraciones lentas, sino las malas configuraciones de CDN y las cachés obsoletas que bloquean o desorientan a los bots.

TL;DR — La caché funciona en tres capas importantes para el SEO: navegador, edge de CDN y caché de solicitudes condicionales propia del rastreador. No es un factor de posicionamiento, pero impulsa la velocidad de página (TTFB/LCP y, mediante bfcache, los Core Web Vitals de las navegaciones repetidas) y la eficiencia de rastreo. El rastreador de Google prefiere ETag frente a Last-Modified, lee max-age solo como sugerencia de nuevo rastreo y, según su propia documentación, “other HTTP caching directives aren’t supported.” (traducción) «No se admiten otras directivas de caché HTTP.» Las CDN obtienen una asignación de frecuencia de rastreo mayor, pero solo cuando su caché está caliente; los riesgos reales son los lanzamientos con caché fría y las configuraciones incorrectas de CDN/WAF que bloquean directamente a los bots.

Evidence for this claim Google's crawler documentation supports ETag/If-None-Match and Last-Modified/If-Modified-Since, prefers ETag when both are present, and says other HTTP caching directives are unsupported; Google's separate max-age advice is a recrawl-timing hint, not proof it follows browser cache semantics. Scope: Google crawling Confidence: high · Verified: Crawling December: HTTP caching Evidence for this claim HTTP caching uses Cache-Control and validators to control reuse and revalidation. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching Evidence for this claim Browser caches can reuse stored responses according to HTTP caching semantics. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching

Las tres capas de caché

La caché para SEO no es una sola cosa: son tres, y cada una se controla de una manera algo distinta:

  1. Caché del navegador: el dispositivo del visitante guarda archivos para que las vistas repetidas eviten la red. Esto es lo que PageSpeed Insights recuerda con «Servir recursos estáticos con una política de caché eficiente».
  2. Caché de CDN/edge: una red de distribución de contenido guarda copias en nodos edge de todo el mundo (consulta el análisis profundo de CDN y SEO para conocer todos los detalles). Según la descripción de Google, las CDN son intermediarias entre tu origen y el usuario y, históricamente, su mayor foco es la caché: guardan el contenido de una URL para que tu servidor no tenga que servir ese archivo otra vez durante un tiempo.
  3. Caché del lado del rastreador: Googlebot y Bingbot mantienen su propio registro de si el contenido cambió mediante solicitudes condicionales. Esta es la palanca del presupuesto de rastreo; la mecánica corresponde al análisis profundo de solicitudes condicionales, así que aquí la resumiré.

«Caché del navegador» arriba es una forma abreviada de referirse a más de un mecanismo. Según la guía de caché HTTP de MDN, conviene distinguir la caché HTTP privada (por navegador, indexada por solicitud y, en los navegadores modernos, particionada por sitio de nivel superior para limitar el seguimiento entre sitios), la caché en memoria de la sesión actual, la bfcache que se explica abajo y, por separado, el Cache Storage de un service worker, controlado por el propio JavaScript del sitio y no gobernado directamente por los encabezados Cache-Control. «Comprobar la caché del navegador» puede significar cuatro pasos de depuración distintos según cuál esté fallando.

Cómo la caché alimenta los Core Web Vitals

Obtener recursos por la red es lento y costoso. La caché elimina la latencia de red y el coste de transferencia de todo lo que no ha cambiado. Eso repercute directamente en dos medidas relacionadas con los vitales: TTFB (una respuesta en caché evita regenerar el contenido en el origen) y LCP (las imágenes, el CSS y las fuentes en caché se renderizan antes).

Cache-Control, en las directivas que importan

Cache-Control es el encabezado principal. Estas son las directivas que conviene conocer:

  • max-age=<seconds>: cuánto tiempo es válida una copia reciente. Para recursos inmutables y versionados, la documentación de Lighthouse de Chrome recomienda guardar en caché un año o más, por ejemplo Cache-Control: max-age=31536000.
  • no-cache: no significa «no guardar en caché». Significa «guárdalo, pero vuelve a validarlo con el servidor antes de reutilizarlo». Sigue habilitando el flujo ligero 304.
  • no-store: es la directiva que realmente significa no guardar ninguna copia en ningún sitio de una caché HTTP. Es una directiva de caché, no un interruptor de privacidad general; según RFC 9111, no es una forma fiable de borrar el historial del navegador y no dice nada sobre el Cache Storage propio de un service worker.
  • public / private: indica si las cachés compartidas (como una CDN) pueden guardar la respuesta o si solo puede hacerlo el navegador del usuario final.
  • immutable: omite por completo la revalidación mientras la respuesta siga siendo reciente. No significa «nunca se queda obsoleta»: cuando se agota max-age, vuelven a aplicarse las reglas normales de frescura.
  • must-revalidate: el extremo opuesto de la línea temporal: solo importa después de que una respuesta se quede obsoleta y le dice a la caché que debe revalidar con el origen en vez de servir de todos modos la copia obsoleta.
  • s-maxage, stale-while-revalidate, stale-if-error: controles más precisos, sobre todo para CDN y otras cachés compartidas (una duración de frescura separada para cachés compartidas, reutilización limitada de contenido obsoleto mientras se ejecuta una descarga en segundo plano y reutilización limitada de contenido obsoleto cuando falla el origen, respectivamente). La compatibilidad varía según el navegador/CDN, así que comprueba la compatibilidad actual antes de depender de ellas; como veremos, el rastreador de Google no respeta este conjunto adicional de directivas.

Invalidación de caché con nombres de archivo versionados

El truco que permite guardar agresivamente en caché y actualizar al instante: incluye un hash del contenido en el nombre de archivo, como style.x234dff.css. Como la URL es la clave de caché, cambiar el archivo cambia la URL, así que las cachés obtienen inmediatamente la versión nueva mientras las versiones antiguas permanecen en caché todo el tiempo que quieras. Tanto la guía de caché HTTP de web.dev de Google como el artículo de ingeniería de front-end de Bing describen el mismo patrón: Bing incluye un hash del contenido en la URL para que «the URL acts as the cache key,» (traducción) «la URL actúe como clave de caché», lo que mantiene coherentes las cachés y permite tiempos de expiración largos.

La trampa de bfcache: cómo no-store perjudica silenciosamente los CWV

Este caso se menciona menos de lo que debería. La caché de atrás/adelante (bfcache) es la que permite que pulsar «atrás» restaure una página al instante. Una restauración desde bfcache omite por completo la medición de LCP/CLS/INP, así que es una ventaja neta para tus datos de campo de CrUX. Sin embargo, según la guía de bfcache de Google, establecer Cache-Control: no-store en el documento de la página ha hecho históricamente que los navegadores se nieguen a guardar esa página en bfcache. Si necesitas frescura en un documento HTML pero no quieres sacrificar la elegibilidad para la caché de atrás/adelante, usa no-cache o max-age=0 en lugar de no-store.

Cómo decide una caché que algo está «lo bastante fresco»

Antes de que intervenga cualquier validador, una caché comprueba la frescura: ¿la antigüedad de la respuesta almacenada ha superado la duración de frescura que le dio Cache-Control (o, si no hay una duración explícita, una duración heurística que la caché puede estimar)? El encabezado de respuesta Age informa de cuánto tiempo ha conservado ya una respuesta una caché compartida; así puedes saber, en DevTools o en un registro de CDN, cuánto tiempo de frescura queda. Fresca significa que la caché puede reutilizarla inmediatamente, sin ninguna solicitud. Obsoleta significa que debería validarla antes de reutilizarla; justo ahí resultan útiles ETag/If-None-Match y Last-Modified/If-Modified-Since, que se describen a continuación para la versión más limitada de este mecanismo HTTP general que usa Googlebot.

Cómo usa Googlebot la caché (el ángulo de la eficiencia de rastreo)

Google hizo una petición inusualmente directa en su publicación de diciembre de 2024 Rastreo de diciembre: caché HTTP: habilita la caché para que sus rastreadores puedan evitar volver a descargar páginas sin cambios. El dato llamativo de esa publicación es que las descargas almacenables en caché han ido disminuyendo: hace 10 años se podía guardar en caché aproximadamente el 0,026 % del total de descargas y hoy esa cifra es del 0,017 %. Son cifras pequeñas, pero Google quiere claramente que vayan en la otra dirección.

ETag frente a Last-Modified: cuál prefiere Google

La infraestructura de rastreo de Google admite los dos validadores estándar: ETag (con If-None-Match) y Last-Modified (con If-Modified-Since). Google recomienda encarecidamente ETag porque su valor no está estructurado y, por tanto, es menos propenso a los errores de análisis que puede provocar una cadena de fecha; si ambos están presentes, sus rastreadores usan el valor de ETag, como exige el estándar HTTP. Aun así, Google recomienda establecer ambos, ya que otras aplicaciones, como los CMS los usan. Si utilizas Last-Modified, la fecha debe seguir el formato HTTP (por ejemplo, Fri, 4 Sep 1998 19:15:56 GMT) o no se analizará.

Cuando el validador almacenado por el rastreador sigue coincidiendo, tu servidor devuelve un 304 Not Modified sin cuerpo, que es precisamente el objetivo. Como dice Google, no tener cuerpo significa que tu servidor no gasta capacidad de cálculo en generar contenido ni ancho de banda en transferirlo. (Ese mecanismo 304 es el mecanismo de presupuesto de rastreo que se trata en profundidad en el artículo sobre solicitudes condicionales; aquí basta con saber que existe y ahorra dinero a ambas partes.)

El matiz que casi todo el mundo pasa por alto

El rastreador de Google no actúa sobre el conjunto completo de directivas Cache-Control como lo hace un navegador o una CDN. Según la descripción oficial de los rastreadores, aparte de ETag/Last-Modified, “other HTTP caching directives aren’t supported.” (traducción) «No se admiten otras directivas de caché HTTP.» La única excepción parcial: Google dice que puedes establecer max-age opcionalmente para ayudar a los rastreadores a determinar cuándo volver a rastrear una URL: una sugerencia de nuevo rastreo, no un bloqueo estricto. Así que no-cache, s-maxage, stale-while-revalidate y similares siguen dando forma al comportamiento del navegador y de la CDN, pero no cambian cómo guarda Googlebot la caché. El consejo de Google sobre cuándo invalidar también es sensato: exige una actualización de caché cuando haya cambios importantes; actualizar solo la fecha de copyright del pie de página no es importante.

CDN y rastreo

Una CDN te aporta más que velocidad. La infraestructura de rastreo de Google está diseñada para permitir frecuencias de rastreo más altas en sitios respaldados por una CDN, inferidas a partir de la dirección IP que sirve las URL: supone que un origen respaldado por una CDN puede gestionar más solicitudes simultáneas.

Pero hay un inconveniente que conviene planificar: la caché fría. En el primer acceso a una URL, la caché de la CDN está «fría»: nadie la ha solicitado todavía, así que tu origen tiene que servirla al menos una vez para calentar la caché. Google advierte que lanzar muchas URL a la vez supone por eso una carga real para el presupuesto de rastreo, con una frecuencia de rastreo alta durante unos días. Si haces un lanzamiento grande o una migración de sitio, reserva capacidad para que el origen soporte la carga completa de cada URL antes de que la CDN empiece a ayudar.

Una configuración incorrecta de CDN es un riesgo de rastreo

Los problemas relacionados con la caché más preocupantes no son las duraciones lentas, sino las configuraciones de CDN y WAF que bloquean a los bots. La publicación de Google sobre CDN es explícita: para bloqueos temporales, enviar 503/429 es la forma preferida de indicarlo, mientras que los tiempos de espera de red se tratan como errores terminales «duros» que pueden hacer que las URL se eliminen del índice. El caso sutil es un bloqueo blando: un intersticial de verificación de bots. El rastreador solo ve la página de desafío, no tu sitio; por eso Google recomienda encarecidamente devolver un 503 a los clientes automatizados. La forma más sencilla de comprobar que una CDN no está bloqueando Google silenciosamente es usar la herramienta de inspección de URL de Search Console: mira la imagen renderizada; si muestra un desafío para bots o una página vacía, habla con tu CDN.

Desviar las redirecciones a la CDN es una técnica que me gusta. En el podcast Marketing Speak lo describí así: “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (traducción) «Una de mis favoritas personales, que creo que no se usa lo suficiente, es simplemente trasladar las redirecciones al nivel de la CDN.» (Ir a la cita).

Errores de caché que perjudican el rastreo y la indexación

Este es el ángulo que la mayoría de artículos sobre «caché para SEO» omite. Una caché no solo hace que las cosas sean rápidas: una caché incorrecta puede servir bytes equivocados a un bot y romper el rastreo o la indexación.

Un caso real: una caché compartida que sirve un robots.txt bloqueante. Analicé un caso de bloqueo intermitente de Googlebot que se remontaba a una caché de CDN compartida entre un entorno de pruebas y el sitio activo. Como escribí en Indexed, though blocked by robots.txt: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (traducción) «Una causa posible sería una caché compartida entre un entorno de pruebas y un entorno activo. Cuando está activa la caché del entorno de pruebas, el archivo robots.txt puede incluir una directiva de bloqueo.» La solución fue separar la caché o excluir los archivos .txt de la caché en el entorno de pruebas. Una mala configuración de caché provocó directamente un fallo de rastreo; esa es la categoría de riesgo que realmente causa problemas.

Otros errores de la misma familia:

  • Caché de CDN obsoleta que sirve contenido antiguo a los bots. Si tu caché edge conserva una versión antigua mucho después de que hayas publicado un cambio, los bots siguen viendo la anterior. Purga al publicar o vincula la duración de la caché con la frecuencia real de cambio de la página.
  • Fragmentación de la caché por Vary / User-Agent. La clave de una caché compartida normalmente es solo la URL; Vary añade encabezados de solicitud (como User-Agent o Accept-Language) a esa clave para que se almacenen por separado distintas variantes. Si omites un encabezado que realmente cambia la respuesta, un solicitante puede recibir la variante de otro: la confusión entre móvil/escritorio o bot/persona. Añade demasiados encabezados a Vary y fragmentarás la caché en tantas claves casi duplicadas que apenas mejorará la tasa de aciertos. Por separado, los navegadores modernos también particionan sus propias cachés por sitio de nivel superior para proteger la privacidad, así que un recurso guardado mientras estaba incrustado en un sitio normalmente no se reutiliza al incrustarlo en otro: es un mecanismo distinto de Vary que conviene no confundir al depurar un informe de «por qué esto no está en caché».

Mi regla general sobre la duración viene del trabajo de LCP: como dije en mi guía de Ahrefs sobre Largest Contentful Paint, “Your cache time should be as long as you are comfortable with” (traducción) «El tiempo de caché debería ser tan largo como te resulte cómodo.» y “An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” (traducción) «Una configuración ideal es guardar en caché durante un periodo realmente largo, pero purgar la caché cuando haces un cambio en una página.» La caché larga y la purga instantánea. Esa combinación es la que te mantiene rápido y fresco.

¿Es la caché un factor de posicionamiento?

No, no directamente. No existe una señal de posicionamiento por tener ETags configurados o una buena política Cache-Control. Lo que hace la caché es alimentar dos cosas que importan para la visibilidad: la velocidad de página/Core Web Vitals (un factor explícito de experiencia de página) y la eficiencia de rastreo (que determina a qué velocidad se descubre y actualiza el contenido nuevo y modificado, con un efecto indirecto en los resultados sensibles a la frescura). Configúrala porque hace que tu sitio sea rápido y fácil de rastrear, no porque esperes una mejora directa de posiciones.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.