La diferencia entre un índice de sitemap y un sitemap se reduce a una función específica de cada uno. Un sitemap.xml normal es una lista plana de las URL reales de tu sitio. Un índice de sitemap es una lista de sitemaps, no de páginas. Cuando un sitio supera las 50,000 URL o un tamaño de archivo sin comprimir de 50MB, un solo sitemap.xml ya no es válido, y debes dividir tus URL en varios archivos de sitemap a los que apunta un archivo de índice. Esta guía cubre exactamente cuándo es obligatorio ese cambio, la sintaxis precisa, cómo dividir un sitio grande de forma lógica y cómo enviar el índice a Google para que rastree de manera eficiente.
La mayoría de las páginas sobre este tema se quedan en la especificación de una línea de Google ("50,000 URL y 50MB por archivo") y te dejan resolver el resto. Las preguntas prácticas que nadie responde son: cómo dividir, cómo se ve realmente el archivo de índice y dónde encajan los sitemaps de hreflang e imágenes. Ese es el vacío que este artículo llena.
Diferencia clave entre un Sitemap Index y un Sitemap#
Un sitemap y un sitemap index son dos tipos de archivos que usan dos elementos raíz diferentes. Confundirlos es el error más común, y los motores de búsqueda rechazarán el archivo si los anidas incorrectamente.
- Un sitemap usa el elemento raíz
<urlset>y contiene entradas<url>. Cada entrada es una página real e indexable de tu sitio. - Un sitemap index usa el elemento raíz
<sitemapindex>y contiene entradas<sitemap>. Cada entrada apunta a la ubicación de otro archivo sitemap, no a una página.
Piensa en el índice como una tabla de contenidos. No enumera directamente tus artículos o páginas de producto. Enumera los archivos sitemap más pequeños, y cada uno de esos enumera las páginas. Los motores de búsqueda obtienen primero el índice y luego rastrean cada sitemap hijo al que hace referencia.
Regla clave: un sitemap index solo puede apuntar a sitemaps. No puedes poner URLs de página y URLs de sitemap hijo en el mismo archivo. Mezclar los dos elementos raíz no es válido y fallará la validación en Search Console.
Por qué existe la estructura de dos niveles#
La razón principal de esta estructura es el límite máximo de un solo archivo. El protocolo sitemaps.org (y Google, Bing y los demás lo siguen) limita cualquier sitemap a:
- 50,000 URLs como máximo por archivo.
- 50MB sin comprimir como tamaño máximo de archivo.
Si se alcanza cualquiera de estos límites, el archivo no cumple con la especificación. Los sitios grandes superan constantemente las 50,000 URLs, por lo que el protocolo permite publicar muchos archivos sitemap y unirlos con un solo índice. Un solo sitemap index puede hacer referencia a hasta 50,000 sitemaps, lo que significa que el límite teórico es 50,000 x 50,000 = 2.5 mil millones de URLs. Te quedarás sin páginas mucho antes de quedarte sin capacidad de sitemap.
Cuándo pasar de un solo sitemap a un índice de sitemaps#
El cambio no es una cuestión de estilo. Lo imponen los límites, y hay tres desencadenantes. El primero que alcances decide el asunto.
| Desencadenante | El límite | Qué ocurre si lo ignoras |
|---|---|---|
| Número de URL | Más de 50.000 URL en un solo archivo | Los motores de búsqueda dejan de leer al alcanzar el límite; las URL adicionales se descartan silenciosamente |
| Tamaño del archivo | Más de 50 MB sin comprimir | El archivo se rechaza como inválido; nada de lo que contiene se rastrea de forma fiable |
| Organización lógica | Sin límite estricto, pero útil a partir de unos miles de URL | Es más difícil depurar problemas de rastreo y leer informes de cobertura por sección |
Aquí tienes la lectura práctica de cada uno.
El número de URL es la razón más común. Con más de 50.000 URL publicadas e indexables, debes dividir. No hay una opción que activar ni una cuota que aumentar. O divides en varios sitemaps bajo un índice, o las URL a partir del número 50.000 nunca se envían.
El tamaño del archivo afecta a sitios con URL largas. Puedes alcanzar el límite de 50 MB antes de las 50.000 URL si tus URL son muy largas, o si incluyes muchas entradas <image:image> y <xhtml:link> (hreflang) por URL. Cada elemento adicional añade bytes, y los sitios multilingües con anotaciones hreflang se inflan rápidamente.
La organización lógica es la razón infravalorada. Incluso con 8.000 URL, dividir en sitemaps temáticos es inteligente. Cuando Search Console informa de que un sitemap tiene problemas de indexación, una división por sección te dice inmediatamente si el problema está en tu blog, productos o páginas de categoría. Un archivo gigante no te dice nada.
Consejo práctico: si estás cerca de las 40.000 URL, construye la estructura del índice ahora, no después de superar las 50.000. Hacer una adaptación forzada cuando las páginas están desapareciendo del índice es mucho más estresante que configurarlo con antelación.
La sintaxis exacta del índice de sitemap (con ejemplo)#
Esta es la parte que omiten las especificaciones técnicas breves. Un índice de sitemap es un pequeño archivo XML. Aquí tienes un ejemplo completo y válido que apunta a tres sitemaps secundarios.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-06-24T14:30:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-06-20T08:15:00+00:00</lastmod>
</sitemap>
</sitemapindex>
Tres detalles importantes.
<loc>debe ser una URL absoluta. Usa la ruta completahttps://example.com/..., no una relativa como/sitemap-posts.xml. Las URL relativas no son válidas en los sitemaps.<lastmod>es el único otro elemento hijo permitido. Cada entrada<sitemap>acepta<loc>y opcionalmente<lastmod>. No hay<changefreq>ni<priority>a nivel de índice (Google ignora estos incluso en sitemaps normales).<lastmod>debe ser honesto. Establécelo en la fecha más reciente en que una URL dentro de ese sitemap secundario haya cambiado realmente. Un<lastmod>que siempre dice "hoy" entrena a los rastreadores para ignorarlo, mientras que uno preciso ayuda a decidir qué sitemaps secundarios volver a rastrear primero.
Cada sitemap secundario es solo un archivo <urlset> normal:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/blog/first-post</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</url>
<url>
<loc>https://example.com/blog/second-post</loc>
<lastmod>2026-06-22T11:00:00+00:00</lastmod>
</url>
</urlset>
Puedes editarlos manualmente para una división pequeña, pero para algo real se generan. Un generador de sitemap XML gratuito maneja la división, el archivo de índice y el formato de URL absoluta para que no introduzcas un error tipográfico que rompa el rastreo silenciosamente.
Cómo dividir un sitio grande de forma lógica#
Puedes dividir arbitrariamente ("URLs 1 a 50.000 aquí, 50.001 a 100.000 allá"), pero eso es una oportunidad desperdiciada. Dividir por sección o tipo de contenido convierte tus sitemaps en una herramienta de diagnóstico, no solo en un requisito de cumplimiento.
Dividir por tipo de contenido o sección#
El patrón más limpio es un sitemap por grupo lógico, todos referenciados por un único índice:
sitemap-posts.xmlpara URLs de blogs o artículossitemap-products.xmlpara páginas de productos o listadossitemap-categories.xmlpara páginas de taxonomía y categoríassitemap-pages.xmlpara páginas estáticas (acerca de, contacto, legal)
Ahora, cuando Search Console diga "sitemap-products.xml: 4.200 enviados, 3.100 indexados", sabrás exactamente dónde investigar. Con un solo archivo monolítico solo sabrías que algo, en algún lugar, no está indexado.
Mantén cada sitemap hijo muy por debajo del límite#
No llenes cada archivo hijo hasta los 49.999 URLs. Apunta a unos pocos miles hasta aproximadamente 10.000 a 20.000 URLs cada uno. Los archivos más pequeños se obtienen y reobtienen más rápido cuando solo cambia una sección, y te mantienen seguro por debajo del límite de 50 MB a medida que las URLs crecen.
Decide entre sitemaps separados y combinados#
Tienes la opción entre sitemaps especializados dedicados o combinar todo por URL.
| Enfoque | Cuándo usarlo | Compensación |
|---|---|---|
| Combinar imágenes y hreflang en los sitemaps de URL principales | La mayoría de los sitios | Estructura más simple; vigila el límite de 50 MB |
| Sitemap de imágenes separado | Sitios con muchas imágenes (galerías, stock, ecommerce) | Informes más limpios sobre indexación de imágenes, pero más archivos que mantener |
| Manejo separado de hreflang/idiomas | Sitios multilingües grandes | Evita inflar un archivo; requiere anotaciones recíprocas |
Para la mayoría de los sitios, menos archivos es mejor. Recurre a sitemaps especializados separados solo cuando una sección sea tan grande que combinarla acerque un archivo al límite de tamaño o enturbie tus informes.
Dónde encajan los hreflang y los sitemaps de imágenes en un índice#
Esta es la parte que casi ningún artículo competidor aborda y que causa problemas en sitios grandes internacionales y con muchos medios.
Hreflang dentro de un índice de sitemaps#
Las anotaciones hreflang viven dentro de las entradas <url> de un sitemap normal, usando el elemento xhtml:link. No cambian el archivo de índice en absoluto. El índice sigue listando solo los sitemaps hijos. Un sitemap hijo con hreflang se ve así:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page"/>
<xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/page"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page"/>
</url>
</urlset>
Dos cosas a recordar. Primero, las anotaciones hreflang deben ser recíprocas: si la página en inglés apunta a la versión en español, la página en español debe apuntar de vuelta. Segundo, cada xhtml:link añade bytes, por lo que los sitemaps con muchos hreflang alcanzan el límite de 50MB con muchas menos de 50,000 URL. Ese es precisamente el caso en el que dividir en más sitemaps hijos bajo un mismo índice se vuelve necesario incluso con un número modesto de URL.
Sitemaps de imágenes dentro de un índice#
Las entradas de imágenes también viven dentro del bloque <url> de la página, usando el espacio de nombres image:image, no en el índice. Puedes adjuntar imágenes a las URL en tus sitemaps principales o crear un sitemap de imágenes dedicado y añadirlo como otra entrada <sitemap> en el índice.
Para un sitio con miles de imágenes por sección, un sitemap de imágenes separado mantiene tus sitemaps principales ligeros y te da una línea limpia en Search Console para la indexación de imágenes. Para todo lo demás, adjuntar imágenes a las entradas de URL existentes es más simple y funciona bien.
Cómo enviar un índice de sitemap a Google#
Una vez que tu índice está creado, solo envías una cosa: el archivo de índice. No envías cada sitemap hijo por separado. Google descubre los hijos al leer el índice.
Paso 1: Referencia el índice en robots.txt#
Agrega una línea Sitemap: en tu robots.txt que apunte a la URL absoluta del archivo de índice. Esto permite que cualquier rastreador lo descubra, no solo Google.
Sitemap: https://example.com/sitemap-index.xml
Puedes listar varias líneas Sitemap: si es necesario, pero con un índice adecuado solo necesitas una. Si también necesitas controlar qué rutas pueden acceder los rastreadores, genera un archivo limpio con un generador de robots.txt gratuito para que las directivas y la referencia del sitemap tengan el formato correcto.
Paso 2: Envía el índice en Google Search Console#
En Search Console, abre el informe de Sitemaps para tu propiedad e ingresa la ruta a tu archivo de índice (por ejemplo, sitemap-index.xml). Envíalo. Google lee el índice y luego pone en cola cada sitemap hijo. Verás el índice listado y, en los días siguientes, se completarán los recuentos de descubrimiento e indexación por sitemap.
Paso 3: Verifica que cada sitemap hijo se haya leído#
Después de que Google procese el índice, el informe de Sitemaps muestra cada sitemap hijo referenciado. Confirma que los recuentos de URL enviadas coincidan con lo que esperas por sección. Si un sitemap hijo muestra cero URL o un error, ese archivo tiene un problema (un <loc> incorrecto, un error de sintaxis o un desbordamiento de tamaño) y corriges ese archivo en lugar de toda la estructura.
Paso 4: Monitorea y mantén lastmod actualizado#
Rara vez se necesita reenviar una vez que el índice está en su lugar. Google vuelve a obtener el índice y los sitemaps hijos según su propio cronograma. Lo más útil que puedes hacer es mantener <lastmod> preciso, tanto en las entradas del índice como dentro de los sitemaps hijos, para que los rastreadores prioricen las secciones que realmente cambiaron. Mientras ajustas las señales técnicas de SEO, vale la pena combinar tu sitemap con datos estructurados: nuestro generador de marcado de esquema ayuda a que tus páginas clave obtengan resultados enriquecidos una vez que sean rastreadas.
Errores comunes en índices de sitemap que debes evitar#
Unos pocos errores causan la mayoría de los problemas en sitemaps de sitios grandes.
- Anidar un índice dentro de otro índice. Un índice de sitemap no puede apuntar a otro índice de sitemap, solo a sitemaps normales. Solo se permite un nivel de indexación.
- Mezclar entradas
<url>y<sitemap>. Un archivo es o un<urlset>o un<sitemapindex>, nunca ambos. - URLs relativas en
<loc>. Siempre absolutas, con el protocolo y host correctos. - Listar la misma URL en varios sitemaps hijos. Cada URL debe aparecer una sola vez en todo el conjunto. Los duplicados desperdician el presupuesto de rastreo y confunden los informes.
- Enviar sitemaps hijos individualmente después de enviar el índice. Es redundante y satura tu informe de Sitemaps. Envía solo el índice.
La conclusión sobre Mapa del sitio índice vs Mapa del sitio#
La decisión entre mapa del sitio índice y mapa del sitio se define por tu cantidad de URL y tamaño de archivo, no por preferencia. Con menos de 50,000 URL y 50 MB, un solo sitemap.xml es suficiente. Si superas alguno de esos límites, debes dividir tus páginas en varios mapas del sitio secundarios unidos por un solo archivo <sitemapindex>, y luego enviar solo ese índice a Google.
Bien hecho, la división va más allá del cumplimiento. Agrupar por sección convierte tus mapas del sitio en un panel de salud de rastreo, mantiene los archivos con hreflang y muchas imágenes por debajo del límite de tamaño, y te indica exactamente dónde están los problemas de indexación. Si prefieres no escribir ni una línea de XML, un generador de mapas del sitio XML gratuito crea el índice y los archivos secundarios, formatea las URL absolutas y te evita los errores tipográficos que silenciosamente rompen el rastreo en un sitio grande.
Preguntas Frecuentes#
¿Cuál es la diferencia entre un sitemap y un índice de sitemap?
Un sitemap (<urlset>) lista las URL de páginas reales de tu sitio. Un índice de sitemap (<sitemapindex>) lista otros archivos de sitemap, no páginas. Los motores de búsqueda leen primero el índice y luego rastrean cada sitemap hijo que referencia. Usas un índice cuando tienes más archivos de sitemap de los que puede contener uno solo.
¿Cuándo necesito un índice de sitemap en lugar de un sitemap.xml? Debes cambiar cuando un solo archivo supera las 50,000 URL o los 50MB sin comprimir, lo que ocurra primero. Los sitios multilingües con hreflang o sitios con muchas imágenes pueden alcanzar el límite de 50MB mucho antes de las 50,000 URL. Muchos equipos también dividen antes, alrededor de unos miles de URL, solo para tener informes más limpios por sección en Search Console.
¿Puede un índice de sitemap apuntar a otro índice de sitemap?
No. Un índice de sitemap solo puede referenciar sitemaps regulares (archivos <urlset>), no otros archivos de índice. Tienes exactamente un nivel de indexación. Si necesitas organizar muchos sitemaps, agrégalos lógicamente bajo un solo índice en lugar de intentar anidar índices.
¿Cuántas URL puede manejar un índice de sitemap en total? Un solo índice de sitemap puede referenciar hasta 50,000 sitemaps hijos, y cada sitemap hijo puede contener hasta 50,000 URL. Esto da un límite de aproximadamente 2.5 mil millones de URL desde un índice, que es mucho más de lo que cualquier sitio real necesita.
¿Debo enviar cada sitemap hijo a Google o solo el índice? Envía solo el archivo de índice en Google Search Console y refiérelo una vez en robots.txt. Google lee el índice y descubre automáticamente cada sitemap hijo. Enviar sitemaps hijos individualmente es redundante y solo desordena tu informe de Sitemaps.
¿Dónde van las entradas de hreflang e imagen en un índice de sitemap?
Nunca van en el archivo de índice en sí. Las anotaciones de hreflang (xhtml:link) e imagen (image:image) viven dentro de las entradas <url> de los sitemaps hijos regulares. El índice solo lista las ubicaciones de los sitemaps hijos. Debido a que estas anotaciones aumentan el tamaño del archivo, los sitemaps hijos con muchos hreflang o imágenes alcanzan el límite de 50MB con menos URL, lo que a menudo es la razón por la que divides.
