Índices de sitemaps: qué son y cuándo usarlos
Cuando un solo sitemap se queda corto, el protocolo ofrece un archivo que lista otros sitemaps. Así se construye, así se envía y así se valida.
Un índice de sitemaps es un archivo XML cuyo elemento raíz es <sitemapindex> y que, en lugar de páginas, lista otros archivos de sitemap. Lo necesitas cuando superas las 50.000 URLs o los 50 MB por archivo, o cuando prefieres organizar los sitemaps por tipo de contenido, idioma o fecha.
Qué es exactamente un índice de sitemaps
El protocolo de sitemaps.org define dos tipos de archivo. El sitemap normal (<urlset>) lista páginas; el índice (<sitemapindex>) lista sitemaps. Ambos comparten el mismo espacio de nombres y las mismas reglas básicas: XML bien formado, URLs absolutas y escapadas, y los mismos límites de tamaño. Para el rastreador, el índice es un punto de entrada único desde el que descubre todos los sitemaps hijos y, a través de ellos, todas tus páginas.
Cuándo necesitas uno
- Por obligación: tu sitio supera las 50.000 URLs o el archivo pasa de 50 MB sin comprimir. El protocolo no deja alternativa: hay que dividir.
- Por organización: incluso muy por debajo del límite, separar por tipo de contenido (
sitemap-productos.xml,sitemap-blog.xml), por idioma o por fecha de publicación hace el diagnóstico mucho más fácil. Si Search Console señala un problema en el sitemap de productos, ya sabes dónde mirar. - Por frescura: con sitemaps divididos por fecha, el archivo del mes en curso cambia a diario y los históricos permanecen intactos, con su lastmod estable. Los rastreadores concentran sus visitas donde hay novedad.
Ejemplo completo
Un índice con dos sitemaps hijos tiene este aspecto:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-productos.xml</loc>
<lastmod>2026-07-15</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-blog.xml</loc>
<lastmod>2026-07-16</lastmod>
</sitemap>
</sitemapindex>Cada entrada <sitemap> lleva un <loc> obligatorio con la URL absoluta del archivo hijo y, opcionalmente, un <lastmod>. Fíjate en que el índice no lleva <changefreq> ni <priority>: esos campos solo existen en los sitemaps de páginas, y aun allí los buscadores los ignoran. En cuanto a los nombres de archivo, el protocolo no impone ninguno: sitemap.xml para el índice y nombres descriptivos para los hijos es la convención más extendida, y la única que agradecerás al depurar.
Las reglas del protocolo
| Regla | Detalle |
|---|---|
| Capacidad máxima | Un índice puede listar hasta 50.000 sitemaps y pesar hasta 50 MB sin comprimir |
| Sin anidamiento | Un índice no puede listar otro índice: solo sitemaps de tipo urlset. La jerarquía tiene exactamente dos niveles |
| Contenido de las entradas | Cada entrada referencia un archivo de sitemap, nunca una página del sitio |
| Mismo host | Los sitemaps hijos deben estar en el mismo host que el índice, con las excepciones habituales vía robots.txt |
| lastmod por hijo | Opcional pero valioso: indica cuándo cambió cada archivo hijo por última vez |
| Compresión | Tanto el índice como los hijos pueden servirse comprimidos con gzip (.xml.gz) |
La capacidad combinada es enorme: 50.000 sitemaps por 50.000 URLs cada uno son 2.500 millones de URLs con un solo índice. Ningún sitio real lo agota.
El lastmod de cada hijo
El <lastmod> de una entrada del índice indica cuándo cambió ese archivo de sitemap, no sus páginas una a una. Bien mantenido, es una señal muy eficiente: el rastreador compara la fecha con la de su última visita y se ahorra descargar los hijos que no han cambiado. Aplican las mismas reglas que en cualquier lastmod: formato W3C y veracidad. Si tu generador escribe la misma fecha en todos los hijos cada noche, mejor omitir el campo.
Envía solo el índice
En Google Search Console y Bing Webmaster Tools basta con enviar la URL del índice: los buscadores descubren los hijos automáticamente y Search Console muestra el desglose por hijo dentro del propio informe. Enviar además cada sitemap hijo por separado no aporta nada y duplica filas en el informe. Lo mismo vale para robots.txt: una sola línea Sitemap: apuntando al índice es suficiente.
Cómo validan los índices las herramientas
Un buen validador trabaja en dos fases. Primero comprueba el índice en sí: sintaxis XML, espacio de nombres, que cada <loc> sea una URL absoluta válida y que las fechas lastmod estén bien formateadas. Después están los hijos: cada uno es un archivo independiente con sus propios errores posibles, así que hay que descargarlo y validarlo por separado. Nuestro validador de sitemaps hace exactamente eso: valida el índice, lista todos los hijos encontrados y te deja comprobar cada uno con un clic, sin copiar URLs a mano.
Errores comunes en índices
- Anidar índices. Un índice que lista otro índice viola el protocolo; Google no sigue el segundo nivel. Aplana la estructura: un índice, muchos urlset.
- Listar páginas en el índice. Las entradas
<sitemap>deben apuntar a archivos de sitemap. Si mezclas URLs de páginas, esas entradas se descartan. - Hijos rotos. El índice es válido pero un hijo devuelve 404 o quedó vacío tras un despliegue. Como el índice «pasa» la validación superficial, el fallo puede vivir semanas sin que nadie lo vea: valida los hijos, no solo el índice.
- Rutas desincronizadas. El generador renombra los archivos (por fecha o por hash) pero el índice sigue apuntando a los nombres antiguos. Regenera siempre índice e hijos en la misma operación.
- Elemento raíz equivocado. Usar
<urlset>en un archivo que lista sitemaps, o al revés. El tipo de archivo lo define el elemento raíz, no el nombre del archivo.
En resumen
El índice de sitemaps es la pieza que hace escalar el protocolo: dos niveles, límites generosos y reglas simples. Divide cuando toque (o antes, por orden), mantén el lastmod de los hijos honesto, envía solo el índice y valida las dos capas. Si quieres repasar qué debe contener cada sitemap hijo, sigue con la guía de buenas prácticas de sitemaps.