Robots.txt: o que é, exemplos e erros que tiram o site do Google

O que é o robots.txt

O robots.txt é um ficheiro de texto que indica aos robôs dos motores de pesquisa quais as áreas de um site que podem ou não rastrear. Fica na raiz do domínio, normalmente em https://exemplo.pt/robots.txt, e permite controlar o acesso dos crawlers a determinados URLs.

Quando o Googlebot, o robô de rastreio do Google, visita um site, consulta as regras do robots.txt para saber que caminhos pode percorrer. Por exemplo, uma empresa pode permitir o rastreio das páginas dos seus serviços e impedir o acesso a determinadas áreas técnicas ou resultados de pesquisa interna.

O ficheiro segue o Robots Exclusion Protocol (REP), um padrão utilizado para comunicar instruções aos robôs. As regras são públicas e os crawlers legítimos tendem a respeitá-las, mas não existe uma garantia de que todos o façam.

A distinção mais importante é entre rastreio e indexação. O robots.txt controla o acesso dos robôs às páginas, mas não determina diretamente se essas páginas aparecem nos resultados de pesquisa. Um URL bloqueado pode continuar a surgir no Google, por exemplo, quando recebe ligações de outros sites.

Por isso, o robots.txt deve ser entendido como uma ferramenta de gestão do rastreio, não como um mecanismo de privacidade ou uma forma garantida de remover páginas do Google. Uma configuração incorreta pode impedir o Googlebot de aceder a conteúdos importantes para a visibilidade orgânica de um site.

Para que serve o robots.txt num site de empresa

Num site empresarial, nem todos os URLs têm o mesmo valor para os motores de pesquisa. As páginas de serviços, produtos e contactos são importantes para atrair potenciais clientes, enquanto filtros, pesquisas internas e algumas áreas técnicas podem gerar endereços que não precisam de ser rastreados.

O robots.txt permite estabelecer prioridades de acesso, indicando aos robôs quais os caminhos que devem evitar. Quando bem configurado, ajuda a reduzir o rastreio desnecessário e a manter os recursos de rastreio mais disponíveis para as páginas relevantes.

Concentrar o rastreio nas páginas que contam

Os motores de pesquisa não rastreiam todos os URLs de um site com a mesma frequência. O Google gere os seus próprios recursos de rastreio, tendo em conta fatores como a capacidade de resposta do servidor e a procura pelos conteúdos.

Num site de empresa com centenas ou milhares de URLs, bloquear caminhos pouco úteis pode ajudar a evitar pedidos repetidos a páginas que não acrescentam valor à pesquisa.

Por exemplo, uma loja online pode ter dezenas de combinações de filtros para ordenar produtos por preço, cor ou tamanho. Se cada combinação gerar um URL diferente, o Googlebot poderá gastar recursos a explorar variações muito semelhantes.

Ao limitar o rastreio dessas combinações, a empresa pode reduzir pedidos desnecessários ao servidor. No entanto, bloquear URLs no robots.txt não garante que o Google passe automaticamente a rastrear mais vezes as páginas importantes.

Em sites pequenos, com poucas dezenas de páginas, os ganhos podem ser mínimos. Nestes casos, uma boa estrutura de navegação, ligações internas claras e um sitemap atualizado costumam ser mais relevantes do que regras de bloqueio extensas.

Afastar áreas internas, filtros e pesquisa interna

O robots.txt também é útil para evitar que os crawlers explorem áreas que não contribuem para os objetivos de visibilidade do negócio.

Entre os caminhos que podem justificar restrições estão:

• Pesquisa interna: URLs gerados quando um visitante pesquisa dentro do site, como /pesquisa?q=limpeza.
• Filtros e ordenações: combinações de parâmetros que produzem versões semelhantes de uma listagem.
• Áreas técnicas: caminhos associados a processos internos que não precisam de ser rastreados, como determinadas páginas de administração.
• Carrinhos e processos de compra: URLs operacionais que não constituem páginas de entrada relevantes para os motores de pesquisa.

O Google recomenda limitar o rastreio de filtros quando estes criam numerosas combinações de URLs sem valor autónomo para a pesquisa.

Contudo, nem todas as páginas internas ou filtradas devem ser bloqueadas. Uma categoria filtrada pode corresponder a uma pesquisa comercial relevante e merecer indexação. Da mesma forma, bloquear uma área de administração no robots.txt não impede o acesso de pessoas não autorizadas.

A decisão deve partir de uma pergunta simples: este URL contém informação que queremos que o Google descubra e apresente aos potenciais clientes?

Se a resposta for negativa, pode fazer sentido restringir o rastreio. Se a página tiver potencial para atrair tráfego qualificado, é preferível avaliar o seu valor antes de criar uma regra que impeça o Googlebot de a visitar.

Como o robô lê o robots.txt antes de rastrear

Antes de aceder aos conteúdos de um site, o Googlebot verifica as regras do robots.txt aplicáveis ao endereço que pretende visitar. Se ainda não tiver uma versão válida em cache, solicita o ficheiro ao servidor.

O Google identifica primeiro o grupo de instruções correspondente ao seu user-agent. Depois, compara o caminho do URL com as regras Allow e Disallow desse grupo para determinar se pode rastreá-lo.

Este processo depende de três fatores: a especificidade das regras, o endereço onde o ficheiro está publicado e a versão que o Google tem guardada. Uma alteração incorreta em qualquer um destes pontos pode produzir resultados diferentes dos esperados.

Que regra ganha quando Allow e Disallow se contradizem

Quando existem instruções contraditórias, o Google não aplica simplesmente a primeira ou a última linha do ficheiro. A regra mais específica, determinada pelo comprimento do caminho correspondente, tem prioridade.

Considere este exemplo:

User-agent: Googlebot
Disallow: /servicos/
Allow: /servicos/limpeza-escritorios/

A primeira regra impede o rastreio dos URLs dentro de /servicos/. A segunda cria uma exceção para /servicos/limpeza-escritorios/, permitindo ao Googlebot aceder a esse caminho e aos seus subcaminhos.

Se duas regras igualmente específicas entrarem em conflito, o Google escolhe a menos restritiva, ou seja, Allow.

Esta lógica é importante quando uma empresa precisa de bloquear uma pasta sem impedir o acesso a determinadas páginas. Uma exceção mal definida pode deixar conteúdos importantes inacessíveis ao Googlebot ou permitir o rastreio de URLs que deveriam estar excluídos.

Um ficheiro por subdomínio, protocolo e porta

O robots.txt só se aplica ao protocolo, ao host e à porta onde está publicado. Isto significa que as regras de um endereço não são automaticamente herdadas por outros endereços do mesmo negócio.

Por exemplo, estes ficheiros têm âmbitos diferentes:

• https://exemplo.pt/robots.txt
• https://blog.exemplo.pt/robots.txt
• http://exemplo.pt/robots.txt

O mesmo princípio aplica-se a portas diferentes, como https://exemplo.pt:8443/robots.txt.

Se uma empresa tiver um site institucional no domínio principal e uma loja online num subdomínio, deve verificar separadamente as regras de rastreio de cada um.

Também é importante distinguir www.exemplo.pt de exemplo.pt. São hosts diferentes, mesmo que apresentem o mesmo site.

O robots.txt deve estar disponível na raiz do endereço que pretende controlar. Colocar o ficheiro numa subpasta não faz com que as suas instruções se apliquem a todo o site.

Quanto tempo o Google demora a ler um ficheiro alterado

Alterar o robots.txt no servidor não significa que o Googlebot passe imediatamente a utilizar as novas regras.

Segundo a documentação oficial do Google, o ficheiro é geralmente guardado em cache durante até 24 horas. Esse período pode variar consoante os cabeçalhos HTTP de cache ou prolongar-se quando existem problemas de acesso ao servidor.

Imagine que uma empresa remove uma regra que bloqueava as páginas dos seus serviços. Embora o novo ficheiro já esteja acessível no navegador, o Google pode continuar temporariamente a respeitar a versão anterior.

Para acelerar a atualização, é possível utilizar a opção de solicitar novo rastreio no relatório de robots.txt do Google Search Console. Contudo, atualizar o ficheiro em cache não garante que todas as páginas afetadas sejam rastreadas ou indexadas de imediato.

Depois de uma alteração importante, convém confirmar que o servidor apresenta a versão correta, verificar o relatório no Search Console e acompanhar os URLs afetados.

Esta precaução torna-se especialmente relevante quando se remove um bloqueio acidental, porque corrigir o robots.txt é apenas o primeiro passo para recuperar o acesso do Google às páginas.

As diretivas do robots.txt, uma a uma

Um ficheiro robots.txt utiliza instruções simples para comunicar aos crawlers que partes de um site podem rastrear. Cada diretiva tem uma função específica, mas nem todas são reconhecidas pelos mesmos motores de pesquisa.

O Google suporta quatro campos principais: User-agent, Disallow, Allow e Sitemap. Também reconhece caracteres especiais para criar regras mais precisas.

User-agent: a que robô se aplica cada grupo

A diretiva User-agent identifica o crawler a que pertencem as instruções seguintes. O asterisco (*) representa todos os robôs que não tenham um grupo mais específico.

User-agent: *
Disallow: /pesquisa/

User-agent: Googlebot
Disallow: /admin/

Neste exemplo, o Googlebot segue o seu grupo específico, que bloqueia /admin/, mas não herda a regra geral relativa a /pesquisa/.

Por isso, ao criar grupos individuais para determinados crawlers, é importante repetir as restrições que também devem aplicar-se a esses robôs.

Disallow: o que o robô não deve rastrear

A diretiva Disallow identifica caminhos que o crawler não deve visitar.

User-agent: *
Disallow: /pesquisa/

Esta regra impede o rastreio da pasta /pesquisa/ e dos respetivos subcaminhos pelos robôs que a respeitem.

Existe uma diferença importante entre Disallow: /, que bloqueia o rastreio de todo o site, e Disallow: sem valor, que não impõe qualquer bloqueio.

Allow: a exceção dentro de uma pasta bloqueada

A diretiva Allow permite abrir exceções em caminhos abrangidos por uma restrição mais geral.

User-agent: *
Disallow: /recursos/
Allow: /recursos/publicos/

Assim, os robôs ficam impedidos de rastrear a generalidade da pasta /recursos/, mas podem visitar /recursos/publicos/.

A exceção deve ser suficientemente específica para corresponder apenas aos URLs pretendidos.

Sitemap: onde está o mapa do site

A diretiva Sitemap indica o endereço do ficheiro XML que contém os URLs que o site pretende dar a conhecer aos motores de pesquisa.

Sitemap: https://exemplo.pt/sitemap.xml

Ao contrário das regras de rastreio, esta diretiva utiliza um URL completo, incluindo protocolo e domínio.

É possível indicar vários sitemaps no mesmo robots.txt. A sua inclusão facilita a descoberta do mapa do site, mas não garante a indexação das páginas apresentadas.

Asterisco e cifrão: os caracteres especiais que o Google aceita

O Google reconhece dois caracteres especiais nos caminhos das regras:

• * corresponde a zero ou mais caracteres.
• $ assinala o final do URL.

Por exemplo:

User-agent: *
Disallow: /*.pdf$
Disallow: /*?*ordenar=

A primeira regra bloqueia URLs terminados em .pdf. A segunda corresponde a URLs que contenham ? seguido, eventualmente, de outros caracteres e de ordenar=.

Estes padrões permitem controlar grupos de URLs sem escrever uma regra para cada endereço. Contudo, devem ser testados com atenção, porque podem abranger mais páginas do que o previsto.

Crawl-delay e noindex: o que o Google ignora

Alguns ficheiros robots.txt incluem diretivas que o Google não reconhece.

A instrução Crawl-delay, por exemplo, pretende estabelecer um intervalo entre pedidos de rastreio. Embora seja suportada por alguns crawlers, o Googlebot ignora esta diretiva.

A instrução Noindex também não é suportada pelo Google dentro do robots.txt. Para impedir que uma página seja indexada, deve utilizar-se uma meta tag noindex ou um cabeçalho HTTP X-Robots-Tag, conforme o tipo de recurso.

Nestes casos, o Google precisa de conseguir rastrear o URL para identificar a instrução de não indexação.

A regra prática é simples: use o robots.txt para controlar o rastreio e mecanismos próprios de indexação para controlar a presença nos resultados de pesquisa. Confundir estas funções pode deixar URLs indesejados visíveis no Google ou impedir que o motor de pesquisa leia as instruções necessárias para os remover.

Exemplos de robots.txt para os casos mais comuns

Não existe um robots.txt ideal para todos os sites. As regras dependem da estrutura dos URLs, da plataforma utilizada e dos conteúdos que a empresa pretende disponibilizar aos motores de pesquisa.

Um site institucional com cinco páginas pode precisar apenas de um ficheiro simples. Já uma loja online, com filtros, áreas de cliente e milhares de produtos, pode beneficiar de instruções mais específicas.

A tabela seguinte apresenta exemplos de robots.txt para diferentes situações.

Os exemplos são ilustrativos e devem ser adaptados aos caminhos reais de cada site. Uma regra que funciona corretamente numa plataforma pode bloquear páginas importantes noutra.

Em particular, Disallow: / deve ser utilizado com extrema cautela. Pode fazer sentido num ambiente de testes, mas não deve ser publicado num site que pretende receber tráfego orgânico.

Um robots.txt de site empresarial, linha a linha

Considere uma empresa que apresenta serviços de criação de sites, CRM e automação, além de conteúdos informativos no seu website.

É um exemplo útil para perceber como um site empresarial pode organizar as suas regras de rastreio.

O bloco seguinte é um exemplo ilustrativo para um site com esta estrutura.

# Regras gerais para os crawlers
User-agent: *
# Bloquear a pesquisa interna, caso exista
Disallow: /pesquisa/
# Bloquear uma área técnica, caso exista
Disallow: /admin/

# Indicar o sitemap XML
Sitemap: https://www.exemplo.pt/sitemap.xml

O significado de cada linha é simples:

• User-agent: * aplica o grupo de regras aos crawlers que não tenham instruções mais específicas.
• Disallow: /pesquisa/ impede o rastreio de URLs dentro dessa pasta, caso seja utilizada para resultados de pesquisa interna.
• Disallow: /admin/ restringe o rastreio desse caminho, sem substituir mecanismos de autenticação e segurança.
• Sitemap: comunica aos robôs onde procurar o mapa XML do site. O endereço apresentado deve ser confirmado antes da publicação.

As linhas iniciadas por # são comentários. Servem para documentar a configuração e são ignoradas pelos crawlers.

Neste exemplo, as páginas de serviços, os artigos do blog e os restantes URLs públicos não são bloqueados pelas regras apresentadas. Isto permite que os motores de pesquisa continuem a descobrir conteúdos relevantes para potenciais clientes, desde que não existam outras restrições.

O ponto essencial é que o robots.txt deve refletir a estrutura real do website, e não um modelo copiado de outro projeto. Antes de publicar qualquer regra, é necessário verificar se os caminhos existem, que páginas abrangem e se o Google precisa de lhes aceder.

Robots.txt ou noindex: qual usar para tirar uma página do Google

Quando uma empresa pretende impedir que determinada página apareça nos resultados de pesquisa, bloquear o URL no robots.txt pode parecer a solução mais simples. No entanto, impedir o rastreio não é o mesmo que impedir a indexação.

O robots.txt controla o acesso dos crawlers. A diretiva noindex, por sua vez, indica aos motores de pesquisa que não devem apresentar a página nos resultados.

A escolha depende do objetivo. Se pretende reduzir pedidos dos robôs a determinados caminhos, utilize o robots.txt. Se pretende manter uma página acessível aos visitantes, mas fora do Google, utilize noindex.

Uma página bloqueada pode aparecer no Google na mesma

Imagine que uma empresa publica uma página com uma campanha exclusiva e adiciona a seguinte regra:

User-agent: Googlebot
Disallow: /campanha-exclusiva/

O Googlebot deixa de poder rastrear esse caminho. Contudo, se encontrar uma ligação para a página noutro website, poderá descobrir o URL e apresentá-lo nos resultados, mesmo sem conhecer o respetivo conteúdo.

É por isso que alguns resultados de pesquisa podem apresentar um endereço sem uma descrição normal da página.

Para evitar essa situação, deve permitir-se o rastreio e incluir a seguinte meta tag no elemento <head> do HTML:

<meta name="robots" content="noindex">

Quando o Googlebot voltar a visitar a página e processar a instrução, poderá removê-la dos resultados de pesquisa.

Atenção: não combine Disallow e noindex no mesmo URL quando pretende garantir a sua remoção. Se o robots.txt impedir o rastreio, o Google não conseguirá ler a meta tag.

Como tirar as landing pages do Google sem as bloquear

Num site empresarial, uma landing page pode servir para campanhas de publicidade, formulários de contacto ou ofertas dirigidas a públicos específicos.

Estas páginas precisam de continuar acessíveis às pessoas que chegam através dos anúncios ou de ligações diretas, mas nem sempre faz sentido apresentá-las na pesquisa orgânica.

O procedimento adequado para este cenário consiste em manter o acesso do Googlebot à landing page e aplicar a diretiva noindex.

Por exemplo, numa página de campanha em /lp/campanha-crm/, a configuração seria:

1. Confirmar que o robots.txt não bloqueia o caminho /lp/campanha-crm/.
2. Inserir <meta name="robots" content="noindex"> no HTML da landing page.
3. Verificar no Google Search Console se o Googlebot consegue aceder à página e identificar a diretiva.
4. Acompanhar o estado da indexação até a página deixar de aparecer nos resultados.

Este método permite manter a landing page funcional para os visitantes e para as campanhas, sem a disponibilizar como resultado de pesquisa após o Google processar a instrução.

Se a página já estiver indexada e for necessário retirá-la rapidamente dos resultados, a ferramenta de remoções do Search Console pode ser utilizada para solicitar uma ocultação temporária, enquanto o noindex assegura a exclusão após o novo rastreio.

A diferença fundamental está no acesso: o robots.txt diz ao Google que não deve entrar; o noindex permite que entre para perceber que não deve mostrar a página.

Erros no robots.txt que tiram o site do Google

Um pequeno erro no robots.txt pode impedir o Googlebot de aceder a páginas importantes, mesmo quando o site continua a funcionar normalmente para os visitantes.

O problema é que estas falhas nem sempre são visíveis. O site abre no navegador, os formulários funcionam e os conteúdos continuam publicados, mas o Google pode deixar de rastrear determinadas áreas.

Conhecer os erros mais comuns ajuda a evitar perdas de visibilidade orgânica e a identificar problemas antes de afetarem o negócio.

Publicar o bloqueio total do ambiente de testes

Durante o desenvolvimento de um website, é comum utilizar um robots.txt que impede o rastreio de todas as páginas:

User-agent: *
Disallow: /

O problema surge quando este ficheiro é transferido para o domínio de produção e permanece ativo após o lançamento.

A instrução Disallow: / bloqueia o rastreio de todo o site. Isto não significa que todas as páginas desapareçam imediatamente do Google, mas pode impedir a descoberta de novos conteúdos e a atualização dos existentes.

Antes de publicar um website, é fundamental confirmar que esta regra foi removida. Para proteger ambientes de testes, a autenticação é mais segura do que depender exclusivamente do robots.txt.

Bloquear o CSS e o JavaScript de que a página precisa

Algumas configurações antigas bloqueiam pastas inteiras de recursos técnicos, como /css/, /js/ ou /assets/.

Embora pareçam ficheiros secundários, o CSS e o JavaScript podem ser essenciais para o Google compreender a estrutura, a apresentação e os conteúdos de uma página.

Se o Googlebot não conseguir carregar scripts responsáveis por apresentar serviços, produtos ou ligações internas, poderá não interpretar corretamente esses elementos.

A recomendação é permitir o acesso aos recursos necessários para a renderização e utilizar a ferramenta de Inspeção de URL do Google Search Console para verificar como o Google vê a página.

Usar o robots.txt para esconder áreas privadas

Outra falha frequente é utilizar Disallow como se fosse uma medida de segurança.

Por exemplo, bloquear /clientes/ não impede que uma pessoa visite esse endereço. Além disso, o robots.txt é público e pode revelar a localização de pastas que a empresa pretendia manter reservadas.

Áreas com dados de clientes, documentos confidenciais ou informação interna devem estar protegidas por autenticação e permissões de acesso adequadas.

O robots.txt controla o comportamento dos crawlers cooperantes, não o acesso de utilizadores ao servidor.

Um robots.txt que responde com erro do servidor

Mesmo um ficheiro com regras corretas pode causar problemas se o servidor não conseguir disponibilizá-lo.

O Google interpreta os códigos de resposta HTTP de formas diferentes:

Perante erros 5xx, o Google suspende inicialmente o rastreio durante 12 horas, enquanto tenta recuperar o ficheiro. Se a falha persistir, pode recorrer à última versão válida guardada em cache, seguindo as regras específicas de recuperação.

Por isso, um erro 500 no robots.txt não deve ser tratado como um simples problema técnico sem consequências para o SEO.

Editar um ficheiro que o servidor não publica

Existe ainda uma situação particularmente enganadora: o responsável pelo site altera o robots.txt, guarda as modificações e assume que as novas regras já estão ativas.

Contudo, algumas plataformas geram o ficheiro automaticamente, enquanto outras utilizam regras de servidor, plugins ou sistemas de cache que podem apresentar uma versão diferente da editada.

Neste cenário, o Googlebot seguirá as regras efetivamente disponibilizadas pelo servidor, não as que aparecem guardadas no editor.

A verificação deve ser feita diretamente no URL público do robots.txt, de preferência também através do relatório correspondente no Search Console.

O princípio é simples: não basta editar o ficheiro; é necessário confirmar que a versão publicada contém exatamente as regras pretendidas. Esta verificação pode evitar que um erro aparentemente corrigido continue a limitar o rastreio durante dias.

Robots.txt e crawlers de IA: GPTBot, ClaudeBot e Google-Extended

O robots.txt já não serve apenas para gerir o rastreio dos motores de pesquisa tradicionais. Também permite definir regras para alguns crawlers de inteligência artificial que recolhem conteúdos públicos para treinar modelos, melhorar pesquisas ou responder a perguntas dos utilizadores.

Para uma empresa, esta distinção é importante. Bloquear um robô associado ao treino de IA não tem necessariamente o mesmo efeito que bloquear um robô responsável por descobrir conteúdos para respostas de pesquisa.

Que robôs de IA leem o robots.txt

A OpenAI, a Anthropic e a Google disponibilizam identificadores específicos para diferentes utilizações dos conteúdos encontrados na web.

As empresas distinguem estas funções nas respetivas documentações. Importa notar que Google-Extended é um identificador de controlo, não um crawler com user-agent HTTP próprio. Além disso, pedidos iniciados por utilizadores, como os do ChatGPT-User, podem não estar sujeitos às mesmas regras de rastreio automático.

Bloquear o treino de modelos sem sair da Pesquisa Google

Uma empresa pode querer que os seus artigos e páginas de serviços continuem acessíveis aos motores de pesquisa, mas não permitir que determinados crawlers os recolham para treino de IA.

Para comunicar essa preferência, pode configurar o robots.txt da seguinte forma:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Estas regras bloqueiam o rastreio pelo GPTBot e pelo ClaudeBot e comunicam à Google a preferência de não utilizar os conteúdos para os fins abrangidos pelo Google-Extended.

Bloquear o Google-Extended não impede que o website continue a aparecer na Pesquisa Google, nem constitui um fator de classificação. No entanto, o controlo também abrange determinadas funcionalidades de fundamentação de respostas do Gemini, não apenas o treino.

Da mesma forma, bloquear o GPTBot não implica bloquear o OAI-SearchBot. Os dois identificadores têm funções distintas.

Estas regras aplicam-se ao comportamento dos serviços que as respeitam. Não removem automaticamente conteúdos já recolhidos nem impedem todas as formas possíveis de acesso ou utilização por sistemas de IA.

Deixar entrar ou bloquear: o critério para uma empresa

A decisão deve considerar os objetivos comerciais do website e a forma como a empresa pretende disponibilizar os seus conteúdos.

Para um site empresarial que depende da descoberta de serviços e da captação de contactos, pode fazer sentido preservar o acesso dos crawlers de pesquisa e avaliar separadamente os destinados ao treino.

Por outro lado, empresas que publicam conteúdos próprios de elevado valor podem preferir restringir determinados usos, mesmo sabendo que isso não garante proteção contra todas as formas de reutilização.

Não existe uma configuração universalmente correta para os crawlers de IA. A melhor escolha é aquela que distingue visibilidade, treino e acesso por utilizadores, sem bloquear inadvertidamente os canais através dos quais potenciais clientes podem descobrir a empresa.

Como criar, publicar e testar o robots.txt

Criar um robots.txt não exige conhecimentos avançados de programação. O essencial é definir corretamente as regras, publicar o ficheiro no local certo e confirmar que os motores de pesquisa conseguem interpretá-lo.

Antes de alterar um ficheiro existente, convém guardar uma cópia da configuração atual. Assim, se uma nova regra bloquear páginas importantes, será mais fácil recuperar a versão anterior.

Checklist antes de publicar

• Confirmei quais os URLs que devem ser rastreados e bloqueados.
• Verifiquei que não existe um bloqueio total acidental (Disallow: /).
• Mantive acessíveis os recursos CSS e JavaScript necessários.
• Confirmei os grupos User-agent e as exceções Allow.
• Verifiquei a localização e a resposta HTTP do ficheiro.
• Testei URLs importantes e caminhos que pretendo bloquear.

Criar o ficheiro e publicá-lo na raiz do domínio

O robots.txt é um ficheiro de texto simples, guardado com o nome exato robots.txt, sem extensões adicionais como .doc ou .html.

Pode ser criado num editor de texto e começar com uma configuração básica:

User-agent: *
Disallow:

Sitemap: https://exemplo.pt/sitemap.xml

Este exemplo não impõe restrições ao rastreio e indica a localização do sitemap. O endereço apresentado deve ser substituído pelo URL real do mapa do site, caso exista.

Depois, é necessário colocar o ficheiro na raiz do domínio, de modo que fique acessível em https://exemplo.pt/robots.txt.

A publicação pode ser feita através do gestor de ficheiros do alojamento, de FTP ou do processo de implementação utilizado pelo website. O servidor deve disponibilizá-lo como texto simples, preferencialmente com o tipo de conteúdo text/plain.

Nas plataformas que geram o ficheiro sozinhas

Nem todos os websites permitem editar diretamente um ficheiro robots.txt físico.

No WordPress, por exemplo, pode existir um robots.txt virtual gerado pela plataforma. Alguns plugins de SEO permitem personalizar as regras, dependendo da configuração do alojamento.

Noutras plataformas, como Shopify ou Wix, existem mecanismos próprios para gerir o rastreio, com diferentes níveis de personalização.

Antes de criar ou substituir o ficheiro, é importante verificar como a plataforma o disponibiliza. Duas configurações diferentes não devem ser tratadas como se ambas estivessem ativas. O que conta é a resposta apresentada no URL público.

Em plataformas com cache ou redes de distribuição de conteúdos, também pode ser necessário confirmar que a versão atualizada já está a ser servida.

Testar no Search Console: relatório robots.txt e Inspeção de URL

Depois de publicar, o Google Search Console permite verificar se o Google consegue aceder ao ficheiro e se determinadas páginas estão bloqueadas.

No Relatório robots.txt, é possível consultar a última versão obtida pelo Google, a data de verificação e eventuais erros de processamento. O relatório também permite solicitar uma nova leitura em situações importantes, como a correção de um bloqueio acidental.

Para verificar uma página específica, utilize a ferramenta de Inspeção de URL:

1. Introduza o URL completo no Search Console.
2. Consulte a informação sobre a permissão de rastreio.
3. Utilize Testar URL publicado para verificar a situação atual.
4. Confirme se o acesso está permitido ou bloqueado conforme pretendido.

A Inspeção de URL distingue problemas de rastreio de problemas de indexação. Uma página pode estar acessível ao Googlebot e, ainda assim, não ser indexada por outros motivos.

O teste deve incluir pelo menos uma página importante, uma área deliberadamente bloqueada e qualquer URL afetado pelas alterações.

Desta forma, a publicação do robots.txt deixa de depender de suposições. A empresa consegue verificar se as regras estão realmente ativas e se continuam a permitir o acesso aos conteúdos essenciais para a sua presença no Google.

Perguntas frequentes sobre robôs, rastreio e indexação

Um site precisa de ter robots.txt?

Não. O robots.txt não é obrigatório para um website funcionar ou aparecer nos resultados do Google.

Se o ficheiro não existir e o servidor devolver uma resposta 404, o Google assume que não existem restrições de rastreio e pode visitar os URLs que descobrir.

Para um site empresarial pequeno, sem áreas que precisem de restrições, pode ser suficiente permitir o rastreio de todas as páginas.

Ainda assim, manter um robots.txt simples pode facilitar a gestão futura, sobretudo quando são adicionados novos serviços, funcionalidades ou secções ao website.

O robots.txt melhora a posição no Google?

Não diretamente. O robots.txt não é um fator de classificação e adicionar regras ao ficheiro não faz com que as páginas subam automaticamente nos resultados de pesquisa.

O seu contributo para o SEO está na gestão do rastreio. Em websites com muitos URLs desnecessários, pode ajudar a reduzir pedidos dos crawlers e evitar o desperdício de recursos do servidor.

Contudo, bloquear conteúdos importantes pode prejudicar a descoberta e atualização dessas páginas pelo Google.

O objetivo deve ser facilitar o acesso aos conteúdos relevantes, não tentar melhorar as classificações através de bloqueios.

O robots.txt também bloqueia imagens, vídeos e PDF?

Sim. O Google respeita as regras do robots.txt aplicáveis a diferentes tipos de recursos, incluindo imagens, vídeos e ficheiros PDF.

Por exemplo:

User-agent: Googlebot

Disallow: /documentos/

Esta regra impede o Googlebot de rastrear os ficheiros localizados em /documentos/, incluindo PDF. Outros crawlers específicos podem ter regras próprias.

No entanto, bloquear o rastreio de um ficheiro não garante que o respetivo URL desapareça dos resultados de pesquisa.

Se a intenção for impedir a indexação de um PDF, uma alternativa é utilizar o cabeçalho HTTP X-Robots-Tag: noindex, mantendo o recurso acessível ao crawler para que consiga ler essa instrução.

É possível esconder só uma parte de uma página?

Não através do robots.txt. As regras deste ficheiro aplicam-se a URLs ou caminhos completos, não a parágrafos, imagens ou elementos específicos dentro de uma página HTML.

Se uma empresa quiser manter uma página indexada, mas evitar que determinado texto apareça nos excertos dos resultados do Google, pode utilizar o atributo HTML data-nosnippet.

Por exemplo:

<p data-nosnippet>Informação que não deve aparecer no excerto.</p>

Esta solução não impede o Google de rastrear ou indexar a página. Apenas restringe a apresentação do conteúdo assinalado nos excertos suportados.

Para proteger informação confidencial, é necessário recorrer a mecanismos de controlo de acesso, e não a instruções de rastreio.

O robots.txt distingue maiúsculas de minúsculas?

Sim. Os caminhos e os nomes dos ficheiros nos URLs são sensíveis a maiúsculas e minúsculas.

Por exemplo, a regra:

Disallow: /Privado/

Não bloqueia necessariamente o caminho /privado/, porque o Google interpreta os dois endereços como diferentes.

O nome do próprio ficheiro também deve ser escrito exatamente como robots.txt, em minúsculas.

Esta diferença merece atenção quando um website utiliza URLs com letras maiúsculas, especialmente após migrações ou alterações na estrutura dos endereços.

Para evitar bloqueios inesperados, é recomendável manter os URLs consistentes e testar as regras com os caminhos exatos que o servidor disponibiliza.