Conflitos de Indexabilidade: Quando Seu Próprio Site Diz ao Google para Ir embora

Cada auditoria que realizamos faz uma pergunta direta sobre as páginas que um site declara importantes — a página inicial mais as URLs que seu próprio sitemap lista: os motores de busca podem indexá-las como declaradas? Entre maio 5 e August 15, 2026, 21 de 49 sites auditados falharam nessa pergunta. Isso é 42.9% do conjunto que diz aos rastreadores para pular páginas que alguém se esforçou em publicar, vincular e listar. As falhas compartilham uma assinatura: cada um desses sites funciona perfeitamente para humanos. Páginas são renderizadas, links resolvidos, nada no navegador indica que uma diretiva embaixo está enviando os motores de busca embora. Conflitos de indexabilidade são a categoria mais auto-infligida em nossos dados — nenhum concorrente os causou, nenhuma atualização de algoritmo os desencadeou, e ninguém na equipe pode vê-los sem buscar o site da maneira que um bot faz.

O conjunto de dados

Metodologia: instantâneo de auditoria concluída mais recente por domínio do nosso conjunto de verificações atual, maio 5 – August 15, 2026 — 49 sites auditados, anonimizado. Os denominadores por verificação variam de 46 a 49 porque uma verificação só é executada quando suas entradas existem — um site sem sitemap acessível não gera veredictos de página de sitemap. A amostra é auto-selecionada — proprietários que realizaram uma auditoria — e tende a pequenos a médios, então trate as taxas como direcionais para esse segmento.

Redirecionamentos e canonicals causam mais falhas do que noindex

A lacuna entre as primeiras linhas 2 é a descoberta. A verificação de indexabilidade falha uma página por qualquer um dos 4 motivos: bloqueada por robots.txt, com diretiva noindex, redirecionando para um URL diferente, ou declarando um canonical que aponta para outro lugar. A verificação específica de noindex falhou em 7 sites — o que significa que na maioria dos 21 sites falhos, as páginas não indexáveis não têm noindex nenhum. Eles redirecionam para longe do URL que o sitemap prometeu, ou dizem Google que seu canonical vive em um endereço diferente. Essa distribuição importa porque as equipes caçam o culpado errado. A palavra que todos conhecem é noindex, então é isso que é grepped — e volta limpo. O conflito real costuma ser estrutural: um sitemap gerado a partir do banco de dados CMS enquanto as URLs ao vivo migraram para um novo esquema de caminho, ou uma tag canonical templada para uma variante URL que nenhuma página realmente serve. A verificação é cuidadosa sobre o que conta. Ela desculpa o redirecionamento que é infraestrutura correta — um domínio nu saltando para sua variante www — e pula caminhos utilitários como /login e /signup que deveriam ter noindex. As falhas 21 são o que permanece depois que os casos benignos são removidos.

Os padrões de conflito 4 nos dados

O noindex de staging que foi enviado. 7 sites listam páginas em seu sitemap que têm diretiva noindex — no meta robots tag ou no cabeçalho de resposta X-Robots-Tag. Isso é o resíduo clássico de lançamento: a diretiva que corretamente ocultou o ambiente de staging entra em produção dentro de um template, uma configuração de plugin, ou um toggle de plataforma. A caixa de seleção "Discourage search engines from indexing this site" do WordPress é o exemplo canônico — 1 configuração, noindex em todo o site, nada visivelmente diferente. robots.txt gritando sobre tudo. 3 sites servem um robots.txt com Disallow: / para todos os bots — o sinal de "vá embora" em todo o site — e 5 falham na verificação de consistência mais ampla, onde robots.txt bloqueando ou um noindex na página inicial contradiz a intenção evidente de ranquear. A armadilha sutil nesse padrão: robots.txt e noindex fazem trabalhos opostos, e combiná-los cancela o mais forte. Uma página bloqueada por robots.txt não pode ser rastreada, então um noindex colocado nela nunca é lido — que é como as URLs acabam no estado "Indexado, embora bloqueado por robots.txt", presente nos resultados como um link Google que foi proibido de buscar. Contradições de canonical. Uma tag canonical apontando para um alvo que por si só tem noindex dá Google 2 instruções que não podem ser honradas simultaneamente: consolidar sinais nessa página, e manter essa página fora do índice. Nosso motor resolve cada alvo canônico e falha na auditoria quando o alvo está noindex, redireciona ou recusa declarar-se canônico. A mesma contradição aparece em forma de 1-página quando uma página carrega tanto noindex quanto um canônico para outro lugar — pedindo ao Google transferir autoridade através de uma página que lhe foi dito esquecer. O sitemap promovendo o que as diretivas proíbem. Um sitemap é uma reivindicação legível por máquina de que todo URL nele merece indexação. Listar um URL que robots.txt bloqueia ou uma diretiva que aplica noindex faz o site argumentar consigo mesmo, e o argumento custa orçamento de rastreamento em cada ciclo. Medimos este padrão por conta própria no nosso relatório de higiene do sitemap [/articles/xml-sitemap-hygiene-audit-data].

Resolva conflitos nesta ordem: intenção, depois mecanismo 1, então prova

Conflitos de indexabilidade persistem porque as correções são aplicadas sinal por sinal — alguém corrige um noindex aqui, edita robots.txt lá — sem que ninguém decida para que cada classe de página realmente serve. A correção durável funciona na direção 1.

Conteúdo classificável, variantes duplicadas, páginas utilitárias privadas e espaços de parâmetros infinitos recebem cada um 1 intenção — antes que alguém toque em um arquivo de configuração. 1. Decida a intenção por classe de página. 2. Expresse cada intenção por exatamente 1 mecanismo.

• Classificar: listado no sitemap, canônico apontando para si mesmo, sem diretivas robots em absoluto.
• Consolidar duplicatas: <link rel="canonical" href="https://example.com/primary/" /> na variante, que permanece rastreável e sai do sitemap. Canônicos são uma dica — a própria documentação do Google diz que pode escolher um canônico diferente quando outros sinais discordam, o que é exatamente por isso que o alvo deve estar limpo: indexável, 200, auto-canônico.
• Manter fora dos resultados: uma tag meta robots noindex na página, ou o cabeçalho de resposta X-Robots-Tag: noindex para PDFs e outras respostas não-HTML. A página deve permanecer rastreável — uma diretiva atrás de um bloco robots.txt é uma diretiva que não existe.
• Salvar orçamento de rastreamento: Disallow: /search/ em User-agent: * no robots.txt, reservado para espaços com URLs ilimitadas. robots.txt controla o rastreamento, nunca a indexação — ele não remove nada que já esteja indexado.

Por plataforma, a intenção noindex é de 1 linha: robots: { index: false } na exportação de metadata de uma rota Next.js, o toggle “Visibilidade do motor de busca” em WordPress — marcado deliberadamente por ambiente, nunca herdado do staging — ou add_header X-Robots-Tag "noindex" always; limitado a um bloco de localização no nginx. O navegador não prova nada aqui; busque da forma que os rastreadores fazem: 3. Verifique como um bot, por classe de página.

curl -sI -A "Googlebot" https://example.com/page/ | grep -i "x-robots-tag\|location"
curl -s -A "Googlebot" https://example.com/page/ | grep -i "robots\|canonical"

1 representante URL por classe de página é suficiente, verificado contra a intenção que você decidiu na etapa 1. A Inspeção URL do Search Console dá a segunda opinião autoritária, incluindo qual canonical Google foi realmente escolhido. Nossa auditoria executa o loop completo em cada relatório — robots.txt contra a membresia do sitemap, diretivas contra canonicals, alvos canonicals resolvidos e verificados — e o relatório gratuito lista cada par conflitante com a página onde o encontrou. A taxa de falha 42.9% coloca conflitos de indexabilidade entre os achados sérios mais comuns em nossos dados, no mesmo nível das lacunas de cabeçalho da classificação de nossos checks mais falhados — com uma consequência mais severa, já que uma página bloqueada não ganha nada independentemente de quão boa seja. Os sites que passam são aqueles onde a intenção de indexação foi decidida uma vez, escrita no mecanismo 1 por classe de página, e verificada da forma que um rastreador faria. Tudo sobre esta categoria de falha está sob controle do proprietário do site — o que a torna a mais corrigível 42.9% no conjunto de dados.