Um cliente me ligou numa terça de manhã na primavera passada -- puro pânico na voz. Ele rodava um site de listagens imobiliárias, cerca de 42 mil páginas, e o Google Search Console tinha acabado de avisar que apenas 5.800 delas estavam indexadas. Ele havia perdido aproximadamente 86% de suas páginas indexáveis, aparentemente do dia para a noite. Nenhuma atualização de algoritmo. Nenhuma ação manual. Nenhum deploy recente que ele se lembrasse. Simplesmente... desaparecidas.
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.When a 40,000-page WordPress site has 6,000 pages indexed, the cause is almost always architecture: faceted URLs, thin templates, and crawl waste, not a Google penalty.
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.WordPress builds. And the maddening thing is that indexation loss on large sites rarely has one cause. It's usually three or four small failures that compound quietly until something collapses.
É assim que realmente faço o diagnóstico.
---
Comece Pelo 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 Coverage -- 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 um screenshot no primeiro dia. Você precisa de uma linha de base.Pages report in Google Search Console. Not the old Coverage report -- Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
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 perderem 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 ela não valia a pena indexar. Geralmente conteúdo fino, quase-duplicatas, ou páginas que não ganham backlinks ou links internos.: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- Descoberta -- atualmente não indexada: Google encontrou a URL (provavelmente no seu sitemap) mas ainda não se importou em rastreá-la. Este é um problema de orçamento de rastreamento, não um problema de conteúdo.: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- Excluída pela tag 'noindex': Alguém -- possivelmente você, possivelmente um plugin -- adicionou uma diretiva noindex. Mais sobre isso abaixo.: Someone -- possibly you, possibly a plugin -- added a noindex directive. More on this below.
- Duplicada, o Google escolheu um canonical diferente: Suas tags canonical estão apontando para algum lugar inesperado, ou o Google está substituindo-as.: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- Página com redirecionamento: uma página que deveria ser indexável está redirecionando para algum lugar, correta ou incorretamente.: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
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, a Seahawk estava trabalhando com um grande cliente de e-commerce -- cerca de 28 mil páginas de produtos -- e não conseguíamos descobrir por que o Google estava rastreando apenas cerca de 3 mil páginas por dia. O site era rápido. O sitemap era limpo. Tudo parecia estar bem na superfície.
Descobrimos 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 estavam consumindo a cota de rastreamento do Googlebot antes dele chegar às páginas de produtos reais.?colour=red&size=large&sort=price -- that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
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 do próprio Google sobre crawl budget realmente vale a pena ler -- eles são honestos sobre como funciona. Em resumo: se você está desperdiçando em URLs inúteis, as páginas importantes não são rastreadas.Google's own documentation on crawl budget is genuinely worth reading -- they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
Como Realmente Auditar Orçamento de Crawl
- Puxe seus server logs. Não as estatísticas de rastreamento do Google -- logs reais do servidor. Ferramentas como Screaming Frog Log File Analyser permitem que você filtre apenas os acessos do Googlebot.Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- 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.
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
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.robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
---
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 essa caixa de seleção em um lugar que ninguém espera. E certos plugins de SEO -- Yoast, Rank Math, até mesmo 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 grandes porções do seu site.
Como Verificar noindex em Escala
Execute o Screaming Frog no site completo e filtre páginas que retornam uma diretiva noindex. Exporte a lista. Depois faça referência cruzada com seus grupos de URLs importantes -- páginas de produtos, páginas de serviços, posts do blog, o que importa para o negócio.noindex directive. Export the list. Then cross-reference against your important URL groups -- product pages, service pages, blog posts, whatever matters to the business.
Verifique também seu robots.txt em yourdomain.com/robots.txt. Procure por regras Disallow excessivamente amplas. Já vi regras como Disallow: /wp-content/ bloqueando CSS e JS que o Google precisa para renderizar as páginas corretamente -- o que pode causar falhas de renderização que parecem problemas de indexação, mas na verdade são o Googlebot vendo uma página quebrada.robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly -- which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
---
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 por múltiplos caminhos de URL -- /product/red-shoes/, /product-category/footwear/red-shoes/ e às vezes /shop/red-shoes/. Cada um tem uma tag canonical, mas se essas canonicals 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 consolidá-las./product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to consolidate.
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..htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and 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./page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
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 -- 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.documented limits here.
No site de listagens de imóveis do início deste post, o sitemap tinha 41 mil URLs incluindo todos os arquivos de tags, todas as páginas de paginação e -- isso ainda dói falar -- a página de login do WordPress. Limpe isso 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. Esses são sinais diferentes.matters. Those are different signals.
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.
Eu 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. Aí trabalho de volta 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.
robots.txtfor accidental broad disallows. - 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 as tags canônicas -- saída renderizada, não as configurações do 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 expiram consistentemente são depriorizadas pelo 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 crawl. Uma página que foi indexada seis meses atrás pode ser removida se não tiver conquistado links, não estiver sendo ligada internamente, ou se a avaliação de qualidade do Google para seu domínio tiver mudado. Isso é especialmente comum após uma migração de site ou uma reformulação significativa de conteúdo -- Google faz crawl novamente, reavalia, e às vezes decide que páginas previamente indexadas não atendem ao padrão mais.
A velocidade do site afeta a indexação?
Sim, mais diretamente do que a maioria das pessoas percebe. Se as páginas são lentas para responder -- consistentemente acima de 2-3 segundos para a resposta inicial do servidor -- o Googlebot vai depriorizá-las no crawling. Em escala, isso significa que páginas lentas simplesmente não são crawleadas 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 crawling.Core Web Vitals matter for rankings, but TTFB matters for crawling.
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 mil URLs e 30 mil delas são páginas de arquivo fino, Google aprende a tratar seu sitemap como ruído. Mantenha sitemaps compactos e de alta qualidade. Pense nisso como curadoria editorial, não como 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 manualmente a indexação para milhares de URLs. Não escala e Google disse que não dá tratamento especial a URLs solicitadas manualmente a longo prazo. Corrija os problemas subjacentes de crawl e qualidade e deixe o crawling natural do Google fazer o trabalho. Use a inspeção manual para verificar que páginas específicas podem ser indexadas, não para forçar a indexação de tudo.can be indexed, not to force index everything.
---
A verdade honesta é que diagnóstico de indexação não é trabalho glamouroso. É planilhas, arquivos de log e muito tempo de espera. Mas em um site grande, até recuperar 20% de suas páginas indexadas perdidas pode significar um salto significativo no tráfego orgânico -- e em um site de 40 mil páginas de listagens de imóveis, isso é dinheiro de verdade. Acerte o básico antes de perseguir qualquer coisa exótica. Quase nunca é exótica.