robots.txt do Magento 2 vem vazio: onde ele é configurado de verdade

É uma rota, não um arquivo

O módulo Magento_Robots registra um router próprio que compara o caminho pedido com a string robots.txt. Bateu, ele chama o controller do módulo, que devolve a resposta com Content-Type: text/plain.

O que sai na resposta é curto assim: o bloco Magento\Robots\Block\Data lê a configuração e concatena uma quebra de linha. Nada mais. Sem cabeçalho, sem User-agent automático, sem regra sugerida.

O valor vem de design/search_engine_robots/custom_instructions, no escopo de website. E o config.xml do Magento_Theme não define valor padrão pra esse caminho — define pra um caminho vizinho, o default_custom_instructions, que é outra coisa. Por isso a resposta de uma instalação nova é exatamente uma linha em branco.

Confira o que está gravado sem sair do terminal:

php bin/magento config:show design/search_engine_robots/custom_instructions

Onde preencher

Não é em Stores > Configuration. É em Content > Design > Configuration, na linha do escopo que você quer editar. Abra a seção Search Engine Robots e você vê três coisas:

• Default Robots — essa é a meta tag robots das páginas, vem INDEX,FOLLOW, e não tem relação com o arquivo.
• Edit custom instruction of robots.txt File — a caixa de texto que vira o /robots.txt.
• Reset To Defaults — o botão que preenche a caixa com a lista que o Magento traz pronta.

O botão puxa o conteúdo do default_custom_instructions, que é este:

User-agent: *
Disallow: /index.php/
Disallow: /*?
Disallow: /checkout/
Disallow: /app/
Disallow: /lib/
Disallow: /*.php$
Disallow: /pkginfo/
Disallow: /report/
Disallow: /var/
Disallow: /catalog/
Disallow: /customer/
Disallow: /sendfriend/
Disallow: /review/
Disallow: /*SID=

Serve como ponto de partida, não como resposta final. Eu tiro o Disallow: /*? da maioria das lojas: ele bloqueia toda URL com query string de uma vez só, o que é grosso demais e às vezes atinge coisa que você queria rastreável. Os três campos são marcados como escopo de website — editar na linha de uma store view não separa nada.

Depois de salvar, limpe o cache. O valor tem tag de cache própria, então php bin/magento cache:flush resolve.

O arquivo físico atropela tudo

Aqui mora o segundo motivo de o robots.txt "não obedecer" ao admin. Se existir um arquivo pub/robots.txt no disco, o nginx e o Apache entregam ele direto: o try_files encontra o arquivo e a requisição nunca chega no index.php. O campo do admin vira decoração.

ls -la pub/robots.txt

Isso não é raro. Migração de Magento 1 traz o arquivo junto, porque lá ele era físico mesmo. E ambiente de homologação costuma ganhar um com Disallow: / pra não indexar — que segue no pacote quando alguém copia a pasta pra produção. Já vi loja sumir do Google por isso, e o time procurando o problema em canonical e sitemap — dois assuntos que eu trato junto com este no guia de SEO técnico para Magento 2.

Decida um dos dois e apague o outro. Se você quer o controle pelo admin, remova o arquivo. Se prefere versionar o robots.txt no repositório, mantenha o arquivo e deixe o campo do admin vazio de propósito, com um comentário no README do projeto explicando.

A linha do sitemap entra sozinha

Um detalhe que economiza manutenção: você não precisa digitar a linha Sitemap: na caixa de texto.

php bin/magento config:set sitemap/search_engines/submission_robots 1
php bin/magento cache:flush

Com essa configuração ligada, o Magento_Sitemap injeta um bloco próprio na mesma resposta e monta a linha Sitemap: com a URL de cada sitemap cadastrado em Marketing > SEO & Search > Site Map. Loja com várias store views ganha uma linha por sitemap, sem você mexer em nada.

Se você digitar a linha na mão e deixar a configuração ligada, o robots.txt sai com a URL duplicada. Não quebra nada, mas fica feio pra quem for auditar.