About cruzfong364180

Como medir cobertura de indexação e destravar seu SEO técnico

A cobertura de indexação é a razão entre as URLs que o Google efetivamente mantém em seu índice e as URLs que o seu site publica ou declara como relevantes. Medir essa cobertura significa cruzar dados de fontes diferentes — o relatório Indexação de páginas do Google Search Console, sitemaps XML, logs de servidor, dados de campo do CrUX e o resultado de rastreamentos com ferramentas como Screaming Frog — para descobrir quais páginas ficaram de fora, por qual motivo declarado e quanto de tráfego orgânico isso está custando. Para CTOs, seo setup diretores de marketing e desenvolvedores, esse número funciona como o teto silencioso de qualquer estratégia de SEO: nenhuma otimização de conteúdo, velocidade ou links gera receita em uma página que nunca entrou no índice.

A maioria dos times só descobre o problema quando a queda de tráfego já apareceu no relatório de desempenho. Nesse ponto, a causa raiz está enterrada semanas atrás, em uma mudança de template, um deploy com robots.txt indevido ou um conflito de canonical que fragmentou sinais de ranqueamento entre dezenas de URLs. Este artigo percorre o processo completo de medição com o rigor de uma auditoria técnica: quais dados coletar, como calcular, como interpretar cada status de exclusão e como transformar o diagnóstico em correção priorizada.

O que a cobertura de indexação mede e por que ela define o limite do seu resultado orgânico

Antes de abrir qualquer relatório, é necessário separar três conceitos que o mercado trata como sinônimos e que produzem diagnósticos completamente diferentes quando confundidos. A confusão entre eles é a origem mais comum de planos de ação errados.

Rastreamento, indexação e cobertura não são a mesma coisa

Rastreamento é a fase em que o Googlebot busca uma URL, executa o HTML, processa JavaScript quando necessário e armazena o conteúdo em uma versão de trabalho. Indexação é a decisão posterior de incluir esse conteúdo no índice de busca, o que envolve análise de qualidade, duplicidade, sinais de canonicalização e valor percebido. Cobertura é a métrica agregada: quantas das suas URLs terminaram indexadas e quantas foram descartadas, com o motivo atribuído.

Uma URL pode ser rastreada com sucesso e ainda assim não ser indexada. Outra pode estar no índice mesmo sem nunca ter aparecido em um sitemap. Sem essa distinção, um time pode celebrar um aumento de rastreamento enquanto a indexação permanece estagnada — ou seja, o servidor trabalha mais, o orçamento de banda cresce e o tráfego não se move.

O que o relatório do Search Console realmente informa

O relatório de Indexação de páginas (antigo ”Cobertura”) apresenta duas visões complementares. A primeira lista todos os motivos pelos quais URLs foram excluídas do índice, agrupados em categorias como Rastreada, mas não indexada, Descoberta, mas não rastreada, Página alternativa com tag canônica, Soft 404, Página com redirecionamento, Bloqueada por robots.txt e Excluída por tag noindex. A segunda lista as URLs indexadas, com contagem aproximada.

Esse relatório é uma amostra, não um censo. O Google documenta explicitamente que os dados são agregados por propriedade, podem levar dias para refletir mudanças e não cobrem todas as URLs de um site grande. Tratá-lo como inventário completo leva a decisões erradas sobre páginas que simplesmente não aparecem na amostra.

O custo de negócio de uma cobertura deficiente

Cada URL relevante fora do índice representa receita que não existe. Em catálogos de e-commerce, um filtro de categoria mal configurado pode gerar milhares de URLs com conteúdo duplicado, todas canibalizando a versão principal e desperdiçando o orçamento de rastreamento que deveria ser gasto nas páginas de produto. Em portais de conteúdo, uma migração de domínio sem redirecionamentos 301 corretos pode congelar a indexação de centenas de artigos por semanas, com queda mensurável em sessões orgânicas.

Empresas de mídia e SaaS B2B costumam sentir o efeito no funil: páginas de comparação, documentação técnica e casos de uso deixam de aparecer em consultas comerciais, e o time atribui a perda a ”mudança de algoritmo”. Na prática, o problema é de infraestrutura e de configuração — mensurável, diagnosticável e reversível.

As fontes de dados que você precisa cruzar para medir cobertura de indexação de verdade

Nenhuma ferramenta isolada responde à pergunta central. O Search Console mostra o que o Google decidiu; os logs de servidor mostram o que o Googlebot fez; os rastreadores próprios mostram o que existe no site; o CrUX mostra como usuários reais experimentam as páginas que sobreviveram ao filtro. A medição confiável nasce do cruzamento.

Indexação de páginas no Google Search Console

É o ponto de partida. Exporte a lista completa de motivos de exclusão e a lista de indexadas. Duas leituras importam: a distribuição relativa entre categorias (um crescimento de Descoberta, mas não rastreada sinaliza problema de orçamento de rastreamento, não de qualidade) e a evolução temporal de cada categoria.

Use o filtro por sitemap para comparar a cobertura de um sitemap específico contra o total da propriedade. Se um sitemap de produtos tem 12% de exclusão e o sitemap de blog tem 40%, o problema está no template do blog e não na infraestrutura global.

Inspeção de URL: o teste que confirma a causa raiz

A ferramenta de Inspeção de URL retorna o status de indexação de uma URL individual, o canonical escolhido pelo Google, a versão rastreada do HTML renderizado, recursos bloqueados e o resultado do teste de página ativa. Ela resolve a ambiguidade do relatório agregado: em vez de inferir, você lê a decisão do sistema para aquela URL específica.

Em conflitos de canonical, a inspeção é insubstituível. Se o Google escolheu uma URL diferente da que você declarou, a causa costuma estar em links internos apontando para a versão errada, parâmetros de URL sem tratamento ou conteúdo genuinamente idêntico. Sem essa verificação, times corrigem a tag canônica e o Google continua ignorando a declaração.

Sitemaps XML e a API do Search Console

O sitemap é a sua declaração de intenção. A comparação entre URLs enviadas e URLs indexadas produz a taxa de indexação líquida por conjunto. A API do Search Console permite automatizar essa extração e enviar os dados para um data warehouse, o que é o único caminho viável para propriedades com mais de algumas centenas de milhares de URLs.

Mantenha sitemaps separados por tipo de conteúdo e com lastmod preciso. Sitemaps que declaram todas as URLs como modificadas diariamente perdem credibilidade e passam a ser tratados como ruído.

Logs de servidor e dados de campo do CrUX

Os logs de acesso mostram a frequência real de rastreamento por diretório, o status HTTP retornado a cada requisição do Googlebot e a proporção de rastreamento desperdiçado em URLs de baixo valor — paginação infinita, parâmetros de ordenação, filtros, URLs de sessão. Se 60% das requisições do Googlebot atingem URLs que nunca serão indexadas, o orçamento de rastreamento está sendo consumido por páginas que não geram tráfego.

O CrUX entra como camada de qualidade percebida. Páginas com LCP, INP ou CLS persistentemente ruins em dados de campo tendem a ser rastreadas com menos frequência e podem enfrentar menor prioridade de recrawl. Corrigir Core Web Vitals não garante indexação, mas remove um obstáculo real de eficiência de rastreamento.

Rastreadores próprios: Screaming Frog, Sitebulb e equivalentes

Ferramentas de crawling local fornecem o inventário controlado: todas as URLs internas descobertas, status HTTP, diretivas de indexação, canônicas, profundidade de clique, número de links internos e conteúdo duplicado. É aqui que se encontra a discrepância entre ”o que o site diz que existe” e ”o que o Google decidiu incluir”.

Configure o rastreamento fale com especialista renderização de JavaScript ativada quando o site for uma SPA ou usar hidratação. Sem isso, o inventário ignora conteúdo carregado no cliente — exatamente o conteúdo que costuma ficar de fora do índice.

Como calcular a taxa de cobertura de indexação

Com os dados em mãos, o cálculo parece trivial, mas a escolha do denominador determina se a métrica informa ou engana.

Escolha do denominador correto

Não use o total de URLs rastreadas pelo Screaming Frog como denominador. Esse número inclui paginação, filtros, parâmetros e páginas de baixo valor que não deveriam ser indexadas e cuja exclusão é desejável.

O denominador correto é o conjunto de URLs indexáveis por intenção: páginas com conteúdo único, valor de busca e status 200, sem diretivas noindex ou bloqueios de robots.txt. Separe o inventário em três grupos — URLs que devem ser indexadas, URLs que não devem ser indexadas e URLs ambíguas — e calcule a taxa apenas sobre o primeiro grupo.

Segmentação por template e por diretório

Uma taxa global de 78% esconde realidades opostas. Segmentada, ela pode revelar 98% de cobertura em produtos e 31% em páginas de blog, indicando que o problema está no template do blog ou na sua estrutura de links internos. A segmentação por pasta, idioma e tipo de template transforma uma métrica de vaidade em diagnóstico acionável.

Acompanhamento temporal e janela de observação

Indexação é um processo com latência. Mudanças levam de dias a semanas para aparecer, e o Search Console reporta dados com atraso. Compare períodos de 30 dias contra 30 dias, não uma semana contra a seguinte. Uma queda seguida de recuperação em quatro dias costuma ser ruído de reprocessamento, não regressão real.

Interpretando os status de exclusão e encontrando a causa raiz

Cada categoria de exclusão aponta para um conjunto específico de causas técnicas. Tratar todas como ”problema de SEO” impede a correção.

Rastreada, mas não indexada

Esta é a categoria mais mal interpretada. O Google acessou a página, processou o conteúdo e decidiu não incluí-la. As causas típicas incluem conteúdo de baixo valor percebido, duplicação próxima com páginas existentes, ausência de links internos relevantes, respostas rasas para a intenção de busca ou canibalização entre URLs quase idênticas.

A ação não é reenviar para indexação repetidamente. É melhorar o conteúdo, consolidar URLs semelhantes com 301, fortalecer links internos apontando para a página principal do agrupamento e garantir que a página resolva uma intenção distinta. O envio manual só funciona quando a página realmente merece estar no índice.

Descoberta, mas não rastreada

A URL é conhecida pelo Google, mas o rastreador ainda não a visitou — ou não priorizou a visita. Isso é sintoma clássico de orçamento de rastreamento mal alocado ou de ausência de sinal de importância. Páginas descobertas apenas por sitemap, sem nenhum link interno apontando para elas, ficam nessa categoria indefinidamente.

A correção combina três frentes: reduzir o volume de URLs de baixo valor que consomem rastreamento, criar links internos contextuais a partir de páginas já indexadas e melhorar o tempo de resposta do servidor para reduzir o custo de cada requisição. Menos URLs irrelevantes significa mais rastreamento disponível para as relevantes.

Página alternativa com tag canônica e duplicatas

O Google escolheu outra URL como canônica, diferente da declarada. Isso normalmente significa que links internos apontam para a versão ”errada”, que variações por parâmetro retornam o mesmo conteúdo, ou que a tag canônica declarada é inconsistente entre versões com e sem barra final, HTTP e HTTPS, ou com e sem www.

Verifique a coerência completa: redirecionamento 301 para uma única versão, links internos apontando para essa versão, sitemap listando apenas ela e canônica autorreferencial. Um único link interno para a versão antiga pode manter a ambiguidade viva.

Erros 4xx, 5xx e soft 404

Erros 404 e 410 são legítimos para páginas removidas, mas URLs que retornam 404 por erro de configuração destroem cobertura silenciosamente. Erros 5xx intermitentes são piores: o Google reduz a frequência de rastreamento de todo o domínio quando detecta instabilidade recorrente, afetando páginas que nada têm a ver com o problema.

Soft 404 ocorre quando a página retorna status 200 mas apresenta conteúdo vazio, genérico ou de ”nenhum resultado encontrado”. É comum em páginas de busca interna, filtros sem resultados e listagens esgotadas. A correção técnica é retornar 404 real ou implementar a página com conteúdo útil e links de navegação.

Bloqueios por robots.txt, noindex e conflitos

A diretiva noindex remove a URL do índice; o bloqueio em robots.txt impede o rastreamento. Combinar os dois é um erro frequente: se a URL está bloqueada, o Googlebot não lê o noindex e a página pode continuar indexada por links externos, sem conteúdo atualizado. A regra é usar noindex sem bloqueio de rastreamento, e nunca bloquear o acesso ao CSS ou JavaScript necessário para renderizar páginas que devem ser indexadas.

Conteúdo de baixo valor e duplicação sem canônica

Páginas de tag com um único artigo, arquivos de data, variações de filtro e páginas de resultado interno geram duplicação em escala. Sem canônica ou noindex, elas competem com as versões principais e diluem sinais. Defina uma política explícita de indexação por tipo de URL e documente-a — sem política escrita, cada novo deploy reintroduz o problema.

Orçamento de rastreamento como variável central da cobertura

Orçamento de rastreamento é o volume de requisições que o Googlebot está disposto a fazer no seu domínio em determinado período. Ele é finito e proporcional à importância percebida do site, à sua velocidade de resposta e à qualidade do conteúdo descoberto.

Sinais que indicam desperdício: grande volume de requisições em URLs com parâmetros, rastreamento repetido de páginas noindex, taxa alta de respostas 5xx, tempo de resposta elevado no servidor e profundidade excessiva de cliques para chegar a páginas importantes. A correção envolve bloquear ou canonicalizar URLs de baixo valor, achatar a arquitetura de links, melhorar TTFB e garantir que o conteúdo prioritário esteja a poucos cliques da home.

Páginas críticas devem estar a até três cliques da página inicial e receber links internos de páginas já indexadas e com autoridade. Links internos são o sinal mais direto de prioridade que você controla.

Automação e monitoramento contínuo da cobertura

Medição pontual resolve crises. Medição contínua evita que elas aconteçam.

API do Search Console e integração com data warehouse

Exporte diariamente as listas de indexação e exclusão via API para BigQuery, Snowflake ou equivalente. Com histórico armazenado, você compara categorias, acompanha tendências por template e correlaciona variações de cobertura com deploys, mudanças de conteúdo e alterações de infraestrutura.

Alertas por limiar e por variação

Configure alertas para crescimento percentual de Descoberta, mas não rastreada acima de um limiar, aumento de 5xx detectado em logs, quedas bruscas na contagem de URLs indexadas e aparição súbita de soft 404 em massa. Esses alertas capturam regressões em horas, não em semanas.

Cruzamento com Bing Webmaster Tools e logs

O Bing Webmaster Tools oferece relatórios de indexação com granularidade diferente e pode revelar padrões que o Search Console agrega. Cruzar os dois reduz o risco de decisões baseadas em peculiaridades de um único rastreador. Para o mercado brasileiro, onde a fatia de busca do Bing é pequena mas relevante em contextos corporativos, o cruzamento permanece útil como validação.

Corrigindo lacunas de cobertura para recuperar receita orgânica

Diagnóstico sem priorização gera trabalho infinito e resultado marginal. Ordene as correções por impacto esperado em receita e por esforço de implementação.

Priorização por impacto

Comece pelas URLs que já geram receita em outros canais ou que têm potencial comprovado de busca. Páginas de produto, categorias comerciais, páginas de comparação e artigos com backlinks são prioridade máxima. Páginas de arquivo e tags são prioridade mínima — muitas vezes a ação correta é noindex, não indexação.

Boas práticas alinhadas à documentação do Google Search Central

Mantenha uma única versão canônica por conteúdo, com redirecionamento 301 permanente. Use canônicas autorreferenciais em todas as páginas indexáveis. Garanta que o conteúdo principal esteja no HTML inicial ou seja renderizável de forma confiável. Mantenha sitemaps atualizados, enxutos e sem URLs que retornam erro. Não bloqueie recursos de renderização. Evite noindex em páginas com links internos importantes. Retorne códigos HTTP corretos para cada situação.

Após cada correção, monitore a categoria afetada por 30 a 60 dias antes de concluir que funcionou. Indexação responde com latência, e conclusões prematuras levam a reverter correções que estavam funcionando.

Resumo e próximos passos

Medir cobertura de indexação é cruzar quatro camadas — decisão do Google (Search Console), inventário do site (rastreadores próprios), comportamento do rastreador (logs de servidor) e experiência real (CrUX) — e calcular a taxa apenas sobre URLs que deveriam estar indexadas. Cada status de exclusão tem causa e correção próprias, seo setup e confundir Rastreada, mas não indexada com Descoberta, mas não rastreada leva a ações opostas.

Próximos passos concretos: exporte hoje as listas de indexação e exclusão da propriedade e segmente por template e diretório; calcule a taxa de cobertura sobre o conjunto de URLs indexáveis por intenção, não sobre o inventário bruto; rode um rastreamento completo com renderização de JavaScript ativada e compare com o inventário do Search Console; analise quatro semanas de logs para identificar desperdício de orçamento de rastreamento; defina uma política escrita de indexação por tipo de URL e implemente-a no template, não página a página; automatize a extração via API com alertas de variação; e priorize as correções pelo impacto em receita. Repita o ciclo mensalmente — cobertura de indexação é uma métrica de infraestrutura, e infraestrutura se degrada silenciosamente a cada deploy.