X-Robots-Tag para SEO: além do HTML

O X-Robots-Tag é uma diretiva de indexação enviada dentro do cabeçalho da resposta HTTP, e não dentro do HTML da página. Ele aceita o mesmo vocabulário da meta tag robots — noindex, nofollow, none e outras diretivas — mas resolve um problema que a meta tag sozinha nunca vai conseguir resolver: controlar arquivos que não têm HTML nenhum.

A meta tag robots só existe dentro da seção <head> de um documento HTML. Isso significa que ela é, por definição, inútil para um PDF, uma imagem, um vídeo, uma planilha ou qualquer outro arquivo que não seja uma página web renderizada. Um catálogo em PDF indexado por engano, uma imagem em alta resolução aparecendo no Google Imagens, um arquivo de exportação que não deveria estar em lugar nenhum do índice — nenhum desses casos se resolve com uma tag no <head>, porque simplesmente não existe <head> para colocá-la ali. É exatamente aí que o X-Robots-Tag entra: como ele viaja no cabeçalho da resposta HTTP, funciona para qualquer tipo de conteúdo que o servidor devolva, seja HTML, PDF, imagem, vídeo ou qualquer outro formato.

Meta robots e X-Robots-Tag: mesma sintaxe, lugares diferentes

Tecnicamente, as duas ferramentas fazem a mesma coisa: informam a um rastreador o que ele pode indexar, seguir ou exibir nos resultados de busca. A diferença inteira está em onde a instrução mora. A meta tag fica escrita no corpo do documento, como uma linha de marcação HTML que o rastreador só encontra depois de baixar e interpretar a página inteira. O X-Robots-Tag fica no cabeçalho da resposta — a parte da comunicação HTTP que o servidor envia junto com o conteúdo, ao lado de outras informações como o tipo de arquivo (Content-Type) e o código de status (200, 404, 301).

Essa diferença de localização é o que dá ao header uma vantagem que a meta tag nunca vai ter: ele não depende do formato do arquivo. Um servidor devolve cabeçalhos HTTP para absolutamente qualquer resposta, seja ela um documento HTML, um arquivo binário ou uma imagem. Uma tag HTML, por outro lado, só existe dentro de HTML — e isso deixa de fora praticamente tudo que não é uma página web.

• PDFs (catálogos, relatórios, apostilas, contratos)
• Imagens e vídeos indexados no Google Imagens ou Vídeos
• Planilhas e arquivos de exportação (CSV, XLS)
• Documentos de escritório publicados diretamente (DOCX, PPTX)
• Qualquer resposta de API ou arquivo estático sem HTML

As diretivas que o X-Robots-Tag aceita

O valor do header usa exatamente o mesmo vocabulário da meta tag robots, então quem já configurou uma meta robots não precisa aprender uma sintaxe nova — só um lugar novo para colocá-la. As diretivas podem ser combinadas na mesma linha, separadas por vírgula.

Na prática, noindex é de longe a mais usada: é a resposta direta para 'eu quero que isso não apareça no Google'. As demais são refinamentos — controlam como um conteúdo que continua indexado aparece no resultado de busca, ou programam a saída automática dele, o que é útil para conteúdo com prazo de validade natural, como uma página de evento ou uma promoção sazonal.

• noindex — não inclua esta URL nos resultados de busca
• nofollow — não siga os links deste conteúdo para fins de descoberta
• none — equivalente a usar noindex e nofollow juntos
• noarchive — não guarde uma cópia em cache pública deste conteúdo
• nosnippet — não mostre trecho de texto nem miniatura de vídeo no resultado
• max-snippet:[número] — limita o tamanho do trecho de texto exibido, em caracteres
• max-image-preview:[none|standard|large] — controla o tamanho da miniatura de imagem
• unavailable_after:[data] — para de indexar automaticamente depois da data informada

Quando faz sentido usar o X-Robots-Tag

O caso mais comum na prática é desindexar PDFs que acabaram sendo rastreados sem que ninguém planejasse isso — um catálogo de produtos desatualizado, uma tabela de preços antiga, um manual técnico que expõe informação interna. Como esses arquivos são servidos diretamente pelo servidor, sem passar por nenhuma aplicação que renderize HTML, a única forma de dar a eles uma instrução de indexação é pelo cabeçalho da resposta.

Outro uso frequente é manter ambientes de staging, subdomínios internos ou pastas de teste fora do índice quando parte do que é servido não é HTML — exports de dados, imagens de protótipo, arquivos de build que acabam acessíveis publicamente por engano. E há o caso de conteúdo com prazo: uma imagem promocional de uma campanha sazonal, o PDF de um evento que já aconteceu, um relatório trimestral que perde relevância depois de um tempo. Nesses casos, unavailable_after evita que alguém precise lembrar de voltar e remover o arquivo manualmente na data certa.

• Catálogos e tabelas de preço em PDF que vazaram para o índice
• Imagens em alta resolução competindo por espaço no Google Imagens sem necessidade
• Ambientes de staging que servem arquivos não-HTML publicamente
• Relatórios, contratos e materiais com data de validade natural

O erro que anula o X-Robots-Tag

Existe um erro que aparece com frequência desproporcional em auditorias técnicas, e ele anula completamente o X-Robots-Tag — junto com a meta tag robots, pelo mesmo motivo. Se uma URL está bloqueada no robots.txt, o rastreador nunca chega a baixar essa URL. E se ele nunca baixa a resposta, ele nunca lê o cabeçalho HTTP dela. Um noindex colocado no header de uma página que também tem Disallow no robots.txt simplesmente nunca é visto por ninguém. Não é ignorado por decisão do rastreador — ele literalmente não existe para quem nunca chegou a fazer a requisição.

A ordem das operações é o que importa aqui. O robots.txt é consultado antes da requisição acontecer; ele decide se o rastreamento vai ocorrer ou não. O X-Robots-Tag só pode ser lido depois que a requisição já aconteceu, como parte da resposta a essa requisição. Bloquear no robots.txt e tentar noindexar pelo header ao mesmo tempo são instruções que operam em momentos diferentes da mesma jornada, e a primeira impede a segunda de sequer acontecer.

Na prática, isso significa que uma página já indexada que você quer remover precisa continuar acessível ao rastreador — sem bloqueio no robots.txt — enquanto o noindex estiver no ar, até que o rastreador visite a URL de novo, leia a diretiva e processe a remoção. Só depois que a página já saiu do índice é que bloquear o caminho no robots.txt passa a fazer sentido, e mesmo assim por um motivo diferente: economizar orçamento de rastreamento em algo que não precisa mais ser visitado, não reforçar uma remoção que já aconteceu.

• Bloquear no robots.txt e noindexar ao mesmo tempo é a combinação mais comum desse erro
• A ordem certa: manter crawlable com noindex, esperar o recrawl, só então bloquear no robots.txt se fizer sentido
• Um Disallow no robots.txt não remove nada do índice — apenas impede o rastreamento futuro

Como aplicar o header na prática

De forma geral, existem duas camadas onde o X-Robots-Tag pode ser adicionado. A primeira é a camada de servidor web: uma regra de configuração que identifica requisições por um padrão — extensão de arquivo, caminho, tipo de conteúdo — e anexa o cabeçalho à resposta antes mesmo de qualquer aplicação entrar em ação. Essa costuma ser a abordagem mais simples para arquivos estáticos como PDFs e imagens, porque não existe lógica de negócio envolvida: o arquivo sempre deve, ou nunca deve, levar o header, então uma regra fixa por padrão de URL resolve o problema de uma vez.

A segunda camada é a aplicação: o próprio código que monta a resposta HTTP define o cabeçalho antes de enviá-la. Faz sentido quando a decisão depende de alguma condição — o status de uma página, uma data, o tipo de usuário, uma flag no banco de dados. Nesses casos o servidor web não tem como saber de antemão se aquela URL específica deve levar o header, porque a resposta é montada de forma dinâmica.

Alguns detalhes importam independentemente da camada escolhida: o header precisa estar presente em toda variação da resposta para aquele recurso, incluindo redirecionamentos e páginas de erro, não só na resposta padrão. E é possível restringir a diretiva a um rastreador específico, no formato X-Robots-Tag: googlebot: noindex, embora isso raramente seja necessário — na maioria dos casos a diretiva deve valer para qualquer rastreador.

Como verificar se o header está realmente lá

Esse é o ponto onde mais gente erra na hora de conferir o próprio trabalho: o X-Robots-Tag não aparece em lugar nenhum do código-fonte da página. Ver o HTML — seja pelo recurso de exibir código-fonte do navegador, seja pelas ferramentas de desenvolvedor olhando o DOM — não mostra nada, porque a diretiva nunca esteve no HTML. Ela é metadado da conversa HTTP entre o rastreador e o servidor, não parte do documento em si.

A forma correta de verificar é inspecionar os cabeçalhos da resposta, não o conteúdo dela. Nas ferramentas de desenvolvedor do navegador, a aba de rede mostra a requisição feita para aquela URL; abrindo os detalhes dela existe uma seção de cabeçalhos de resposta, e é ali que o X-Robots-Tag aparece, se estiver presente. Também é possível fazer uma requisição que pede só os cabeçalhos, sem baixar o corpo do arquivo inteiro, o que é especialmente prático para confirmar rapidamente um PDF grande sem precisar baixá-lo por completo.

Vale checar isso na URL de produção, pelo mesmo caminho que o rastreador realmente acessa — um CDN ou proxy intermediário às vezes reescreve ou descarta cabeçalhos customizados sem que ninguém perceba durante um deploy, o que faz o header desaparecer silenciosamente mesmo que ele esteja corretamente configurado na origem. Repetir essa verificação depois de mudanças de infraestrutura, e não só na configuração inicial, evita que essa lacuna passe despercebida por meses.

• Aba de Rede das ferramentas de desenvolvedor: clique na requisição e abra os cabeçalhos de resposta
• Uma requisição que traz só os headers, sem o corpo, confirma o valor sem baixar o arquivo inteiro
• Nunca confie no código-fonte da página para essa verificação — o header não mora ali
• Reconfirme depois de mudanças em CDN, proxy ou deploy, porque cabeçalhos customizados podem se perder no caminho

Erros comuns além do conflito com o robots.txt

O conflito com o robots.txt é o erro mais frequente, mas não o único. Um clássico acontece na migração de um ambiente de staging para produção: o header de noindex configurado de propósito no ambiente de testes é replicado junto com o resto da configuração, e a página de produção nasce invisível para o Google sem que ninguém tenha decidido isso — só descoberto semanas depois, quando alguém percebe que o tráfego orgânico de uma seção inteira nunca decolou.

Outro erro comum é confiar em um plugin ou ferramenta de SEO que só mexe em meta tags HTML e assumir, por extensão, que ele também cobre os arquivos enviados no site. Esses plugins normalmente não têm nenhum gancho na resposta de arquivos estáticos — eles editam o <head> de páginas, não os cabeçalhos HTTP de tudo que o servidor entrega, o que deixa PDFs e imagens completamente fora do alcance da ferramenta mesmo que a interface passe a impressão de cobrir todo o SEO técnico do site.

Vale também prestar atenção ao formato da data em unavailable_after: uma data em formato ambíguo ou não reconhecido é simplesmente ignorada pela diretiva, sem gerar aviso nenhum — o conteúdo continua indexado indefinidamente, como se a diretiva nunca tivesse sido escrita.