Caching para SEO

TL;DR — Caching significa salvar uma cópia de uma página ou arquivo para que ele não precise ser criado e enviado novamente do zero. Isso deixa seu site mais rápido para as pessoas e para os bots de busca, e permite que os bots pulem o download novamente de páginas que não mudaram. O caching não faz você ranquear melhor por si só — mas a velocidade que ele proporciona e a eficiência de rastreamento que ele permite ajudam indiretamente.

O que é caching

Toda vez que alguém abre uma página, o servidor precisa trabalhar: gerar o HTML, enviar as imagens e entregar o CSS e o JavaScript. Caching armazena uma cópia pronta dessas coisas para que a próxima visita possa reutilizá-la, em vez de repetir todo esse trabalho.

Há três lugares onde uma cópia pode ficar e que importam para SEO:

1. Cache do navegador — arquivos salvos no dispositivo do próprio visitante, para que uma segunda visualização ou uma visita de retorno carregue quase instantaneamente.
2. Cache da CDN (edge) — cópias armazenadas em servidores espalhados pelo mundo, para que um arquivo seja servido de algum lugar fisicamente próximo do usuário (ou do bot), em vez de sair do seu único servidor de origem.
3. Cache próprio do crawler — Googlebot e Bingbot lembram se uma página mudou desde a última vez e pulam o download novamente se ela não mudou.

Por que isso importa para SEO

Há dois motivos, e vale a pena mantê-los separados:

• Velocidade. Uma entrega mais rápida ajuda seus Core Web Vitals — especialmente a rapidez com que o servidor responde (TTFB) e a velocidade com que o conteúdo principal aparece (LCP). A velocidade faz parte dos sinais de experiência da página do Google.
• Eficiência de rastreamento. Quando um bot consegue saber que uma página não mudou, ele não desperdiça um download nela. Em um site grande, isso libera o bot para dedicar seu tempo a páginas novas e atualizadas.

O ponto que você precisa entender

“Cache do Google” e “caching HTTP” são duas coisas diferentes. O antigo operador de busca cache: — o recurso de “ver a cópia salva dessa página pelo Google” — foi aposentado em 2024. Isso não tem nada a ver com o caching abordado neste artigo. Os cabeçalhos Cache-Control e ETag continuam ativos, funcionando bem e sendo importantes. A ausência de uma “versão em cache” da sua página no Google não diz nada sobre a correção da sua configuração de caching.

O que fazer de fato

• Armazene seus arquivos estáticos (imagens, CSS, JavaScript e fontes) por bastante tempo.
• Adicione nomes de arquivo versionados ou com hash para poder atualizá-los instantaneamente quando necessário.
• Use uma CDN para que os arquivos carreguem de perto dos seus usuários.
• Não deixe acidentalmente um cache antigo ou compartilhado servir a coisa errada para os bots (o modo assustador de falha — veja as abas Avançado e Antipadrões).

Quer os detalhes no nível dos cabeçalhos — diretivas de Cache-Control, ETag versus Last-Modified, a história da taxa de rastreamento das CDNs e os erros de caching que quebram o rastreamento? Mude para a aba Avançado.

TL;DR — O caching opera em três camadas importantes para SEO: navegador, edge da CDN e o cache de solicitações condicionais do próprio crawler. Não é um fator de ranqueamento, mas impulsiona a velocidade da página (TTFB/LCP e, via bfcache, os Core Web Vitals de navegações repetidas) e a eficiência de rastreamento. O crawler do Google prefere ETag a Last-Modified, lê max-age apenas como uma sugestão de novo rastreamento e — segundo a própria documentação — “other HTTP caching directives aren’t supported.” (tradução: outras diretivas de caching HTTP não são compatíveis.) As CDNs recebem uma permissão de taxa de rastreamento maior, mas somente depois que o cache aquece; os riscos reais são lançamentos com cache frio e configurações incorretas de CDN/WAF que bloqueiam bots diretamente.

As três camadas do caching

Caching para SEO não é uma coisa só — são três camadas, cada uma controlada de uma forma um pouco diferente:

1. Cache do navegador — o dispositivo do visitante armazena arquivos para que visualizações repetidas pulem a rede. É disso que o PageSpeed Insights reclama com “Serve static assets with an efficient cache policy” (sirva recursos estáticos com uma política de cache eficiente).
2. Cache da CDN / edge — uma rede de distribuição de conteúdo armazena cópias em nós de edge no mundo todo (veja o aprofundamento sobre CDN e SEO para o tratamento completo). A descrição do próprio Google: as CDNs são intermediárias entre sua origem e o usuário, e historicamente seu maior foco é o caching — armazenar o conteúdo de uma URL para que seu servidor não precise servir aquele arquivo novamente por algum tempo.
3. Cache no lado do crawler — Googlebot e Bingbot mantêm seu próprio registro sobre se o conteúdo mudou, usando solicitações condicionais. Essa é a alavanca do orçamento de rastreamento, e a mecânica pertence ao aprofundamento sobre solicitações condicionais; aqui vou mantê-la em nível de resumo.

“Cache do navegador” acima é uma abreviação para mais de um mecanismo. Conforme o guia de caching HTTP da MDN, vale separar: o cache HTTP privado (por navegador, indexado pela solicitação e, nos navegadores modernos, particionado pelo site de nível superior para limitar o rastreamento entre sites), o cache em memória usado na sessão atual, o bfcache abordado abaixo e — separadamente — o Cache Storage de um service worker, controlado pelo próprio JavaScript do site e não governado diretamente pelos cabeçalhos Cache-Control. “Verificar o cache do navegador” pode significar quatro etapas de depuração diferentes, dependendo de qual deles está realmente se comportando mal.

Como o caching alimenta os Core Web Vitals

Buscar recursos pela rede é lento e caro. O caching remove a latência da rede e o custo de transferência de tudo o que não mudou. Isso entra diretamente em duas medidas próximas dos vitals: TTFB (uma resposta em cache pula a regeneração na origem) e LCP (imagens, CSS e fontes em cache são renderizados mais cedo).

Cache-Control, nas diretivas que importam

Cache-Control é o cabeçalho principal. Estas são as diretivas que vale conhecer:

• max-age=<seconds> — por quanto tempo uma cópia fresca é válida. Para recursos imutáveis e versionados, a documentação do Chrome Lighthouse recomenda caching por um ano ou mais — por exemplo, Cache-Control: max-age=31536000.
• no-cache — não significa “não faça cache”. Significa “armazene, mas faça uma nova validação com o servidor antes de reutilizar”. Ainda permite o fluxo leve de 304.
• no-store — a única que realmente significa não armazenar cópia alguma em nenhum cache HTTP. É uma diretiva de caching, não um controle geral de privacidade — conforme a RFC 9111, não é uma forma confiável de apagar o histórico do navegador e não diz nada sobre o Cache Storage próprio de um service worker.
• public / private — se caches compartilhados (como uma CDN) podem armazenar a resposta ou somente o navegador do usuário final.
• immutable — pula a revalidação enquanto a resposta ainda estiver fresca. Não significa “nunca fica obsoleta” — quando o max-age acaba, as regras normais de frescor voltam a valer.
• must-revalidate — a outra ponta da linha do tempo: só importa depois que uma resposta fica obsoleta e informa ao cache que ele precisa revalidar com a origem, em vez de servir a cópia obsoleta mesmo assim.
• s-maxage, stale-while-revalidate, stale-if-error — controles mais detalhados, principalmente para CDNs e outros caches compartilhados (um período de frescor separado para caches compartilhados, reutilização limitada de conteúdo obsoleto enquanto uma busca em segundo plano roda e reutilização limitada de conteúdo obsoleto quando há um erro na origem, respectivamente). O suporte varia por navegador/CDN, portanto verifique o suporte atual antes de depender deles — e nenhuma dessas diretivas extras é considerada pelo crawler do Google, como veremos.

Cache-busting com nomes de arquivo versionados

O truque que permite fazer caching agressivo e atualizar instantaneamente: coloque um hash de conteúdo no nome do arquivo — style.x234dff.css. Como a URL é a chave do cache, mudar o arquivo muda a URL, então os caches buscam a nova versão imediatamente enquanto as versões antigas permanecem em cache pelo tempo que você quiser. Tanto o guia de cache HTTP do web.dev quanto o texto da própria equipe de engenharia de front-end do Bing descrevem o mesmo padrão — o Bing transforma o conteúdo dos arquivos em hash dentro da URL para que “the URL acts as the cache key,” (tradução) «a URL funcione como a chave do cache», mantendo os caches consistentes e permitindo tempos de expiração longos.

A armadilha do bfcache — quando no-store prejudica silenciosamente os CWV

Aqui está um ponto pouco abordado. O back/forward cache (bfcache) é o que faz pressionar “voltar” restaurar uma página instantaneamente. Uma restauração do bfcache pula completamente a medição de LCP/CLS/INP, então é uma vantagem pura para seus dados de campo do CrUX. Mas, conforme o guia de bfcache do Google, definir Cache-Control: no-store no próprio documento da página historicamente fez os navegadores se recusarem a armazenar essa página no bfcache. Se você precisa de frescor em um documento HTML, mas não quer abrir mão da elegibilidade para o cache de voltar/avançar, use no-cache ou max-age=0 em vez de no-store.

Como um cache decide se algo está “fresco o suficiente”

Antes de qualquer validador entrar em ação, um cache verifica o frescor: a idade da resposta armazenada já passou do período de frescor que o Cache-Control forneceu (ou, na ausência de um período explícito, de um período heurístico que o cache pode estimar)? O cabeçalho de resposta Age informa há quanto tempo um cache compartilhado já mantém uma resposta, permitindo saber — no DevTools ou em um log da CDN — quanto tempo de frescor ainda resta. Se estiver fresca, o cache pode reutilizá-la imediatamente, sem solicitação alguma. Se estiver obsoleta, ele deve validá-la antes de reutilizar, que é exatamente onde ETag/If-None-Match e Last-Modified/If-Modified-Since são úteis — descritos a seguir, para a versão mais restrita do Googlebot desse mecanismo HTTP geral.

Como o Googlebot usa caching (o ângulo da eficiência de rastreamento)

O Google fez um pedido excepcionalmente direto em sua publicação de dezembro de 2024, Crawling December: HTTP caching: habilite o caching para que seus crawlers possam pular o download novamente de páginas que não mudaram. O dado marcante da publicação é que as buscas que podem usar cache vêm diminuindo — cerca de 0,026% do total de buscas podiam usar cache há 10 anos, e hoje esse número é 0,017%. Números pequenos, mas o Google claramente quer que caminhem na direção oposta.

ETag versus Last-Modified — qual o Google prefere

A infraestrutura de rastreamento do Google dá suporte aos dois validadores padrão: ETag (com If-None-Match) e Last-Modified (com If-Modified-Since). O Google recomenda fortemente o ETag porque seu valor não é estruturado e, portanto, é menos propenso aos erros de análise que uma string de data convida — e, se ambos estiverem presentes, seus crawlers usam o valor ETag como exige o padrão HTTP. Mesmo assim, o Google sugere definir os dois, já que outros aplicativos, como CMSs os utilizam. Se você usar Last-Modified, a data precisa seguir o formato HTTP (por exemplo, Fri, 4 Sep 1998 19:15:56 GMT) ou não será analisada.

Quando o validador armazenado pelo crawler ainda corresponde, seu servidor retorna 304 Not Modified sem corpo — esse é o objetivo. Como o Google explica, a ausência de corpo significa que seu servidor não gasta computação gerando conteúdo nem largura de banda transferindo-o. (Essa mecânica de 304 é o mecanismo de orçamento de rastreamento explicado em profundidade no artigo sobre solicitações condicionais; aqui basta saber que ela economiza dinheiro dos dois lados.)

A nuance que quase todo mundo deixa passar

O crawler do Google não age sobre o conjunto completo de diretivas Cache-Control da mesma forma que um navegador ou uma CDN. Conforme a visão geral oficial dos crawlers, além de ETag/Last-Modified, “other HTTP caching directives aren’t supported.” (tradução: outras diretivas de caching HTTP não são compatíveis.) A única exceção parcial: o Google diz que você pode definir opcionalmente max-age para ajudar os crawlers a determinar quando rastrear novamente uma URL — uma sugestão de novo rastreamento, não um bloqueio rígido. Portanto, no-cache, s-maxage, stale-while-revalidate e semelhantes continuam moldando o comportamento do navegador e da CDN, mas não mudam como o Googlebot faz caching. E o conselho do Google sobre quando invalidar é sensato: exija uma atualização do cache em mudanças significativas — atualizar apenas a data de copyright no rodapé não é significativo.

CDNs e rastreamento

Uma CDN oferece mais do que velocidade. A infraestrutura de rastreamento do Google é projetada para permitir taxas de rastreamento maiores em sites apoiados por uma CDN, inferidas a partir do endereço IP que serve as URLs — ela presume que uma origem apoiada por CDN consegue lidar com mais solicitações simultâneas.

Mas há uma ressalva que vale planejar: o cache frio. No primeiro acesso a uma URL, o cache da CDN está “frio” — ninguém a solicitou ainda, então sua origem precisa servi-la pelo menos uma vez para aquecer o cache. O Google alerta que lançar muitas URLs de uma vez é, por isso, um peso real sobre o orçamento de rastreamento, com uma taxa de rastreamento alta durante alguns dias. Se você estiver fazendo um grande lançamento ou uma migração de site, reserve capacidade para que a origem assuma toda a carga por URL antes que a CDN comece a ajudar.

Configuração incorreta da CDN é um risco de rastreamento

Os problemas mais assustadores relacionados ao caching não são durações lentas de cache — são configurações de CDN e WAF que bloqueiam bots. A publicação do Google sobre CDNs é explícita: para bloqueios temporários, enviar 503/429 é a forma preferida de sinalizar o problema, enquanto timeouts de rede são tratados como erros terminais e “hard”, que podem fazer URLs serem removidas do índice. O caso sutil é um bloqueio suave: um intersticial de verificação de bot. O crawler vê apenas a página do desafio, não o seu site — por isso o Google recomenda fortemente retornar 503 para clientes automatizados. A forma mais fácil de verificar se uma CDN não está bloqueando o Google silenciosamente é usar a ferramenta de inspeção de URL no Search Console — observe a imagem renderizada; se ela mostrar um desafio de bot ou uma página vazia, fale com sua CDN.

Descarregar redirecionamentos para a CDN é uma técnica de que gosto. No podcast Marketing Speak, descrevi-a assim: “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.” (tradução) «uma das minhas técnicas favoritas, que na minha opinião não é usada o suficiente, é simplesmente descarregar seus redirecionamentos no nível da CDN». (Ir para a citação)

Armadilhas de caching que prejudicam o rastreamento e a indexação

Este é o ângulo que a maioria dos artigos sobre “caching para SEO” ignora. Um cache não apenas torna as coisas rápidas — um cache errado pode servir bytes errados para um bot e quebrar o rastreamento ou a indexação.

Um caso real: um cache compartilhado servindo um robots.txt bloqueador. Investiguei um caso de bloqueio intermitente do Googlebot que apontava para um cache compartilhado de CDN entre um ambiente de teste e o site em produção. Como escrevi em 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.” (tradução) «uma possível causa seria um cache compartilhado entre um ambiente de teste e um ambiente de produção. Quando o cache do ambiente de teste está ativo, o arquivo robots.txt pode incluir uma diretiva de bloqueio». A correção foi separar o cache — ou excluir arquivos .txt do cache no ambiente de teste. Uma configuração incorreta de caching causou diretamente uma falha de rastreamento; essa é a categoria de risco que realmente dói.

Outras armadilhas da mesma família:

• Cache antigo da CDN servindo conteúdo desatualizado aos bots. Se o cache de edge mantiver uma versão antiga muito tempo depois de você publicar uma mudança, os bots continuarão vendo a antiga. Faça a limpeza na publicação ou vincule a duração do cache à frequência real de mudança da página.
• Fragmentação de cache por Vary / User-Agent. A chave de um cache compartilhado normalmente é apenas a URL; Vary adiciona cabeçalhos de solicitação (como User-Agent ou Accept-Language) a essa chave para que variantes diferentes sejam armazenadas separadamente. Se você esquecer um cabeçalho que realmente muda a resposta, um solicitante pode receber a variante de outro — a mistura entre mobile/desktop ou bot/humano. Adicione cabeçalhos demais a Vary e você fragmenta o cache em tantas chaves quase duplicadas que a taxa de acerto mal melhora. Separadamente, os navegadores modernos também particionam seus próprios caches pelo site de nível superior por motivos de privacidade, então um recurso armazenado em cache enquanto incorporado em um site geralmente não é reutilizado quando incorporado em outro — um mecanismo diferente de Vary, que vale não confundir ao depurar um relatório de “por que isso não está em cache”.

Minha regra geral sobre duração vem do trabalho com LCP: como escrevi no meu guia da Ahrefs sobre Largest Contentful Paint, “Your cache time should be as long as you are comfortable with” (tradução) «seu tempo de cache deve ser tão longo quanto você se sentir confortável». Ir para a citação — e “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.” (tradução) «uma configuração ideal é manter o cache por um período realmente longo, mas limpá-lo quando você mudar uma página». Cache longo, limpeza instantânea. Essa combinação mantém você rápido e atualizado.

Caching é um fator de ranqueamento?

Não — não diretamente. Não há um sinal de ranqueamento por definir ETags ou por ter uma boa política de Cache-Control. O que o caching faz é alimentar duas coisas que importam para a visibilidade: velocidade da página / Core Web Vitals (um componente explícito da experiência da página) e eficiência de rastreamento (que determina a rapidez com que conteúdo novo e atualizado é descoberto e atualizado, tocando indiretamente resultados sensíveis a frescor). Configure-o porque deixa seu site rápido e fácil de rastrear — não porque você espera um aumento direto no ranqueamento.

Resumo de IA

Uma síntese da versão Avançada:

• Caching = três camadas para SEO: cache do navegador, cache de CDN/edge e cache de solicitações condicionais do próprio crawler. Cada uma é controlada de um jeito um pouco diferente.
• Não é fator de ranqueamento — mas impulsiona duas coisas que importam: velocidade da página (TTFB/LCP, além dos vitals de navegação repetida via bfcache) e eficiência de rastreamento.
• Noções básicas de Cache-Control: max-age define o frescor (um ano ou mais para recursos estáticos imutáveis e versionados); no-cache = “armazene, mas faça nova validação” (não significa “não faça cache”); no-store = não armazene nada; public/private controlam caches compartilhados/CDN.
• Cache-busting: coloque um hash de conteúdo no nome do arquivo para poder fazer caching agressivo e ainda atualizar instantaneamente (tanto o Google quanto o Bing usam esse padrão).
• Armadilha do bfcache: Cache-Control: no-store no documento HTML pode desqualificar uma página do cache de voltar/avançar, prejudicando silenciosamente os vitals do CrUX. Use no-cache ou max-age=0.
• O Googlebot respeita apenas ETag e Last-Modified (prefere ETag; lê max-age como sugestão de novo rastreamento). Segundo o Google, “other HTTP caching directives aren’t supported.” (tradução: outras diretivas de caching HTTP não são compatíveis.) Um validador correspondente retorna 304 Not Modified sem corpo, economizando computação e largura de banda.
• As CDNs recebem uma permissão de taxa de rastreamento maior — mas somente depois que o cache aquece. Lançamentos com cache frio ainda atingem a origem uma vez por URL; planeje isso em grandes lançamentos e migrações.
• O maior risco não é um caching lento — é uma configuração incorreta de CDN/WAF que bloqueia bots (retorne 503/429 para bloqueios temporários; observe intersticiais de bloqueio suave) e caches antigos/compartilhados que servem conteúdo errado (por exemplo, um robots.txt bloqueador).

Documentação oficial

Documentação de fontes primárias dos mecanismos de busca e das equipes responsáveis por suas ferramentas.

Google

• Crawling December: HTTP caching — publicação de Gary Illyes de dezembro de 2024: ETag versus Last-Modified, mecânica de 304, a queda da estatística de buscas que podem usar cache e a sugestão de novo rastreamento por max-age.
• Google Crawler (User Agent) Overview — HTTP Caching section — a referência viva: a regra de desempate do ETag e a frase “other HTTP caching directives aren’t supported” (tradução) «outras diretivas de caching HTTP não são compatíveis».
• Crawling December: CDNs and crawling — Splitt e Illyes sobre caching de CDN, a permissão de uma taxa de rastreamento maior, lançamentos com cache frio e bloqueios rígidos versus suaves.
• Serve static assets with an efficient cache policy — a auditoria do Lighthouse/PageSpeed e a orientação de “um ano ou mais” para recursos imutáveis.
• Prevent unnecessary network requests with the HTTP Cache — referência das diretivas e do padrão de cache-busting com nomes de arquivo com hash.
• Back/forward cache (bfcache) — por que no-store no documento HTML pode custar a elegibilidade para o bfcache.
• Crawling December series index — índice da série completa de 2024: Googlebot, caching HTTP, navegação facetada e CDNs.

Bing / Microsoft

• Fast Front-End Performance for Microsoft Bing — a equipe de engenharia do Bing explica como transformar o conteúdo dos arquivos em hash nas URLs para manter a consistência do cache e permitir expirações longas, além do papel da CDN em acelerar a entrega de recursos estáticos.
• bingbot Series: Maximizing Crawl Efficiency — a lógica de frescor do rastreamento (rastrear menos quando o conteúdo não mudou) que o caching apoia.
• Bing Webmaster Guidelines — o hub da orientação do Bing sobre CDN e desempenho.

Citações da fonte

Declarações registradas do Google e dos meus próprios textos. Cada link é um link profundo que salta para o trecho citado na página de origem.

Google — Crawling December: caching HTTP

• “While Google’s crawling infrastructure supports heuristic caching mechanisms, in fact always had, the number of requests that can be returned from local caches has decreased: 10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%.” (tradução) «embora a infraestrutura de rastreamento do Google ofereça mecanismos de caching heurístico — na verdade, sempre ofereceu — o número de solicitações que podem ser respondidas por caches locais diminuiu: há 10 anos, cerca de 0,026% do total de buscas podia usar cache, o que já não era tão impressionante; hoje esse número é 0,017%». Ir para a citação
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). And, if you have the option, set them both: the internet will thank you. Maybe.” (tradução) «recomendamos fortemente usar ETag porque ele é menos propenso a erros e enganos (o valor não é estruturado, ao contrário do valor Last-Modified). E, se você puder, defina os dois: a internet agradecerá. Talvez». Ir para a citação
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (tradução) «nossa recomendação é exigir uma atualização do cache em mudanças significativas no conteúdo; se você apenas atualizou a data de copyright no rodapé da página, isso provavelmente não é significativo». Ir para a citação

Visão geral dos crawlers do Google (seção de caching HTTP)

• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (tradução) «se os campos de cabeçalho de resposta ETag e Last-Modified estiverem presentes na resposta HTTP, os crawlers do Google usarão o valor ETag conforme exige o padrão HTTP». Ir para a citação
• “Other HTTP caching directives aren’t supported.” (tradução) «outras diretivas de caching HTTP não são compatíveis». Ir para a citação

Google — Crawling December: CDNs e rastreamento

• “Historically, CDNs’ biggest focus is caching, meaning that once a user requested a URL from your site, CDNs will store the contents of that URL in their caches for a time so your server doesn’t have to serve that file again for a while.” (tradução) «historicamente, o maior foco das CDNs é o caching: quando um usuário solicita uma URL do seu site, as CDNs armazenam o conteúdo dessa URL em seus caches por algum tempo para que seu servidor não precise servir esse arquivo novamente por um período». Ir para a citação

Patrick Stox — sobre caching e CDNs

• “Your cache time should be as long as you are comfortable with.” (tradução) «seu tempo de cache deve ser tão longo quanto você se sentir confortável» — eu, no guia da Ahrefs sobre Largest Contentful Paint. Ir para a citação
• “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.” (tradução) «uma possível causa seria um cache compartilhado entre um ambiente de teste e um ambiente de produção. Quando o cache do ambiente de teste está ativo, o arquivo robots.txt pode incluir uma diretiva de bloqueio» — eu, sobre uma falha real de rastreamento atribuída a um cache compartilhado. Ir para a citação
• “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.” (tradução) «uma das minhas técnicas favoritas, que na minha opinião não é usada o suficiente, é simplesmente descarregar seus redirecionamentos no nível da CDN» — eu, no podcast Marketing Speak. Ir para a citação

Caching para SEO — guia rápido

Diretivas de Cache-Control, decodificadas

O que o Googlebot realmente considera

• ✅ ETag + If-None-Match (validador preferido pelo Google)
• ✅ Last-Modified + If-Modified-Since (formate a data de acordo com HTTP: Fri, 4 Sep 1998 19:15:56 GMT)
• ✅ max-age — mas somente como sugestão de tempo de novo rastreamento, não como regra
• ❌ Todo o resto — “other HTTP caching directives aren’t supported” (outras diretivas de caching HTTP não são compatíveis)

Fatos rápidos

• O Google prefere ETag; se ambos estiverem definidos, ETag vence. Defina os dois mesmo assim (os CMSs os utilizam).
• Um validador correspondente → 304 Not Modified, sem corpo → economiza computação e largura de banda.
• Chrome/Lighthouse: faça caching de recursos imutáveis por um ano ou mais.
• As CDNs recebem uma permissão de taxa de rastreamento maior — mas somente depois que o cache está aquecido.
• Bloqueio temporário? Retorne 503/429, nunca uma página silenciosa 200-with-error ou um intersticial de bot.
• no-store no documento HTML pode desqualificar o bfcache → use no-cache/max-age=0.
• O “cache do Google” (operador cache:) foi aposentado em 2024 — não tem relação com caching HTTP.

Mitos e erros sobre caching

Cada um: por que está errado e o que fazer no lugar.

Mito: “Fazer caching da minha página vai melhorar meu ranqueamento.” Por que está errado: não há sinal de ranqueamento para configuração de caching. A equipe de Search Relations do Google deixou claro que caching não é fator de ranqueamento. Faça isto: configure caching pelos benefícios reais — velocidade da página / Core Web Vitals e eficiência de rastreamento — que tocam a visibilidade indiretamente. Não espere um aumento direto.

Mito: “O cache do Google e o caching HTTP são a mesma coisa.” Por que está errado: o operador de busca cache: e o visualizador de páginas em cache eram um recurso de snapshot voltado ao usuário, completamente aposentado em 2024. O caching HTTP (Cache-Control/ETag) é uma infraestrutura não relacionada. Faça isto: ignore a ausência da “versão em cache” — ela não diz nada sobre sua configuração. Avalie seu caching pelos cabeçalhos e pelo comportamento de rastreamento/desempenho.

Mito: “no-cache significa não fazer cache.” Por que está errado: no-cache significa “armazene, mas faça nova validação com o servidor antes de usar”. Ele ainda permite o fluxo de revalidação 304. no-store é a diretiva que realmente impede o armazenamento. Faça isto: use no-cache quando quiser frescor com revalidação; reserve no-store para respostas genuinamente sensíveis que nunca devem ser armazenadas.

Mito: “Uma duração de cache longa faz o Google ver conteúdo obsoleto para sempre.” Por que está errado: o crawler do Google valida por ETag/Last-Modified em cada novo rastreamento, independentemente do seu max-age; max-age é uma sugestão de novo rastreamento, não um bloqueio que impede o Google de buscar novamente. Faça isto: faça caching longo, mas acione um cache-buster real (novo ETag/Last-Modified ou URL) em mudanças significativas de conteúdo — exatamente a recomendação do próprio Google.

Mito: “Uma CDN corrige automaticamente problemas de orçamento de rastreamento.” Por que está errado: uma CDN só ajuda depois que seu cache aquece; a origem ainda serve cada URL pelo menos uma vez (o problema do cache frio), e uma CDN configurada de forma incorreta pode bloquear crawlers e piorar tudo. Faça isto: planeje a carga na origem em grandes lançamentos/migrações e confirme que a CDN não está bloqueando bots (inspeção de URL e retorno de 503/429 para bloqueios temporários).

Mito: “Qualquer diretiva de Cache-Control que eu defina muda a forma como o Googlebot rastreia.” Por que está errado: conforme a documentação do Google, além de ETag/Last-Modified (e da sugestão opcional de max-age), “other HTTP caching directives aren’t supported” (outras diretivas de caching HTTP não são compatíveis) pelo crawler. Faça isto: use stale-while-revalidate, s-maxage, no-cache etc. para ajustar o comportamento do navegador e da CDN — mas dependa de ETag/Last-Modified para influenciar o caching do Googlebot.

Configurações de caching, antes e depois

1. Recurso estático sem política de cache → aviso do PageSpeed desaparece

• Antes: style.css servido sem Cache-Control; o Lighthouse sinaliza “Serve static assets with an efficient cache policy” e as visitas repetidas fazem novo download.
• Depois: renomeie para style.a1b2c3.css e sirva Cache-Control: public, max-age=31536000, immutable. As visitas repetidas pulam o download; uma mudança no conteúdo significa um novo nome de arquivo, invalidando instantaneamente.

2. Documento HTML que você queria manter “fresco” → bfcache perdido

• Antes: Cache-Control: no-store no HTML para forçar frescor. Efeito colateral: a página é desqualificada do bfcache, então navegações de “voltar” medem LCP/CLS/INP novamente e arrastam seus dados de campo do CrUX.
• Depois: mude para no-cache (ou max-age=0) — você ainda faz nova validação para manter o frescor, mas a página continua elegível para o bfcache e as navegações repetidas são restauradas instantaneamente.

3. Cache compartilhado entre staging e produção → bloqueio intermitente do Googlebot

• Antes: os ambientes de teste e produção compartilham um cache de CDN. Quando a versão de teste está ativa, o robots.txt armazenado em cache carrega uma diretiva de bloqueio, então o Googlebot vê intermitentemente um disallow que não deveria existir.
• Depois: separe o cache entre os ambientes — ou exclua arquivos .txt do cache do ambiente de teste — para que o robots.txt de produção nunca seja servido de um cache de staging. (Este é um caso real que descrevi em Indexed, though blocked by robots.txt.)

4. Grande lançamento atrás de uma CDN → pico de rastreamento inesperado

• Antes: publique 50 000 URLs novas de uma vez supondo que a CDN absorverá a carga. Cada URL é um cache miss frio, então a origem serve cada uma pelo menos uma vez e a taxa de rastreamento permanece alta por dias.
• Depois: aqueça o cache antes do lançamento (ou faça o rollout em etapas) e espere — e provisione — que a origem assuma toda a carga por URL antes que a CDN comece a protegê-la.

Checklist de configuração de caching HTTP

• Recursos estáticos (imagens, CSS, JS e fontes) carregam um max-age longo (um ano ou mais para arquivos imutáveis/versionados).
• Nomes de arquivo versionados/com hash são usados para fazer caching agressivo e ainda invalidar instantaneamente.
• ETag está definido (validador preferido do Google); Last-Modified também, com uma data HTTP formatada corretamente.
• Seu servidor retorna 304 Not Modified (sem corpo) quando um validador ainda corresponde.
• Documentos HTML que precisam de frescor usam no-cache/max-age=0, não no-store (proteja a elegibilidade para o bfcache).
• Uma mudança significativa de conteúdo aciona um cache-buster real (novo ETag/Last-Modified/URL), não apenas uma alteração na data do rodapé.
• Há uma CDN na frente da origem, com public/s-maxage definidos para que caches compartilhados possam armazenar o que deve ser compartilhado.
• O cache é limpo na publicação para que os bots nunca recebam conteúdo antigo.
• Staging e produção não compartilham um cache para robots.txt ou outros arquivos de controle.
• Bloqueios temporários retornam 503/429, não páginas 200-with-error silenciosas nem intersticiais de bot.
• A inspeção de URL no Search Console mostra sua página real (não um desafio nem uma página vazia) — confirmando que a CDN/WAF não está bloqueando o Googlebot.

Arquivos atualizados continuam obsoletos depois da implantação

Sintoma: visitantes continuam recebendo um arquivo CSS, JavaScript ou de imagem antigo. Causa provável: um cache de longa duração usa a mesma URL para bytes alterados. Correção: publique recursos imutáveis com nomes de arquivo com hash de conteúdo e atualize a referência no HTML; limpe o objeto antigo no edge somente quando a própria URL tiver sido reutilizada. Confirme que a nova URL carrega.

O Googlebot baixa novamente páginas que não mudaram

Sintoma: os logs mostram respostas 200 completas repetidas para um HTML inalterado. Causa provável: validadores ETag/Last-Modified ausentes ou instáveis. Correção: emita um validador estável e correto para o conteúdo e teste uma solicitação condicional. Uma nova validação funcionando retorna 304 quando a representação não mudou.

Usuários diferentes recebem a variante errada em cache

Sintoma: conteúdo de idioma, dispositivo, sessão autenticada ou personalizado vaza entre usuários. Causa provável: a chave do cache compartilhado não inclui a dimensão que muda a resposta, ou o conteúdo privado foi marcado como público. Correção: corrija o comportamento da chave do cache e de Vary, marque as respostas privadas adequadamente, limpe objetos contaminados e teste novamente várias variantes.

A CDN nunca informa um cache hit

Sintoma: solicitações elegíveis repetidas continuam chegando à origem. Causa provável: no-store/private, cookies, uma chave de cache fragmentada demais ou uma regra de bypass no edge. Correção: inspecione os cabeçalhos de resposta e de status do cache da CDN, altere somente regras seguras para essa classe de conteúdo e solicite a mesma chave de cache duas vezes para confirmar um hit.

Faça cache pelo risco da representação, não apenas pela extensão do arquivo

Classifique cada resposta antes de atribuir uma política:

1. Recurso público imutável: CSS, JS, fontes ou imagens com hash de conteúdo podem usar uma vida útil longa, porque bytes alterados recebem uma nova URL.
2. Documento público, mas mutável: o HTML pode ser armazenado brevemente ou revalidado com ETag/Last-Modified; o frescor e a correção rápida importam mais do que o TTL máximo.
3. Resposta específica do usuário: caching compartilhado não é seguro, a menos que a personalização seja removida da representação ou corretamente separada na chave do cache.
4. Resposta sensível: use a política rígida exigida pelos dados, aceitando o custo de desempenho em vez de expor conteúdo.

A pergunta útil não é “por quanto tempo posso fazer caching deste tipo?” É “o que estaria errado se esta representação exata fosse reutilizada para este solicitante depois desta mudança?”

Frescor, correção, eficiência

Uma política de caching precisa passar por três testes: frescor (mudanças aparecem como prometido), correção (o solicitante certo recebe a variante certa) e eficiência (bytes inalterados não são regenerados nem transferidos sem necessidade). Uma taxa de acerto alta não é sucesso se a resposta servida estiver errada.

Ferramentas para inspecionar caching HTTP

• Painel Network do DevTools do navegador — inspecione Cache-Control, ETag, Last-Modified, Age, Vary e se a resposta veio da memória, do disco ou da rede.
• curl — envie solicitações HEAD e condicionais sem a ambiguidade do cache do navegador; compare o validador inicial com If-None-Match ou If-Modified-Since.
• PageSpeed Insights / Lighthouse — encontre recursos estáticos com políticas de cache ineficientes; o artigo inclui um link para a orientação oficial sobre política de cache do Lighthouse.
• Análises e logs da CDN — inspecione status de hit/miss/bypass, chaves de cache, solicitações à origem e limpezas na camada que realmente serve a resposta pública.
• Logs do servidor — confirme que o Googlebot recebe revalidações 304, e não corpos completos, para páginas que não mudaram.

Prove que uma mudança de caching funciona

Teste de solicitação condicional

Teste a executar: busque a resposta, copie seu ETag e depois solicite-a com If-None-Match. Resultado esperado: uma representação inalterada retorna 304 sem corpo de resposta. Interpretação de falha: o validador está ausente, instável ou é ignorado. Janela de monitoramento: imediata. Gatilho de rollback: conteúdo alterado é respondido incorretamente com 304 ou o validador colide entre variantes.

Teste de recurso versionado

Teste a executar: implante bytes alterados sob uma nova URL com hash de conteúdo e recarregue uma página que a referencia. Resultado esperado: a nova URL retorna o novo recurso, enquanto a antiga pode continuar armazenada. Interpretação de falha: o HTML ainda referencia o recurso antigo ou o build não mudou o hash. Janela de monitoramento: imediatamente após a propagação do HTML/CDN. Gatilho de rollback: estilo quebrado ou erros de script no novo recurso.

Teste de variante do cache compartilhado

Teste a executar: solicite cada variante significativa pela CDN, repita cada uma e compare corpo, chave/status do cache e Vary. Resultado esperado: cada solicitante recebe a representação correta e somente variantes seguras são reutilizadas. Interpretação de falha: falta uma dimensão na chave do cache ou conteúdo privado está sendo compartilhado. Janela de monitoramento: imediata, além da revisão dos logs de produção. Gatilho de rollback: um usuário recebe o conteúdo personalizado ou específico de idioma de outro usuário.

Teste seus conhecimentos: caching para SEO

Cinco perguntas rápidas sobre caching HTTP, CDNs e rastreamento. Escolha uma resposta para cada uma e depois confira.

Registro de alterações