¿Qué es un índice de sitemaps?

El protocolo de sitemaps impone dos techos a cada fichero: 50.000 URLs y 50 MB sin comprimir. Un sitio corporativo de doscientas páginas nunca se acerca a esa frontera. Una tienda con catálogo profundo, un portal de noticias con archivo o un clasificado inmobiliario la rebasan sin esfuerzo, y entonces hay que partir el fichero.

La diferencia con un sitemap corriente está en el contenido de cada entrada. En un sitemap normal, cada elemento url describe una página del sitio y su loc contiene la dirección de esa página. En un índice, cada elemento sitemap describe un fichero y su loc contiene la dirección de ese fichero. El rastreador que lo lee trabaja en dos pasos: descarga primero el índice y después cada uno de los sitemaps listados.

Todo lo demás es idéntico. Mismo espacio de nombres XML, misma codificación UTF-8 obligatoria, mismas reglas de escapado de entidades. Google lo dice sin rodeos: los requisitos que valen para un sitemap valen también para un índice. De ahí que un índice mal formado falle igual que un sitemap mal formado, y que el techo de 50 MB se aplique también al propio fichero de índice.

La estructura es breve. La raíz es sitemapindex, cada fichero listado va dentro de un sitemap y solo loc es obligatorio. La etiqueta lastmod es opcional e indica cuándo se modificó por última vez el fichero sitemap correspondiente, en formato W3C Datetime.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns=
"http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
  <loc>https://ejemplo.com/sitemap-1.xml</loc>
  <lastmod>2026-08-18</lastmod>
  </sitemap>
  <sitemap>
  <loc>https://ejemplo.com/sitemap-2.xml</loc>
  <lastmod>2026-07-30</lastmod>
  </sitemap>
</sitemapindex>

Los límites repiten los de un sitemap normal: un índice puede listar hasta 50.000 ficheros y no debe superar los 50 MB sin comprimir, es decir 52.428.800 bytes. Combinando ambos techos, un solo índice cubre hasta 2.500 millones de URLs. Search Console admite además hasta 500 ficheros de índice por sitio, así que el margen práctico supera con mucho lo que necesita casi cualquier proyecto.

Hay una restricción que sorprende a mucha gente: un índice no puede listar otro índice. Google rechaza esa construcción con un error propio, «Nested sitemap indexes», y pide retirar las entradas que apunten a ficheros de índice. Cuando un proyecto necesita más capacidad, la salida es enviar varios índices por separado.

La ubicación también manda. Los sitemaps referenciados deben residir en el mismo sitio que el índice y en su mismo directorio o por debajo. Un índice colocado en la raíz del dominio abarca todo el sitio; uno colocado en /public/ solo alcanza esa carpeta y sus subdirectorios. Para listar sitemaps alojados en otro host hace falta el envío entre sitios, que se apoya en el robots.txt del host de destino o en la propiedad correspondiente de Search Console.

La decisión que cuelga de este fichero es cómo trocear el sitemap, y esa decisión determina qué podrás medir después. Search Console informa por sitemap: URLs descubiertas, errores de lectura y, cruzando con el informe de indexación de páginas, cuántas de esas URLs han entrado. Si todo el catálogo viaja en un único fichero gigante, esa cifra llega agregada y apenas dice nada.

Trocear por tipo de contenido cambia el diagnóstico. Un índice que apunta a un sitemap de fichas de producto, otro de categorías, otro de artículos y otro de páginas legales deja ver que las categorías se indexan al 95 % mientras las fichas se quedan en el 40 %. Ese contraste señala dónde está el problema antes de tocar nada.

Conviene recordar hasta dónde llega la herramienta. Enviar un sitemap es solo una pista para el buscador: no obliga a descargarlo ni garantiza que las URLs listadas se rastreen o se indexen. Un índice acelera el descubrimiento en sitios grandes y ordena el diagnóstico, y ahí se acaba su poder. La calidad de las páginas y la estructura de enlaces internos siguen decidiendo el resultado.

• Coloca el índice en la raíz del dominio, por ejemplo en https://ejemplo.com/sitemap_index.xml, para que su alcance cubra el sitio entero.
• Declara su dirección en el robots.txt con la directiva Sitemap: y envíalo además desde Search Console.
• Trocea por tipo de contenido en vez de cortar en bloques arbitrarios de 50.000 URLs: así cada cifra del informe responde a una pregunta concreta.
• Mantén lastmod vivo y sincero. Google lo usa cuando resulta coherente y verificable, y deja de fiarse si cada regeneración estampa la fecha de hoy en todos los ficheros.
• Incluye solo URLs canónicas que devuelvan 200 y sean indexables; una redirección o un noindex dentro de un sitemap es ruido que juega en tu contra.
• Comprime los sitemaps hijos con gzip cuando pesen mucho, recordando que el límite de 50 MB se mide sobre el fichero sin comprimir.

• Anidar índices. Un índice que apunta a otro índice provoca el error «Nested sitemap indexes» y deja sin leer todo lo que cuelga de esa entrada.
• Colocar el índice en un subdirectorio y listar sitemaps situados por encima en la jerarquía. Esas entradas quedan fuera de su alcance.
• Mezclar hosts o protocolos. Un índice servido en un dominio no puede listar sitemaps de otro sin el envío entre sitios verificado.
• Regenerar el fichero cada noche con la fecha del día en todos los lastmod. La señal pierde valor y el buscador deja de tenerla en cuenta.
• Dejar dentro URLs muertas después de una migración. El índice sigue validando y el informe se llena de errores que tapan los problemas reales.