Um profissional de SEO postou no Reddit, no fim de julho de 2026, um caso que ilustra bem um detalhe técnico do robots.txt que costuma passar despercebido. A loja Shopify de um cliente estava recebendo spam na busca interna do site, com termos de nicho suspeito sendo injetados na URL de pesquisa, e mesmo depois de adicionar uma regra de disallow bloqueando o diretório /search, o Google seguia indexando essas páginas geradas pelos spammers.
John Mueller, do Google, entrou na conversa e identificou um detalhe que pode passar despercebido em auditorias técnicas: o robots.txt do site tinha uma seção separada só para user-agent: Googlebot, além da seção genérica user-agent: *. E, quando isso acontece, o Googlebot ignora completamente a seção geral.
Se a regra de bloqueio da busca interna só existia lá, ela nunca chegou a valer para o rastreador do Google. Vale conferir se o seu próprio robots.txt não está com esse mesmo problema entre os blocos.
O caso do robots.txt investigado por John Mueller no Reddit
A pergunta original, feita por quem cuidava da conta Shopify, nem era sobre o problema real. A pessoa queria saber se devia trocar o redirecionamento das URLs de spam por uma página 404, sem perceber que o problema de fundo era outro: aquelas páginas continuavam aparecendo no Google mesmo com o disallow: /search configurado.
Mueller foi além da pergunta feita e revisou o arquivo robots.txt do domínio. Encontrou uma seção com comentários indicando um bloco de “regras customizadas” endereçado especificamente a user-agent: Googlebot, separada de um bloco maior de regras genéricas em user-agent: *, logo mais abaixo no arquivo. Foi aí que identificou a causa raiz do problema de indexação.
Por que o Google ignorou a regra geral do robots.txt
A explicação de Mueller reforça algo que já está documentado oficialmente no Google Search Central, mas que continua pegando gente de surpresa em auditorias técnicas mesmo depois de anos de robots.txt sendo, digamos, um arquivo relativamente simples de se configurar.
A regra de especificidade que decide qual bloco o Google obedece
Segundo Mueller, “com robots.txt, as regras mais específicas vencem, então se você tem uma seção user-agent: Googlebot, ela vai usar só essa seção. Se você quer aplicar todas as regras da seção user-agent: *, precisa copiá-las.” Ou seja, o Googlebot não soma as duas seções, ele escolhe uma e ignora a outra por completo.
A própria documentação oficial do Google confirma esse comportamento: o rastreador identifica, entre todos os grupos do arquivo, aquele com o user-agent mais específico que corresponde a ele, e segue só as regras desse grupo. Os demais grupos, incluindo o genérico, são simplesmente descartados para aquele rastreador específico.
Na prática, isso significa que ter uma seção nomeada Googlebot no meio de um robots.txt cheio de plugins e customizações herdadas de temas ou apps de terceiro aumenta o risco desse tipo de configuração equivocada, sobretudo quando ninguém revisita esse bloco depois que ele foi criado.
Vale separar as duas camadas do problema nesse caso específico. A primeira é que a regra de bloqueio simplesmente não chegava a valer para o Googlebot, por estar isolada na seção genérica. A segunda, ainda mais importante para quem generaliza esse aprendizado para outros sites, é que mesmo se a regra estivesse na seção certa, um disallow sozinho não garante que a URL saia do índice, porque ele controla rastreamento, não indexação.
Como corrigir e evitar esse erro no seu próprio robots.txt
Mueller já deixou uma solução pronta na própria resposta: se o objetivo é aplicar as mesmas regras para vários rastreadores, o caminho mais direto é listar todos os user-agents relevantes dentro do mesmo grupo, em vez de espalhá-los em blocos separados.
Vale registrar que essa é a sugestão de Mueller pra esse caso específico, não a única forma tecnicamente correta: a especificação do Google também aceita manter grupos separados por user-agent, desde que as mesmas regras sejam repetidas em cada um deles. O problema nunca foi ter seções separadas, foi esperar que uma seção “herdasse” regras de outra, o que a especificação nunca previu. Algo como:
user-agent: googlebot
user-agent: otherbot
disallow: /search
disallow: /orange-cats
Isso elimina o risco de uma regra genérica ficar esquecida numa seção que o Googlebot nunca vai ler. Na revisão técnica de qualquer site, principalmente os que rodam sobre CMS ou plataforma de e-commerce com módulos de terceiro mexendo no robots.txt (Shopify, WordPress, Wix), vale abrir o arquivo e procurar, literalmente, quantas vezes a palavra “Googlebot” aparece separada da seção com asterisco.
Outro ponto que ajuda bastante aqui é apostar em rastreabilidade técnica sólida desde a estrutura do site, para que esse tipo de bloco de regras não precise crescer de forma improvisada conforme surgem novos problemas de spam ou rastreamento indesejado.
O robots.txt controla rastreamento, não indexação
Esse é o outro ponto que Mueller reforçou no mesmo fio, e que também apareceu na cobertura do Search Engine Journal sobre o caso: o robots.txt nunca foi feito para impedir indexação, só rastreamento. Bloquear uma URL com disallow impede o Googlebot de visitar aquela página, mas se outras páginas linkam pra ela com texto âncora descritivo, o Google ainda pode indexar a URL sem nunca ter aberto o conteúdo, só sem gerar um snippet de descrição na SERP.
Pra quem quer de fato impedir que uma página apareça nos resultados de busca, a diretiva correta é o noindex, seja via meta tag ou via header HTTP, e não o disallow no robots.txt. O próprio Shopify tem um tutorial oficial ensinando a inserir esse noindex direto no arquivo theme.liquid da loja, cobrindo justamente o template de busca interna. No WordPress, quem já usa Yoast, Rank Math ou AIOSEO nem precisa se preocupar com isso, porque essas ferramentas já colocam a página de busca interna em noindex por padrão.
Vale lembrar que confiar cegamente numa diretiva que parece controlar um comportamento, mas na prática não tem o efeito esperado, não é exclusividade do robots.txt. Já vimos aqui como uma diretiva parecida, o Content Signals da Cloudflare, também não gera o efeito que boa parte do mercado assumia que ela teria sobre o rastreamento de bots de IA.
Como esse caso de robots.txt muda a rotina de auditoria técnica de SEO
Esse erro passa despercebido justamente porque o disallow parece certo no papel. Ninguém questiona se aquela regra está mesmo valendo pro rastreador certo, até o spam continuar aparecendo na SERP.
A lição prática tem duas partes. Primeiro, todo robots.txt com seção nomeada por user-agent precisa ser lido bloco por bloco, nunca como um conjunto único de regras.
Segundo, disallow e noindex resolvem problemas diferentes. Tratar um como substituto do outro foi exatamente o que gerou o caso investigado por Mueller.
A documentação oficial do Google já explica esse comportamento há anos, de graça, mas configurações reais continuam ignorando esse detalhe. Falta reler a especificação de um arquivo que parece simples demais pra dar errado.
Manter essa checagem em dia evita repetir o mesmo erro na próxima vez que alguém mexer no robots.txt, seja por um plugin novo ou uma troca de tema.
É esse tipo de detalhe que a EducaSEO ajuda você a enxergar antes que vire problema. A gente acompanha de perto casos reais como esse, semana a semana, com leitura aplicada sobre rastreamento, indexação e visibilidade em busca, inclusive na era da IA generativa. Vem com a gente.
Referências
- Search Engine Journal. Google Says Why It May Ignore Robots.txt And Negatively Impact SEO. Disponível em: https://www.searchenginejournal.com/google-says-why-it-may-ignore-robots-txt-and-negatively-impact-seo/583475/
- Google for Developers. How Google Interprets the robots.txt Specification. Disponível em: https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec
