Se o Google Search Console mostra seu índice de sitemap como Sucesso enquanto Páginas descobertas fica em zero, e os sitemaps filhos continuam em "Não foi possível buscar" não importa quantas vezes você reenvie, provavelmente você não está olhando para um problema de servidor. Você está olhando para um backoff por URL dentro do agendador de sitemap do Google. A forma mais rápida de comprovar é reenviar o arquivo idêntico em uma URL ligeiramente diferente e observar o que acontece.
Esse diagnóstico me levou seis meses, cinco auditorias separadas e quatro modelos de IA diferentes. O teste que finalmente resolveu levou 14 segundos.
Ponto-chave: Um índice de sitemap pode reportar Sucesso enquanto cada sitemap filho nele fica invisível para o Google. Se seus logs de borda não mostram nenhuma solicitação do Googlebot para um filho "Não foi possível buscar", a falha está do lado do Google, não do seu. Reenviar o mesmo arquivo em uma URL versionada como /sitemap/0.xml?v=20260815 contorna o backoff e processa em segundos.
O que "Sucesso" estava realmente reportando
O site é Deluxe Astrology, a plataforma de astrologia Védica dos meus pais e a coisa maior que gerencio: aproximadamente 240.000 URLs em 30 idiomas, publicada a partir do Supabase e servida como um índice de sitemap com 63 sitemaps filhos sob ela. Escrevo sobre a arquitetura por trás dela na página do projeto Deluxe Astrology.
As páginas indexadas vinham caindo há semanas. Impressões despencaram no final de junho. E o único sistema cujo trabalho inteiro é entregar ao Google uma lista de URLs atualizadas estava mostrando uma marca verde.
Abra o índice de sitemap no Search Console e ele diz "Índice de sitemap processado com sucesso". Clique nele e a tabela de leitura de Sitemaps diz 0-0 de 0. O Google havia buscado o índice três vezes separadas em três semanas, analisou-o corretamente como um índice e não registrou nenhum de seus filhos. Nenhum sitemap filho foi jamais buscado. Quando enviei três deles diretamente, ficaram em "Não foi possível buscar" por horas.
Essa é a armadilha. O status em um índice de sitemap é uma declaração apenas sobre o arquivo de índice. Ele informa que o XML foi analisado e as URLs filhas pareciam bem formadas. Ele não informa se o Google foi realmente ler as páginas. Essa distinção fica escondida em uma tabela que a maioria das pessoas nunca faz scroll, e é tudo que importa em qualquer site grande o bastante para precisar de um índice de sitemap em primeiro lugar.
Tudo no servidor foi verificado, cinco vezes separadas
Se você recebeu "Não foi possível buscar", você sabe como a próxima hora vai. Você faz curl da URL. Você verifica robots.txt. Você verifica o firewall. Você verifica o cache da CDN. Você executa o teste ao vivo em Inspeção de URL. Tudo volta limpo. Então você se diz a mentira clássica do Search Console: só precisa de tempo, volte em 24 a 72 horas.
Ao longo dos meses isso se tornou uma investigação genuinamente minuciosa, e não apenas por mim. Rodei o problema através de vários modelos de fronteira como auditores independentes: Claude, Kimi, GLM e um par de agentes customizados, cada um com acesso à base de código, aos dados do Search Console e aos logs de borda. Já escrevi antes sobre quantos modelos de IA realmente vale a pena executar de uma vez, e esse foi o caso que mais testou.
Eles concordaram em quase tudo, e estavam certos em quase tudo:
- O índice de sitemap ao vivo serviu um
<sitemapindex>válido com todos os 63 filhos, tipo de conteúdo correto, sem marca de ordem de byte, sem URLs entre hosts. - Cada filho serviu um
<urlset>válido com as contagens de URL esperadas. - O fetch ao vivo do próprio Googlebot do índice e de um filho, através da URL Inspection, retornou o XML real. "URL está disponível para Google."
- Os logs de borda mostraram requisições reais do Googlebot para o índice sendo permitidas e servidas com 200 do cache.
- Nada em robots.txt, middleware, redirects ou configuração de CDN tocou os caminhos do sitemap.
Um erro anterior era real e já havia sido corrigido. Um limite de taxa por IP no WAF, adicionado meses antes para combater uma bot farm que estava queimando minha conta de hospedagem, havia estado desafiando o tráfego de crawlers por um tempo. Essa regra foi corrigida. Após a correção, cada auditoria chegou à mesma conclusão: o lado do servidor está limpo, Google precisa de tempo, verifique novamente em 24 a 72 horas.
Cinco auditorias. Mesmo veredicto. Mesma recomendação. Os números nunca se moveram.
O indício era uma ausência, não um erro
O fato desconfortável estava escondido nos logs de borda, no que não estava lá. Após enviar três sitemaps filhos, não houve requisição do Googlebot para nenhum deles. Não uma permitida, não uma desafiada, não uma negada. Google não estava falhando em buscar os filhos. Google estava escolhendo não tentar.
Você não pode diagnosticar isso do servidor, por construção. Nada chega para inspecionar. Cada ferramenta do kit padrão é construída para explicar uma requisição que deu errado, e não havia requisição. Esta é a única classe de problema que análise de arquivo de log resolve por omissão em vez de por evidência: você vai procurando pelos hits, e a resposta é o conjunto de resultados vazio.
O teste ao vivo do Search Console piora isso, porque ele ignora qualquer agendador que está fazendo essa escolha. Ele busca sob demanda, de um caminho de código diferente, e relata alegremente "disponível" para uma URL que o subsistema de sitemap não colocará na fila. Um teste ao vivo verde não é prova de que o pipeline de sitemap jamais tocará o arquivo.
A API disse a verdade que a UI não diria
A Search Console Sitemaps API deu o primeiro sinal honesto. A UI diz "Não foi possível buscar", o que se lê como uma falha com uma causa. A API retorna isPending: true com errors: 0 e nenhum timestamp de lastDownloaded.
Essas são reivindicações diferentes. "Não foi possível buscar" implica uma tentativa que falhou. isPending com zero erros significa que nunca houve uma tentativa. Seis meses de depuração haviam sido direcionados a uma falha que não existia.
Se você executa algo em escala, tenha a API conectada antes de precisar dela. É um escopo OAuth e algumas linhas de código, e é a diferença entre uma string de status projetada para tranquilidade e o estado real do registro. Confio muito nela em meu Claude Code SEO audit workflow exatamente por esse motivo.
O experimento controlado
Em vez de executar uma sexta auditoria, executei um controle.
Primeiro, uma linha de base. Enviei um sitemap que Google nunca havia visto antes, um pequeno para uma seção secundária do site. Ele foi baixado e processado 34 segundos após o envio. Então o pipeline estava saudável, o host era alcançável, e Google estava disposto a buscar sitemaps deste domínio agora.
Então o teste real. Reenvi um dos filhos presos, byte por byte idêntico, servido pela mesma rota no mesmo servidor, com exatamente uma diferença: uma string de consulta no final. /sitemap/0.xml?v=20260815.
| Envio | Estado do Google | Tempo para processar |
|---|---|---|
| `/sitemap/0.xml` | Pendente após 2h 30m | Nunca |
| Novo sitemap, nunca enviado antes | Processado | 34 segundos |
| `/sitemap/0.xml?v=20260815` (arquivo idêntico) | Processado, 2.187 URLs | 14 segundos |
Mesmo arquivo. Mesmo servidor. Mesmos bytes. String diferente. Um ficou invisível por duas horas e meia e contando, o outro foi lido em 14 segundos.
Esse é o diagnóstico completo, e é a razão pela qual continuo argumentando que um teste controlado supera outra rodada de verificação. Cada auditoria tinha confirmado fatos sobre o servidor. Nenhuma havia variado o único input que se mostrou relevante.
O que estava realmente acontecendo
O sistema de sitemap do Google mantinha aquelas 63 URLs exatas em um backoff de falha por URL.
Meses antes, toda leitura do índice tinha disparado uma rajada de 63 buscas de child a partir de um único IP do Google em segundos. Esse é o comportamento normal do Googlebot para um índice: ele lê o pai e depois vai buscar os filhos mais ou menos ao mesmo tempo. O limite de taxa por IP no WAF, dimensionado para tráfego humano médio, viu uma rajada de 63 requisições de um endereço e fez o que estava configurado para fazer. Desafiou-as. A cada ciclo. Por semanas.
A única requisição do índice em si sempre conseguiu passar, porque uma requisição não é uma rajada. É por isso que o índice continuava lendo "Sucesso" enquanto seus filhos nunca chegavam a existir. A regra estava perfeitamente moldada para quebrar exatamente as URLs que eu mais precisava que o Google lesse, enquanto deixava a URL que relata sobre elas intocada.
Corrigir o firewall não limpou a memória do Google das URLs que tinham falhado. Apenas parou de criar novas falhas. O backoff naquelas 63 strings específicas sobreviveu ao conserto, e nada sobre esperar ia expirar isso em uma escala de tempo que eu pudesse observar.
O conserto: 63 envios, zero deploys
Através da API do Search Console reenviei todos os 63 filhos com a string de versão query. Em cerca de dois minutos cada um deles tinha sido buscado e processado: 155.545 URLs registradas no Google, zero erros, zero avisos. Páginas descobertas, que tinham lido zero por meio ano, popularam enquanto eu observava.
O conserto durável é uma mudança de duas linhas na próxima versão: fazer o índice do sitemap emitir as URLs de child versionadas, para que o índice e robots.txt apontem para URLs que o Google está disposto a ler. Aumente o token de versão sempre que a lógica de geração muda e você consegue um mecanismo de cache-busting gratuito.
Uma ressalva honesta. Indexação não é descoberta. O Google está rastreando este host em um gotejamento após meses de desconfiança, e 155.000 URLs não são varridas em uma semana. Descoberta funcionando novamente é a pré-condição, não o resultado. Se seu crawl budget já está apertado, corrigir o sitemap é onde o trabalho começa.
Por que cinco auditorias convergiram na resposta errada
Essa é a parte para a qual continuo voltando.
Os modelos eram excelentes em verificação. Dada uma afirmação sobre tipo de conteúdo, cache headers, diretivas robots ou middleware, eles verificavam com precisão e relatavam honestamente. O que nenhum deles fez, por conta própria, foi propor enviar o mesmo arquivo com um nome diferente para ver o que acontecia.
Convergência em um ponto cego compartilhado parece exatamente como consenso. Cinco auditores lendo a mesma evidência com a mesma suposição, que uma falha de busca implica uma tentativa de busca, produzirão cinco concordâncias confiantes e zero progresso. A concordância parece confirmação. Na verdade é correlação entre os auditores, não entre os auditores e a realidade.
O que quebrou o impasse não foi outra auditoria. Foi decidir que seis meses de "aguarde 72 horas" era uma hipótese e não um plano, e desenhar um teste onde a única variável era a string da URL. Isso é um trabalho humano, e não acho que deixe de ser em breve.
As cinco regras que tirei disso
- Sucesso em um índice de sitemap é sobre o arquivo de índice, não os filhos. Role até "Sitemaps read". Se disser zero, o tick verde é decorativo.
- "Couldn't fetch" na interface significa "não processado ainda" na API. Leia a API.
isPendingelastDownloadedsão o que você realmente precisa saber, e a interface não mostra nenhum dos dois. - Google lembra dos seus erros de infraestrutura mais tempo do que você. Um limite de taxa que desafiou o crawler por algumas semanas pode deixar URLs específicas em backoff muito depois que a regra desaparece. Esperar não limpa isso de forma confiável. Versionar a URL sim.
- Dimensione limites de taxa para rajadas do crawler, não para tráfego médio. Uma leitura de índice dispara N buscas de filhos de um IP em segundos. Qualquer limite por IP abaixo de N desafiará exatamente as URLs que você mais precisa que o Google leia, enquanto o próprio índice passa e relata sucesso.
- Quando vários modelos concordam que o servidor está limpo e você deve esperar, eles provavelmente estão certos sobre o servidor e errados sobre a espera. Execute um controle em vez de uma sexta auditoria.
Se você acha que tem o mesmo problema
Trabalhe nisso em ordem. Leva uns quinze minutos e separa um problema de servidor de um backoff do lado do Google de forma limpa.
- Abra o índice de sitemap no Search Console e leia a contagem de Sitemaps read, não o status. Zero filhos lidos em um índice saudável é a assinatura.
- Puxe os mesmos sitemaps através da API do Search Console. Anote
isPending,errorselastDownloadedpara cada um. - Pesquise seus logs de edge ou CDN por requisições do Googlebot para os caminhos de filho específicos nos últimos 30 dias. Nenhuma requisição, de nenhum status, significa que o problema não está no seu servidor.
- Envie um URL de sitemap totalmente novo que o Google nunca viu. Se for processado em menos de um minuto, seu host e seu pipeline estão bem.
- Reenvie um filho preso com uma string de consulta de versão. Se aquele for processado e a URL simples não, você tem sua resposta e o remédio no mesmo passo.
- Audite seus limites de taxa de WAF contra comportamento de rajada, não médias, para que o backoff não se reconstrua. Depois verifique o resto dos seus fundamentos de indexação em sites grandes.
Para o material de referência por trás de tudo isso, o próprio guia do Google para construir e enviar um sitemap e o protocolo sitemaps.org ainda são os dois únicos documentos que importam. Nenhum menciona backoff por URL, o que é parte do motivo pelo qual isso demorou tanto.
Se você executa um site com mais de 100.000 URLs e está preso no mesmo sintoma, esse é o tipo de coisa que faço para viver: SEO técnico em sites grandes, incluindo as construções de SEO programático onde sitemaps deixam de ser uma formalidade e viram todo o canal de distribuição. Tenho os scripts da API, a sequência de diagnóstico e as cicatrizes.
FAQ
Por que meu índice de sitemap diz Sucesso mas mostra zero páginas descobertas?
Porque o status se refere apenas ao arquivo de índice. Google analisou seu <sitemapindex> e encontrou URLs de filho bem formadas, que é tudo que "Sucesso" afirma. Se depois buscou esses filhos é reportado separadamente na tabela Sitemaps read. Zero lido em um índice válido significa que os filhos nunca foram processados, e o tick verde não está dizendo nada útil.
O que "Couldn't fetch" realmente significa no Search Console?
Menos do que parece. Na Search Console API o mesmo sitemap geralmente retorna isPending: true com errors: 0 e sem valor lastDownloaded, o que significa que o Google ainda não tentou fazer o download em vez de ter tentado e falhado. Verifique a API antes de gastar tempo debugando uma falha que pode nunca ter ocorrido.
Quanto tempo devo esperar antes de assumir que um sitemap está realmente travado?
Um sitemap que o Google está disposto a ler geralmente é processado em segundos a minutos, não em dias. Se um sitemap filho está pendente por mais de cerca de 24 horas enquanto um novo sitemap URL no mesmo host é processado imediatamente, esperar mais tempo não é uma estratégia. Execute o teste de resubmissão versionada em vez disso.
Adicionar uma query string a uma URL de sitemap causa conteúdo duplicado ou outros problemas de SEO?
Não. Um sitemap é um arquivo de descoberta, não uma página indexável, e as URLs dentro dele não mudam. O Google trata /sitemap/0.xml e /sitemap/0.xml?v=20260815 como dois recursos de sitemap distintos, que é exatamente a propriedade que você está explorando. Aponte seu índice e robots.txt para as URLs versionadas para que haja um conjunto canônico em jogo.
Um rate limit de WAF pode quebrar a descoberta de sitemap sem quebrar mais nada?
Sim, e é isso que torna tão difícil de detectar. Ler um índice de sitemap dispara uma rajada de downloads de filhos a partir de um único IP do Google em segundos, então um limite por IP dimensionado para tráfego humano desafiará os filhos enquanto a única solicitação de índice passa. Tudo mais no site, incluindo testes de Inspeção de URL em tempo real, continua funcionando perfeitamente.
Corrigir o sitemap restaurará imediatamente as impressões perdidas?
Não. Descoberta e indexação são estágios separados. Obter 155.000 URLs registradas restaura a entrada no pipeline, mas a taxa de rastreamento em um host que está falhando há meses se recupera gradualmente, e as decisões de indexação seguem o rastreamento. Espere semanas e use o tempo para garantir que as páginas sendo descobertas valem a pena ser indexadas.