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 listadas no próprio sitemap: os motores de busca podem indexá-las conforme declarado? Entre maio 5 e August 15, 2026, 21 de 49 sites auditados falharam nessa pergunta. Isso representa 42.9% da amostra que instrui os rastreadores a ignorar 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. Uma página não pode ser indexada como declarada por qualquer um de 4 motivos: está bloqueada por robots.txt, tem uma diretiva noindex, redireciona para um URL diferente ou declara um canonical que aponta para outro lugar. Apenas 7 sites tinham um problema de noindex — o que significa que na maioria dos 21 sites falhos, as páginas não indexáveis não têm noindex de forma alguma. Elas redirecionam para longe do URL que o sitemap prometeu, ou dizem ao 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 limpa. 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.

Casos benignos não são contados: um redirecionamento que é infraestrutura correta, como um domínio sem www indo para sua variante www, e páginas utilitárias que deveriam ter noindex. As falhas 21 são o que resta depois que esses casos são removidos.

Os padrões de conflito 4 nos dados

O noindex de staging que foi enviado. Sites 7 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 clássico resíduo 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 "Desencorajar motores de busca a indexar este site" do WordPress é o exemplo canônico — uma única configuração, noindex em todo o site, nada visivelmente diferente.

robots.txt gritando acima de tudo. Sites 3 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 simples Google foi proibido de ser buscado.

Contradições de canonical. Uma tag canonical apontando para um alvo que por si só tem noindex dá ao Google 2 instruções que não podem ser honradas simultaneamente: consolidar sinais nessa página, e manter essa página fora do índice. O alvo, portanto, precisa estar limpo: um canonical que cai em uma página com noindex, em um redirecionamento ou em uma página que nomeia um canonical diferente para si mesma é uma contradição. A mesma contradição aparece dentro de uma única página quando ela tem tanto noindex quanto um canonical para outro lugar — pedindo ao Google para transferir autoridade através de uma página que lhe foi dito para 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 o robots.txt bloqueia ou uma diretiva noindex faz o site argumentar consigo mesmo, e a argumentação custa orçamento de rastreamento em cada ciclo. Medimos esse padrão sozinho em nosso relatório de higiene do sitemap.

Resolva conflitos nesta ordem: intenção, depois um único mecanismo, então prova

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

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

2. Expressar cada intenção por meio de um único mecanismo.

• Classificar: listado no sitemap, canônico apontando para si mesmo, sem diretivas robots.
• 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 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 bloqueio robots.txt é uma diretiva que não existe.
• Economizar orçamento de rastreamento: Disallow: /search/ sob User-agent: * no robots.txt, reservado para espaços com URLs ilimitadas. robots.txt controla a navegação, nunca a indexação — ele não remove nada que já esteja indexado.

Por plataforma, a intenção noindex é uma única linha: robots: { index: false } na exportação de metadata de uma rota Next.js, o alternador "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.

3. Verifique como um bot, por classe de página. O navegador não prova nada aqui; busque da forma que os crawlers fazem:

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"

Um representante URL por classe de página é suficiente, verificado contra a intenção que você definiu na etapa 1. A Inspeção URL do Search Console dá a segunda opinião autoritária, incluindo qual canonical Google foi realmente escolhido. Um diagnóstico pago do SEOReport executa o ciclo completo em cada relatório e lista cada par conflitante com a página onde foi encontrado.

A taxa de falha de 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 testes 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, registrada em um único mecanismo por classe de página, e verificada da forma que um crawler 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.