Check de SEO em pull request no GitHub: como pegar o noindex antes do merge

Por que conferir SEO no PR

A maioria dos problemas que tiram um site do Google entra num deploy. O robots.txt do ambiente de teste vai junto pra produção, uma variável de ambiente errada liga o noindex em todas as páginas, um refactor troca o domínio do canonical. Nada disso quebra o build nem os testes, e o site continua abrindo normal.

Quando o problema é pego depois, o custo já existe: dias de tráfego perdido até alguém perceber, e mais dias até o Google rastrear de novo. No PR, o mesmo erro custa um comentário e um commit.

O que deve travar e o que só deve avisar

Um check que fica vermelho por qualquer coisa vira ruído, e o time aprende a ignorar. Separe em dois grupos:

Opção 1: uma GitHub Action que lê o diff

É a mais simples e não depende de preview. A Action olha as linhas que o PR adiciona nos arquivos que controlam a indexação e falha se encontrar um bloqueio novo. Ajuste a lista de arquivos ao seu framework.

name: SEO no PR
on: pull_request
jobs:
  seo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Bloqueios novos de indexação
        run: |
          base=origin/${{ github.base_ref }}
          arquivos='robots.txt public/robots.txt app/robots.ts app/layout.tsx next.config.js vercel.json _headers netlify.toml'
          novas=$(git diff "$base"...HEAD -- $arquivos | grep '^+' | grep -v '^+++' || true)
          if echo "$novas" | grep -Eiq 'noindex|index: *false'; then
            echo "::error::noindex novo neste PR"; exit 1
          fi
          if echo "$novas" | grep -Eiq 'disallow: */ *$'; then
            echo "::error::robots.txt passa a bloquear o site inteiro"; exit 1
          fi

Funciona bem pro caso mais grave. O ponto fraco é que ela só enxerga texto: não sabe se o noindex vale só no preview, não segue a variável de ambiente que liga a tag e não vê o que o servidor manda de verdade no cabeçalho.

Opção 2: Lighthouse CI no preview

Se a Vercel, a Netlify ou a Cloudflare Pages geram um preview por PR, dá pra rodar o Lighthouse CI nele. A auditoria is-crawlable do Lighthouse falha quando a página está bloqueada pra indexação, pela meta tag, pelo cabeçalho ou pelo robots.txt.

{
  "ci": {
    "assert": {
      "assertions": {
        "is-crawlable": "error",
        "canonical": "warn",
        "document-title": "warn",
        "meta-description": "warn",
        "http-status-code": "error"
      }
    }
  }
}

O cuidado aqui é o próprio preview: muita hospedagem manda X-Robots-Tag: noindex em todo preview, de propósito, pra ele não cair no Google. A Vercel faz isso nos domínios de preview. Nesse caso o is-crawlable fica vermelho em todo PR, e você precisa ignorar esse cabeçalho ou comparar com a produção. O Lighthouse também só olha as URLs que você listar, uma a uma.

Opção 3: uma GitHub App que compara com a produção

A terceira opção é instalar uma App que faz o trabalho das duas anteriores e compara o PR com o que já está no ar. É o que o check Varrida / SEO técnico faz:

• Lê primeiro o código do PR. O check abre e fecha em segundos, assim que o PR abre, sem esperar preview.
• Quando o GitHub não entrega o código, varre o preview da Vercel, da Netlify ou da Cloudflare Pages e compara com a produção, então o noindex que todo preview tem não vira alarme falso.
• robots.txt fechando o site e noindex novo deixam o check vermelho. Canonical, robôs de IA e o resto só avisam.
• Comenta no PR só quando algo mexe com o Google. PR limpo fica só com o check verde.
• Arquivos de teste e páginas de conteúdo que só citam uma configuração ficam de fora.

O check faz parte do Pro, R$ 49 por site por mês, junto com a varredura diária da produção. O teste de 7 dias é grátis e sem cartão. Fora do GitHub, qualquer CI pode chamar a URL de gatilho no fim do deploy.

Como fazer o check travar o merge

Um check vermelho, sozinho, só avisa: o botão de merge continua lá. Pra travar, o check precisa ser obrigatório na branch principal:

1. No repositório, abra Settings › Rules › Rulesets (ou Settings › Branches, nas regras clássicas de proteção).
2. Crie uma regra pra branch main.
3. Marque Require status checks to pass e adicione o check pelo nome. Ele só aparece na lista depois de rodar pelo menos uma vez num PR.
4. Salve. A partir daí, o merge fica bloqueado enquanto o check estiver vermelho.

A ressalva importante: pelo GitHub, regras de branch funcionam em repositório público em qualquer plano, mas em repositório privado só com GitHub Pro, Team ou Enterprise. No plano Free com repositório privado, o check aparece e avisa, mas não impede o merge.

Cuidados pra não virar ruído

• noindex de propósito. Login, carrinho, busca interna e páginas de obrigado devem ter noindex. O check precisa olhar se a página estava indexada antes, não só se a palavra apareceu.
• Regra só do preview. Um if (process.env.VERCEL_ENV !== "production") em volta do noindex está certo. Uma Action que só lê texto vai reclamar dele.
• Código de exemplo. Aconteceu com a gente: um artigo deste blog mostrava, num bloco de código, o robots.txt que a Cloudflare escreve pros robôs de IA, e travou o próprio PR. Páginas de conteúdo, Markdown e testes precisam ficar de fora.
• Mensagem clara. O check vermelho tem que dizer qual linha, de qual arquivo, e o que acontece se for pro ar. "SEO falhou" faz o time desligar o check.

Resumo das três opções

Qualquer uma das três é melhor que nenhuma. Se o PR já passou e o site está no ar, confira como ele está agora com a varredura grátis, e veja como ser avisado quando o site sai do Google.