Volatilidade de Agosto: quando não há update para culpar

O cenário de agosto

Os resultados começaram a apresentar volatilidade incomum por volta de 1º de agosto de 2026, com relatos se acumulando até o dia 6. Pelo que acompanho nos projetos e no que a comunidade reporta, o padrão tem três componentes: perda abrupta de tráfego orgânico, ranking subindo e descendo em ciclos curtos, e comportamento anômalo no Discover, com páginas que entregavam volume constante simplesmente sumindo.

Até aqui, nenhum update confirmado. Considerando a cadência histórica de três a quatro meses entre core updates, e que o último foi concluído em 2 de junho, um novo core no terceiro trimestre é plausível. Mas plausível não é confirmado, e SEO feito com base em suposição de update é diagnóstico feito por manchete.

Quando não é o algoritmo

Na maior parte dos casos em que o cliente chegou dizendo que o Google tinha mudado alguma coisa, a causa estava dentro de casa. Em ordem de frequência:

Deploy. Alguém subiu código. Um noindex que vazou de staging, um robots.txt sobrescrito, um canonical apontando para o domínio errado, um redirect que virou cadeia de quatro saltos. Sempre cheque o histórico de deploy contra a data da queda. É a primeira coisa que peço, e resolve mais casos do que qualquer análise de SERP.

Mudança de template. O time de produto mexe numa página modelo e, sem perceber, remove um bloco de conteúdo, altera a hierarquia de h1 e h2, ou passa a renderizar via JavaScript algo que antes vinha no HTML. Esse último é fatal para crawler de IA, como explico em crawlers de IA não executam JavaScript.

Performance. Uma tag nova de marketing, um script de chat, um teste A/B mal implementado. O site fica lento e o desempate técnico começa a jogar contra.

Mudança de SERP, não de ranking. Você continua na posição 3, mas apareceu um AI Overview em cima e o clique evaporou. Impressão estável com clique caindo é a assinatura desse caso, e é o assunto de zero-click e a nova economia da busca.

Sazonalidade. Agosto tem comportamento próprio em vários setores. Compare com o mesmo período do ano anterior antes de acionar o alarme.

Infraestrutura. Erro 5xx intermitente, firewall bloqueando Googlebot, CDN devolvendo página de erro só para bot. Não aparece no seu navegador e derruba o site no índice. Já vi isso custar seis semanas de tráfego porque ninguém olhou log.

Protocolo de investigação

A ordem importa. Começa pelo que é barato de verificar e definitivo de descartar.

1. Ações manuais no Search Console. Trinta segundos, elimina uma hipótese.
2. Cobertura de indexação. Alguma categoria de erro saltou na janela? "Descoberta, não indexada" crescendo aponta qualidade ou crawl budget. "Excluída por tag noindex" crescendo é quase sempre deploy.
3. Histórico de deploy cruzado com as datas. Peça a lista de releases do período.
4. Impressões contra cliques, em curvas separadas. Elas contam histórias diferentes.
5. Quebra por página e por consulta. Concentrada aponta causa específica, difusa aponta algoritmo.
6. Teste de renderização. Pegue três URLs afetadas e compare o HTML bruto com o renderizado. Diferença grande é bandeira vermelha.
7. Logs de servidor. O Googlebot ainda passa na mesma frequência? Está recebendo 200? A resposta está nos logs, não na intuição de ninguém.
8. Só então compare com rastreadores de volatilidade do mercado. Se o setor inteiro se mexeu junto, aí sim é algoritmo.

O caso do Discover

O Discover merece parágrafo próprio porque a instabilidade dele é estruturalmente diferente. Não é busca. Não existe consulta, existe recomendação. O tráfego é volátil por natureza, e uma página pode entregar 50 mil sessões num dia e zero no seguinte sem que nada tenha mudado no seu site.

O que costuma explicar um sumiço:

• Perda de frescor. O Discover favorece conteúdo recente, e uma matéria que performou por três dias simplesmente saiu do ciclo.
• Imagem. Imagem grande e de boa qualidade, com largura mínima de 1200px e max-image-preview:large, é pré-requisito prático. Se um deploy mexeu na entrega de imagem, o Discover some.
• Sinal de qualidade. Título sensacionalista com conteúdo que não entrega derruba a elegibilidade.

Minha recomendação, que já custou caro para gente que ignorou: nunca construa previsão de receita em cima de Discover. Trate como upside.

Como reportar isso

A parte mais difícil de volatilidade não anunciada não é técnica. É de comunicação. O cliente ou o board quer explicação, e "o Google está instável" soa exatamente como desculpa, mesmo quando é verdade.

O que eu faço nesses casos é mostrar a investigação, não a conclusão. Um relatório que lista as sete hipóteses testadas, o que cada teste descartou e o que sobrou convence muito mais que uma frase sobre volatilidade de mercado. É a mesma lógica que aplico em BI e inteligência de dados: dado bruto não convence ninguém, raciocínio documentado convence.

E deixe explícito o que não mudou. Se conversão e receita do canal seguem estáveis enquanto as sessões caíram, você tem uma história bem diferente para contar, e provavelmente melhor do que parecia no começo da reunião.

Checklist de 30 minutos

Quando o cliente liga dizendo que o tráfego caiu, esse é o roteiro que consigo rodar antes de responder qualquer coisa. Trinta minutos, e na maioria das vezes já dá para dizer se o problema é interno.

1. Ações manuais. Search Console. Um minuto.
2. A URL principal responde 200 para bot? curl -I -A "Googlebot" na home e em três páginas importantes. Dois minutos, e já peguei site inteiro devolvendo 403 para Googlebot por causa de regra de firewall nova.
3. O robots.txt mudou? Compare com a versão que você conhece. Se não tem histórico, esse é o momento de começar a guardar.
4. Meta robots e canonical nas páginas afetadas. Um noindex vazado de staging é a causa mais comum de queda abrupta e concentrada.
5. Cobertura de indexação. Alguma categoria explodiu na janela?
6. Sitemap acessível e atualizado.
7. Impressões contra cliques. Curvas separadas, sempre.
8. Deploys no período. Peça a lista. Se o time não tem registro de deploy, esse é um problema maior que a queda.
9. Core Web Vitals. Piora súbita costuma acompanhar tag nova.
10. Comparação com o mesmo período do ano anterior. Elimina sazonalidade.

O que os logs contam e as ferramentas não

Log de servidor é a fonte mais subutilizada em diagnóstico de SEO, e a única que mostra o que de fato aconteceu entre o bot e o seu servidor.

O que procuro:

Frequência de rastreamento por bot. Se o Googlebot passava 8 mil vezes por dia e caiu para 900 na semana da queda, você tem uma pista forte, e ela aponta para problema técnico ou de qualidade percebida, não para mudança de ranking.

Distribuição de status. Um salto de 5xx, mesmo pequeno em proporção, é grave. Bot que encontra erro intermitente reduz rastreamento por conta própria.

Tempo de resposta para bot. Costuma ser diferente do tempo para usuário, principalmente com cache que não beneficia user-agent de bot.

Quais seções o bot visita. Se ele passa 70% do orçamento em páginas de filtro e paginação, o problema é arquitetura, e isso aparece como queda difusa meses depois.

Bots de IA. Vale separar GPTBot, ClaudeBot, PerplexityBot e OAI-SearchBot na análise. Uma queda no rastreamento deles não afeta o Google, mas afeta um canal inteiro, e é exatamente o cenário do bloqueio acidental de crawlers de IA.

Se você não tem acesso a log, priorize conseguir. Em Cloudflare, Vercel ou CDN equivalente, existe alguma forma de exportar. É o investimento de diagnóstico com melhor retorno que conheço.

O relatório que funciona

Já escrevi que o problema aqui é de comunicação, e vale detalhar a estrutura, porque é o que evita a conversa virar defesa.

Comece pelo impacto no negócio, não pelo tráfego. "As sessões caíram 22% e a receita do canal caiu 4%" conta uma história completamente diferente de "as sessões caíram 22%". Se você abre com sessão, a reunião inteira gira em torno de sessão.

Mostre as hipóteses testadas. Uma tabela com hipótese, teste feito, resultado. Isso transforma "não sabemos" em "investigamos dez coisas e eliminamos nove", que é uma posição bem diferente.

Separe o que você controla. Deixe explícito o que é decisão sua, o que depende de outro time e o que está fora do alcance de todo mundo. Volatilidade de SERP está na terceira categoria, e nomear isso reduz a pressão por ação imediata.

Diga o que você vai fazer e o que vai deixar de fazer. A parte de deixar de fazer é a que dá credibilidade. "Não vamos mexer na arquitetura durante a janela de instabilidade" é uma decisão defensável e mostra método.

Defina o gatilho de reavaliação. "Se em duas semanas a curva não estabilizar, mudamos de hipótese." Sem isso, a expectativa fica em aberto e a próxima reunião começa do zero.

Conclusão

Agosto de 2026 está instável de verdade, e é possível que um core update seja confirmado depois, retroativamente. Mas a postura que protege o seu resultado não muda: elimine primeiro o que está sob o seu controle, documente o que testou, e resista à vontade de mexer em tudo enquanto a SERP está balançando.

Mudança grande feita no meio de uma janela de volatilidade é a receita mais confiável para não entender nada depois. E não entender depois é bem pior que a queda em si.