Em 2021 herdei um site WooCommerce com 140.000 URLs de produtos, um único sitemap.xml que chegava a exatamente 50.000 entradas, e um cliente que não conseguia entender por que o Google Search Console mostrava apenas uma fração de suas páginas indexadas. O arquivo de sitemap simplesmente... parava. Sem erro. Sem aviso. Apenas truncamento silencioso. É o tipo de coisa que custa seu ranking sem nunca enviar um sinal visível de que algo está errado.
Se seu site está crescendo além de 50.000 URLs, este post é o que você precisa ler antes de bater nessa barreira.
Por Que o Limite de 50.000 URLs Existe
O protocolo Sitemaps, mantido conjuntamente por Google, Bing e outros, estabelece duas restrições rígidas em um único arquivo de sitemap: não mais de 50.000 URLs e não maior que 50MB descompactados. Estas não são sugestões. O Googlebot para de fazer parse do arquivo quando atinge qualquer um dos limites primeiro.
Honestamente, o limite de 50MB raramente é o problema. A maioria das URLs é curta o suficiente que você precisaria de caminhos comicamente longos para atingir o limite de tamanho de arquivo antes do limite de contagem de URLs. O limite de 50.000 URLs é o que afeta as pessoas.
Então, o que você faz quando seu catálogo, seu arquivo de blog, sua seção de conteúdo gerado pelo usuário ultrapassa esse limite? Você usa um arquivo de índice de sitemap.
O Que um Arquivo de Índice de Sitemap Realmente É
Conceito simples. Em vez de um sitemap com URLs nele, você cria um arquivo XML pai que aponta para múltiplos sitemaps filhos. Cada sitemap filho pode armazenar até 50.000 URLs. O arquivo de índice em si pode referenciar até 50.000 sitemaps filhos. Então o teto teórico é 2,5 bilhões de URLs. Você não vai chegar lá.
A estrutura fica assim:
`` sitemap_index.xml ├── sitemap-posts-1.xml (até 50.000 posts de blog) ├── sitemap-posts-2.xml (posts em excesso) ├── sitemap-products-1.xml (até 50.000 produtos) ├── sitemap-products-2.xml (produtos em excesso) └── sitemap-pages.xml (páginas estáticas) ``
O arquivo de índice usa <sitemapindex> como elemento raiz em vez de <urlset>. Cada filho é envolvido em uma tag <sitemap> com um <loc> apontando para o arquivo filho, e opcionalmente um timestamp <lastmod>.
O que você envia ao Google Search Console é a URL do arquivo de índice, não cada filho individual. Uma submissão, uma única fonte de verdade.
Como Dividir Suas URLs de Forma Inteligente
É aqui que a maioria dos tutoriais erra. Eles dizem "apenas divida suas URLs em grupos de 50.000" e deixam por isso. Mas os limites dos grupos importam para a manutenibilidade e para a lógica de rastreamento do Googlebot.
Eu divido por tipo de conteúdo, não por número arbitrário. Sempre. Toda vez.
Divida por tipo de conteúdo primeiro
- Produtos em sua própria série de sitemaps (sitemap-products-1.xml,
sitemap-products-2.xml) - Posts de blog em sua própria série
- Páginas de categoria e tag juntas (são navegacionais, trate-as como um grupo)
- Páginas estáticas (Sobre, Contato, landing pages) em um único arquivo, normalmente bem abaixo de 1.000 URLs
Por que isso importa? Porque quando um banco de dados de produtos recebe uma atualização em massa, apenas os sitemaps de produtos precisam ser regenerados. Você não está invalidando e regenerando um arquivo monolítico que mistura produtos com posts de blog. O Googlebot também tende a rastrear sitemaps sequencialmente, então agrupar por tipo oferece um sinal mais claro sobre que tipo de conteúdo ele vai encontrar.
Depois faça paginação dentro de cada tipo
Uma vez que um tipo de conteúdo excede 50.000 URLs, faça paginação dele. Use uma convenção de nomenclatura consistente desde o primeiro dia. Eu uso sitemap-{type}-{page}.xml. Não use datas no nome do arquivo. Cometi esse erro em um site de notícias em 2019 e acabei com nomes de arquivo como sitemap-articles-2019-march.xml que se tornaram completamente sem sentido no momento em que precisávamos regenerar conteúdo histórico. Mantenha-se em páginas numeradas.
Mantenha o lastmod honesto
O elemento <lastmod> em seus sitemaps filhos deve refletir quando o conteúdo foi realmente modificado pela última vez, não quando você regenerou o sitemap. Já vi configurações onde cada regeneração marca cada URL com a data de hoje. Isso treina o Googlebot a ignorar seu lastmod completamente porque o sinal é ruído. Use o timestamp de modificação real do seu CMS. No WordPress, esse é o post_modified_gmt da tabela wp_posts.
Ferramentas: O que Realmente Funciona em Escala
Para sites WordPress (que é a maior parte do que construímos na Seahawk), as opções que realmente uso são:
- Yoast SEO manipula índices de sitemap automaticamente quando você tem mais de 1.000 URLs por tipo de post. Gera arquivos limpos e segmentados. Mas o tamanho de lote padrão é 1.000 URLs por sitemap filho, o que é conservador. Você pode aumentar isso com
wpseo_sitemap_entries_per_page. Normalmente eu o coloco em 5.000 em servidores bem hospedados. - Rank Math faz o mesmo, com controle ligeiramente mais granular sobre quais tipos de post e taxonomias ganham seus próprios sitemaps filhos. Em um site cliente recente com 80.000 produtos WooCommerce, a segmentação padrão do Rank Math era mais limpa que a do Yoast.
- Geração customizada com WP-CLI é o que eu uso quando o site tem tipos de conteúdo incomuns ou os sitemaps gerados por plugin são muito lentos para gerar. Já escrevi scripts que consultam o banco de dados diretamente, paginam resultados em chunks de 10.000, gravam o XML em disco e depois gravam o arquivo de índice por último. Executa em menos de 30 segundos para 200.000 URLs. A chave é gravar em um arquivo temporário e movê-lo atomicamente para o lugar, para que o Googlebot nunca acesse um arquivo meio escrito.
Para stacks fora do WordPress, Screaming Frog SEO Spider consegue rastrear seu site e gerar um índice de sitemap para você, embora seja melhor como uma ferramenta de validação do que um gerador de sitemap em produção. Para produção, gere sitemaps da sua fonte de dados, não de um rastreador. Rastreadores deixam coisas de fora.
Enviando e Validando no Search Console
Vá para Google Search Console, abra o relatório de Sitemaps e envie a URL do seu arquivo de índice. Uma URL. É isso.
Após o envio, aguarde 24-48 horas e depois verifique duas coisas:
- Enviado vs Descoberto. A contagem de "URLs Descobertas" deve estar subindo em direção à sua contagem real de URLs. Se ela chegar a um patamar estranho cedo demais, você provavelmente tem um problema de orçamento de rastreamento ou um sitemap filho malformado.
- Status individual de cada sitemap filho. O Search Console mostrará cada sitemap filho e seu status. Se um filho estiver retornando erro, você consegue isolá-lo sem tocar nos outros. Essa é a vantagem subestimada da estrutura de índice.
Bing Webmaster Tools funciona da mesma forma. Envie o arquivo de índice, não os filhos. Leva dois minutos.
Erros Comuns que Vejo Constantemente
Seahawk faz auditoria de sites para agências com bastante regularidade. Os mesmos erros de sitemap aparecem repetidamente.
URLs com noindex no sitemap. Se uma URL tem uma meta tag noindex ou cabeçalho X-Robots, ela não deveria estar no seu sitemap. Ponto final. Um sitemap é uma recomendação para rastrear e indexar. Incluir URLs com noindex desperdiça crawl budget e confunde o sinal. Faço um rastreamento rápido com Screaming Frog contra as URLs do sitemap e filtro respostas noindex antes de qualquer lançamento importante de site.
URLs bloqueadas no sitemap. Pior ainda que noindex: URLs que são disallowed no robots.txt mas ainda listadas no sitemap. O Googlebot consegue ver a contradição. Não vai penalizá-lo por isso, mas é desleixado e desperdiça tempo.
Não atualizar o arquivo de índice após adicionar um novo sitemap filho. Isso parece óbvio mas pega implementações customizadas. Você adiciona um novo tipo de conteúdo, gera um novo arquivo sitemap filho, e esquece de adicionar a entrada <sitemap> no índice. O arquivo filho existe no disco mas nada aponta para ele. Já vi isso passar despercebido por meses.
Enviar sitemaps filhos individualmente em vez do índice. Se você tem 12 sitemaps filhos e envia todos os 12 para o Search Console separadamente, você perdeu o benefício organizacional. Envie o índice. Deixe cascatear.
Crawl Budget: A Visão Maior
Arquivos de índice sitemap conectam diretamente ao gerenciamento de crawl budget. A documentação do Google sobre crawl budget vale a pena ler se você está operando nessa escala. A versão curta: Googlebot tem uma quantidade finita de tempo que vai gastar no seu site por dia, e um sitemap index bem estruturado ajuda ele a gastar esse tempo no seu conteúdo de prioridade mais alta primeiro.
Eu coloco conteúdo recém-atualizado em seu próprio sitemap filho em sites grandes. Algumas implementações que fiz usam um sitemap-recent.xml que contém apenas URLs modificadas nos últimos 30 dias, atualizado a cada hora. O Googlebot rastreia esse arquivo de forma agressiva. Os arquivos de sitemap histórico mais antigos são rastreados com menos frequência, o que é normal porque esse conteúdo não está mudando.
Isso não é um truque. É apenas fazer o sinal de rastreamento corresponder à realidade do conteúdo.
FAQ
Quantos sitemaps filho um arquivo de índice de sitemap pode conter?
O protocolo permite até 50.000 sitemaps filho em um único arquivo de índice. Na prática, se você está se aproximando desse número, você tem centenas de milhões de URLs e está lidando com problemas que a maioria dos sites nunca enfrenta. Para a grande maioria dos sites grandes, você terá algo entre 5 e 50 sitemaps filho.
Preciso compactar meus arquivos de sitemap com gzip?
Você não precisa, mas vale a pena fazer para arquivos grandes. Um sitemap de 50MB é compactado para aproximadamente 3-5MB com gzip. O Googlebot aceita arquivos .xml.gz sem nenhuma configuração. A maioria dos servidores web modernos tratará isso de forma transparente se você ativar a compressão gzip no nível do servidor. Para sitemaps de arquivo estático gerados em disco, eu pré-comprimo com gzip e sirvo o .xml.gz diretamente.
Devo incluir sitemaps de imagem ou vídeo no índice?
Sim. Se você está usando extensões de sitemap de imagem ou sitemaps de vídeo, eles podem ser incluídos como sitemaps filho no mesmo arquivo de índice. Mantenha-os em seus próprios arquivos filho em vez de misturar dados de imagem em seus sitemaps de URL padrão. Isso mantém os arquivos menores e facilita a regeneração apenas do sitemap de imagem quando sua biblioteca de mídia é atualizada.
O que acontece se um sitemap filho retorna um 404?
O Search Console sinalizará esse child como erro no relatório de Sitemaps. O Googlebot ainda processará os outros child sitemaps no índice. Não invalidará todo o índice, mas as URLs listadas apenas naquele child com erro 404 não serão descobertas pelo sitemap. Corrija prontamente. O erro persiste no relatório do Search Console por semanas mesmo após você corrigi-lo, o que é incômodo mas inofensivo.
Posso usar um sitemap index em um site pequeno?
Tecnicamente sim, mas não há motivo para isso. A complexidade adicional não compensa abaixo de 10.000 URLs. Um único sitemap.xml é mais simples de manter, mais simples de debugar e faz exatamente o mesmo trabalho. Use um arquivo de índice quando precisar, não antes.
---
O limite de 50.000 URLs pega as pessoas desprevenidas toda vez, geralmente no pior momento possível, como logo antes de um lançamento de produto. Acertar a estrutura do índice uma vez significa que você nunca precisa pensar nela novamente conforme o site cresce. Vale a pena uma hora de configuração.
Leitura relacionada: Pesquisa de palavras-chave em busca com IA em 2026: o que é, por que tradicional, busca com IA e SEO multilíngue.