Armadilhas de rastreamento: como achar as que você tem

Uma armadilha de rastreamento é um padrão de URL que gera variações quase infinitas a partir de um único mecanismo — um calendário que aceita qualquer mês e ano na URL, um filtro de loja que multiplica cada combinação de cor, tamanho e preço em uma URL própria, uma busca interna que indexa cada consulta digitada por um visitante. O rastreador encontra essas URLs por meio de links internos, começa a visitá-las, e passa a dividir a atenção que deveria estar concentrada nas suas páginas reais entre milhares de páginas que não deveriam existir como destino de rastreamento.

Isso não é uma questão de orçamento de rastreamento no sentido de capacidade — sites pequenos e médios, sem tráfego suficiente para o Google se preocupar em limitar quantas páginas rastreia por dia, também caem nessa armadilha, porque o problema não é quanto o rastreador pode visitar, e sim o que ele decide visitar quando um gerador de URLs está ativo em algum canto do site. Este texto assume que você não sabe se tem uma armadilha ativa agora, e mostra como descobrir isso com três sinais concretos antes de falar sobre o conserto de cada tipo encontrado.

O sintoma que aparece primeiro

Uma armadilha de rastreamento raramente se anuncia. O que você nota é um efeito colateral: páginas novas demoram semanas para aparecer no índice, atualizações de conteúdo existente não são refletidas na busca por muito mais tempo do que deveriam, ou o relatório de páginas do Google Search Console mostra um número de URLs "conhecidas pelo Google" bem maior do que o número de páginas que você acha que publicou.

Nenhum desses sintomas prova sozinho que existe uma armadilha, porque todos têm outras causas possíveis. É por isso que o diagnóstico não pode parar na sensação de "algo está lento": ele precisa comparar números que, juntos, só fazem sentido se houver um gerador de URLs jogando lixo no caminho do rastreador.

Um indício indireto útil, antes mesmo de abrir logs ou relatórios, é acompanhar se a proporção entre o total rastreado e o tamanho real do site cresce mês a mês sem que o site tenha publicado conteúdo novo na mesma proporção. Quando o rastreador visita cada vez mais URLs enquanto o número de páginas de verdade fica praticamente parado, essa diferença crescente já é motivo suficiente para rodar os três sinais a seguir.

Sinal 1: a contagem do rastreador contra o sitemap

O primeiro número a puxar é quantas URLs distintas o rastreador do Google realmente visitou em um período. O relatório de estatísticas de rastreamento no Search Console, em Configurações, mostra o total de requisições por dia, e o histórico de log bruto do servidor mostra o mesmo dado com mais detalhe, incluindo exatamente quais caminhos foram acessados.

Compare esse total com o número de URLs listadas no seu sitemap XML. Se o sitemap tem, digamos, 800 páginas e o rastreador está acessando 6 mil URLs distintas por mês, a diferença — os outros 5.200 acessos — não veio do nada: são URLs que existem por causa de links internos que alguém colocou no site, não porque foram declaradas como conteúdo a ser indexado. Se a construção e manutenção desse sitemap ainda não são claras para você, isso tem seu próprio guia neste blog; aqui o sitemap entra só como o número de referência para a comparação, não como o assunto principal.

• Estatísticas de rastreamento do Search Console: total de requisições, além da distribuição por tipo de arquivo e por código de resposta
• Contagem de URLs únicas nos logs brutos do servidor no mesmo período
• Contagem de URLs listadas no sitemap XML atual

Sinal 2: agrupar os padrões de URL nos logs

Contar o total não diz onde está o problema. Para isso, você precisa agrupar as URLs dos logs por padrão, não examinar cada uma individualmente. A técnica é simples: pegue o caminho de cada URL acessada pelo rastreador, remova os valores que variam — IDs de produto, datas, termos de busca, valores de parâmetro — e fique só com o "molde": /produto/[id], /busca?q=[termo], /catalogo?cor=[valor]&tamanho=[valor]. Depois conte quantas vezes cada molde aparece no período analisado.

Um catálogo com 400 produtos reais deveria gerar, no molde /produto/[id], algo próximo de uma visita por produto a cada ciclo recente de rastreamento — não 15 mil hits nesse mesmo molde. Quando um único molde concentra uma fração desproporcional das visitas do rastreador em relação ao número de páginas que ele de fato representa, esse molde é o candidato a armadilha. Essa comparação é uma fatia da análise de logs; o processo completo, incluindo como ler o arquivo bruto e quais ferramentas usar, tem seu próprio guia neste blog — aqui o objetivo é só o teste de padrão contra volume.

• Remova IDs, datas e valores de parâmetro até chegar ao "molde" da URL
• Conte hits por molde, não por URL individual
• Compare o número de hits do molde com o número real de páginas que ele deveria representar

Sinal 3: o relatório "rastreada, mas não indexada"

O terceiro sinal vem do relatório de páginas do Search Console, especificamente das categorias "Rastreada, mas não indexada no momento" e "Descoberta, mas não indexada no momento". Exporte a lista de URLs de cada categoria e aplique o mesmo teste de agrupamento por molde que você já usou nos logs.

Se uma fatia grande dessa lista compartilha um padrão — todas terminam em ordenar=preco, ou seguem /eventos/2019/, /eventos/2020/ e assim sucessivamente, ou têm a forma /busca?q= seguida de qualquer coisa — isso confirma o que os logs já sugeriram: o Google está gastando ciclos de rastreamento nessas URLs e decidindo conscientemente não indexá-las. Isso é bem diferente de um problema de qualidade de conteúdo espalhado pelo site inteiro, e muda completamente qual conserto faz sentido aplicar.

Os padrões mais comuns

Na prática, a grande maioria das armadilhas de rastreamento cai em um punhado de mecanismos recorrentes. Reconhecer qual deles está ativo no seu site orienta diretamente qual conserto aplicar depois.

• Parâmetros de URL para ordenação, filtro ou sessão, em que cada combinação gera uma URL própria e rastreável
• Navegação por facetas em catálogos, onde cor, tamanho, preço e marca se multiplicam em URLs distintas
• Calendários de eventos ou agenda que aceitam qualquer mês e ano na URL, inclusive décadas no futuro
• Busca interna cujos resultados geram uma URL indexável para cada consulta digitada por um visitante
• Paginação sem limite superior, aceitando qualquer número de página mesmo além do conteúdo real existente
• IDs de sessão embutidos diretamente na URL em vez de guardados em cookie

Parâmetros e facetas: o conserto que a maioria adia

Esse é o padrão mais comum e também o mais mal resolvido, porque a correção parece contraditória à primeira vista: as páginas de filtro continuam existindo e continuam úteis para quem clica nelas dentro do site — o objetivo não é apagar a funcionalidade, é impedir que cada combinação vire um destino de rastreamento independente.

A base do conserto tem três camadas que trabalham juntas. Primeiro, a tag canônica em cada URL filtrada deve apontar para a versão base da categoria, sem parâmetros, sinalizando qual é a página "real" mesmo quando a versão filtrada continua acessível. Segundo, a disciplina de links internos: o site não deve linkar ativamente para combinações de filtro a partir de menus, trilhas de navegação ou blocos de "produtos relacionados" — se o link não existe em lugar nenhum, o rastreador não descobre essa URL por ali. Terceiro, quando uma combinação específica de filtro realmente merece ser indexada, porque tem volume de busca e intenção próprios, como "tênis azul tamanho 42", ela deixa de ser um parâmetro dinâmico e vira uma URL estática com conteúdo próprio — o inverso de deixar o gerador de facetas criar milhares de páginas automaticamente.

O antigo recurso de tratamento de parâmetros de URL do Search Console foi descontinuado, então hoje a canonicalização e a disciplina de links internos carregam esse trabalho sozinhas. Em casos extremos, bloquear o padrão de parâmetro específico via robots.txt é uma opção, mas só depois que a canonical já estiver no lugar — bloquear antes disso impede o Google de sequer chegar a ler a tag canônica na própria página bloqueada. O guia de navegação por facetas deste blog cobre a arquitetura completa de filtros do ponto de vista de UX e SEO; aqui o foco fica só em fechar a fonte da armadilha.

Calendários, busca interna, paginação e sessão: os consertos rápidos

Calendários com navegação infinita, do tipo "mês seguinte" sem limite algum, pedem um teto explícito: bloquear ou aplicar noindex em datas além de uma janela razoável, por exemplo de doze a dezoito meses à frente, porque nenhum evento real existe além disso e o gerador só está produzindo páginas vazias que o rastreador insiste em visitar mesmo assim.

Páginas de resultado de busca interna devem levar noindex,follow: continuam acessíveis e úteis para quem pesquisa dentro do site, mas param de competir por um lugar no índice, já que uma busca interna reflete a intenção momentânea de um visitante, não um destino de conteúdo estável.

Paginação precisa de um limite superior real, condizente com o volume de itens existente. Uma URL de página 4000 em uma categoria com 50 produtos é, por definição, uma página vazia, e mesmo assim continua sendo gerada e rastreada sempre que o sistema não valida o número solicitado contra o total real de itens da categoria.

URLs com identificador de sessão embutido são o padrão mais fácil de eliminar, ainda que a mudança costume exigir a camada de aplicação, não só ajustes de SEO: mover o identificador de sessão para um cookie faz a mesma página ficar com a mesma URL para qualquer visitante, o que elimina o gerador na origem em vez de tentar conter o que ele já produziu. Enquanto essa mudança não sai, redirecionar de forma permanente qualquer acesso com ID de sessão na URL para a versão limpa, e manter a canonical apontando para essa mesma versão limpa, evita que o rastreador trate cada sessão nova como se fosse uma página inédita.

• Calendário: limitar o intervalo navegável e aplicar noindex além da janela útil
• Busca interna: noindex,follow nos resultados de busca
• Paginação: validar o número da página contra o total real de itens, não aceitar qualquer valor
• Sessão: mover o identificador para cookie e redirecionar de forma permanente as URLs antigas com sessão

Confirmando que o conserto funcionou

Depois de aplicar as correções, volte aos três sinais originais nas semanas seguintes, não no dia seguinte. O rastreador precisa primeiro descobrir que o comportamento mudou, e isso acontece ao longo de vários ciclos de rastreamento, não de forma instantânea.

O sinal mais confiável de melhora é a queda no número de hits do molde de URL problemático nos logs, seguida pela redução da contagem de URLs daquele mesmo padrão dentro de "rastreada, mas não indexada". Quando os dois caem juntos, a atenção liberada tende a aparecer como indexação mais rápida das páginas novas e reais que você publica depois — o mesmo rastreador, gastando os mesmos ciclos, agora com bem menos lixo pelo caminho.