Ferramenta que avisa quando o site sai do Google: o que funciona e o que não

Por que quase todo mundo descobre tarde

Quando um noindex ou um robots.txt errado vai pro ar, nada parece quebrado. O site abre, o checkout funciona, o time segue o dia. O Google só percebe quando rastreia a página de novo, e o tráfego só cai quando ele tira a página do índice.

Na prática, a ordem costuma ser esta: o deploy sai, alguns dias depois as visitas orgânicas começam a cair, alguém estranha o gráfico do analytics e só então vai olhar o Search Console. Entre a causa e a descoberta passa uma semana ou mais, e cada dia é tráfego perdido.

Por isso a pergunta certa não é "qual ferramenta me avisa que o site saiu do Google", e sim "qual ferramenta me avisa que o site vai sair". A diferença é olhar a causa (o que o site está mandando pro Google) em vez do efeito (o que o Google já fez).

O Google Alerts não serve pra isso

É a primeira resposta que aparece quando alguém pergunta, e é a errada. O Google Alerts manda um e-mail quando o Google encontra resultados novos pra um termo que você escolheu, como o nome da sua marca. Ele serve pra acompanhar menções.

Ele não confere se as suas páginas continuam no índice. Se a home ganhar um noindex amanhã, o Alerts não manda nada, porque não apareceu nenhum resultado novo. Ele também não lê o seu robots.txt nem o seu canonical.

O que o Search Console avisa (e o que não avisa)

O Search Console é obrigatório e grátis, e é o único lugar que mostra o que o Google de fato indexou. Pra vigiar, ele tem três limites:

• Avisa depois. O e-mail de problema novo de indexação só sai quando o Google já rastreou a página com o problema. Em páginas que ele visita pouco, isso pode levar dias ou semanas.
• Os relatórios atrasam. O relatório Indexação › Páginas e o de Desempenho mostram dados de alguns dias atrás, não de hoje.
• Nem tudo vira e-mail. Um canonical apontando pro domínio errado ou um redirect que passou a mandar tudo pra home costumam aparecer só quando você abre o relatório e procura.

Use o Search Console pra confirmar o que aconteceu e pedir indexação depois de corrigir. Pra ser avisado antes, ele precisa de companhia.

Monitor de uptime também não pega

Ferramentas como UptimeRobot e Better Stack conferem se o site responde. Se a resposta for 200, está tudo verde. Só que uma página com noindex responde 200, um robots.txt fechando o site inteiro responde 200 e uma página de erro que devia ser 404 também responde 200 (o soft 404).

Dá pra improvisar: alguns monitores têm o modo "palavra-chave", que alerta quando um texto aparece ou some da resposta. Um monitor na home que alerta se aparecer a palavra noindex já pega o caso mais grave. Ele só olha uma página, não lê o cabeçalho X-Robots-Tag nem o robots.txt, mas é melhor que nada.

O que precisa ser conferido todo dia

Quase toda queda brusca no Google vem de uma destas mudanças. Se elas forem conferidas todo dia e a cada deploy, a queda vira um aviso antes de virar prejuízo.

Um vigia caseiro com GitHub Actions

Se o site está no GitHub, dá pra montar uma checagem diária de graça. O script abaixo confere a home: robots.txt fechando tudo, noindex na meta tag ou no cabeçalho e canonical apontando pra outro domínio. Se algo der errado, o job falha e o GitHub manda e-mail pra quem acompanha o repositório.

#!/usr/bin/env bash
# Uso: SITE=https://seusite.com.br bash scripts/vigia-seo.sh
set -u
UA="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
host=$(echo "$SITE" | sed -E 's#https?://([^/]+).*#\1#')
erro=0

# 1. robots.txt: "Disallow" só com a barra, dentro do bloco que vale pra todos
if curl -s -A "$UA" "$SITE/robots.txt" | tr -d '\r' \
  | awk '/^[Uu]ser-agent: *\*/{f=1;next} /^[Uu]ser-agent:/{f=0} f' \
  | grep -Eiq '^disallow: */ *$'; then
  echo "robots.txt fecha o site inteiro"; erro=1
fi

# 2. noindex no cabeçalho
if curl -sI -A "$UA" "$SITE/" | grep -iq '^x-robots-tag:.*noindex'; then
  echo "X-Robots-Tag com noindex na home"; erro=1
fi

# 3. noindex na meta tag e canonical
html=$(curl -s -A "$UA" "$SITE/")
if echo "$html" | grep -Eio '<meta[^>]+name="(robots|googlebot)"[^>]*>' | grep -iq noindex; then
  echo "meta robots com noindex na home"; erro=1
fi
canon=$(echo "$html" | grep -Eio '<link[^>]+rel="canonical"[^>]*>' | grep -Eio 'href="[^"]+"' | head -1)
if [ -n "$canon" ] && ! echo "$canon" | grep -q "$host"; then
  echo "canonical aponta pra outro domínio: $canon"; erro=1
fi

exit $erro

E o workflow que roda o script todo dia às 9h (12h em UTC):

name: Vigia de SEO
on:
  schedule:
    - cron: "0 12 * * *"
  workflow_dispatch:
jobs:
  vigia:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bash scripts/vigia-seo.sh
        env:
          SITE: https://seusite.com.br

Os limites são os de qualquer script caseiro: olha só a home, não acompanha as páginas do sitemap, não compara com o dia anterior e ninguém atualiza quando o site muda. Em repositório público sem atividade, o GitHub desliga os workflows agendados depois de 60 dias, então confira de vez em quando se ele ainda está rodando.

Ferramentas que vigiam e avisam

• Google Search Console (grátis). Obrigatório, mas avisa depois do estrago, como explicado acima.
• Varrida (brasileira, em português). A varredura avulsa é grátis e sem cadastro. No plano grátis, ela olha 1 site por semana e manda e-mail se algo piorar. No Pro, R$ 49 por site por mês, confere a produção todo dia (até 2.000 páginas), cada deploy pela URL de gatilho de qualquer CI e cada PR do GitHub, e avisa por e-mail e Slack. Ela não faz pesquisa de palavra-chave nem backlinks.
• Conductor Monitoring (antigo ContentKing). Monitoramento contínuo com histórico de cada mudança, em inglês, pensado pra empresas grandes e times de SEO.
• Rastreadores com agendamento, como o Screaming Frog na licença paga. Rodam no seu computador no horário marcado, e comparar um rastreamento com o anterior fica com você. Veja Varrida ou Screaming Frog.

Pra conferir cada item à mão, sem cadastro, use as ferramentas grátis da Varrida.

O melhor aviso chega antes do deploy

A maioria dos problemas que tiram páginas do Google entra num deploy. Conferir o site todo dia pega em horas o que o Search Console pegaria em dias. Conferir o pull request antes do merge pega antes de ir pro ar. O passo a passo está em Check de SEO em pull request no GitHub.

Recebeu o aviso. E agora?

1. Descubra o que mudou e quando: o último deploy, uma atualização de plugin, uma troca de hospedagem.
2. Corrija a causa e confira de novo, como o Googlebot: Verificar noindex e Testar robots.txt.
3. No Search Console, use a Inspeção de URL nas páginas mais importantes e peça indexação.
4. Se o tráfego já caiu, siga o guia Meu site sumiu do Google pra checar as outras causas.