Em que eu estava errado sobre o robots.txt

• Ao tentar bloquear todos os crawlers do site com a configuração do robots.txt, acabei enfrentando efeitos colaterais inesperados
• A prévia de posts no LinkedIn desapareceu, e também houve queda no alcance das publicações
• A causa foi que o robots.txt bloqueava o acesso do LinkedInBot à página, impedindo a coleta das meta tags
• Passei a entender melhor que o Open Graph Protocol tem um papel central na geração de prévias em redes sociais
• Corrigi o problema ao ajustar o robots.txt com permissão parcial e percebi a necessidade de testar bem futuras mudanças de funcionalidade

---

Introdução: configuração do robots.txt e um problema não intencional

• Recentemente, enquanto aprendia sobre a configuração do robots.txt no blog, comecei a pensar sobre a questão dos direitos sobre os dados do meu conteúdo
• Editei o robots.txt para bloquear todos os crawlers no site
• De forma inesperada, isso causou resultados indesejados no site

Problema com a prévia de posts no LinkedIn

• Depois de mudar o robots.txt, ao postar o link do meu blog no LinkedIn, a prévia (miniatura e resumo) não aparecia
• Antes disso, a prévia era exibida normalmente, mas depois da mudança houve uma queda brusca na exibição e no engajamento
• No começo, achei que fosse um problema temporário, mas o fenômeno continuou por mais de 2 semanas
• Ao analisar com o LinkedIn Post Inspector, ficou claro que o robots.txt estava restringindo o acesso do LinkedInBot, impedindo a coleta dos metadados
• Nas plataformas de redes sociais, é essencial solicitar a página e coletar meta tags para gerar a prévia de links

Introdução ao Open Graph Protocol

• O Open Graph Protocol (OGP) é um protocolo padrão criado pelo Facebook para transformar páginas da web em objetos do grafo social
• O OGP define um conjunto mínimo de meta tags obrigatórias
  • og:title: título da publicação
  • og:type: tipo do objeto, por exemplo, "video.movie"
  • og:image: URL da imagem de miniatura
  • og:url: URL canônica do objeto
• Graças a esse protocolo, o conteúdo pode ser resumido de forma eficaz e exibido de maneira atraente em várias plataformas sociais

Solução com permissão parcial no robots.txt

• Para resolver o problema, alterei o robots.txt para permitir apenas o LinkedInBot
• Se você também precisar da prévia em outras plataformas sociais, será necessário permitir cada bot separadamente
• Exemplo da configuração aplicada atualmente:

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

Reflexão e lições aprendidas

• Bloquear todos os crawlers indiscriminadamente pode causar problemas de exposição e apresentação do conteúdo
• Percebi que foi um erro agir sem testes suficientes sobre o efeito da mudança
• Com essa experiência, aprendi mais sobre Open Graph Protocol, LinkedIn Post Inspector e outros padrões e ferramentas úteis da web
• Ao adicionar ou alterar funcionalidades, é necessário entender e validar suficientemente toda a área de impacto
• No início, eu não tinha ligado OGP ao bloqueio via robots.txt, mas essa experiência me fez reconhecer sua importância

[GN⁺]

Opiniões do Hacker News

• Antigamente, o principal objetivo do robots.txt era evitar penalidades de conteúdo duplicado nos mecanismos de busca. Ao operar sites dinâmicos difíceis de gerenciar, a mesma página podia aparecer em várias URLs por causa de parâmetros de consulta e afins, e isso gerava penalização nos buscadores. O robots.txt servia para dizer: "esta é a URL canônica, ignore o resto". Além disso, ajudava crawlers “bem-comportados” a não se perderem rastreando links infinitos. Claro, crawlers “maliciosos” não ligavam para isso, e esses bots eram bloqueados com medidas como bloqueio por IP. Bloquear com base em User-Agent não fazia sentido. É ingênuo acreditar que um bot malicioso vai obedecer direitinho às regras. O cabeçalho DNT (Do Not Track) é parecido: é como pedir a empresas cujo negócio é rastrear que “por favor, não rastreiem”. Ou como a ideia do Evil Bit, da RFC, que seria esperar que um pacote malicioso marcasse no cabeçalho “sou malicioso”

  • Vale lembrar que a proposta do Evil Bit era uma RFC de Primeiro de Abril ver RFC 3514

  • No fim, isso também faz pensar se o robots.txt teria um papel parecido com o sitemap, mas na verdade é o oposto. O robots.txt indica onde o crawler não deve entrar; o sitemap indica o que você quer que seja indexado. Eu não conhecia esse objetivo original de controlar penalidade por conteúdo duplicado, então isso adiciona um novo contexto à forma de pensar sobre controle de SEO

  • O ponto central é que, ao declarar certo comportamento como “proibido”, isso só funciona com alguns agentes honestos ou com casos em que o User-Agent não foi escondido corretamente por acidente. Além disso, quase não funciona, então no fim é uma medida um tanto simbólica

  • Como no caso do cabeçalho DNT, tentativas que parecem inviáveis na prática às vezes recebem críticas, mas a ideia do DNT na verdade buscava ser aplicada junto com mecanismos legais. Mesmo que um bloqueio técnico completo seja difícil, quando alguém comete ilegalidades em larga escala isso pode acabar vindo à tona por denúncia interna

  • Há pessoas que acreditam que, se você definir regras, todo mundo vai segui-las, e às vezes fico pensando se isso vem mesmo de uma diferença cultural

• Em 2003, cheguei a criar meu próprio mecanismo de busca e rastrear a web. Coloquei um endereço principal de e-mail no User-Agent e recebi muitas mensagens de reclamação. Mesmo tendo criado o crawler da forma mais correta e educada possível, senti que as pessoas simplesmente não queriam nada que não fosse o Google. Esse tipo de postura é justamente o que impede o surgimento de concorrentes ao Google. Isso não se limita ao problema das prévias do LinkedIn; também é preciso pensar que a web deve permanecer aberta para diferentes bots e usuários. Claro que crawlers maliciosos precisam ser barrados, mas tratar todos os bots como maliciosos por padrão não é desejável

  • A experiência mais irritante que tive, do ponto de vista de operar um bot de forma correta, foi quando alguém criou um bot malicioso usando o User-Agent do meu bot para atacar, e as reclamações vieram para mim

  • Qualquer um pode querer proteger o próprio bot, mas na prática não é só uma questão do seu bot; o problema é que há como se fossem 9.000 bots iguais por aí consumindo recursos do servidor em excesso. Esses bots não trazem tráfego de referência real

  • Eu também adotei no começo uma abordagem de bloquear tudo, mas depois percebi a interconexão e a complexidade da web. Acho importante ter controle sobre os próprios recursos. Ainda assim, ao decidir permitir ou bloquear o tráfego que você quer, é preciso se perguntar “por quê” e entender o que cada bot faz. Esse processo exige tempo e esforço. Passei a me interessar por robots.txt por causa da prática de empresas de IA de fazer crawling indiscriminado para treinar dados. Quero poder escolher diretamente se permito ou bloqueio. Nem todos os bots respeitam robots.txt, mas muitos respeitam. Uma forma de testar diretamente é pedir, por meio de um modelo com suporte a navegação, que faça scraping de um link específico. No fundo, o que define se um bot é malicioso é mais a forma como a empresa usa os dados e como eu me sinto em relação a isso

  • Quanto ao argumento de que “nem todo bot é malicioso, então não bloqueie tudo”, eu acho que permitir acesso sem base para confiança é uma estratégia arriscada

  • É natural desconfiar de crawlers desconhecidos. A maioria dos crawlers é maliciosa, e não há como saber de antemão quais são bons ou ruins, então faz sentido tratar bots desconhecidos como potencialmente maliciosos por padrão

• Tento evitar opiniões excessivamente críticas, mas me surpreende que o autor deste texto pareça ter percebido as consequências das próprias ações como se fosse algo muito profundo. Histórias de crescimento pessoal têm seu valor, mas este texto parece mais uma confissão de ignorância do que um insight. No fim, dá a impressão de que foi publicado só para chamar atenção

  • O autor não percebeu que o fetcher de prévia da página não era um crawler, e não pensou em bloqueá-lo com robots.txt. Mesmo que não seja algo brilhante, ao menos houve algo novo que ele aprendeu do ponto de vista pessoal. Acho que posts de blog realmente escritos por pessoas ajudam a elevar a qualidade média da web

  • Ele postou aqui (no Hacker News) porque não aparece no Google

  • Para mim também houve partes que trouxeram algo realmente novo. Foi uma oportunidade de aprender mais sobre o Open Graph Protocol e o Robots Exclusion Protocol. Costumo registrar e compartilhar aquilo que aprendo ou considero interessante. Compartilhei porque achei que também poderia interessar a outras pessoas

  • Fico me perguntando como esse texto chegou à front page. Parece uma versão longa demais de algo óbvio: “se você bloquear a água, os bonzinhos vão desviar e os maus vão ignorar”. No fim, é evidente que robots.txt é só um pedido educado de “por favor, não faça isso”, não um firewall

• O problema do robots.txt é que, no fim, ele filtra com base não no objetivo do crawler, mas na “identidade” do crawler. O autor também bloqueou todos os bots para barrar coleta por IA, mas reabriu para crawlers de prévia OpenGraph, como o do LinkedIn. Só que aí surge a pergunta: e se o link for compartilhado no Twitter, no Mastodon ou em outras plataformas? Você teria que permitir manualmente o UA de cada rede social, o que no fim favorece apenas algumas grandes plataformas. Em essência, precisamos de um meio de dizer “bloqueie treinamento de IA, mas permita indexação de busca, prévias, arquivamento etc.”. Para que isso seja realmente aplicável, provavelmente seria necessário um arcabouço legal, embora isso também não seja simples

  • Sempre existiu discussão sobre o propósito fundamental do robots.txt. Na minha visão, originalmente (e ainda hoje), ele era voltado principalmente para crawlers no sentido clássico de seguir links e descobrir coisas novas. Motores de busca são o exemplo típico. Mas quando um usuário solicita diretamente uma URL específica, como num navegador ou numa assinatura iCal, não há obrigação de seguir robots.txt. Já houve casos em que serviços como o Google Calendar não conseguiam assinar algo por causa de bloqueio em robots.txt, e eu considero isso um comportamento incorreto. No caso de prévias de URL, se o usuário solicitou apenas um link, isso se parece mais com um pedido específico do que com crawling. Mas se uma mensagem longa contém vários links, isso já se aproxima de uma forma de crawling. Em resumo, ainda acho ambíguo se a funcionalidade de prévia de URL de redes sociais deveria obedecer ao robots.txt

  • Dados como os do Common Crawl podem ser reutilizados tanto por mecanismos de busca quanto por treinamento de IA e outros usos. Não é fácil separar as finalidades

  • Uma solução seria dividir isso out-of-band em vez de in-band. Se metadados Open Graph fossem fornecidos por um caminho ou cabeçalho separado, seria possível permitir esse caminho (com dados pouco úteis) e rejeitar fortemente o conteúdo principal. Não necessariamente seria preciso um arcabouço legal

  • Gosto da ideia de criar um padrão que permita autorizar ou bloquear por função/finalidade. Mas a questão central seria validar a função e evitar spoofing, e no fim isso também se conecta a questões legais. Na prática, parece que eu teria que voltar a permitir várias plataformas, como prévias de redes sociais, e estou aprendendo bastante ao ponderar cuidadosamente o que permitir e o que bloquear. Ouvir várias opiniões assim tem sido muito útil

• Para o OP: 1) Você pensou só no LinkedIn, mas na prática seu link pode ser compartilhado também em Facebook, Bluesky e outras redes. Também passei pela experiência de que o ai.robots.txt do Facebook pode acabar bloqueando até mesmo o crawler de prévia do FB (exemplo de ai.robots.txt).

2. Sobre ranking no Google e bloqueio por robots.txt: mesmo que bloquear via robots.txt impeça alguma exposição em busca, e existam outras variáveis como links indiretos, em termos gerais permitir crawling direto é muito mais favorável para SEO no Naver/Google. Ao bloquear, miniaturas e descrições deixam de aparecer nos resultados, o que piora a qualidade. Se o tráfego vindo de mecanismos de busca é importante, vale pensar bem antes de fazer um bloqueio total com robots.txt

• Obrigado pelo feedback! 1) Eu também só estava pensando em LinkedIn e HN. Não me ocorreu que outras pessoas poderiam compartilhar links do meu blog em plataformas diversas. Talvez eu precise reconsiderar permitir acesso a várias plataformas. 2) Vendo a tendência dos buscadores de irem cada vez mais para resumos gerados por IA, acho que no futuro o tráfego orgânico direto para o site vai diminuir. Então a queda no tráfego do Google não me incomoda tanto. Posso mudar de ideia depois, mas por enquanto considero que HN e o boca a boca via compartilhamento social devem gerar tráfego mais significativo para o meu blog. Vou pesquisar mais para ver se a decisão que tomei não vai acabar me prejudicando. As diferentes opiniões estão ajudando muito na tomada de decisão

• Há outro efeito colateral que surge quando se confunde “crawling” com “indexação” no robots.txt.
  Para impedir de forma definitiva que uma nova página entre no índice do Google, bloquear via robots.txt pode funcionar.
  Mas, para remover uma página que já foi indexada, adicionar apenas ao robots.txt é um erro. Como o Google não consegue rastrear a página, ele continua mostrando o resultado sem metadados, e como não consegue ver a tag noindex, ela pode permanecer nos resultados por bastante tempo. Só depois o Google acaba removendo totalmente a página, e esse processo pode ser muito frustrante

  • O Google pode descobrir URLs bloqueadas por robots.txt por meio de links externos e coisas do tipo e, nesse caso, mesmo sem conseguir rastrear a página, um registro indexado pode continuar aparecendo nos resultados (veja o aviso: documentação oficial do Google). Para remover totalmente dos resultados de busca, é obrigatório colocar a tag noindex no código; mas se a página estiver bloqueada por robots.txt, essa tag também não poderá ser lida, então é preciso tomar cuidado

  • No meu caso, eu não quero necessariamente que o Google remova do índice. Sou indiferente à indexação; só me preocupo com crawling e scraping. Reconheço que às vezes usei os termos de forma confusa

• Este texto parece ter esticado demais um assunto que poderia ser resolvido em uma ou duas linhas. Dá até aquela sensação de redação escolar inflando volume

  • O problema poderia ter sido explicado em um parágrafo. O objetivo do meu texto era registrar minha experiência, o problema, a pesquisa e a jornada até a solução. Escrevi o mais detalhadamente possível para que até pessoas não técnicas conseguissem acompanhar

• A limitação fundamental do robots.txt é que o problema real não são os bots que o respeitam, mas os que não respeitam. O robots.txt não consegue controlar a maior parte dos bots que hoje geram problemas de tráfego. Quanto mais danoso o bot para o servidor, menos ele se importa com o robots.txt

  • Para capturar esses bots, um “honeypot” pode ser útil. Basta declarar explicitamente no robots.txt o bloqueio do caminho /honeypot e adicionar em index.html um link oculto com display:none: <a href="/honeypot">ban me</a>. Dá para bloquear imediatamente qualquer IP que acesse esse caminho

  • Não entendo por que isso recebeu downvote. Não há base para confiar no quanto empresas como OpenAI e Anthropic realmente respeitam robots.txt. Essas empresas dificultam a detecção ao rotear tráfego por IPs residenciais de ISP e distribuem a responsabilidade evitando rastreamento direto por meio de “anúncios de terceiros” e outros mecanismos

• O que mais me choca é que quase não existem bibliotecas de parsing bem organizadas para interpretar ao mesmo tempo robots.txt e tags meta robots, e decidir qual deve prevalecer em caso de conflito entre permitir e bloquear. O parser de referência oficial do Google é baseado em C++11, o que é um caso incomum, e nas bibliotecas populares de Python ou JS o desenvolvedor acaba tendo que implementar isso por conta própria. No caso de meta robots, então, a informação nem fica no arquivo robots.txt, mas escondida dentro do index.html. O problema é que, mesmo que o autor de um bot queira agir corretamente do ponto de vista ético, a dificuldade de implementação acaba atrapalhando

  • A biblioteca padrão do Python tem o urllib.robotparser (documentação oficial). Já o rel=nofollow tem um propósito totalmente diferente de robots.txt. Esse atributo indica que mecanismos de busca não devem “confiar” naquele link (isto é, não devem transferir valor de link), não significa “não siga este link” (explicação detalhada). A intenção original era evitar que comunidades cheias de spam deixassem links para seus próprios sites indiscriminadamente

  • Desenvolvedores de bots “bem-intencionados” com poucos recursos não costumam bombardear servidores indiscriminadamente, então na prática não sofrem tanto assim por falta de bibliotecas

  • Se alguém realmente quiser criar um bot correto e de boa-fé, também é perfeitamente viável portar uma biblioteca de parser para outra linguagem e publicar isso como open source. Não é nada impossível

• Curiosamente, a Apple aborda esse problema de outro jeito. Quando você compartilha um link no iMessage, é o cliente de quem envia que busca diretamente os dados para montar a prévia. Serviços como o LinkedIn provavelmente fazem scraping do lado do servidor por motivos como combate a spam e phishing, mas sem dúvida é uma abordagem diferente

  • Eu também achei razoável que, ao receber um link numa mensagem, o cliente gerasse a prévia por conta própria. E até esperava que alguém já tivesse apontado isso. Ainda assim, entendo os vários motivos para o servidor fazer o scraping direto: 1) preparar-se para um futuro em que todas as páginas sejam capturadas e aproveitadas; 2) mesmo que a página mude, retorne 404 ou o banco de dados do cliente seja perdido, o servidor ainda pode fornecer informações de prévia previamente extraídas; 3) o cliente não precisa gerar a prévia localmente e pode mostrar uma visão rápida junto da mensagem. No fim, se a prévia for gerada pelo “remetente”, como no iMessage, restam basicamente apenas o “1” e parte do “2”, e continuar tentando do lado do servidor pode ser uma escolha melhor em termos de robustez