Guias de robots.txt por plataforma

Webflow robots.txt: como configuramos regras, sitemap e sinais de IA

Nosso fluxo em SEO → Indexing para publicar alterações, evitar Sitemap duplicado e separar Content-Signal de crawling.

Por Robots.txt Tools Editorial TeamÚltima verificação em 2026-10-012 min de leitura

Método editorial: este guia documenta o processo de revisão da equipe editorial do Robots.txt Tools. A linguagem procedural em primeira pessoa descreve esse método; não representa alegação de trabalho para clientes ou casos pessoais.

Webflow robots.txt: como configuramos regras, sitemap e sinais de IA

No Webflow nós tratamos robots.txt como parte do publish. A configuração fica em Site settings → SEO → Indexing.

Abrimos produção primeiro

Conferimos /robots.txt, Disallow amplos, domínio e Sitemap: duplicado.

Respeitamos o sitemap automático

Antes de adicionar outra linha, verificamos se Webflow já incluiu o sitemap. Em reverse proxy/multi-site revisamos a opção documentada para trocar essa referência.

Save não é publish

Editamos, salvamos, fazemos publish e buscamos o arquivo novamente. Se continuar antigo, investigamos cache e domínio.

Content-Signal é separado

Content-Signal expressa preferência de uso por IA; robots.txt controla crawling. Não misturamos as duas camadas.

Testamos e protegemos previews

Usamos o tester e o validator. Preview privado usa autenticação.

Content-Signal é uma camada separada

O Webflow documenta o header Content-Signal para preferências como ai-train=no, search=yes e ai-input=no, mas também informa que ele vem de uma extensão proposta e não de um padrão aceito. robots.txt responde “o crawler pode acessar?”; Content-Signal expressa preferência de uso onde houver suporte.

Sitemap, publicação e domínio precisam concordar

O Webflow normalmente adiciona o sitemap automaticamente. Antes de inserir outra linha, confirmamos se ela já existe e se usa o domínio canônico. Em reverse proxy ou arquitetura multi-site verificamos qual camada realmente serve /robots.txt e /sitemap.xml.

Salvar não é publicar. O teste final usa o domínio público depois do publish, incluindo status, body, sitemap e regras específicas. Staging e domínio customizado são origens separadas e entram em verificações independentes.

Fazemos rollback com estado conhecido

Antes de uma alteração de crawl relevante, registramos o texto publicado e o domínio de destino. Se o resultado pós-publish não corresponde ao planejado, voltamos a uma configuração conhecida em vez de empilhar exceções. Essa disciplina é especialmente útil em migrações de domínio e projetos com proxy, onde a origem que aparece no Designer pode não ser a mesma que responde aos crawlers.

Guias relacionados