Gerador Robots.txt Gratuito

O que é o robots.txt e por que razão é importante?

robots.txt é um ficheiro de texto simples servido a partir da raiz do seu domínio que implementa o Protocolo de Exclusão de Robots (REP). Quando um crawler chega ao seu site, solicita https://yourdomain.com/robots.txt antes de qualquer outro URL e utiliza as regras definidas para decidir quais os caminhos que pode aceder. O protocolo é uma convenção pública, não um padrão imposto, o que significa que bots bem-comportados como o Googlebot, o Bingbot e a maioria das ferramentas de SEO legítimas o respeitam, enquanto scrapers maliciosos podem ignorá-lo por completo.

O ficheiro é um pedido, não uma barreira. Não bloqueia utilizadores humanos, não restringe o acesso ao nível HTTP e não oferece qualquer garantia de segurança. Qualquer pessoa pode aceder ao seu robots.txt diretamente no browser e ler todos os caminhos que listou. Trate-o como um documento público. Se um caminho for sensível, proteja-o com autenticação, não com uma linha Disallow.

O robots.txt também não remove páginas dos resultados de pesquisa. Um URL bloqueado em robots.txt pode ainda aparecer no índice do Google se outros sites criarem links para ele. O Google irá mostrar o URL sem snippet, uma vez que não pode aceder à página para ler o seu conteúdo. Para manter uma página fora do índice por completo, deixe-a crawlável e adicione uma diretiva noindex através de meta tag ou cabeçalho X-Robots-Tag.

A catástrofe de produção mais comum com robots.txt é uma única linha: Disallow: /. Esta bloqueia todos os caminhos do site. É o padrão em muitos ambientes de staging para impedir que os crawlers indexem URLs de desenvolvimento, e acaba por chegar a produção por acidente com mais frequência do que qualquer SEO gostaria de admitir. Em poucas horas, o tráfego orgânico começa a cair à medida que o Google remove páginas do índice. Compare sempre o robots.txt de produção com o de staging antes de cada deploy, e trate o ficheiro como um artefacto versionado em controlo de versões.

Como usar este gerador

O gerador foi concebido para o levar de um ficheiro em branco a um robots.txt validado e pronto para produção em menos de um minuto.

Passo 1 — Escolha uma predefinição de CMS. Selecione a plataforma que corresponde à sua stack: WordPress, Shopify, Next.js, Joomla, ou comece com um template em branco. Cada predefinição carrega o conjunto padrão de regras para essa plataforma, incluindo os diretórios normalmente bloqueados e a localização do sitemap habitualmente utilizada por esse CMS.

Passo 2 — Personalize as regras. Adicione ou remova caminhos Allow e Disallow, agrupe regras por User-agent (use * para todos os crawlers, ou aponte para bots específicos como Googlebot ou Bingbot), e adicione uma diretiva Sitemap apontando para o URL do seu sitemap. Se precisar de limitar um crawler específico, adicione uma linha Crawl-delay, mas tenha em atenção que o Googlebot a ignora.

Passo 3 — Valide contra o seu site em produção. Introduza o seu domínio e o validador obtém o seu /robots.txt existente, analisa ambos os ficheiros e mostra as diferenças. Vê exatamente quais os caminhos que alteram o estado, quais as regras que entram em conflito e se a referência ao sitemap é válida. Só então deve copiar o resultado e fazer o deploy.

O resultado é texto simples, formatado exatamente como o parser do Google espera:

User-agent: *
Disallow: /admin/
Allow: /admin/public/
Sitemap: https://example.com/sitemap.xml

Padrões comuns por CMS

WordPress

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Sitemap: https://example.com/sitemap_index.xml

O diretório wp-admin contém o painel de administração e não deve ser crawlado, mas admin-ajax.php é utilizado por funcionalidades de front-end como pesquisa de tema e submissão de comentários, pelo que é explicitamente permitido. wp-includes contém ficheiros PHP do núcleo que não têm valor para SEO. O caminho do sitemap sitemap_index.xml é o padrão tanto para o Yoast SEO como para o Rank Math, que geram o ficheiro dinamicamente; se usar um plugin de SEO diferente ou um sitemap estático, ajuste o URL.

Shopify

User-agent: *
Disallow: /admin
Disallow: /cart
Disallow: /orders
Disallow: /checkout
Disallow: /search

O Shopify inclui um robots.txt padrão que já bloqueia /admin, /cart, /orders e /checkout para manter páginas transacionais e de conta fora dos resultados de pesquisa. Desde 2021, o Shopify permite substituir o ficheiro criando um template robots.txt.liquid no seu tema. Bloquear /search é opcional mas comum, uma vez que as páginas de resultados de pesquisa produzem conteúdo escasso e quase duplicado que pode diluir o seu orçamento de crawl.

Next.js / Vercel

User-agent: *
Disallow: /api/
Disallow: /_next/
Sitemap: https://example.com/sitemap.xml

No App Router, a abordagem idiomática é gerar o robots.txt programaticamente com app/robots.ts, que exporta um objeto MetadataRoute.Robots. Um ficheiro estático em /public/robots.txt também funciona e tem precedência se ambos existirem. Bloqueie /api/ para manter os route handlers fora da pesquisa e /_next/ para ignorar os artefactos de build. No Vercel, os deploys de pré-visualização ficam expostos em subdomínios únicos; sirva um robots.txt separado com Disallow: / em ambientes de pré-visualização para evitar que sejam indexados.

Joomla

User-agent: *
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /modules/

O Joomla inclui um ficheiro robots.txt.dist padrão que copia para robots.txt no primeiro deploy. As regras padrão bloqueiam o painel de administração, o diretório de cache e as pastas de componentes e módulos do núcleo. Versões mais recentes do Joomla geram sitemaps automaticamente através de extensões como JSitemap ou OSMap, e deve adicionar o URL resultante com uma diretiva Sitemap:.

Erros comuns que prejudicam o SEO

A maior parte dos danos causados pelo robots.txt é autoinfligida. Os padrões abaixo são responsáveis pela maioria dos incidentes de tráfego orgânico que encontramos em auditorias.

Bloquear CSS e JS. O Google renderiza páginas com um motor Chromium real há mais de uma década, o que significa que precisa de aceder às suas folhas de estilo e scripts para entender como a sua página realmente aparece. Bloquear /css/, /js/, ou um diretório de build como /_next/static/ faz com que o Googlebot renderize um layout quebrado. A compatibilidade com dispositivos móveis, o layout shift e a visibilidade do conteúdo degradam-se, e o posicionamento pode cair em conformidade. Permita estes diretórios explicitamente se o seu CMS os bloquear por padrão.

Bloqueios de staging esquecidos. Uma linha Disallow: / em produção é a causa mais comum de perda de tráfego da noite para o dia. Normalmente chega porque um programador copiou uma configuração de staging sem atualizar os valores específicos do ambiente. Use variáveis de ambiente para definir a política de robots, gere o ficheiro no momento do build e faça do robots de staging um artefacto separado que fisicamente não pode ser enviado para produção.

Conflito entre Allow e Disallow. Quando duas regras no mesmo grupo User-agent cobrem o mesmo caminho, o Google usa a regra mais específica pelo comprimento do caminho. Crawlers mais antigos ou simples processam as regras de cima para baixo e ficam com a primeira correspondência. As duas estratégias discordam com frequência suficiente para causar surpresas reais, por isso escreva regras de forma a que o resultado seja o mesmo de qualquer das formas: liste linhas Allow mais específicas primeiro, depois linhas Disallow mais abrangentes.

Bloquear o seu sitemap. Acontece quando um site bloqueia /sitemap/ e o sitemap está efetivamente em /sitemap.xml. A diretiva Disallow: /sitemap/ não corresponde ao ficheiro /sitemap.xml, mas a semelhança é suficiente para que erros de copiar-colar criem correspondências como Disallow: /sitemap. Verifique sempre se o URL do sitemap em produção está acessível depois de fazer o deploy do robots.txt.

Uso indevido do Crawl-delay. O Googlebot ignora o Crawl-delay. O Bingbot respeita-o. Definir Crawl-delay: 30 num site de grande dimensão diz ao Bing para aceder a um URL a cada trinta segundos, o que significa que o Bing consegue crawlar cerca de 2.880 URLs por dia. Para um site com 100.000 URLs, isso representa mais de um mês entre crawls completos, e a frescura do conteúdo diminui. Use a definição de velocidade de crawl do Bing Webmaster Tools se realmente precisar de limitar, e omita o Crawl-delay caso contrário.

Segurança: não confie no robots.txt para proteger informação sensível

O robots.txt é de leitura pública. Qualquer pessoa pode abrir https://yourdomain.com/robots.txt num browser e ver todos os caminhos que listou. Os atacantes sabem disso e acedem regularmente ao robots.txt como passo de reconhecimento, porque o ficheiro muitas vezes aponta diretamente para painéis de administração, ferramentas internas, diretórios de backup e secções em pré-lançamento.

Listar Disallow: /admin/ não esconde o seu painel de administração; anuncia que existe um painel de administração em /admin/. O mesmo se aplica a Disallow: /staging/, Disallow: /old-site/, ou qualquer caminho que preferiria que os atacantes não descobrissem. Se um caminho precisar de se manter privado, coloque-o por detrás de autenticação HTTP, lista de permissões por IP, ou uma camada de autorização real. O servidor web deve devolver 401 ou 403 a pedidos não autenticados, independentemente do que o robots.txt diz.

Quando pretende manter uma página fora do Google mas o próprio URL não é sensível, use a diretiva noindex. Adicione <meta name="robots" content="noindex"> no <head> da página, ou envie um cabeçalho de resposta HTTP X-Robots-Tag: noindex. Os crawlers precisam de conseguir aceder à página para ver a diretiva, por isso deixe o caminho crawlável no robots.txt. A combinação — crawlável mais noindex — mantém o URL fora do índice sem revelar a sua localização a quem lê o robots.txt.