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.Sitemaps protocol, maintained jointly by Google, Bing, and others, sets two hard constraints on a single sitemap file: no more than 50,000 URLs, and no larger than 50MB uncompressed. These aren't suggestions. Googlebot will stop parsing the file at whichever limit it hits first.
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) `` sitemap_index.xml ├── sitemap-posts-1.xml (up to 50,000 blog posts) ├── sitemap-posts-2.xml (overflow posts) ├── sitemap-products-1.xml (up to 50,000 products) ├── sitemap-products-2.xml (overflow products) └── sitemap-pages.xml (static pages) ``
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>.<sitemapindex> as the root element instead of <urlset>. Each child is wrapped in a <sitemap> tag with a <loc> pointing to the child file, and optionally a <lastmod> timestamp.
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)
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.sitemap-{type}-{page}.xml . Don't use dates in the filename. I made that mistake on a news site in 2019 and ended up with filenames like sitemap-articles-2019-march.xml that became completely meaningless the moment we needed to regenerate historical content. Stick to numbered pages.
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.<lastmod> element in your child sitemaps should reflect when the content was actually last modified, not when you regenerated the sitemap. I've seen setups where every regeneration stamps every URL with today's date. That trains Googlebot to ignore your lastmod entirely because the signal is noise. Use your CMS's actual modified timestamp. In WordPress, that's post_modified_gmt from the wp_posts table.
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. handles sitemap indexes automatically once you have more than 1,000 URLs per post type. It generates clean, segmented files. But the default batch size is 1,000 URLs per child sitemap, which is conservative. You can filter that up with
wpseo_sitemap_entries_per_page. I usually push it to 5,000 on well-hosted servers. - 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. does the same, with slightly more granular control over which post types and taxonomies get their own child sitemaps. On a recent client site with 80,000 WooCommerce products, Rank Math's segmentation out of the box was cleaner than Yoast's.
- 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. is what I reach for when the site has unusual content types or the plugin-generated sitemaps are too slow to generate. I've written scripts that query the database directly, paginate results in chunks of 10,000, write the XML to disk, and then write the index file last. Runs in under 30 seconds for 200,000 URLs. The key is writing to a temp file and atomically moving it into place so Googlebot never hits a half-written file.
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.Screaming Frog SEO Spider can crawl your site and generate a sitemap index for you, though it's better as a validation tool than a production sitemap generator. For production, generate sitemaps from your data source, not from a crawler. Crawlers miss things.
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.Google Search Console, open the Sitemaps report, and submit your index file URL. One URL. That's it.
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. The "Discovered URLs" count should be climbing toward your actual URL count. If it plateaus weirdly early, you likely have a crawl budget issue or a malformed child sitemap.
- 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. Search Console will show you each child sitemap and its status. If one child is returning an error, you can isolate it without touching the others. This is the underrated advantage of the index structure.
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. If a URL has a noindex meta tag or X-Robots header, it should not be in your sitemap. Full stop. A sitemap is a recommendation to crawl and index. Including noindexed URLs wastes crawl budget and confuses the signal. I run a quick Screaming Frog crawl against the sitemap URLs and filter for noindex responses before any major site launch.
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. Even worse than noindex: URLs that are disallowed in robots.txt but still listed in the sitemap. Googlebot can see the contradiction. It won't penalise you for it, but it's sloppy and it wastes time.
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. This sounds obvious but it trips up custom implementations. You add a new content type, generate a new child sitemap file, and forget to add the <sitemap> entry to the index. The child file exists on disk but nothing points to it. I've seen this sit unnoticed for months.
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. If you have 12 child sitemaps and you submit all 12 to Search Console separately, you've lost the organisational benefit. Submit the index. Let it cascade.
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.Google's documentation on crawl budget is worth reading if you're operating at this scale. The short version: Googlebot has a finite amount of time it'll spend on your site per day, and a well-structured sitemap index helps it spend that time on your highest-priority content first.
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.sitemap-recent.xml that only contains URLs modified in the last 30 days, refreshed hourly. Googlebot recrawls that one aggressively. The older historical sitemap files get crawled less frequently, which is fine because that content isn't changing.
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.need to, but it's worth doing for large files. A 50MB sitemap compresses down to roughly 3-5MB with gzip. Googlebot accepts .xml.gz files without any configuration. Most modern web servers will handle this transparently if you enable gzip compression at the server level. For static-file sitemaps generated to disk, I pre-compress with gzip and serve the .xml.gz directly.
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.