Resposta curta
Quando um site some do Google de um dia pro outro, quase sempre foi uma mudança técnica, não um castigo. Confira nesta ordem: noindex no HTML ou no cabeçalho, robots.txt com Disallow: /, canonical apontando pra outro domínio, redirects quebrados, servidor ou firewall barrando o Googlebot e conteúdo que só aparece com JavaScript. Cada um leva um minuto pra checar e o roteiro está abaixo.
Primeiro: sumiu mesmo ou só caiu de posição?
São dois problemas diferentes, com causas diferentes. Antes de mexer em qualquer coisa, descubra qual dos dois é o seu.
- Busque o nome exato da marca. Se nem pelo nome o site aparece, ele provavelmente saiu do índice.
- Busque
site:seudominio.com.br. O número é aproximado, mas zero resultado (ou só meia dúzia, quando antes eram centenas) é sinal forte de desindexação. - Abra o Search Console, em Desempenho. Se as impressões despencaram pra perto de zero numa data específica, algo mudou naquele dia. Se caíram aos poucos, é mais provável que seja concorrência ou atualização do algoritmo.
Se as páginas continuam indexadas e só perderam posição, o problema costuma ser de conteúdo ou de concorrência, e o fim deste artigo fala disso. Se elas saíram do índice, siga a lista abaixo na ordem: ela vai da causa mais comum pra menos comum.
Ache a data em que tudo mudou
Quase todo sumiço tem um dia. No gráfico de Desempenho do Search Console, procure o ponto em que as impressões caíram e cruze com o que aconteceu no site naquela semana: um deploy, a troca de tema, a migração de plataforma, um plugin novo, a mudança de domínio, a ativação de um firewall. Na maioria das vezes a causa está numa dessas mudanças, e saber a data corta a investigação pela metade.
1. Uma tag noindex entrou no ar
É a causa número um depois de um deploy. A tag <meta name="robots" content="noindex"> manda o Google tirar a página do índice, e ele obedece. Ela costuma vir do ambiente de teste: alguém marca o staging como "não indexar" e a configuração vai junto pra produção.
Como checar: abra o código-fonte da home (Ctrl+U) e procure por noindex. Depois confira o cabeçalho HTTP, porque a mesma instrução pode vir como X-Robots-Tag: noindex e não aparecer no HTML:
curl -sI https://seusite.com.br | grep -i x-robots-tag
No Search Console, as páginas afetadas aparecem em Indexação › Páginas com o motivo "Excluída pela tag 'noindex'". O passo a passo pra achar de onde ela vem, por plataforma, está no artigo sobre noindex sem querer.
2. O robots.txt fechou a porta
Duas linhas bastam pra impedir o Google de rastrear o site inteiro:
User-agent: *
Disallow: /
De novo, quase sempre é herança do staging. Abra seusite.com.br/robots.txt no navegador e leia. Se aparecer Disallow: / no grupo do * ou do Googlebot, achou. No Search Console, o motivo é "Bloqueada pelo robots.txt", e às vezes a página continua no resultado, mas sem descrição.
Existem pegadinhas menos óbvias, como um robots.txt que responde erro 5xx (o Google para de rastrear por um tempo) ou um grupo específico do Googlebot que faz ele ignorar todo o resto. Elas estão no artigo sobre robots.txt bloqueando o Google.
3. O canonical aponta pra outro lugar
A tag <link rel="canonical"> diz ao Google qual é a versão oficial da página. Se ela aponta pra outro endereço, o Google tende a indexar o outro endereço e esconder o seu. Os casos clássicos:
- Canonical apontando pro domínio de preview, como
projeto.vercel.app,projeto.netlify.appoustaging.seusite.com.br. - Todas as páginas com o canonical da home, porque o valor ficou fixo no template.
- Canonical em
http://num site que já éhttps://, ou comwwwnum site semwww.
Como checar: no código-fonte, procure por rel="canonical" e confira se o endereço é exatamente o da página que você está vendo. O Search Console mostra o problema como "Página alternativa com tag canônica adequada" ou "Duplicada, o Google escolheu uma canônica diferente da do usuário". As correções, inclusive no Next.js, estão em canonical apontando pro vercel.app.
4. Os redirects quebraram na migração
Trocar de domínio, de plataforma ou de estrutura de URL sem mapear os endereços antigos é a forma mais rápida de perder anos de tráfego. Os erros mais comuns:
- Redirecionar tudo pra home. O Google trata isso como soft 404: a página antiga não tem equivalente, então o sinal dela se perde.
- Usar 302 em vez de 301. O 302 diz que a mudança é temporária, e o Google pode continuar guardando o endereço antigo.
- Correntes de redirect.
http→https→www→ endereço novo. Cada salto atrasa e gasta rastreamento. - Endereços antigos dando 404. Links de outros sites passam a apontar pro nada.
Pra ver cada salto de um endereço, use o verificador de redirect. Numa migração, o certo é um 301 direto de cada URL antiga pra sua equivalente nova. Os detalhes estão no artigo sobre redirect 301 ou 302.
5. O servidor ou o firewall estão barrando o Googlebot
O site abre normal pra você, mas o Google recebe erro. Acontece mais do que parece:
- Um firewall, regra de WAF ou proteção anti-bot (Cloudflare, Sucuri, plugin de segurança) bloqueando ou desafiando o Googlebot.
- Servidor respondendo 5xx nos horários de pico, ou caindo sob o rastreamento.
- Bloqueio por país ou por faixa de IP que pega os servidores do Google, que rastreiam principalmente a partir dos Estados Unidos.
Como checar: no Search Console, abra Configurações › Estatísticas de rastreamento e veja se os erros de servidor ou de "host indisponível" subiram. Depois use a Inspeção de URL com "Testar URL publicada": ela busca a página como o Googlebot e mostra o que voltou.
6. O conteúdo só aparece com JavaScript
Em sites feitos como SPA (React, Vue ou Angular sem renderização no servidor), o HTML que chega pro robô é uma casca quase vazia, e o conteúdo só aparece depois que o JavaScript roda. O Google até renderiza JavaScript, mas numa segunda fila, sem prazo, e qualquer erro de script deixa a página em branco pra ele. Se o sumiço coincidiu com uma reescrita do front-end, desconfie disso.
Como checar: rode curl -s https://seusite.com.br | head -100 ou desligue o JavaScript no navegador. Se o texto principal não estiver ali, o Google depende da renderização pra ver seu conteúdo. A saída é renderizar no servidor ou gerar as páginas no build (SSR ou SSG, com Next, Nuxt, Astro, Remix e afins). Robôs de IA costumam nem tentar renderizar, assunto do artigo sobre aparecer nas respostas com IA.
7. Alguém pediu a remoção no Search Console
A ferramenta Remoções esconde URLs do Google por cerca de seis meses. Um pedido feito por engano, com um prefixo amplo demais (como o domínio inteiro), some com o site. Abra Indexação › Remoções e veja se existe algum pedido ativo. Se existir, cancele.
8. Ação manual ou site invadido
É raro, mas é a causa mais grave. Abra Segurança e ações manuais no Search Console. Ali aparecem penalidades aplicadas por um revisor do Google (spam, links comprados, conteúdo gerado em massa) e problemas de segurança, como páginas de spam injetadas por um invasor. Um sinal típico de invasão é a busca site: mostrar páginas que você nunca criou, muitas vezes em japonês ou com nomes de remédios. Nesse caso, limpe o site, troque as senhas, corrija a brecha e peça revisão pelo próprio relatório.
Resumo: sintoma, causa provável e onde olhar
| O que você vê | Causa provável | Onde olhar |
|---|---|---|
| Sumiu tudo logo depois de um deploy | noindex ou robots.txt do staging | Código-fonte, cabeçalhos, /robots.txt |
| Resultado aparece, mas sem descrição | Bloqueio no robots.txt | /robots.txt e o relatório do robots.txt |
| Aparece outro domínio no lugar do seu | Canonical errado | rel="canonical" e Inspeção de URL |
| Caiu depois de migrar de domínio ou plataforma | Redirects faltando ou em 302 | Verificador de redirect, páginas 404 |
| Erros de servidor no Search Console | Firewall, WAF ou servidor instável | Estatísticas de rastreamento |
| Páginas novas nunca entram | Conteúdo só com JavaScript | HTML cru com curl |
Páginas estranhas no site: | Invasão | Segurança e ações manuais |
Corrigiu? Faça o Google voltar mais rápido
- Na Inspeção de URL, teste a home e as páginas mais importantes com "Testar URL publicada". Confirme que aparece "A URL pode ser indexada".
- Clique em "Solicitar indexação" nessas páginas. Existe um limite diário, então priorize as que trazem mais tráfego.
- Reenvie o sitemap em Indexação › Sitemaps.
- Acompanhe o relatório de Páginas nos dias seguintes. A volta costuma levar de alguns dias a algumas semanas, dependendo do tamanho do site e da frequência de rastreamento.
Pedir indexação de novo não acelera nada depois do primeiro pedido. O que acelera é o site estar certo quando o robô voltar.
E se não foi nada técnico?
Se as páginas seguem indexadas, os resultados aparecem com descrição e mesmo assim o tráfego caiu, olhe pra fora do código. O Google publica as atualizações principais do algoritmo no painel de status da Pesquisa, e quedas que coincidem com uma delas costumam ter a ver com a qualidade do conteúdo em relação aos concorrentes. Aí o trabalho é outro: páginas mais úteis, mais completas e mais atualizadas do que as que passaram na sua frente.
Como não passar por isso de novo
Repare que as seis primeiras causas têm algo em comum: entram no ar num deploy, sem ninguém perceber, e só aparecem semanas depois, quando o tráfego já caiu. A defesa é conferir noindex, robots.txt, canonical, redirects e status das páginas toda vez que o site muda, e não só quando alguém reclama.
Dá pra fazer isso na mão, com os comandos deste artigo, ou deixar com a Varrida: a varredura grátis confere tudo isso numa amostra do site em menos de um minuto, e o plano grátis acompanha um site por semana e avisa por e-mail se algo piorar.


