Índice de Sitemap

TL;DR — Um índice de sitemap é um sitemap de sitemaps. Um único sitemap pode conter apenas 50 000 URLs, então sites grandes dividem suas URLs em vários sitemaps e depois listam esses sitemaps em um pequeno arquivo “índice”. Você envia apenas o índice, e os mecanismos de busca o seguem para todos os demais.

O que é um índice de sitemap

Um sitemap XML normal é uma lista das URLs das suas páginas. Um índice de sitemap é um nível acima: é um arquivo que lista os seus outros sitemaps em vez de listar páginas. Pense nele como um sumário que aponta para vários capítulos, onde cada capítulo é um sitemap cheio de URLs.

Você entrega o índice aos mecanismos de busca, e eles o leem para encontrar cada sitemap que ele referencia, e então leem cada um deles para encontrar suas URLs. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

Por que você precisaria de um

Um único sitemap tem limites rígidos: ele pode conter no máximo 50 000 URLs, e o arquivo não pode ser maior que 50MB sem compressão. No momento em que você tem mais URLs do que isso — ou o arquivo fica grande demais — você precisa dividi-lo em vários sitemaps. O índice de sitemap é o que une essas partes novamente para que você envie apenas uma coisa.

Você não precisa esperar até atingir o limite, também. Muitos sites grandes usam um índice apenas para manter tudo organizado — um sitemap para o blog, um para produtos, um por idioma — mesmo quando cada parte está bem abaixo de 50 000 URLs.

Quanto ele pode cobrir?

Muito. Um índice pode listar até 50 000 sitemaps filhos, e cada um deles pode conter até 50 000 URLs. Multiplique isso e um único índice já cobre 2,5 bilhões de URLs. Qualquer que seja o tamanho do seu site, você nunca ficará sem capacidade de sitemap.

Como você o usa

• Divida suas URLs em vários arquivos de sitemap (a maioria dos plugins e frameworks de SEO faz isso automaticamente por você).
• Coloque um arquivo de índice de sitemap no topo que liste cada um desses sitemaps.
• Envie apenas o índice no Google Search Console e no Bing Webmaster Tools. Esse único envio cobre todos os filhos.

Quer a anatomia, os limites exatos, a regra de “não aninhe um índice em um índice” e o truque de divisão que transforma seus sitemaps em um diagnóstico de indexação? Mude para a aba Avançado.

TL;DR — Um índice de sitemap é um sitemap de sitemaps — um arquivo <sitemapindex> listando entradas <sitemap> (<loc> + <lastmod> opcional) em vez de URLs. Você precisa de um assim que um único sitemap excederia 50 000 URLs ou 50MB sem compressão, ou para organizar um site grande com várias seções/regiões. Um índice pode referenciar até 50 000 sitemaps filhos × 50 000 URLs cada = 2,5 bilhões de URLs por índice; com até 500 arquivos de índice por site no Search Console, o teto teórico é 1,25 trilhão — um número que nenhum site real se aproxima. Os filhos permanecem no mesmo site no mesmo nível de diretório ou abaixo, você não aninha um índice dentro de um índice (não há tag para isso, nem suporte de ferramentas), e você envia apenas o índice. A recompensa que vale a pena buscar: divida por seção/tipo de conteúdo para que você possa ler enviado-vs-indexado por segmento.

O que um arquivo de índice de sitemap realmente é

Um índice de sitemap é um sitemap cujas entradas são outros sitemaps. Onde um sitemap regular envolve blocos <url> em um <urlset>, um índice envolve blocos <sitemap> em um <sitemapindex>. Cada <sitemap> tem um <loc> apontando para um dos seus arquivos de sitemap e, opcionalmente, um <lastmod>. Essa é toda a estrutura — ele não carrega URLs de página próprias. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

Ele existe por uma razão: o formato de sitemaps tem limites rígidos de tamanho, e sites grandes os ultrapassam. Então você divide suas URLs em muitos sitemaps e usa um índice para apresentá-los aos mecanismos de busca como uma unidade única.

Quando você precisa de uma

Dois gatilhos:

1. Você atingiu os limites de tamanho. Um único sitemap tem o máximo de 50 000 URLs ou 50MB descompactados, o que vier primeiro. A orientação do Google é direta: “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” Evidence for this claim A sitemap index can list up to 50,000 sitemap files, and each sitemap is limited to 50,000 URLs or 50 MB uncompressed. Scope: Google-supported sitemap and sitemap-index limits. Confidence: high · Verified: 2026-07-14 Google Search Central: Manage sitemaps with a sitemap index file (tradução) «Se você tiver um sitemap que exceda os limites de tamanho, precisará dividir seu sitemap grande em vários sitemaps.» Depois de dividir, um índice une as partes.
2. Você quer organizar um site grande — mesmo abaixo do limite. Sites com várias seções (blog vs. produtos vs. páginas de categoria) e sites multirregionais/multi-idiomas são muito mais fáceis de gerenciar e monitorar como sitemaps separados sob um único índice. Esse uso organizacional é, na minha opinião, a melhor razão para usar um índice, e eu volto a ele na aba Frameworks.

Anatomia

O índice é pequeno e simples por design — <sitemapindex>, depois um bloco <sitemap> por filho, cada um com um <loc> e um <lastmod> opcional:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap1.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap2.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
</sitemapindex>

Notas que importam:

• O namespace é o mesmo sitemaps.org/schemas/sitemap/0.9 que você usa em um sitemap comum; o arquivo é UTF-8 e os valores de <loc> são URLs absolutas totalmente qualificadas.
• Os filhos podem ser compactados com gzip — .xml.gz é aceitável, e o limite de 50MB é medido no tamanho descompactado.
• O <lastmod> opcional aqui descreve quando aquele sitemap filho mudou pela última vez, não quando páginas individuais mudaram.

Quantos você pode enviar — e quantas páginas isso representa?

É aqui que as pessoas subestimam o teto. Some os limites:

• O Google Search Console aceita até 500 arquivos de índice de sitemap por site: “You can submit up to 500 sitemap index files for each site in your Search Console account.” (tradução) «Você pode enviar até 500 arquivos de índice de sitemap para cada site na sua conta do Search Console.»
• Cada índice pode listar até 50 000 sitemaps filhos.
• Cada sitemap filho pode conter até 50 000 URLs.

Faça a multiplicação e o teto teórico é 500 × 50 000 × 50 000 = 1,25 trilhão de URLs (1.250.000.000.000). Trate isso como um teto que nenhum site real se aproxima, não como uma meta — a conclusão é simplesmente que você nunca vai ficar sem capacidade de sitemap. E raramente você precisa complicar com vários arquivos de índice: um único índice de sitemap, sem enviar nenhum outro, já cobre 50 000 × 50 000 = 2,5 bilhões de URLs. Se você tem 2,5 bilhões de URLs indexáveis, sua configuração de sitemap não é o seu problema.

Regras de localização

Os sitemaps filhos que um índice referencia precisam estar no mesmo site que o índice, e no mesmo nível de diretório ou inferior ao arquivo de índice. Um índice em https://www.example.com/sitemap-index.xml pode apontar para https://www.example.com/sitemaps/products.xml, mas não para um sitemap em um host diferente ou acima do seu próprio caminho. Se quebrar isso, o Search Console marca os filhos como “URL not allowed.” (Referências entre domínios só são válidas quando ambos os domínios estão verificados no Search Console — mas para um índice comum de site único você não vai por aí.)

Não aninhe um índice dentro de outro índice

Um índice de sitemap lista sitemaps, não outros índices. Nem a página do protocolo ao vivo do sitemaps.org nem a documentação de índice de sitemap do Google afirmam isso em muitas palavras hoje — verifiquei ambos diretamente em vez de confiar em uma paráfrase mais antiga. O que o protocolo diz é mais restrito: a tag <loc> dentro de um <sitemapindex> é definida como identificando “a Sitemap, an Atom file, RSS file or a simple text file” — um arquivo de índice não está nessa lista, e o formato não tem tag para aninhar um índice dentro de outro. Todo gerador de sitemap, plugin e mecanismo de busca que eu conheço trata índice-de-índices como não suportado com base nisso; é uma convenção forte de profissionais fundamentada na estrutura do formato, em vez de uma única frase citável de qualquer um dos documentos. Trate como uma regra rígida: apenas um nível de indexação. Se você se pegar querendo um índice-de-índices, quase certamente tem espaço para reorganizar dentro do teto de 2,5 bilhões de URLs que um único índice já te dá.

Envie apenas o índice

Você envia o arquivo de índice, e esse único envio puxa todos os sitemaps filhos que ele referencia — você não precisa enviar os filhos um por um. John Mueller colocou de forma clara: “You can submit the individual ones, but you don’t really need to.” (tradução) «Você pode enviar os individuais, mas não precisa realmente.» Enviar tanto o índice quanto seus filhos não é prejudicial, apenas redundante. Um envio limpo do índice é o caminho.

Dito isso, enviar um sitemap — índice ou não — é um auxílio de descoberta, não uma garantia de indexação. O índice ajuda os mecanismos a encontrar seus sitemaps; não promete que as URLs dentro deles sejam rastreadas ou indexadas.

Estratégia de divisão — para monitoramento, não eficiência de rastreamento

Aqui está a parte que é subestimada em todos os outros lugares. Como você divide seus sitemaps em um índice não muda como o Google rastreia ou indexa suas páginas. O motivo para dividir com cuidado é o monitoramento. O enquadramento de Mueller é o que eu uso: “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” (tradução) «Eu geralmente recomendo dividir um arquivo de sitemap em partes lógicas do seu site para que você possa monitorar essas partes individualmente (por exemplo, páginas de categoria vs páginas de detalhes…). … Isso não muda como o Google rastreia e indexa, é realmente apenas para que você possa acompanhá-los melhor do seu lado.»

O retorno prático: o relatório de Sitemaps no Search Console mostra contagens de enviados vs indexados por sitemap. Divida seu índice por seção ou tipo de conteúdo — blog, produtos, categorias, documentação, por região — e você pode ver qual segmento está subindexado em vez de olhar para um único número do site inteiro. Esse é um diagnóstico que uso constantemente. (É o mesmo motivo pelo qual mantenho um sitemap de URLs antigas durante uma migração: para poder observar esse conjunto específico sair do índice no GSC.)

Então divida pelo que você quer medir, não por algum benefício imaginário de rastreamento. O benefício de rastreamento não existe; o benefício de monitoramento é real.

Como isso se relaciona com o resto da família de sitemaps

Um índice de sitemap fica no topo dos seus XML sitemaps regulares, e a visão geral mais ampla de sitemaps é o lugar para começar se você é novo no tópico inteiro. Seus image e video sitemaps são apenas mais arquivos filhos que um índice pode referenciar, e todo o aparato faz parte de como os mecanismos de busca lidam com descoberta. Nenhum deles precisa de links daqui — são irmãos no mesmo cluster.

Resumo de IA

Uma visão condensada da versão Avançada:

• Um índice de sitemap é um sitemap de sitemaps — um arquivo <sitemapindex> listando entradas <sitemap> (<loc> + <lastmod> opcional), não URLs de página.
• Você precisa de um quando um único sitemap excederia 50 000 URLs ou 50MB descompactado, ou quando você quer organizar um site grande com várias seções/regiões (o uso organizacional é o melhor motivo).
• Capacidade é efetivamente ilimitada: até 50 000 sitemaps filhos por índice × 50 000 URLs cada = 2,5 bilhões de URLs por índice. Com até 500 arquivos de índice por site no Search Console, o teto teórico é 1,25 trilhão de URLs — um número que nenhum site real se aproxima.
• Regras: os filhos ficam no mesmo site, no mesmo nível de diretório ou inferior; não aninhe um índice dentro de um índice (o formato não tem tag para isso, e nenhum gerador ou mecanismo de busca suporta); os filhos podem ser compactados com gzip (.xml.gz).
• Envie apenas o índice — um envio cobre todos os filhos. Enviar os filhos também é redundante, não prejudicial (Mueller: “you don’t really need to” — «você não precisa realmente»).
• Dividir é para monitoramento, não eficiência de rastreamento. Isso não muda o rastreamento ou a indexação; divida por seção/tipo de conteúdo para que você possa ler enviados vs indexados por segmento no relatório de Sitemaps do Search Console.

Documentação oficial

Documentação de fonte primária sobre arquivos de índice de sitemap e os limites por trás deles.

Google

• Gerenciar sitemaps grandes com um arquivo de índice de sitemap — dividir além dos limites, o formato do índice de sitemap e o limite de 500 arquivos de índice por site.
• Criar e enviar um sitemap — o limite de 50 000 URLs / 50MB sem compressão, UTF-8 e as regras de URL absoluta que se aplicam a todo sitemap.
• Visão geral dos sitemaps — o que é um sitemap e o enquadramento de “descoberta, não garantia de indexação”.

sitemaps.org

• Protocolo XML de sitemaps — a especificação canônica: o formato <sitemapindex>, o limite de 50 000 sitemaps / 50MB no índice e a regra de que “um arquivo de índice não pode listar outros arquivos de índice”.

Citações da fonte

Declarações registradas do Google e do protocolo sitemaps.org. Cada link é um link profundo que salta para a passagem citada na página de origem.

Google — limites de divisão e envio

• “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” (tradução) «Se você tiver um sitemap que exceda os limites de tamanho, precisará dividir seu sitemap grande em vários sitemaps.» — Google, Gerenciar sitemaps grandes. Ir para a citação
• “You can submit up to 500 sitemap index files for each site in your Search Console account.” (tradução) «Você pode enviar até 500 arquivos de índice de sitemap para cada site na sua conta do Search Console.» Ir para a citação

sitemaps.org — os limites de tamanho do protocolo (veja a nota de rodapé abaixo para a origem da regra de não aninhamento, que não é uma citação isolada)

• “Sitemap index files may not list more than 50,000 Sitemaps and must be no larger than 50MB (52,428,800 bytes) and can be compressed.” (tradução) «Arquivos de índice de sitemap não podem listar mais de 50.000 sitemaps e devem ter no máximo 50MB (52.428.800 bytes) e podem ser compactados.» — protocolo sitemaps.org. Ir para a citação

John Mueller, Google — dividir para monitoramento e enviar apenas o índice

• “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” (tradução) «Geralmente recomendo dividir um arquivo de sitemap em partes lógicas do seu site para que você possa monitorar essas partes individualmente (por exemplo, páginas de categoria vs páginas de detalhes…). … Isso não muda como o Google rastreia e indexa, é realmente apenas para que você possa acompanhá-las melhor do seu lado.» Ir para a citação
• “You can submit the individual ones, but you don’t really need to.” (tradução) «Você pode enviar os individuais, mas não precisa realmente.» Ir para a citação

Índice de sitemap — folha de referência de limites

Os números que definem sua capacidade

Fatos rápidos

• Um índice de sitemap lista sitemaps, não URLs — <sitemapindex> envolvendo blocos <sitemap> (<loc> + <lastmod> opcional).
• Você precisa de um quando um único sitemap excederia 50 000 URLs ou 50MB, ou para organizar um site grande com várias seções/regiões.
• Os filhos devem estar no mesmo site, no mesmo nível de diretório ou inferior ao do índice.
• Os filhos podem ser compactados com gzip (.xml.gz).
• Não aninhe um índice dentro de outro índice (não há tag para isso, não é suportado por nenhum gerador ou mecanismo).
• Envie apenas o índice — ele cobre todos os filhos; enviar os filhos também é redundante.
• Divida por seção/tipo de conteúdo para relatórios, não para eficiência de rastreamento — isso não muda o rastreamento/indexação.

Como dividir um índice de sitemap (divida pelo que você mede)

O modelo mental que importa aqui: como você divide não muda o rastreamento — isso muda o que você pode monitorar. O Google rastreia e indexa as mesmas URLs, estejam elas em um sitemap ou em cinquenta. Então escolha suas linhas de divisão para corresponder aos segmentos que você quer ler de forma independente no relatório de Sitemaps do Search Console (enviado vs. indexado, por sitemap).

Divida por tipo de conteúdo

• /sitemaps/blog.xml, /sitemaps/products.xml, /sitemaps/categories.xml, /sitemaps/docs.xml.
• Melhor quando modelos diferentes têm comportamentos de indexação diferentes — por exemplo, variantes de produtos com conteúdo raso sendo sub-indexadas enquanto seu blog vai bem. Você verá exatamente qual modelo é o problema.

Divida por seção

• Um sitemap filho por seção principal do site ou subpasta.
• Melhor para sites grandes onde equipes são donas de seções diferentes — cada dono recebe um número de cobertura limpo para sua área.

Divida por região / idioma

• Um filho por localidade (/sitemaps/en.xml, /sitemaps/de.xml, …).
• Melhor para sites internacionais: você pode identificar uma localidade inteira que não está sendo captada, separada de quaisquer problemas de hreflang.

A regra de decisão

• Pergunte: “Se um desses segmentos estivesse sub-indexado, eu gostaria de vê-lo de forma isolada?” Se sim, essa é uma linha de divisão. Se a resposta for “nunca analisaria isso separadamente”, não divida ali — você está apenas criando mais arquivos para manter.

Um uso de migração no qual confio

• Durante uma migração de site, mantenho um sitemap das URLs antigas no índice por um tempo — não para que sejam indexadas, mas para vê-las sair do índice no GSC conforme as novas URLs assumem. O relatório em nível de segmento é o ponto principal.

O ângulo de eficiência de rastreamento que as pessoas esperam da divisão não é real. O ângulo de relatórios é, e vale a pena projetar seu índice em torno disso.

Um índice de sitemap mínimo válido

Esta é a forma completa de um arquivo de índice de sitemap — uma raiz <sitemapindex>, depois um bloco <sitemap> por sitemap filho, cada um com um <loc> e um <lastmod> opcional. Os filhos podem ser compactados com gzip (.xml.gz); o limite de 50MB é medido descompactado.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemaps/blog.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/products.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/categories.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
</sitemapindex>

Regras incorporadas nesse exemplo:

• A raiz é <sitemapindex> (não <urlset>) no namespace sitemaps.org/schemas/sitemap/0.9; o arquivo é UTF-8.
• Cada <loc> é uma URL absoluta totalmente qualificada no mesmo site, no mesmo nível de diretório ou inferior ao deste índice.
• <lastmod> é opcional e descreve quando esse sitemap filho mudou.
• Não adicione uma entrada <sitemap> apontando para outro índice de sitemap — apenas um nível.

Como você o envia

Você envia apenas este arquivo de índice — um envio, e os mecanismos de busca o seguem até cada sitemap filho. Não há necessidade de enviar os filhos separadamente.

# robots.txt — point engines at the index (the Sitemap: line takes the index URL)
Sitemap: https://www.example.com/sitemap-index.xml

Em seguida, adicione a mesma URL do índice no Google Search Console (relatório de Sitemaps) e no Bing Webmaster Tools. É isso — os filhos vêm junto.

Ferramentas para criar e verificar um índice de sitemap

• Google Index Checker — depois de enviar o índice, use esta ferramenta para verificar se URLs específicas de um sitemap filho realmente entraram no índice do Google, em vez de esperar o número agregado do Search Console.
• Google Search Console — relatório de Sitemaps — o principal lugar para acompanhar um índice enviado: status de busca por sitemap filho e contagens de enviados versus indexados que você pode ler por segmento se dividir com cuidado.
• Bing Webmaster Tools — Sitemaps — o relatório equivalente para o Bing; envie a mesma URL do índice lá também.
• Seu gerador de sitemap / plugin de CMS — a maioria dos frameworks e plugins de SEO cria o índice e os arquivos filhos automaticamente conforme sua contagem de URLs cresce; o XML manual na aba Scripts é para quando você precisa ver (ou construir manualmente) a estrutura você mesmo.

Lista de verificação antes de enviar o índice de sitemap

Passe por esta lista antes de apontar o Search Console ou o Bing Webmaster Tools para um índice novo ou reestruturado:

• Cada sitemap filho tem menos de 50 000 URLs e 50MB descompactados (com margem — não construa até o limite máximo).
• O arquivo de índice lista apenas sitemaps, nunca outro índice de sitemap.
• Cada <loc> filho está no mesmo site, no mesmo nível de diretório ou inferior ao arquivo de índice.
• Índice e filhos são XML válido, UTF-8, com o elemento raiz correto (<sitemapindex> para o índice, <urlset> para cada filho).
• robots.txt tem uma linha Sitemap: apontando para o índice, não para um dos filhos.
• Suas linhas de divisão (seção, tipo de conteúdo ou região) correspondem a algo que você realmente queira monitorar separadamente no Search Console — não divida arbitrariamente.
• Apenas o índice está na fila para envio — você não precisa também enviar cada sitemap filho um por um.

Erros a evitar com um índice de sitemap

• Aninhar um índice dentro de outro índice. O formato não tem tag para isso — o <loc> de um índice de sitemap identifica apenas um sitemap, Atom, RSS ou arquivo de texto, nunca outro índice — e nenhum gerador ou mecanismo de busca suporta isso. Em vez disso: mantenha um nível de indexação e, se você for tentado a ir mais fundo, quase certamente há espaço para reorganizar sua divisão dentro do limite de 2,5 bilhões de URLs que um único índice já oferece.
• Enviar cada sitemap filho individualmente além do índice. Não é prejudicial, apenas redundante — o envio do índice já puxa todos os filhos que ele referencia. Em vez disso: envie apenas o índice no Search Console e no Bing Webmaster Tools.
• Dividir sitemaps esperando ganho de orçamento de rastreamento ou de ranqueamento. Como você divide não muda como o Google rastreia ou indexa suas páginas. Em vez disso: divida puramente para relatórios — escolha linhas que você realmente queira monitorar de forma independente no relatório de Sitemaps.
• Apontar um sitemap filho para um host, subdomínio ou diretório diferente acima do índice. O Search Console sinaliza isso como “URL não permitida.” Em vez disso: mantenha cada filho no mesmo site, no nível do diretório do índice ou inferior.
• Deixar um sitemap crescer além de 50 000 URLs ou 50MB descompactados em vez de dividir antecipadamente. Em vez disso: divida proativamente quando uma seção estiver se aproximando do limite, não depois que já estiver quebrada.

Problemas comuns com um índice de sitemap

Sintoma: o Search Console mostra “Não foi possível buscar” no índice. Causa provável: a URL do índice retorna 404, expira ou é bloqueada por robots.txt. Correção: abra a URL exata do índice em um navegador (ou no Validador de Sitemap) e confirme que ela retorna 200 com XML válido antes de reenviar.

Sintoma: o índice é buscado normalmente, mas um sitemap filho específico mostra um erro. Causa provável: um <loc> dentro desse filho aponta para uma URL com erro 404, não canônica ou de domínio errado, ou o próprio filho tem XML malformado. Correção: abra esse sitemap filho diretamente e verifique as entradas <loc>; corrija ou regenere esse arquivo e aguarde a próxima busca.

Sintoma: “O arquivo de índice de sitemap não pode referenciar outro índice de sitemap” (ou a entrada é ignorada silenciosamente). Causa provável: você aninhou um índice dentro de outro índice, o que nenhum gerador ou mecanismo de busca suporta — o formato não prevê que a tag <loc> aponte para outro arquivo de índice. Correção: achate para um único nível — o índice de nível superior deve apontar apenas para sitemaps que listam URLs, nunca para outros índices.

Sintoma: “URL não permitida” em uma entrada de sitemap filho. Causa provável: esse filho está em um host/subdomínio diferente do índice, ou acima do diretório do próprio índice. Correção: mova o filho para o mesmo site, no mesmo nível de diretório ou abaixo (referências entre domínios só funcionam quando ambos os domínios estão verificados no Search Console — e para um índice comum de site único você não deve precisar disso).

Sintoma: um índice ou sitemap filho é rejeitado por tamanho. Causa provável: excede 50 000 URLs, ou 50 MB sem compressão para um sitemap / 50 MB para o próprio arquivo de índice. Correção: divida ainda mais — adicione outro sitemap filho (ou, para um site muito grande, outro índice) em vez de tentar incluir mais.

Prove que o novo índice de sitemap realmente foi aplicado

Teste: carregue a URL do índice diretamente (navegador ou curl -I). Resultado esperado: HTTP 200, XML válido, raiz <sitemapindex>. Interpretação de falha: um 404/timeout aqui significa que o Search Console também não consegue acessá-lo — corrija isso antes de qualquer outra coisa. Janela de monitoramento: imediata. Gatilho de reversão: resposta não-200 sustentada — reverta para a configuração anterior de sitemap.

Teste: envie o índice no relatório de Sitemaps do Search Console (ou execute-o pelo Validador de Sitemap primeiro). Resultado esperado: o status muda para uma busca bem-sucedida e as linhas de cada sitemap filho aparecem. Interpretação de falha: “Não foi possível buscar” significa um problema de URL, hospedagem ou robots.txt, ainda não um problema de indexação. Janela de monitoramento: de horas a um dia para a primeira busca. Gatilho de reversão: falhas repetidas de busca em reenvios.

Teste: verifique a contagem de URLs de cada sitemap filho em relação ao que seu site realmente tem para esse segmento. Resultado esperado: as contagens estão na faixa correta para essa seção/tipo de conteúdo. Interpretação de falha: uma grande discrepância geralmente significa que o gerador está incluindo URLs obsoletas, não canônicas ou duplicadas. Janela de monitoramento: imediata, logo após a geração. Gatilho de reversão: nenhum — corrija a lógica do gerador e regenere.

Teste: verifique as contagens de enviadas versus indexadas por sitemap no relatório de Sitemaps. Resultado esperado: a contagem indexada tende a se aproximar da contagem enviada para cada segmento ao longo do tempo. Interpretação de falha: um segmento preso bem abaixo da contagem enviada aponta para um problema específico desse segmento (conteúdo raso, duplicação, noindex deixado por engano) em vez do próprio índice. Janela de monitoramento: de 2 a 4 semanas para a tendência ser significativa. Gatilho de reversão: a contagem indexada de um segmento caindo ativamente após a mudança, não apenas permanecendo estável.

Teste: confirme se o robots.txt ainda contém a linha Sitemap: correta. Resultado esperado: a linha resolve para a URL do índice atual. Interpretação de falha: uma linha ausente ou desatualizada não quebra a descoberta para mecanismos que já conhecem seu índice, mas remove um dos seus sinais de descoberta para qualquer coisa que rastreie do zero. Janela de monitoramento: imediata. Gatilho de reversão: linha ausente ou apontando para um arquivo descontinuado — restaure-a.

KPIs contínuos para um índice de sitemap

Métrica: contagem de enviados vs. indexados, por segmento de sitemap. O que ela indica: qual seção, tipo de conteúdo ou região está subindexada, em vez de um único número geral do site. Como obter: no relatório Sitemaps do Search Console, lido por sitemap enviado. Referência / faixa realista: não há meta fixa — não existe um número universal honesto aqui. Um estado saudável parece com a contagem indexada próxima da contagem enviada para aquele segmento; uma lacuna grande e persistente em um segmento (e não nos outros) é o sinal que vale investigar, não um percentual específico. Cadência: semanal durante uma migração ou um lançamento grande; mensal caso contrário.

Métrica: status de busca do sitemap, por índice e por filho. O que ela indica: se os mecanismos conseguem ler os arquivos que você enviou — um pré-requisito para tudo o mais nesta lista. Como obter: a coluna de status no relatório de Sitemaps (ou o Validador de Sitemap para uma verificação sob demanda). Referência / faixa realista: isto não é uma faixa — “Sucesso” é o único estado aceitável; “Não foi possível buscar” ou “Tem erros” é um estado de falha para corrigir imediatamente, não algo para tolerar em alguma taxa. Cadência: verifique sempre que você mexer no código de geração de sitemap ou adicionar um novo filho; caso contrário, uma verificação mensal.

Métrica: contagem de URLs e tamanho do arquivo por sitemap, contra os limites. O que ela indica: quanta margem você tem antes de um segmento precisar ser dividido ainda mais. Como obter: as próprias contagens do seu gerador de sitemap, ou o Validador de Sitemap. Referência / faixa realista: fique confortavelmente abaixo de 50 000 URLs e 50 MB sem compressão por arquivo — deixe margem real em vez de chegar perto do teto. Cadência: monitore conforme sua contagem de URLs cresce; divida novamente um segmento quando ele estiver se aproximando do limite, não depois de já estar quebrado.

Prompts de IA para um índice de sitemap

Prompt: verificação de sanidade de uma divisão proposta. Cole uma descrição curta das seções do seu site (aproximadamente quantas URLs cada uma tem) e peça a uma IA para verificar a sanidade das suas linhas de divisão antes de você construir o índice:

I'm building a sitemap index for a site with these sections and approximate
URL counts:
- Blog: <N> URLs
- Product pages: <N> URLs
- Category pages: <N> URLs
- <other sections>

I want to split these into child sitemaps under one sitemap index so I can
read submitted-vs-indexed coverage per section in Google Search Console.
Given these counts, suggest a sensible way to split them into child
sitemaps (staying well under 50,000 URLs and 50MB uncompressed per file),
and flag any section that's small enough it probably doesn't need its own
child sitemap.

Espere de volta: um agrupamento proposto das suas seções em sitemaps filhos, com uma nota sobre qualquer seção pequena demais para valer a pena separar.

Prompt: revisar um índice de sitemap existente para erros estruturais. Cole o XML bruto do seu índice de sitemap (ou um trecho representativo) e peça uma revisão estrutural:

Here is my sitemap index XML:

<paste your <sitemapindex> XML here>

Check it against these rules and flag any violation:
1. The root element is <sitemapindex>, not <urlset>.
2. No <sitemap> entry points at another sitemap index file.
3. Every <loc> is a fully-qualified, absolute URL on the same site as this
   index.
4. No <loc> sits at a directory level above this index's own path.
List any entries that break these rules and explain which rule each one
breaks.

Espere de volta: uma lista linha por linha de quaisquer entradas que violem as regras de aninhamento ou localização, para que você possa corrigi-las antes de reenviar.

Recursos que valem seu tempo

Meus escritos relacionados

• Quando você deve se preocupar com o orçamento de rastreamento? — onde sitemaps limpos e completos se encaixam na eficiência de rastreamento em sites grandes.
• Migração de site: o checklist pré e pós-lançamento — incluindo manter um sitemap de URLs antigas para observar elas saírem do índice no GSC.
• SEO técnico empresarial — sitemaps com automação em primeiro lugar e o diagnóstico de enviados vs. indexados em escala.
• O guia para iniciantes em SEO técnico — onde sitemaps e descoberta se encaixam no panorama geral.

Oficial

• Google — Gerenciar sitemaps grandes com um arquivo de índice de sitemap.
• Protocolo sitemaps.org — a especificação canônica <sitemapindex> e limites.

De outros

• r/TechSEO — a comunidade para depuração de sitemaps, rastreamento e indexação.
• Bing Webmaster Tools — Enviar um sitemap — orientação da Bing sobre como enviar arquivos de índice de sitemap e verificá-los no Bing Webmaster Tools.
• Search Engine Journal — Cobertura de sitemaps — inclui cobertura verbatim de perguntas e respostas de Mueller sobre sitemaps e artigos sobre rastreamento e indexação.
• Onely — Recursos de sitemap — análises aprofundadas de SEO técnico de uma agência focada em rastreamento; cobre problemas de sitemap em grande escala e diagnósticos de indexação.

Teste-se: Índice de sitemap

Cinco perguntas rápidas sobre o que é um índice de sitemap e como usá-lo. Escolha uma resposta para cada uma e depois confira.

Registro de alterações