Se você tem uma loja na Nuvemshop, não consegue editar seu robots.txt. A plataforma gera o arquivo e não te dá acesso a ele. E se você usa Cloudflare com managed robots.txt, também não: o Cloudflare reescreve o arquivo inteiro a partir do bloco # BEGIN Cloudflare Managed content, e o que você editar ali é sobrescrito na próxima regeneração.
Esse é o ponto de partida do editor de robots.txt do IndexNow Connect. Ele não parte do princípio de que você escreve o arquivo. Parte do princípio de que outro escreve por você, e trabalha a partir daí.
O que a tela faz é concreto: lê seu arquivo real, diz quem parece estar escrevendo, deixa você desenhar um novo com um interruptor por bot e — se quiser — publica através de um Worker do Cloudflare que você mesmo cola na sua conta.
Toda vez que você abre a tela, é feita uma requisição ao vivo para https://seudominio/robots.txt. Com timeout de 6 segundos, limite de 500 KB e uma proteção anti-SSRF. Um 4xx é interpretado como "não há arquivo"; um 5xx fica como desconhecido, porque um erro de servidor não equivale a "tudo permitido".
Sobre esse texto roda a análise. Ela devolve:
cdn.shopify.com já é suficiente para marcar Shopify. Por isso a tela diz "quem parece estar escrevendo" e, se nada bater, "não conseguimos identificar"./. A pergunta que o editor responde é "esse bot entra ou não?", não o veredito sobre uma URL específica.AdsBot-Google não nomeado havendo rotas proibidas, tokens que ninguém reconhece (possível typo), tokens duplicados, sem Sitemap:, Crawl-delay presente, e uma nota específica: você declarou ai-train=no mas há bots de IA sem bloqueio.Essa última nota existe porque a leitura intuitiva é a errada. Content-Signal declara uso permitido, não bloqueia acesso. Se você quer o detalhe dessa linha — o que significa cada sinal, quem respeita e quem não — está em content-signals-robots-txt.
A grade tem 45 interruptores divididos em quatro grupos: IA (21), buscadores (10), SEO (6) e sociais (8). Cada um ligado significa "esse bot entra".
Quando você desliga um, o arquivo gerado não adiciona uma linha ao grupo *. Cria um grupo próprio para ele:
User-agent: GPTBot
Disallow: /
Essa é a única forma que o protocolo tem de excluir um e deixar o resto entrar. E isso tem uma consequência que vale entender: como o grupo próprio ganha do curinga, esse bot deixa de ler as regras do *. É assim por design do REP, não por decisão nossa. O Cloudflare faz exatamente o mesmo no bloco dele.
Agora, a decisão de persistência. No banco a gente guarda os bloqueados, não os permitidos.
O motivo é o default. Quando amanhã adicionarmos um bot novo ao catálogo, com "bloqueados" esse bot começa permitido — que é o que você espera — enquanto com "permitidos" ficaria proibido sem que ninguém tenha decidido isso. Uma mudança nossa no catálogo não pode bloquear um tráfego que você nunca pediu para bloquear. Existe um teste dedicado a isso.
O editor na tela trabalha com o conjunto de permitidos, porque é o que cada interruptor marca. A conversão entre os dois modelos vive na borda, entre a tela e o banco.
Além dos interruptores, o editor gerencia:
search, ai-input, ai-train) mais o use experimental do Cloudflare. Se você não declara nenhum, o bloco não é escrito: sem sinais o arquivo não fica sujo.*, uma por linha.Sitemap:, que vão no final.User-agent: AdsBot-Google com as mesmas rotas repetidas. O AdsBot do Google não obedece ao grupo *: se você não nomeia ele, continua entrando. É a mesma solução que a Nuvemshop usa.O arquivo gerado não preserva tudo o que o original tinha. Sobrevivem quatro coisas: os sinais do grupo *, as rotas Disallow do grupo *, os bloqueios totais por bot e os Sitemap:.
Se perdem:
Allow: específicos. Sempre é escrito um Allow: / fixo.Crawl-delay. (O Googlebot ignora de qualquer jeito; Bing e Yandex respeitam.)Googlebot-Image: Disallow: /fotos/ vira "bloqueado por completo" ou nada.Há ainda um bug real que vale nomear. O gerador escreve o nome do bot, não o token dele. Para 44 dos 45 eles coincidem ao passar para minúsculas. A exceção é o Screaming Frog: o catálogo declara o token screaming frog seo spider, mas o arquivo sai com User-agent: Screaming Frog. Desligar esse interruptor não produz uma regra que o crawler reconheça como sua. Verificamos isso gerando um arquivo com todos os bots bloqueados e analisando ele de novo: é o único que volta como não bloqueado.
Também não validamos a sintaxe do que você escreve. Não é checado se as rotas começam com /, nem se os sitemaps são URLs válidas, nem se apontam para o seu domínio. Qualquer linha não vazia entra como está. Por isso a tela avisa, antes do botão: um robots.txt mal montado pode tirar seu site dos buscadores.
Aqui está a limitação mais importante, e a que mais se esquece.
"Salvar e publicar" faz duas coisas: salva a configuração e liga uma flag. Com essa flag ligada, /robotsfile/seudominio passa a devolver o arquivo. Seu domínio continua servindo o mesmo de sempre.
O arquivo vai para o ar só quando o Worker do Cloudflare tem a rota. O Worker é um snippet que você mesmo cola na sua conta do Cloudflare — não há integração com a API do Cloudflare, a rota você configura na mão — e intercepta exatamente duas URLs: a chave IndexNow (/{hex}.txt) e /robots.txt. Qualquer outra passa direto.
E falha aberto, por design. Se nossa API não responde 200, o Worker faz o fetch original e seu domínio serve o robots.txt de sempre. Uma queda nossa não pode deixar a loja de ninguém sem robots.txt — nem com um vazio.
Por que é preciso um Worker: é o único mecanismo que temos para responder uma URL na raiz de um domínio alheio. A plataforma não deixa subir arquivos e o protocolo exige o mesmo host. Não há atalho por outro domínio. É exatamente o mesmo problema que resolvemos para a chave do IndexNow com Cloudflare Workers, e o guia técnico de Cloudflare para SEO e GEO cobre o resto das peças.
A tela distingue três situações que as pessoas confundem e que têm soluções diferentes:
O terceiro estado não é declarado por ter apertado um botão. É comprovado: compara-se o texto do arquivo real contra o gerado, inteiro, exato salvo espaços das pontas. Se não coincidem, não dizemos que está publicado.
Duas honestidades sobre essa verificação. A primeira: a comparação é booleana, não há diff visual. A segunda: o "gerado" com o qual ela compara é o rascunho que você tem na tela. Se você mexe nos interruptores e aperta Gerar sem publicar, o card pode dizer "seu domínio serve outra coisa" mesmo que a versão publicada esteja no ar.
E a limitação de fundo: a verificação acontece só quando alguém abre a tela. Não há verificação programada nem alertas. Nada re-verifica depois se o Worker parou de servir o arquivo. Também não há histórico nem versionamento: guardamos a última configuração, a data de publicação e a de atualização.
O endpoint que o Worker consome regenera o arquivo a cada requisição a partir da configuração; não guardamos o arquivo, guardamos o desenho. Responde com Cache-Control: no-store, porque despublicar tem que aparecer na próxima requisição e não em cinco minutos. E devolve 404 quando não há nada publicado: esse 404 é parte do design, faz o Worker seguir direto. Despublicar apaga a flag e seu domínio volta na hora ao seu robots.txt original, sem tocar no Cloudflare. A configuração é preservada: despublicar é apagar a luz, não jogar fora o desenho.
Se além de decidir quem entra você quer medir o que acontece quando eles entram, o IndexNow Connect conecta sua loja, avisa os buscadores toda vez que você muda um produto e mostra se os bots de IA realmente chegam. O editor de robots.txt é uma peça disso, não o produto inteiro.
Você pode desenhar o arquivo, analisar e baixar. Não pode publicar no seu domínio. Na Nuvemshop o arquivo é servido pela plataforma e o Worker do Cloudflare é a única via que temos para responder uma URL na raiz do seu domínio. Se seu site roda em uma plataforma onde você consegue subir o arquivo, baixe e suba você mesmo.
Ele para de entrar, se respeitar o REP. Disallow é uma preferência, não uma barreira técnica: um crawler pode ignorar. Para bloqueio real são necessárias regras de WAF ou Bot Management, coisa que os próprios docs do Cloudflare recomendam. E cuidado para não confundir bloqueio com Content-Signal: o sinal declara uso permitido, não impede o acesso.
Porque o gerador monta o arquivo a partir da configuração do editor, não faz patch. Ele preserva sinais do grupo *, rotas Disallow do grupo *, bloqueios totais por bot e os Sitemap:. Todo o resto — Allow: específicos, Crawl-delay, grupos com regras parciais — não sobrevive. Antes de publicar, olhe o arquivo gerado na tela e compare com o cru que mostramos acima.
Nada no seu site. O Worker consulta nossa API e só responde se voltar um 200. Se não, cai no fetch original e seu domínio serve o robots.txt de sempre. É uma decisão explícita do design do Worker: falha aberto.
O editor te diz o que seu arquivo declara; não prova o que acontece na rede. Para isso existe o teste de acessibilidade para bots de IA, que sai com o User-Agent de cada bot e verifica a resposta real. São duas ferramentas distintas de propósito: uma trabalha sobre o arquivo, a outra sobre o tráfego.