robots.txt no WordPress em 2026: o que realmente colocar no arquivo

Um bom robots.txt de WordPress tem cerca de cinco linhas. Bloqueie /wp-admin/, libere o admin-ajax.php, aponte os rastreadores para o seu sitemap e pare por aí — aquelas listas de bloqueio de 40 linhas que você acha em fórum na maior parte quebram a renderização ou não fazem nada. O arquivo inteiro:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Troque o domínio e, se você usa um plugin de SEO que assume o controle dos sitemaps, aponte a linha Sitemap para o índice desse plugin. É isso. Se o seu arquivo é maior que isso, as linhas extras provavelmente estão custando alguma coisa.

O WordPress já gera um — até você criar um arquivo real

O WordPress traz um robots.txt virtual. Quando chega uma requisição em /robots.txt e não existe arquivo real na raiz do seu site, o WordPress intercepta a requisição e imprime uma resposta em memória. Nada é gravado em disco. A saída padrão é o bloqueio de wp-admin mostrado acima, mais uma linha Sitemap: para o wp-sitemap.xml, que o núcleo emite desde o WordPress 5.5.

Duas coisas mudam essa saída. Se Configurações → Leitura → Sugerir aos mecanismos de busca que não indexem este site estiver marcado, o WordPress substitui tudo por Disallow: /, o que bloqueia o site inteiro. Essa caixinha é a causa número um de um site sumir da busca depois do lançamento. Segundo, plugins e temas podem alterar a saída virtual pelo filtro robots_txt, que é como os plugins de SEO injetam suas próprias linhas de sitemap e regras.

Agora a parte que faz gente perder a tarde. Um arquivo robots.txt físico na raiz do site sobrescreve tudo isso silenciosamente. Seu servidor encontra um arquivo real no disco, entrega, e o WordPress nem carrega. O gerador virtual não roda. O filtro robots_txt não dispara. O editor de robots.txt do seu plugin de SEO pode continuar mostrando uma interface bonita com as regras certas dentro, e nada disso chega a um rastreador.

Onde as regras ficam	Editável no painel do WordPress	Vence numa requisição real
Virtual (nenhum arquivo no disco)	Sim, pelo filtro robots_txt ou por um plugin	Só quando não existe arquivo físico
Arquivo físico na raiz do site	Só se o plugin gravar em disco	Sempre

Então, antes de investigar qualquer coisa: abra https://seusite.com/robots.txt no navegador, depois conecte por SFTP ou pelo gerenciador de arquivos da sua hospedagem e veja se existe um robots.txt real ao lado do wp-config.php e do .htaccess. Se existir, é esse arquivo que vale. Edite ali ou apague e deixe o WordPress assumir — mas escolha um. Manter os dois é como os sites acabam com uma URL de sitemap desatualizada que ninguém consegue achar.

Por que /wp-admin/ é bloqueado mas o admin-ajax.php é liberado

O /wp-admin/ guarda o painel. Essas URLs são inúteis nos resultados de busca e rastreá-las gasta orçamento de rastreamento com páginas que redirecionam para uma tela de login. Bloquear o diretório não é polêmico.

O admin-ajax.php fica dentro desse diretório, mas não é uma página de administração. É o endpoint que plugins e temas usam para tratar requisições AJAX do site público — botões de “carregar mais”, grades de produtos com filtro, calculadoras, formulários. Se um rastreador não consegue acessá-lo, ele não enxerga o conteúdo que esses recursos carregam, e o Google renderiza sua página como um visitante veria com o recurso quebrado.

Se o Google realmente precisa acessar o admin-ajax.php no seu site específico depende de o seu front-end usá-lo. Resposta honesta: em muitos sites modernos isso não faz diferença nenhuma, porque o tema usa a API REST em /wp-json/. A linha Allow é um seguro barato contra uma falha real, não um fator de posicionamento. Mantenha porque não custa nada.

Não bloqueie /wp-content/ nem /wp-includes/

Esse é o pior conselho sobre robots.txt que ainda circula, e ele vem de uma época em que o Google não renderizava páginas.

O /wp-content/ contém seus temas, plugins e uploads — as folhas de estilo, scripts e imagens que fazem suas páginas parecerem páginas. O /wp-includes/ contém o JavaScript do núcleo do qual os plugins dependem. O Google renderiza suas páginas em um navegador sem interface antes de avaliá-las. Bloqueie esses diretórios e o renderizador recebe uma página sem CSS e sem imagens. O que o Google avalia é uma parede de texto sem estilo, com o layout quebrado, o que afeta como ele entende seu conteúdo e como pontua a usabilidade em celular.

Se você herdou um arquivo com essas linhas, apague:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Você mesmo pode confirmar o estrago na ferramenta de Inspeção de URL do Google Search Console. Rode um teste ao vivo em qualquer página, veja a captura de tela renderizada e confira a lista de recursos da página em busca de itens bloqueados. Se seu CSS aparecer como bloqueado, a causa é essa.

A diretiva Sitemap

Uma linha, URL absoluta, e ela pode ficar em qualquer lugar do arquivo — não está presa a um grupo User-agent.

Sitemap: https://example.com/wp-sitemap.xml

Use a URL que realmente funciona. O núcleo do WordPress serve o wp-sitemap.xml. A maioria dos plugins de SEO desativa os sitemaps do núcleo e serve o próprio índice em outro caminho, normalmente sitemap_index.xml. Abra sua URL no navegador antes de fixá-la — uma linha Sitemap apontando para um 404 é pior do que nenhuma linha, porque parece correta em uma auditoria.

Listar vários sitemaps é permitido, um por linha. Enviar os sitemaps pelo Search Console continua valendo a pena à parte; a diretiva no robots.txt é como os rastreadores que nunca veem sua conta do Search Console encontram os arquivos.

robots.txt não é noindex e não é segurança

Esses dois mal-entendidos causam a maior parte dos estragos com robots.txt.

Bloquear uma URL não a remove do Google. O robots.txt governa o rastreamento. Se outro site aponta para uma URL bloqueada, o Google pode indexar a própria URL — você fica com um resultado mostrando só o endereço e um aviso de que não há informação disponível. E existe uma armadilha pior: se uma página já tem uma meta tag noindex e você depois a bloqueia no robots.txt, o Google não consegue rastreá-la, não consegue ver o noindex, e a página pode continuar indexada por tempo indeterminado. Para remover uma página, libere o rastreamento e entregue uma meta tag robots noindex no head da página, ou um cabeçalho HTTP X-Robots-Tag. O Google deixou de aceitar diretivas noindex dentro do robots.txt em 2019.

Bloquear um caminho não o protege. Seu robots.txt é público por definição. Listar /arquivos-de-clientes/ diz a todo visitante e a todo scanner exatamente onde olhar, e o cumprimento é voluntário — o Google respeita, bots hostis não. Qualquer coisa que precise de proteção precisa de autenticação, restrição por IP ou regras no nível do servidor no .htaccess, não de uma linha em um arquivo de texto que aponta o alvo.

Regras que valem a pena e regras que dá para pular

Duas adições são realmente úteis em muitos sites. Bloquear o caminho de resultados de busca impede que rastreadores gerem URLs infinitas e sem valor a partir da sua busca interna. Bloquear o caminho de carrinho ou finalização no WooCommerce mantém URLs com parâmetro de sessão fora do rastreamento.

Disallow: /?s=
Disallow: /search/

Pule estas:

• Crawl-delay — o Google ignora completamente. Use os controles de taxa de rastreamento do Search Console se você tiver um problema real de carga no servidor.
• Bloquear /feed/ ou /trackback/ — são URLs inofensivas, e os feeds são úteis.
• Listas enormes de nomes de bots — a maioria dos bots que as pessoas tentam bloquear não se identifica com honestidade mesmo.
• Bloquear /wp-json/ — pode ser justamente o que o seu tema usa para renderizar conteúdo.

Monte o arquivo com o gerador de robots.txt para WordPress, que produz a versão mínima correta e permite adicionar as regras de busca e de loja sem editar sintaxe na mão.

Depois de alterar o arquivo

Abra https://seusite.com/robots.txt direto e confirme que os bytes entregues são o que você espera — não o que o editor do seu plugin mostra. Depois rode uma inspeção de URL ao vivo no Search Console em uma página comum e verifique se nenhum recurso de CSS ou JavaScript volta como bloqueado. O Google guarda o robots.txt em cache por cerca de um dia, então uma correção não vale na hora, e um erro também não. Esse atraso é o motivo para verificar com calma em vez de testar em produção e esperar.