Quando um site some do Google, há 8 causas técnicas prováveis que precisam ser checadas em ordem — e a primeira ferramenta de diagnóstico é o Google Search Console, não o Google.com
"Meu site sumiu do Google" é uma das frases mais frequentes em qualquer agência de SEO no Brasil — e quase sempre vem acompanhada de pânico, porque para muitos negócios o tráfego orgânico é o canal de aquisição principal e o desaparecimento dele significa queda de receita imediata. A boa notícia é que na maioria dos casos o problema é diagnosticável e reversível. A má notícia é que sem método, a tentativa de "resolver" rapidamente costuma piorar a situação — gente que mexe em robots.txt sem entender, que apaga e recria páginas, que pede reconsideração à toa, que troca o site inteiro por um novo. Tudo isso atrasa a recuperação.
Antes de qualquer coisa, é preciso confirmar o que efetivamente aconteceu. "Sumir do Google" pode significar coisas diferentes: o site não aparece para o nome da empresa quando alguém pesquisa, mas aparece para outras palavras-chave; o site aparece em algumas posições mas perdeu volume relevante de tráfego; o site não aparece em nada, nem para o próprio domínio. Cada cenário tem causa diferente. Por isso, o primeiro passo do diagnóstico não é abrir o Google.com e digitar o nome — é abrir o Google Search Console, que é a ferramenta oficial e gratuita do Google para webmasters monitorarem como o site está sendo visto e indexado.
Este artigo descreve as 8 causas técnicas mais frequentes para um site sumir do Google, em ordem de probabilidade, e o método de diagnóstico de cada uma. As três primeiras são problemas de configuração do próprio site (causa em mais de 60% dos casos atendidos), as três seguintes são problemas de algoritmo ou penalidade, e as duas últimas são problemas de segurança ou mudança estrutural. Seguir o roteiro nesta ordem economiza tempo e evita ações que pioram o quadro.
Importante destacar antes: SEO técnico é matéria que exige paciência. Mesmo depois de identificar e corrigir a causa, o Google leva de horas a semanas para reindexar o site e devolver as posições. Não é instantâneo. E não há "submissão urgente" que faça ir mais rápido — pedidos de reindexação manual ajudam a acelerar de dias para horas em alguns casos, mas não quebram o ciclo natural de rastreamento do bot. É o framework que a KOP aplica em recuperação de sites há 10 anos: diagnosticar com método, corrigir com critério, esperar com paciência.
Causa 1, 2 e 3: configurações do próprio site que bloqueiam o Google (60% dos casos)
A primeira causa que precisa ser checada — e a mais frequente — é o bloqueio acidental no robots.txt. O arquivo robots.txt, hospedado na raiz do domínio (ex: https://seusite.com.br/robots.txt), informa aos bots de busca quais páginas eles podem ou não rastrear. Em desenvolvimento de site, é comum a equipe técnica adicionar a linha Disallow: / para impedir que o site em construção seja indexado antes de estar pronto. Quando o site vai ao ar, essa linha precisa ser removida. Se ficar esquecida, o site existe na internet mas o Google não pode rastrear nada — e em poucas semanas, o domínio inteiro some das pesquisas. Diagnóstico: abra /robots.txt no navegador e procure por "Disallow: /" ou "Disallow: /*". Se houver, edite removendo a regra excessiva.
A segunda causa é a tag meta noindex no HTML das páginas. Diferente do robots.txt (que bloqueia rastreamento), a tag noindex pede ao Google para não indexar a página mesmo após rastrear. Aparece como <meta name="robots" content="noindex"> dentro do <head>. É comum em CMS como WordPress, onde existe uma checkbox em Configurações > Leitura chamada "Pedir aos buscadores para não indexar este site" — frequentemente marcada durante desenvolvimento e esquecida ao publicar. O efeito é o mesmo do robots.txt mal configurado: páginas saem da indexação. Diagnóstico: ver código fonte da página inicial (Ctrl+U no navegador) e procurar por "noindex". Se houver e for indevido, desmarcar a opção no CMS ou editar o template.
A terceira causa é problema de indexação por motivos técnicos do Google. Mesmo com robots.txt correto e sem noindex, páginas podem não estar indexadas por: tempo de carregamento muito alto (Google tem orçamento de rastreamento limitado por site, sites lentos perdem prioridade); estrutura HTML inválida; conteúdo idêntico ao de muitas outras páginas; erros de servidor recorrentes (5xx); ausência de sitemap.xml; arquitetura de links interna confusa que impede o bot de descobrir as páginas. Diagnóstico via Google Search Console: na seção "Páginas" (em Indexação), o Search Console mostra quantas páginas estão indexadas e quantas não estão, com classificação de motivo: "Descoberta no momento, mas ainda não indexada", "Erro de servidor (5xx)", "Página com redirecionamento", "Excluída pela tag noindex", entre outros. Cada motivo aponta para um conjunto específico de correções.
Antes de mexer em qualquer coisa, sempre fazer backup. Edição em robots.txt, no <head> do template ou em configurações do CMS sem backup é como cirurgia sem exames. Se algo der errado, o backup é o caminho de volta.
Causa 4 e 5: penalidade manual e queda por mudança de algoritmo
A penalidade manual acontece quando um revisor humano do Google identifica que o site viola as Diretrizes para Webmasters e aplica uma sanção que faz o domínio ou parte dele desaparecer da indexação. Causas mais comuns: conteúdo gerado artificialmente para manipular ranking, links de spam comprados em massa, cloaking (mostrar conteúdo diferente para bots e usuários), site invadido com conteúdo malicioso, conteúdo plagiado em volume. Diagnóstico: no Google Search Console, seção "Segurança e ações manuais" > "Ações manuais". Se houver penalidade, aparece com descrição do problema e link para mais detalhes. Se a seção mostra "Nenhum problema detectado", não é penalidade manual — é outra causa.
Quando há penalidade manual confirmada, o caminho é corrigir o problema apontado e enviar pedido de reconsideração pelo próprio Search Console. O pedido precisa ser específico: explicar o que foi corrigido, quando, como, com evidências (screenshots, listas de URLs limpas, logs de remoção). Pedido genérico do tipo "corrigi tudo, por favor reconsiderem" tipicamente é rejeitado. Tempo de resposta: 1 a 8 semanas. Importante: enviar pedido de reconsideração antes de efetivamente corrigir é contraproducente — o pedido será rejeitado e gera histórico negativo. Só pedir reconsideração quando o problema realmente acabou.
Diferente da penalidade manual, a queda por mudança de algoritmo não é sanção contra o site específico — é o Google atualizando como avalia conteúdo e o site perdendo posições por critérios novos. Os "core updates" do Google acontecem trimestralmente e às vezes redistribuem profundamente quem aparece e onde. Sites que dependiam de táticas antigas (palavras-chave repetidas, conteúdo raso, links de baixa qualidade) caem; sites com conteúdo aprofundado, expertise demonstrada, autoridade real e sinais de E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) sobem.
Diagnóstico de mudança de algoritmo: comparar o gráfico de impressões do Search Console com as datas dos core updates publicadas pelo Google (em developers.google.com/search/updates/ranking). Se a queda começou exatamente na data de um core update, é causa provável. Recuperação não é rápida nem garantida — exige melhorar substancialmente o conteúdo (mais profundidade, mais expertise, melhor experiência do usuário) e esperar pelo próximo core update para a melhoria ser reavaliada. Não há atalho.
Sub-causa relacionada: queda em palavras-chave específicas (não em tudo). Se o site continua aparecendo para muitas buscas mas perdeu posições para um conjunto específico (ex.: "advogado em [cidade]"), a causa pode ser concorrência intensificada (concorrentes melhoraram o SEO deles) ou desatualização do próprio conteúdo (a página caiu porque outras estão entregando resposta melhor). A solução é melhorar o conteúdo, atualizar com informação recente, ampliar o que a página cobre, melhorar autoridade externa via backlinks legítimos.
Causa 6, 7 e 8: hack, mudança de URL sem redirect e problemas de servidor
Site invadido (hack) é causa comum em WordPress, Joomla e outros CMS desatualizados. O Google detecta páginas com malware, phishing ou conteúdo manipulativo injetado por invasor e remove o site dos resultados para proteger usuários. Diagnóstico: Search Console > "Segurança e ações manuais" > "Problemas de segurança". Aparece o tipo de problema (malware, conteúdo enganoso, software prejudicial) e amostras de URLs afetadas. Solução: limpar o site (com ajuda técnica especializada — ferramentas como Wordfence, Sucuri, MalCare ajudam, mas em casos graves requer reinstalação de WordPress do zero a partir de backup limpo), atualizar todos os plugins e core, trocar todas as senhas, e enviar pedido de revisão de segurança pelo Search Console.
Mudança de URL sem redirect 301 é erro frequente em redesigns ou migrações de plataforma. Quando o site muda de estrutura (de WordPress para outra plataforma, de URL com numero para URL com palavra-chave, de http para https), todas as URLs antigas precisam ser redirecionadas via redirect 301 para as URLs novas correspondentes. Sem redirect, o Google encontra URLs antigas que retornam erro 404 (não encontrado) e gradualmente remove o site da indexação. Diagnóstico: Search Console > "Páginas" > seção "Não indexado" mostra URLs com erro "Não encontrado (404)". Se houver muitas, é sinal de que ou o site teve mudança recente sem redirect, ou há páginas mortas que precisam ser apontadas para destino válido. Solução: configurar redirect 301 em massa via .htaccess (Apache), nginx.conf (nginx) ou plugin do CMS.
Problemas de servidor recorrentes — erros 5xx, lentidão extrema, timeout — sinalizam ao Google que o site está instável e levam a perda de prioridade no rastreamento. Em casos persistentes, o Google reduz drasticamente a frequência com que rastreia o site, e novas páginas demoram semanas para serem descobertas. Diagnóstico: Search Console > "Estatísticas de rastreamento" mostra histórico de respostas do servidor e tempo médio de download por página. Se houver muitos 5xx ou tempo de download acima de 1 segundo consistentemente, é sinal vermelho. Solução: revisar hospedagem (migrar para servidor mais robusto se necessário), implementar cache (Redis, Varnish), otimizar imagens, reduzir scripts pesados, ativar CDN.
Causa relacionada: conteúdo duplicado interno. Quando o site tem várias páginas com conteúdo muito parecido (catálogo de produtos com pequenas variações, páginas de bairro com texto quase idêntico), o Google pode escolher uma delas como "canônica" e ignorar as outras — efeito prático: páginas que deveriam ranquear não aparecem. Diagnóstico: usar Screaming Frog ou Ahrefs para identificar duplicação. Solução: implementar rel=canonical apontando para a versão correta, ou consolidar páginas duplicadas em uma só com conteúdo aprofundado.
O método de diagnóstico: por onde começar quando o site sumiu
O diagnóstico técnico segue uma sequência específica que evita perder tempo e cometer erros. Passo 1: pesquisar no Google site:seudominio.com.br. Esse comando mostra o que o Google tem indexado do domínio. Se aparecem muitas páginas, o site está indexado parcialmente — o problema é em páginas específicas ou em ranqueamento, não em indexação total. Se aparecem poucas ou nenhuma, é problema sério de indexação.
Passo 2: abrir Google Search Console (criar conta se ainda não tem, verificar propriedade) e checar três seções: "Páginas" (quantas indexadas vs não indexadas e os motivos), "Segurança e ações manuais" (penalidades manuais e problemas de segurança), "Estatísticas de rastreamento" (saúde do servidor). Em 90% dos casos, o problema fica evidente nessas três seções.
Passo 3: checar robots.txt diretamente no navegador (/robots.txt) e código fonte da home (Ctrl+U) procurando por "noindex". Passo 4: comparar gráfico de impressões do Search Console com datas de core updates do Google. Passo 5: rodar auditoria técnica com Screaming Frog ou Ahrefs/Semrush para identificar erros estruturais.
Passo 6: implementar correções identificadas, com backup antes de qualquer mexida. Passo 7: solicitar nova indexação no Search Console ("Inspecionar URL" > "Solicitar indexação") para páginas críticas. Passo 8: monitorar por 1 a 4 semanas. Se o Google reindexar e retornar posições, o problema estava certo. Se não, voltar ao diagnóstico.
Importante saber o que não fazer em pânico: não recriar o site do zero (perde histórico de SEO ainda usável); não migrar para domínio novo (recomeça do zero); não comprar links de "recuperação" (acelera para penalidade); não enviar 50 pedidos de reconsideração (Search Console pode bloquear novas tentativas por 7 dias). O método é boring por design — é assim que funciona.
Framework integrado
- Confirme o estado real: pesquise
site:seudominio.com.brno Google. Se aparecem páginas, é problema parcial; se não aparecem, é total. - Abra o Google Search Console e cheque "Páginas", "Segurança e ações manuais" e "Estatísticas de rastreamento" — diagnóstico nas 3 seções resolve 90% dos casos.
- Verifique robots.txt e meta noindex no código fonte — causas mais comuns e mais fáceis de corrigir.
- Compare datas de queda com core updates do Google. Se coincidem, é mudança de algoritmo, não problema técnico.
- Rode auditoria técnica com Screaming Frog ou ferramenta similar para identificar erros estruturais e duplicação.
- Faça backup antes de qualquer correção — edição em robots.txt ou template sem backup é cirurgia sem exames.
- Solicite reindexação no Search Console depois de corrigir, e monitore por 1-4 semanas com paciência.
- Não recrie o site nem migre o domínio em pânico — perde histórico de SEO e recomeça do zero.
Quando um site some do Google, na grande maioria dos casos a causa é técnica e diagnosticável — bloqueio em robots.txt, tag noindex esquecida, problemas de indexação por servidor lento ou conteúdo duplicado. Em uma minoria, é penalidade manual ou queda por algoritmo, e exige correção mais profunda. Em casos de invasão, é segurança. O método de diagnóstico é boring por design: Google Search Console primeiro, robots.txt e noindex segundo, auditoria técnica terceiro. Sem método, mexer no site em pânico atrasa a recuperação. É o framework que a KOP aplica em recuperação de SEO há 10 anos.
