Um cliente me ligou numa terça de manhã na primavera passada, de verdade assustado. Ele administrava um site de anúncios de imóveis, cerca de 42 mil páginas, e o Google Search Console tinha acabado de informar que apenas 5.800 estavam indexadas. Ele tinha perdido aproximadamente 86% de suas páginas indexáveis, aparentemente da noite para o dia. Nenhuma atualização de algoritmo. Nenhuma ação manual. Nenhum deployment recente que ele se lembrasse. Simplesmente... desapareceram.
Ponto-chave: Quando um site WordPress de 40 mil páginas tem 6 mil páginas indexadas, a causa é quase sempre arquitetura: URLs facetadas, templates finos e desperdício de rastreamento, não uma penalidade do Google.
Já vi esse cenário exato mais vezes do que consigo contar, em 12.000+ construções WordPress da Seahawk. E a coisa frustrante é que a perda de indexação em sites grandes raramente tem uma única causa. Geralmente são três ou quatro pequenas falhas que se acumulam silenciosamente até algo desabar.
É assim que realmente faço o diagnóstico.
---
Comece com o Google Search Console, Mas Não Pare Por Aí
A primeira coisa que sempre faço é abrir o relatório Pages no Google Search Console. Não o antigo relatório de Cobertura, o Google atualizou isso em 2023, e a nova visualização Pages decompõe indexadas vs. não indexadas com códigos de motivo apropriados. Tire uma captura de tela no primeiro dia. Você precisa de uma linha de base.
Os códigos de motivo importam enormemente. "Rastreada, atualmente não indexada" é um problema completamente diferente de "Excluída pela tag 'noindex'". Um é uma questão de sinal de qualidade; o outro é um desastre de configuração. Já vi desenvolvedores tratarem ambas identicamente e desperdiçarem semanas perseguindo a coisa errada.
Os Motivos Que Vejo com Mais Frequência em Sites Grandes
- Rastreada, atualmente não indexada: Google visitou a página mas decidiu que não valia a pena indexá-la. Geralmente conteúdo fino, quase-duplicatas, ou páginas que não conquistam backlinks ou links internos.
- Descoberta, atualmente não indexada: Google encontrou a URL (provavelmente no seu sitemap) mas ainda não se incomodou em rastreá-la. Este é um problema de orçamento de rastreamento, não um problema de conteúdo.
- Excluída pela tag 'noindex': Alguém, possivelmente você, possivelmente um plugin, adicionou uma diretiva noindex. Mais sobre isso abaixo.
- Duplicada, o Google escolheu um canonical diferente: Suas tags canonical estão apontando para algum lugar inesperado, ou o Google está substituindo-as.
- Página com redirecionamento: uma página que deveria ser indexável está redirecionando para algum lugar, correta ou incorretamente.
Não olhe apenas para os totais. Baixe a lista completa para cada código de motivo como CSV. Em um site de 40.000 páginas, você precisa ser capaz de classificar e filtrar.
---
Orçamento de Crawl É Real e Vai Destruir Sites Grandes
Lá em 2019, Seahawk estava trabalhando em um grande cliente de e-commerce, cerca de 28 mil páginas de produtos, e não conseguíamos descobrir por que Google estava rastreando apenas cerca de 3 mil páginas por dia. O site era rápido. O sitemap era limpo. Tudo parecia bem na superfície.
Descobri que o site estava gerando milhares de URLs de navegação facetada, ?colour=red&size=large&sort=price, que eram rastreáveis, não estavam canonicalizadas corretamente, e consumiam a cota de rastreamento do Googlebot antes dele chegar às páginas de produto de verdade.
Crawl budget é essencialmente o número de URLs que o Googlebot está disposto a rastrear no seu site dentro de um período determinado. A documentação própria do Google sobre crawl budget realmente vale a pena ler, eles são honestos sobre como funciona. A versão resumida: se você está desperdiçando em URLs inúteis, as páginas importantes não são rastreadas.
Como Realmente Auditar Orçamento de Crawl
- Puxe seus server logs. Não as estatísticas de rastreamento do Google, os server logs reais. Ferramentas como Screaming Frog Log File Analyser permitem que você filtre apenas para hits do Googlebot.
- Veja qual porcentagem das visitas do Googlebot estão chegando em URLs que você realmente se importa. Se for menor que 60%, você tem um problema de orçamento.
- Encontre os padrões de URL que estão consumindo mais crawls. Ordene por frequência. Os principais culpados são quase sempre: navegação facetada, paginação em arquivos paginados, parâmetros de session ID e páginas de arquivo de categoria/tag vazias.
- Corrija a fonte, não apenas o sintoma. Disallow em robots.txt para parâmetros que nunca devem ser rastreados. Tags canonical para todo o resto.
No projeto de e-commerce, bloqueamos as URLs facetadas via robots.txt e adicionamos rel="canonical" a todas as visualizações filtradas. Em seis semanas, as páginas indexadas aumentaram de 8 mil para 24 mil. Mesmo conteúdo. Apenas o Googlebot finalmente conseguindo alcançá-lo.
---
O Desastre do noindex (Acontece Mais Vezes do Que Você Pensa)
Preciso falar sobre isso porque eu mesmo já casei isso. Não foi meu melhor momento. Durante uma migração de staging para produção de um site de notícias em 2021, falhamos em desmarcar "Desestimular mecanismos de busca de indexar este site" em WordPress Configurações → Leitura. O site foi ao ar com noindex em todo o site. Levou onze dias até o cliente notar que o tráfego orgânico tinha despencar.
WordPress esconde aquele checkbox em um lugar que ninguém espera. E certos plugins de SEO, Yoast, Rank Math, até AIOSEO, têm seus próprios toggles de noindex no nível do tipo de post, no nível da taxonomia, e no nível da página individual. Qualquer um deles pode silenciosamente colocar noindex em enormes porções do seu site.
Como Verificar noindex em Escala
Execute Screaming Frog em todo o site e filtre por páginas retornando uma diretiva noindex. Exporte a lista. Depois cruze as referências com seus grupos de URL importantes, páginas de produto, páginas de serviço, posts de blog, tudo que importa para o negócio.
Também verifique seu robots.txt em yourdomain.com/robots.txt. Procure por regras Disallow: muito amplas. Já vi regras como Disallow: /wp-content/ bloqueando CSS e JS que o Google precisa para renderizar páginas corretamente, o que pode causar falhas de renderização que parecem problemas de indexação mas são na verdade o Googlebot vendo uma página quebrada.
---
Tags Canonical Que Estão Silenciosamente Desafinadas
Canonicals são o indexador mais sorrateiro em sites WordPress grandes. Porque parecem corretas isoladamente e só revelam seu dano em escala.
Aqui está um padrão que vejo constantemente: um site com WooCommerce tem produtos acessíveis via múltiplos caminhos de URL, /product/red-shoes/, /product-category/footwear/red-shoes/, e às vezes /shop/red-shoes/. Cada um tem uma tag canônica, mas se essas canônicas apontam para URLs ligeiramente diferentes (HTTP vs HTTPS, barra final vs sem barra final, www vs non-www), o Google as trata como sinais apontando para páginas diferentes e se recusa a consolidar.
A solução é chata, mas necessária:
- Audite toda estrutura de URL que sua instalação WordPress gera. Use o site crawl do Screaming Frog → filtre por "Canonical" → exporte.
- Verifique protocolos incompatíveis, barras finais e variações de subdomínio.
- Certifique-se de que sua canônica sempre corresponde exatamente à sua URL preferida, caractere por caractere.
Rank Math e Yoast ambos geram tags canônicas automaticamente, mas nenhum plugin sabe sobre seus redirecionamentos de .htaccess ou a normalização de URL do seu CDN. Você tem que verificar a canônica renderizada, não apenas o que o plugin acha que está emitindo. Busque a página com uma ferramenta como httpstatus.io e inspecione os headers de resposta reais e o HTML.
---
XML Sitemaps Estão Frequentemente Erradas em Sites Grandes
A maioria dos plugins de SEO do WordPress gera sitemaps automaticamente. A maioria deles também inclui URLs que você não quer no seu sitemap, páginas paginadas (/page/2/, /page/3/), arquivos de autor, páginas de tag com dois posts nelas, páginas de anexo.
Um sitemap deve ser uma lista curta de suas melhores páginas mais canônicas. Não um dump de toda URL que WordPress já gerou.
Regras de Higiene de Sitemap que Realmente Sigo
- Exclua páginas de arquivo paginado. Sempre.
- Exclua páginas de arquivo de autor a menos que seja um site multi-autor onde as páginas de autor tenham valor de conteúdo genuíno.
- Exclua arquivos de tags a menos que as tags sejam gerenciadas editorialmente e tenham conteúdo significativo.
- Defina um limite de contagem de posts, eu geralmente excluo qualquer página de arquivo com menos de cinco posts.
- Divida sitemaps grandes em índices de sitemap. Mantenha arquivos de sitemap individuais abaixo de 10MB e abaixo de 50.000 URLs. Google documentou limites aqui.
No site de listagem de imóveis do início deste post, o sitemap tinha 41.000 URLs incluindo todo arquivo de tag, toda página de paginação, e, isso ainda me dói dizer, a página de login do WordPress. Limpe primeiro. Sempre.
---
Link Interno É uma Questão de Indexação
As pessoas não pensam em link interno como uma ferramenta de indexação. Deveriam.
Se uma página não tem links internos apontando para ela, o Googlebot pode nunca encontrá-la em primeiro lugar, mesmo que esteja no seu sitemap. Sitemaps dizem ao Google que uma URL existe. Links internos dizem ao Google que uma URL importa. São sinais diferentes.
Em grandes sites de conteúdo, páginas órfãs são abundantes. Um post de blog publicado três anos atrás, linkado apenas do arquivo de posts mas nunca linkado de nenhum outro post, verá sua frequência de rastreamento cair para praticamente nada ao longo do tempo.
Uso o relatório "Orphan Pages" do Screaming Frog (em Site Structure) para identificar páginas no sitemap que têm zero links internos apontando para elas. Depois volto pelo conteúdo para encontrar lugares lógicos para adicionar links. Não links forçados, realmente relevantes. Leva tempo mas o impacto na indexação é real.
---
Um Checklist de Diagnóstico Sistemático
Se eu estivesse passando isso para um desenvolvedor junior na Seahawk, aqui está a ordem em que eu teria eles trabalhando:
- Puxe Google Search Console → relatório Pages → baixe todas as URLs não-indexadas com códigos de razão.
- Verifique robots.txt para disallows amplos acidentais.
- Verifique se o checkbox "Discourage search engines" do WordPress está desligado.
- Execute Screaming Frog e filtre por diretivas noindex no nível da página.
- Verifique tags canônicas, saída renderizada, não configurações de plugin.
- Puxe os logs do servidor e verifique a distribuição de rastreamento do Googlebot entre os tipos de URL.
- Audite o sitemap XML para URLs inúteis (paginação, arquivos vazios, variantes não-canônicas).
- Execute o relatório de Orphan Pages e identifique páginas sem links internos.
- Verifique navegação com facetas ou URLs baseadas em parâmetros gerando caminhos duplicados rastreáveis.
- Verifique a velocidade da página; páginas que têm timeout consistente recebem menor prioridade do Googlebot.
Não tente corrigir tudo de uma vez. Corrija uma categoria de problema, espere três a quatro semanas para o Google rastrear novamente, meça e depois passe para a próxima. Se você mudar tudo simultaneamente, nunca saberá o que realmente funcionou.
---
FAQ
Por que as páginas são indexadas uma semana e depois removidas na próxima?
O índice do Google não é estático. Ele constantemente reavalia páginas com base em sinais de qualidade, atualização e eficiência de rastreamento. Uma página que foi indexada seis meses atrás pode ser removida se não ganhou nenhum link, não está sendo vinculada internamente, ou se a avaliação de qualidade do Google sobre seu domínio mudou. Isso é especialmente comum após uma migração de site ou uma reformulação significativa de conteúdo, o Google rastreia novamente, reavalia, e às vezes decide que páginas previamente indexadas não atendem mais ao padrão.
A velocidade do site afeta a indexação?
Sim, mais diretamente do que a maioria das pessoas percebe. Se páginas são lentas para responder, consistentemente acima de 2-3 segundos para a resposta inicial do servidor, o Googlebot vai deprioritizar rastreá-las. Em escala, isso significa que páginas lentas simplesmente não são rastreadas com frequência suficiente para permanecerem indexadas. Corrija seu Time to First Byte (TTFB) antes de se preocupar com qualquer outra coisa relacionada a velocidade. Um plugin de cache barato como WP Rocket faz uma diferença mensurável. Core Web Vitals importam para rankings, mas TTFB importa para rastreamento.
Muitas páginas em um sitemap podem prejudicar a indexação?
Não diretamente, mas um sitemap inchado com URLs de baixa qualidade dilui o sinal que você está enviando ao Google sobre o que importa. Se seu sitemap contém 40.000 URLs e 30.000 delas são páginas de arquivo finas, o Google aprende a tratar seu sitemap como ruído. Mantenha sitemaps enxutos e de alta qualidade. Pense nisso como curadoria editorial, não como um inventário de URLs.
Devo usar a ferramenta de Inspeção de URL do Google para solicitar indexação manualmente?
Para páginas individuais importantes, sim, absolutamente. Mas não tente solicitar indexação manual para milhares de URLs. Não escala e o Google disse que não dá tratamento especial a URLs solicitadas manualmente a longo prazo. Corrija os problemas de rastreamento e qualidade subjacentes e deixe o rastreamento natural do Google fazer o trabalho. Use inspeção manual para verificar que páginas específicas podem ser indexadas, não para forçar a indexação de tudo.
---
A verdade honesta é que diagnóstico de indexação não é trabalho glamouroso. É planilhas, arquivos de log, e muito tempo esperando. Mas em um site grande, até mesmo recuperar 20% das suas páginas indexadas perdidas pode significar um salto significativo no tráfego orgânico, e em uma propriedade de listagens de 40.000 páginas, isso é dinheiro real. Acerte o básico antes de perseguir qualquer coisa exótica. Quase nunca é exótico.