Guias de robots.txt

Robots.txt em staging: como mantemos testes fora da busca

Nosso modelo para staging: autenticação primeiro, noindex em preview público e robots.txt como camada secundária de crawling.

Por Robots.txt Tools Editorial TeamÚltima verificação em 2026-10-012 min de leitura

Método editorial: este guia documenta o processo de revisão da equipe editorial do Robots.txt Tools. A linguagem procedural em primeira pessoa descreve esse método; não representa alegação de trabalho para clientes ou casos pessoais.

Robots.txt em staging: como mantemos testes fora da busca

Em staging nossa primeira camada é acesso, não robots.txt.

Usamos autenticação para conteúdo privado

Password, autenticação ou rede restrita protegem o ambiente. Disallow: / não é segurança.

Preview público pode precisar de noindex

Se a URL precisa abrir para revisão, mas não deve aparecer na busca, usamos noindex mantendo o crawler capaz de ler a diretiva.

Robots.txt é secundário

User-agent: *
Disallow: /

Pode reduzir crawling, mas não substitui proteção ou noindex.

Separamos staging e produção

Conferimos ambos os hosts, removemos sitemap de staging e garantimos que Disallow: / não seja promovido para produção.

Nosso gate de release

Testamos produção com o tester e abrimos o arquivo real no checker. A divisão correta é acesso → autenticação; indexação → noindex; crawl → robots.txt.

O controle depende do tipo de ambiente

Staging interno ou revisão de cliente usa autenticação ou restrição de rede. Preview público que precisa continuar acessível, mas não aparecer na busca, pode usar noindex mantendo o crawl. robots.txt fica como camada secundária, não como segurança.

O risco mais sério é um Disallow: / de staging chegar ao domínio de produção. Por isso a política de produção é explícita e validada como gate de release.

Também aposentamos previews antigos

Depois do lançamento, removemos acesso público de previews sem uso ou mantemos autenticação. Se um staging já entrou no índice, apenas adicionar Disallow: / não é um processo de remoção. Avaliamos se o host deve exigir login, retornar um status HTTP apropriado ou permanecer crawlable tempo suficiente para que noindex seja processado.

Checklist operacional de release

Antes de promover uma build, nós também confirmamos que links internos, sitemap, canonical e variáveis de ambiente não apontam para o host de staging. Depois do deploy, abrimos uma amostra de páginas públicas e verificamos a diretiva de indexação no HTML ou header. Esse passo reduz o risco de uma preview protegida corretamente coexistir com referências públicas que continuam levando crawlers ao ambiente errado.

Guias relacionados