Esta semana, o r/SEO e o r/TechSEO encheram-se com a mesma captura de ecrã: as impressões no Search Console a cair a pique enquanto a Inspeção de URL continua a dizer que as páginas estão indexadas. As datas variam (7, 11, 16, 17 e 21 de outubro de 2026), as plataformas variam, e o pânico é igual. Uma queda súbita em páginas indexadas tem uma lista curta de causas, e a maioria pode ser confirmada ou excluída em menos de uma hora com as próprias páginas da Google. Este guia põe-nas pela ordem que desperdiça menos tempo, quer o site corra em WordPress, Shopify, um frontend headless em Next.js ou Astro, ou noutra coisa qualquer.
Indexada significa apenas que a Google guardou a página e pode mostrá-la. As impressões medem se ela apareceu de facto numa pesquisa real. O diagnóstico faz-se no intervalo entre as duas coisas.
O que o estado indexada na Inspeção de URL prova, e o que não prova
A ajuda da Inspeção de URL explica que tudo o que a ferramenta mostra sobre o resultado indexado vem da última versão rastreada da página, e indica essa data no campo do último rastreio. Uma página rastreada há três semanas pode continuar a aparecer como presente no Google depois de o modelo ter avariado ontem. Confirme essa data antes de confiar no visto verde.
A mesma página enumera o que o teste não verifica: se a página cumpre as diretrizes de qualidade e de segurança da Google, se o site tem uma ação manual ou um problema de segurança, e se o URL está sujeito a uma remoção legal ou de outro tipo. Diz ainda que o canónico escolhido pela Google só pode ser lido nos dados indexados, não num teste em direto. A Inspeção de URL responde à pergunta se a Google consegue obter e guardar a página; o relatório de desempenho responde à pergunta se a Google a mostra. Uma queda súbita de impressões em páginas indexadas é assunto do segundo relatório.
A queda de impressões no Search Console é real ou é um erro do relatório
Comece pelo instrumento de medição. O guia da Google para depurar quedas de tráfego inclui, ao lado das causas reais, um esboço com a legenda “falha de relatório” (tradução própria) e manda consultar primeiro a página de anomalias de dados no Search Console. Essa página regista os erros de registo conhecidos dos últimos 3 a 16 meses. A 23 de outubro de 2026 não indica nada para outubro. Indica, isso sim, um erro de registo que afetou a contagem de impressões de 13 de maio de 2025 a 27 de abril de 2026, depois do qual as impressões reportadas diminuíram e os cliques ficaram intactos. Uma descida de impressões com cliques estáveis pode ser uma mudança na medição e não uma perda de visibilidade.
Há mais duas armadilhas nos relatórios. A ajuda do relatório de desempenho diz que os dados mais recentes podem ser preliminares e aparecem com uma linha tracejada. Além disso, os vários relatórios são atualizados em calendários diferentes. Um utilizador do r/SEO descreveu o desfasamento:
A 20 de outubro, o meu relatório de indexação de páginas ainda mostrava 12 de outubro como última atualização.
(u/Silberzwiebel, r/SEO, 22 de outubro de 2026, tradução própria)
Na mesma semana, o proprietário de um site no r/TechSEO viu o mesmo atraso: “a data mais recente ali é 12 de outubro, enquanto a captura acima vai até 19 de outubro” (u/ddxv, r/TechSEO, tradução própria). Não compare um gráfico de desempenho acabado de atualizar com um relatório de indexação de páginas com uma semana de atraso.
Houve uma atualização da Google no dia em que o tráfego caiu
Abra o painel de estado da Pesquisa Google e compare o início da sua queda com os incidentes listados. O painel mostra as horas no fuso US/Pacific; o feed legível por máquina dá-as em UTC. Para o outono de 2026, regista a atualização de spam de setembro de 2026 de 24 de setembro, 16:15 UTC, a 8 de outubro, 08:00 UTC. As secções de rastreio e de indexação não mostram incidentes recentes, e o último incidente de apresentação é de 24 de fevereiro de 2026.
Essa janela coincide com um dos casos desta semana. Um utilizador que perdeu cerca de 95% do tráfego do Google atualizou a discussão com o momento exato:
As impressões caíram de cerca de 8900 por dia para cerca de 300 no espaço de uma hora, a 7 de outubro (por volta das 03:00 UTC). É a reta final da atualização de spam de setembro de 2026 (24 de setembro a 8 de outubro).
(u/Longjumping-Ad1011, r/TechSEO, 23 de outubro de 2026, tradução própria)
O mesmo utilizador acrescentou que a maioria dos cerca de 120 000 URLs do sitemap eram páginas programáticas e que 86% não tinham tido nenhuma impressão nas quatro semanas anteriores à queda, precisamente o tipo de perfil que as políticas de spam da Google visam.
Para quedas a 11, 16, 17 ou 21 de outubro o quadro é outro: a Google não regista nada nessas datas, nem no painel nem na página de anomalias. Outro comentador do r/TechSEO resumiu-o sem rodeios: “a 21 de outubro caiu cerca de 90% em duas horas, a partir das 07:00 UTC. As páginas continuam indexadas, não há ação manual e o tráfego do Yandex não mexeu” (u/Radiant_Train_8917, tradução própria). Uma data sem registo não prova que nada aconteceu, porque a Google só publica as atualizações relevantes, mas significa que não pode apontar para uma atualização anunciada e dar a busca por terminada.
Abra também os relatórios de ações manuais e de problemas de segurança no Search Console. O guia da Google aponta ambos como causas de quedas grandes, e excluí-los demora um minuto.
Queda de tráfego ao fim de semana ou sazonalidade
O dia 17 de outubro de 2026 foi um sábado. A resposta mais útil na discussão sobre a queda desde 17 de outubro tinha a ver com o calendário:
O dia 17 de outubro foi há 5 dias e só há dados até 20 de outubro. Viu-se uma descida. Pode ser completamente aleatório. Nada de pânico com cada descida de fim de semana. Se virar tendência, aí sim, é altura de fazer a triagem.
(u/itisoktodance, r/SEO, 22 de outubro de 2026, tradução própria)
Um site que vende a empresas pode perder ao sábado e ao domingo uma boa parte da procura dos dias úteis. O Search Console tem uma definição pensada exatamente para isto: o relatório de desempenho oferece agregação semanal e mensal para suavizar “as flutuações diárias, como as causadas por fins de semana ou feriados” (tradução própria). Mude para a vista semanal e veja se a queda se mantém.
Quanto à sazonalidade, o guia da Google recomenda alargar o intervalo de datas aos últimos 16 meses e ver se a mesma descida apareceu um ano antes. Depois, passe as suas principais pesquisas pelo Google Trends para perceber se a procura caiu em toda a web ou só para o seu site.
O que mudou no seu site: robots.txt, noindex, canónicos, redirecionamentos e renderização
Se a queda é real, não coincide com um fim de semana e não se alinha com uma atualização listada, abra o histórico das suas publicações. O guia da Google faz uma distinção que pesa quando a queda é abrupta: um noindex mal colocado depende de a Google voltar a rastrear cada página, por isso provoca um declínio mais lento, enquanto um problema em todo o site pode ter efeito rápido. Alterações típicas que afetam o site inteiro:
- robots.txt. A ajuda do relatório de estatísticas de rastreio diz que, se o robots.txt devolver 429 ou 5xx e a Google não tiver uma cópia válida com menos de 24 horas, a Google deixa de rastrear o site durante as primeiras 12 horas. Uma regra de firewall mal configurada pode fazer isto apenas ao robots.txt.
- Proteção contra bots. As definições de bots de IA da Cloudflare colocam na categoria de treino os rastreadores de uso misto, que servem tanto para treino como para pesquisa. Explicámos que opções chegam ao Googlebot no artigo a Cloudflare bloqueia o Googlebot.
- Canónicos e redirecionamentos. Uma nova versão de um tema, de uma aplicação ou de um middleware que mude a forma como as etiquetas canónicas ou os redirecionamentos são gerados pode transferir sinais para outro URL ou outro nome de anfitrião, como no nosso guia sobre um site indexado no subdomínio errado.
- Renderização. Uma alteração em JavaScript ou no servidor pode deixar quase vazio o HTML que a Google recebe, enquanto a página parece normal no navegador.
Uma resposta no r/TechSEO mostra como o gatilho pode ser pequeno:
Pus uma regra no htaccess que achava que ia travar isto. Afinal também impedia a renderização de partes da página inicial, e a página inicial acabou desindexada.
(u/emuwannabe, r/TechSEO, 22 de outubro de 2026, tradução própria)
Em Definições, abra as estatísticas de rastreio e verifique o estado do anfitrião (obtenção do robots.txt, resolução de DNS, conectividade do servidor), a percentagem de respostas 5xx e um salto no tempo médio de resposta no dia da queda. Depois, use a Inspeção de URL numa página que perdeu tráfego e abra o HTML rastreado. Uma verificação cruzada da mesma discussão: “veja o seu tráfego no Bing com as Bing Webmaster Tools. Se o padrão for parecido, procure um problema técnico” (u/sammyQc, tradução própria).
Interruptores de cada plataforma que escondem o site da pesquisa
Cada plataforma tem uma definição capaz de tirar o site dos resultados numa única publicação:
- WordPress. A documentação das definições de leitura diz que a caixa que pede aos motores de pesquisa para não indexarem o site acrescenta, desde a versão 5.3, uma meta tag robots com noindex,nofollow a todas as páginas que chamam wp_head. Uma cópia de testes enviada para produção com essa caixa marcada é uma causa clássica. Como se trata de um noindex ao nível da página, o guia da Google prevê um declínio gradual à medida que as páginas são rastreadas de novo, e não uma queda numa hora.
- Shopify. A documentação do robots.txt.liquid diz que acrescentar este modelo substitui o robots.txt gerado pela Shopify, e aconselha a guardar uma cópia do /robots.txt atual e compará-la com o modelo renderizado antes de publicar. Uma mudança de tema que traga um ficheiro robots editado à mão tem de constar do seu histórico de publicações.
- Next.js. A convenção do ficheiro robots permite que
app/robots.tsgere o robots.txt, incluindo regras separadas por user agent, e a documentação indica que fica em cache por predefinição. Depois de cada publicação, leia o /robots.txt em produção, não o ficheiro de origem.
Quanto tempo podem durar os erros de servidor antes de as páginas saírem do índice
A página da Google sobre como os códigos de estado HTTP afetam os rastreadores separa com clareza as duas famílias de erros. Um 5xx ou um 429 faz o Googlebot abrandar temporariamente; os URLs já indexados mantêm-se no índice durante algum tempo, mas acabam por ser retirados, e os URLs que devolvem um erro de servidor de forma persistente são removidos. Com um 500, a frequência de rastreio desce em proporção ao número de URLs que devolvem o erro, e quando o servidor volta a responder 2xx a Google aumenta a frequência de forma gradual. Um 4xx que não seja 429 é tratado de outra maneira: os URLs indexados que o devolvem são removidos do índice.
Daqui resultam duas consequências para o diagnóstico. Uma falha curta, como o incidente de 15 minutos no alojamento referido por um comentador, não remove por si só páginas indexadas de um dia para o outro. Um limitador de pedidos ou uma regra contra bots que responda 429 ao Googlebot durante dias abranda o rastreio e, se persistir, começa a remover URLs. A mesma página nota que uma resposta 200 com uma página vazia ou com uma mensagem de erro pode ser reportada como soft 404, e é assim que uma renderização avariada aparece quando todos os códigos de estado parecem normais.
Como confirmar se o visitante bloqueado pela firewall é mesmo o Googlebot
Registos cheios de user agents com o nome Googlebot não provam nada, porque qualquer scraper pode enviar essa cadeia de texto. Um comentador do r/TechSEO atribuiu uma queda de dois meses precisamente a isto:
Também me aconteceu. Mas foi por causa de um ataque de Googlebot falso. Queda a 1 de agosto. A 1 de outubro voltou.
(u/kimboai, r/TechSEO, 22 de outubro de 2026, tradução própria)
Seja qual for a causa desse caso, o risco corre nos dois sentidos: uma regra escrita contra rastreadores falsos pode bloquear o verdadeiro. O guia da Google para verificar o Googlebot dá o teste. Faça uma pesquisa de DNS inversa ao IP que aparece nos registos, confirme que o nome termina em googlebot.com, google.com ou googleusercontent.com, e depois faça uma pesquisa direta a esse nome e confirme que devolve o mesmo IP:
host 66.249.66.1
host crawl-66-249-66-1.googlebot.comA alternativa é comparar o IP com as listas JSON de intervalos de IP dos rastreadores da Google, para as quais a mesma página tem ligação. Antes de apertar qualquer regra de firewall ou de CDN depois de uma queda, verifique quais dos pedidos bloqueados passaram neste teste.
Impressões estáveis mas menos cliques: resultados enriquecidos perdidos e Vistas gerais de IA
O guia da Google separa os dois padrões. Se as impressões se mantêm e os cliques descem, o título e o excerto podem estar mais fracos do que poderiam, ou outros resultados ganharam um resultado enriquecido mais apelativo. As funcionalidades também desaparecem do lado da Google: a página de anomalias regista que os resultados enriquecidos de FAQ deixaram de aparecer na Pesquisa Google a 7 de maio de 2026, e os sites que dependiam deles viram cair as impressões de FAQ.
As funcionalidades de IA entram nos mesmos números. A documentação da Google sobre funcionalidades de IA diz que as Vistas gerais de IA e o Modo IA são reportados no relatório de desempenho no tipo de pesquisa Web, e a página de metodologia do Search Console diz que todas as ligações de uma mesma Vista geral de IA partilham uma única posição. Não é possível filtrar as Vistas gerais de IA no relatório principal, por isso uma pesquisa que passou a mostrar uma Vista geral de IA pode manter as impressões e perder cliques. Os nossos artigos sobre IA generativa no Search Console e sobre como medir conversões da pesquisa com IA explicam o que dá para medir aí.
Que pesquisas e páginas perderam impressões
O total do site esconde a causa. Como disse uma resposta no r/SEO, “as impressões não dependem do site como um todo, mas do desempenho individual de cada palavra-chave em cada página” (u/WebLinkr, r/SEO, tradução própria). O guia da Google descreve o procedimento: compare o período da queda com um período anterior semelhante, ordene a tabela de páginas pela diferença de cliques e percorra os separadores de consultas, países, dispositivos e aspeto da pesquisa. Verifique também o filtro do tipo de pesquisa, porque uma queda no Google Imagens ou no Google Notícias parece, na vista predefinida, uma queda em todo o site.
Leia o resultado assim:
- Uma página ou um grupo de pesquisas que perde tudo aponta para essa página ou para uma mudança nos resultados desse tema.
- Todas as páginas, línguas e países a perder a mesma fatia na mesma hora apontam para uma causa ao nível do site: um sistema de classificação, um aviso de segurança ou um bloqueio do rastreio.
- Pesquisas de marca que se aguentam enquanto as genéricas desabam apontam para a classificação, não para a indexação.
Para comparar períodos no Search Console sem se enganar:
- Compare períodos com a mesma duração que comecem no mesmo dia da semana, por exemplo 28 dias contra os 28 anteriores.
- Deixe de fora os últimos dois ou três dias se o gráfico ainda os mostrar a tracejado, como preliminares.
- Acrescente uma comparação com o ano anterior antes de culpar uma atualização por uma descida sazonal.
- Para uma queda ao nível da hora, use a vista de 24 horas; a Google diz que mostra dados por hora, preliminares.
- Se extrair dados pela API Search Analytics, repare no parâmetro
dataState: omitido ou com o valorfinal, devolve apenas dados finalizados, enquantoallinclui dados recentes que ainda podem mudar. Misturar os dois na mesma folha de cálculo fabrica uma queda nos últimos dias. - Não faça novas alterações até ter uma semana inteira de dados depois da correção, para saber que alteração teve que efeito.
Tabela de decisão: sintoma, causa provável, onde verificar
| Sintoma | Causa provável | Onde verificar |
|---|---|---|
| Impressões caíram, cliques estáveis | Mudança nos relatórios ou no registo | Página de anomalias de dados, dados preliminares |
| Queda só ao sábado e ao domingo | Ciclo semanal da procura | Relatório de desempenho, agregação semanal |
| A mesma descida há um ano | Sazonalidade | Intervalo de 16 meses, Google Trends |
| Queda abrupta dentro da janela de uma atualização listada | Atualização principal ou de spam | Painel de estado da Pesquisa Google, ações manuais |
| Todas as páginas, todos os países, à mesma hora, sem atualização listada | Bloqueio em todo o site ou mudança na apresentação | Estado do anfitrião nas estatísticas de rastreio, robots.txt, firewall, comparação com o Bing |
| Declínio lento num grupo de páginas | Alteração de noindex, canónicos ou redirecionamentos | Inspeção de URL, relatório de indexação de páginas |
| Impressões estáveis, cliques em baixo | Perda de um resultado enriquecido ou Vista geral de IA na pesquisa | Separador do aspeto da pesquisa, verificação da página de resultados ao vivo |
| Só um tipo de pesquisa em baixo | Mudança em Imagens, Notícias ou Vídeos | Filtro do tipo de pesquisa |
Se preferir que alguém de fora olhe para o problema, a nossa verificação de site lê as regras de robots, os códigos de resposta e os sinais de indexação de qualquer URL público, não apenas de sites WordPress. Quando as estatísticas de rastreio mostram respostas mais lentas na altura da queda, uma auditoria de Core Web Vitals cobre os tempos do servidor e a renderização.
Última atualização: 23 de outubro de 2026.
