Meta robots, robots.txt e X-Robots-Tag: os sinais que se contradizem

Por Miguel Maio · Publicado em 3 de novembro de 2026

A maioria das páginas que somem do Google não foi penalizada - foi desindexada por um sinal que a própria equipa lá pôs, sem dar conta. E o pior é que não dá erro no dia: dá uma queda semanas depois, que ninguém liga à causa. O robots.txt, o noindex, o canonical, o sitemap e o status code são cinco players diferentes, e quase todos os desastres de indexação são dois destes sinais, cada um certo por si, a mandar coisas opostas.

Crawl, index e servir não são a mesma coisa

Antes de qualquer diretiva, três verbos distintos: rastrear (o bot acede ao URL), indexar (a Google guarda-o e mostra-o) e servir (o servidor responde com um status code). Cada sinal atua num destes planos, e confundi-los é a raiz de tudo o que vem a seguir. O robots.txt fala de rastreio. O noindex fala de indexação. O status code é a resposta de serviço que sustenta os dois.

robots.txt não controla a indexação

O robots.txt bloqueia o rastreio, não a indexação - e esta distinção custa tráfego todos os dias. Se puseres Disallow num URL, a Google não o rastreia; mas se houver links para ele, pode indexá-lo na mesma, sem conteúdo, como o aviso "Indexed, though blocked by robots.txt". Pior: se bloqueares um URL que também tem noindex, a Google nunca chega a ver o noindex - e a página fica indexada contra a tua vontade. A própria Google é clara: para o noindex funcionar, a página "não pode estar bloqueada por um ficheiro robots.txt", e declarar o noindex dentro do robots.txt não é suportado.

meta robots vs X-Robots-Tag: a mesma ordem, sítios diferentes

A meta robots e o cabeçalho X-Robots-Tag dão a mesma ordem (noindex, nofollow) - a diferença é onde vivem. A meta robots vai no HTML e serve páginas normais. O X-Robots-Tag vai no cabeçalho HTTP e é a única forma de aplicar noindex a ficheiros não-HTML: PDF, imagens, vídeos. A Google confirma que "têm o mesmo efeito", por isso a escolha é de conveniência. Mas há um senão que quase ninguém testa: se a regra do X-Robots-Tag for gerada por uma condição errada no servidor, desindexa em massa - e em silêncio.

O canonical é uma pista, não uma ordem

O rel=canonical diz à Google qual é a versão boa de um conteúdo duplicado - mas é um sinal, não um comando. A Google usa dezenas de sinais e pode escolher um canonical diferente do que indicaste. Por isso os sinais têm de concordar: o rel=canonical na página, o redirect (o sinal mais forte), o sitemap (o mais fraco) e os links internos. Quando uns dizem A e outros dizem B, a Google decide por ti. E nunca se mistura noindex com canonical: um pede para remover, o outro para consolidar - ordens opostas na mesma página.

O sitemap só devia listar o que queres indexado

O sitemap é um convite, não uma garantia - e por isso deve conter apenas o que queres mesmo no índice: URLs que respondem 200, indexáveis e autocanónicos. Listar lá um URL com noindex, um que redireciona, um 4xx ou um não-canónico é mandar à Google um sinal que tu próprio contradizes noutro sítio. O sitemap é também um sinal (fraco) de canonical: se listar um URL diferente do que o rel=canonical aponta, acrescentas ruído em vez de clareza.

O triângulo do URL

Há uma forma simples de não errar nada do que está acima - a que chamo o triângulo do URL (o teu "golden triangle" da consistência, para não confundir com a zona de eye-tracking da SERP). Os três URLs que descrevem a mesma página têm de ser o mesmo URL, e esse URL tem de responder 200 OK, sem redirect e sem erro.

Quando o triângulo fecha (os três coincidem num 200 autocanónico), os sinais reforçam-se e a Google não tem o que interpretar. Quando um vértice foge - o sitemap lista um URL que redireciona, o canonical aponta para um terceiro, ou um deles dá 4xx -, deste à Google três moradas para a mesma pessoa. É este triângulo que apanha o erro que mais vejo: o sitemap, o canonical e o URL servido a divergirem, cada um certo à sua maneira.

Os status codes são o chão de tudo

Nenhum sinal de cima vale nada se o status code por baixo estiver errado - é o chão onde tudo assenta. O essencial: 200 é "existe" (mas uma página morta a responder 200 vira soft-404, conteúdo-fantasma que compete contigo); 301 e 308 são permanentes e sinal forte, o destino substitui a origem; 302 e 307 são temporários e sinal fraco, o destino não substitui nada - usar 302 numa mudança definitiva é não consolidar equity; 404 e 410 são "não existe" (a Google trata-os igual e remove do índice); 429 é "estás a pedir de mais" e trava o crawler; um 5xx prolongado faz a Google abrandar e acabar por desindexar. O 429 não é um controlo de acesso, por muito que às vezes faça esse papel por acidente.

A tabela das combinações de erros

Posto por combinações, porque é assim que aparece no terreno: não um sinal errado, dois sinais certos a entrar em conflito. Da mais comum para a mais traiçoeira.

Quem gere os redirects nem sempre vê as implicações

A parte que quase nenhum guia admite: isto raramente falha por ignorância técnica, falha por governança. Quem mexe nos redirects - uma equipa interna, uma agência externa, o fornecedor do CMS - muitas vezes não vê as implicações a jusante, e não há ninguém a validar o conjunto. É assim que uma regra simples vira um "blocker": o X-Robots-Tag gerado por uma condição errada, o sitemap apontado ao ambiente de staging, a gralha no domínio que ninguém reviu. A solução não é só técnica: é decidir quem é dono destes sinais e quem valida antes de ir a produção.

A IA agrava: JS, render e os bots que não esperam

Os crawlers de IA seguem o robots.txt e os redirects de servidor (301/302), mas quase não executam JavaScript. Se o teu canonical ou o teu noindex são injetados por JS, a Google ainda os vê numa segunda onda de renderização (com atraso), mas os bots de IA podem simplesmente não os ver - e a versão que a IA aprende de ti passa a ser a errada. Põe estes sinais no HTML inicial ou no cabeçalho, nunca só no JS. É onde o SEO técnico encontra o GEO e a migração.

De onde vem o que digo

Cruzei-me com estes erros em configurações muito diferentes, e o padrão repete-se. Vi um site de um mercado "aterrar" por causa de loops de redirects. Vi um par de sites a começarem a ser desindexados por uma regra errada na geração do X-Robots-Tag - a mesma regra replicada, a tirar páginas do índice em silêncio. Vi sitemaps a listar URLs que redirecionavam para outro, com o canonical a apontar para um terceiro. E vi o clássico que ninguém assume: gralhas no domínio do sitemap, o www a trocar-se por sem-www, a barra final a aparecer e a desaparecer. Nenhum deu "erro" no dia em que foi cometido. E há um fio comum: quem gere os redirects raramente vê todas as implicações a jusante. É aí que o nível "blocker" nasce de um erro simples.

O que perdes se os sinais se contradizem

Nenhum destes erros grita no dia em que é cometido. Grita semanas depois, numa queda que vais atribuir a um update do Google que nunca existiu. A diferença entre um site que aguenta e um que "aterra" não é o algoritmo - é se os sinais que tu controlas estão a dizer todos a mesma coisa. Começa pelo triângulo: o URL servido, o do sitemap e o canonical, o mesmo, a 200. O resto da tabela resolve-se a partir daí.

Fontes

• Google Search Central - Block indexing (noindex)
• Google Search Central - HTTP status codes e soft 404
• Google Search Central - Canonicalização (consolidate duplicate URLs)

Perguntas frequentes