Índice de sitemaps

TL;DR — Un índice de sitemaps es un sitemap de sitemaps. Un sitemap individual admite hasta 50 000 URL, por lo que los sitios grandes distribuyen sus URL entre varios sitemaps y los enumeran en un pequeño archivo de índice. Solo se presenta el índice, y los motores de búsqueda lo siguen para localizar todos los archivos secundarios.

Qué es un índice de sitemaps

Un sitemap XML normal enumera las URL de las páginas. Un índice de sitemaps se encuentra un nivel por encima: enumera otros sitemaps en lugar de páginas. Funciona como una tabla de contenido que apunta a varios capítulos, cada uno de los cuales es un sitemap con URL.

El índice se proporciona a los motores de búsqueda, que lo leen para localizar cada sitemap referenciado y luego consultan esos archivos para descubrir las URL.

Por qué puede necesitarse

Un sitemap individual tiene límites estrictos: admite como máximo 50 000 URL y el archivo no puede superar 50 MB sin comprimir. Cuando se rebasa cualquiera de esos límites, debe dividirse en varios sitemaps. El índice reúne las piezas para que solo sea necesario presentar un archivo. 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

No es necesario esperar hasta alcanzar el límite. Muchos sitios grandes usan un índice para organizar sus archivos: un sitemap para el blog, otro para productos y otro por idioma, aunque cada parte esté muy por debajo de 50 000 URL.

¿Cuánto puede cubrir?

Mucho. Un índice puede enumerar hasta 50 000 sitemaps secundarios, y cada uno puede contener hasta 50 000 URL. Por tanto, un solo índice cubre 2500 millones de URL. En la práctica, la capacidad no será un límite para ningún sitio.

Cómo se usa

• Las URL se distribuyen entre varios archivos de sitemap; la mayoría de los plugins y frameworks de SEO lo hacen automáticamente.
• Se coloca en el nivel superior un archivo de índice que enumera cada sitemap.
• Solo se presenta el índice en Google Search Console y Bing Webmaster Tools. Ese envío abarca todos los sitemaps secundarios.

La pestaña Advanced explica la anatomía, los límites exactos, la regla que impide anidar un índice dentro de otro y el criterio de división que convierte los sitemaps en un diagnóstico de indexación.

TL;DR — Un índice de sitemaps es un sitemap de sitemaps: un archivo <sitemapindex> que enumera entradas <sitemap> (<loc> y un <lastmod> opcional) en lugar de URL. Se necesita cuando un sitemap superaría 50 000 URL o 50 MB sin comprimir, o para organizar un sitio grande con varias secciones o regiones. Un índice puede referenciar hasta 50 000 sitemaps secundarios × 50 000 URL cada uno, es decir, 2500 millones de URL por índice. Con hasta 500 archivos de índice por sitio en Search Console, el límite teórico es 1,25 billones, una cifra que ningún sitio real alcanza. Los archivos secundarios deben estar en el mismo sitio y al mismo nivel de directorio o en uno inferior; no se admite anidar índices y solo se presenta el índice. La ventaja real consiste en dividir por sección o tipo de contenido para comparar URL presentadas e indexadas por segmento.

Qué es realmente un archivo de índice de sitemaps

Un índice de sitemaps es un sitemap cuyas entradas son otros sitemaps. Un sitemap normal contiene bloques <url> dentro de <urlset>; un índice contiene bloques <sitemap> dentro de <sitemapindex>. Cada bloque <sitemap> incluye un <loc> que apunta a un archivo de sitemap y, de forma opcional, un <lastmod>. Esa es toda la estructura: el índice no contiene URL de páginas propias.

El índice existe porque el formato de sitemaps tiene límites estrictos y los sitios grandes los superan. Las URL se distribuyen entre varios sitemaps y el índice los presenta a los motores de búsqueda como una sola unidad.

Cuándo se necesita uno

Dos desencadenantes:

1. Se alcanzan los límites de tamaño. Un sitemap individual admite como máximo 50 000 URL o 50 MB sin comprimir, lo que ocurra primero. La guía de Google es directa: “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” (traducción) «Si un sitemap supera los límites de tamaño, debe dividirse en varios 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 El índice reúne los archivos resultantes.
2. Se desea organizar un sitio grande, incluso por debajo del límite. Los sitios con varias secciones —blog, productos o categorías— y los sitios multirregionales o multilingües son más fáciles de gestionar y supervisar mediante sitemaps separados bajo un índice. Este uso organizativo es la mejor razón para adoptar un índice y se desarrolla en la pestaña Frameworks.

Anatomía

El índice de sitemaps es pequeño y simple por diseño —<sitemapindex>, seguido de un bloque <sitemap> por cada archivo secundario, cada uno con un <loc> y un <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 importan:

• El namespace es el mismo sitemaps.org/schemas/sitemap/0.9 utilizado en un sitemap normal; el archivo es UTF-8 y los valores de <loc> son URL absolutas completamente calificadas.
• Los sitemaps secundarios pueden comprimirse con gzip — .xml.gz está bien, y el límite de 50 MB se mide sobre el tamaño sin comprimir.
• El <lastmod> opcional aquí describe cuándo cambió por última vez ese sitemap secundario, no cuándo cambiaron las páginas individuales.

¿Cuántos pueden presentarse y cuántas páginas abarcan?

La capacidad máxima surge de acumular estos límites:

• Google Search Console acepta hasta 500 archivos de índice de sitemaps por sitio: “You can submit up to 500 sitemap index files for each site in your Search Console account.” (traducción) «Se pueden presentar hasta 500 archivos de índice de sitemaps por cada sitio de una cuenta de Search Console».
• Cada índice puede enumerar hasta 50 000 sitemaps secundarios.
• Cada sitemap secundario puede contener hasta 50 000 URL.

Al multiplicar, el límite teórico es 500 × 50 000 × 50 000 = 1,25 billones de URL (1 250 000 000 000). Debe interpretarse como una capacidad inalcanzable en la práctica, no como un objetivo. Un único índice ya cubre 50 000 × 50 000 = 2500 millones de URL. Si un sitio tiene esa cantidad de URL indexables, la configuración del sitemap no es su problema principal.

Reglas de ubicación

Los sitemaps secundarios deben estar en el mismo sitio que el índice y al mismo nivel de directorio o en uno inferior. Por ejemplo, https://www.example.com/sitemap-index.xml puede apuntar a https://www.example.com/sitemaps/products.xml, pero no a otro host ni a un directorio superior. Si se infringe la regla, Search Console marca el archivo como “URL not allowed”. Las referencias entre dominios solo son válidas cuando ambos dominios están verificados en Search Console, una excepción innecesaria para un índice ordinario de un solo sitio.

No se debe anidar un índice dentro de otro índice

Un índice de sitemaps enumera sitemaps, no otros índices. Ni la página vigente del protocolo de sitemaps.org ni la documentación de Google lo expresan hoy con esas palabras exactas; ambas fuentes se comprobaron directamente. El protocolo define <loc> dentro de <sitemapindex> como la identificación de “a Sitemap, an Atom file, RSS file or a simple text file” (traducción) «un sitemap, un archivo Atom, un archivo RSS o un archivo de texto simple». Un archivo de índice no aparece en la lista y el formato no tiene una etiqueta para anidar otro índice. Los generadores, plugins y motores de búsqueda tratan los índices de índices como incompatibles. Por tanto, debe mantenerse un solo nivel de indexación; el límite de 2500 millones de URL de un índice deja margen suficiente para reorganizar los archivos.

Solo debe presentarse el índice

Se presenta el archivo de índice, y ese único envío incorpora todos los sitemaps secundarios referenciados; no es necesario presentar cada archivo por separado. John Mueller lo expresó así: “You can submit the individual ones, but you don’t really need to.” (traducción) «Se pueden presentar los archivos individuales, pero no es realmente necesario». Presentar el índice y sus archivos secundarios no es perjudicial, solo redundante. Un único envío limpio del índice es la opción indicada.

Dicho esto, enviar un sitemap —sea un índice de sitemaps o no— es una ayuda para el descubrimiento, no una garantía de indexación. El índice ayuda a los motores a encontrar los sitemaps; no promete que las URL dentro de ellos se rastreen o indexen.

Estrategia de división — para informes, no para eficiencia de rastreo

Este aspecto suele pasarse por alto: la forma de dividir los sitemaps en un índice no cambia la manera en que Google rastrea o indexa las páginas. La división cuidadosa sirve para la supervisión. Mueller lo plantea así: “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.” (traducción) «Por lo general, recomiendo dividir un archivo de sitemap en partes lógicas del sitio para supervisarlas por separado —por ejemplo, páginas de categoría frente a páginas de detalle—. Esto no cambia la forma en que Google las rastrea e indexa; solo permite hacer un mejor seguimiento».

La ventaja práctica es que el informe Sitemaps de Search Console muestra recuentos de URL presentadas frente a indexadas por sitemap. Al dividir el índice por sección o tipo de contenido —blog, productos, categorías, documentación o región— puede identificarse qué segmento está poco indexado en vez de consultar una única cifra para todo el sitio. El mismo criterio resulta útil en una migración: conservar temporalmente un sitemap de URL antiguas permite observar cómo ese conjunto específico sale del índice en GSC.

La división debe responder a lo que se desea medir, no a un beneficio de rastreo imaginario. El beneficio de rastreo no existe; el valor de los informes sí.

Cómo se relaciona con el resto de la familia de sitemaps

Un índice se sitúa por encima de los sitemaps XML habituales. La descripción general de sitemaps es el punto de partida para comprender toda esta familia. Los sitemaps de imágenes y video son archivos secundarios adicionales que un índice puede referenciar, y todo el mecanismo forma parte del descubrimiento. No se necesitan enlaces desde aquí: son artículos relacionados del mismo clúster.

Resumen de IA

Una visión condensada de la versión avanzada:

• Un índice de sitemaps es un sitemap de sitemaps: un archivo <sitemapindex> que enumera entradas <sitemap> —<loc> y un <lastmod> opcional—, no URL.
• Se necesita al superar los límites de un sitemap individual o para organizar por separado las secciones y regiones de un sitio grande.
• La capacidad es prácticamente ilimitada: hasta 50 000 sitemaps secundarios por índice × 50 000 URL cada uno = 2500 millones de URL por índice. Con 500 índices por sitio en Search Console, el límite teórico es 1,25 billones de URL.
• Reglas: los archivos secundarios deben estar en el mismo sitio y al mismo nivel de directorio o en uno inferior; no se admiten índices anidados y se permite gzip (.xml.gz).
• Solo debe presentarse el índice. Presentar también los archivos secundarios es redundante, no perjudicial. Mueller: “you don’t really need to” (traducción) «no es realmente necesario».
• La división sirve para los informes, no para mejorar el rastreo. Conviene dividir por sección o tipo de contenido para comparar URL presentadas e indexadas por segmento.

Documentación oficial

Documentación de fuentes primarias sobre los archivos de índice de sitemaps y los límites que los sustentan.

Google

• Manage large sitemaps with a sitemap index file — división por encima de los límites, formato del índice y límite de 500 archivos por sitio.
• Build and submit a sitemap — límites de 50 000 URL y 50 MB sin comprimir, UTF-8 y reglas de URL absolutas.
• Sitemaps overview — definición de un sitemap y formulación “discovery, not a guarantee of indexing” (traducción) «descubrimiento, no garantía de indexación».

sitemaps.org

• Sitemaps XML protocol — especificación de <sitemapindex>, límite de 50 000 sitemaps y 50 MB, y regla “an index file can not list other index files” (traducción) «un archivo de índice no puede enumerar otros archivos de índice».

Citas de la fuente

Declaraciones públicas de Google y del protocolo sitemaps.org. Cada enlace es un enlace profundo que salta al fragmento citado en la página de origen.

Google — límites de división y envío

• “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” (traducción) «Si un sitemap supera los límites de tamaño, debe dividirse en varios sitemaps». — Google, Manage large sitemaps. Ir a la cita
• “You can submit up to 500 sitemap index files for each site in your Search Console account.” (traducción) «Se pueden presentar hasta 500 archivos de índice por cada sitio de una cuenta de Search Console». Ir a la cita

sitemaps.org — límites de tamaño del protocolo (la nota al pie explica la fuente de la regla de no anidamiento, que no es una cita independiente)

• “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.” (traducción) «Los archivos de índice de sitemaps no pueden enumerar más de 50 000 sitemaps, no deben superar los 50 MB (52 428 800 bytes) y pueden comprimirse.» — protocolo de sitemaps.org. Ir a la cita

John Mueller, Google — división para supervisión y envío únicamente del í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.” (traducción) «Por lo general, recomiendo dividir un archivo de sitemap en partes lógicas del sitio para supervisarlas por separado. Esto no cambia la forma en que Google las rastrea e indexa; solo permite hacer un mejor seguimiento». Ir a la cita
• “You can submit the individual ones, but you don’t really need to.” (traducción) «Se pueden presentar los archivos individuales, pero no es realmente necesario». Ir a la cita

Índice de sitemaps — hoja de referencia de límites

Los números que definen la capacidad

Datos rápidos

• Un índice enumera sitemaps, no URL: <sitemapindex> contiene bloques <sitemap> con <loc> y un <lastmod> opcional.
• Se necesita cuando un sitemap superaría 50 000 URL o 50 MB, o para organizar un sitio grande con varias secciones o regiones.
• Los archivos secundarios deben estar en el mismo sitio y al mismo nivel de directorio o en uno inferior.
• Pueden comprimirse con gzip (.xml.gz).
• No debe anidarse un índice dentro de otro; el formato y las herramientas no lo admiten.
• Solo debe presentarse el índice; presentar también los archivos secundarios es redundante.
• La división debe responder a las necesidades de informes, no a una supuesta mejora del rastreo.

Cómo dividir un índice de sitemaps según lo que se mide

El principio fundamental es que la división no cambia el rastreo, sino lo que puede supervisarse. Google rastrea e indexa las mismas URL tanto si se encuentran en un sitemap como en cincuenta. Los criterios de división deben corresponder a los segmentos que conviene analizar por separado en el informe Sitemaps de Search Console.

División por tipo de contenido

• /sitemaps/blog.xml, /sitemaps/products.xml, /sitemaps/categories.xml y /sitemaps/docs.xml.
• Resulta útil cuando las plantillas tienen comportamientos de indexación diferentes, por ejemplo, variantes de producto con contenido escaso frente a un blog bien indexado. Así puede identificarse la plantilla problemática.

Dividir por sección

• Un sitemap secundario por sección principal del sitio o subcarpeta.
• Conviene más para sitios grandes donde distintos equipos son propietarios de diferentes secciones: cada propietario obtiene un número de cobertura claro para su área.

Dividir por región / idioma

• Un sitemap secundario por configuración regional (/sitemaps/en.xml, /sitemaps/de.xml, …).
• Conviene más para sitios internacionales: se puede detectar toda una configuración regional que no se está indexando, independientemente de cualquier problema de hreflang.

Regla de decisión

• La pregunta es: «Si uno de estos segmentos tuviera una indexación insuficiente, ¿convendría verlo de forma aislada?». Si la respuesta es sí, existe un criterio de división útil. Si ese segmento nunca se analizaría por separado, dividirlo solo crea más archivos que mantener.

Uso durante una migración

• Puede mantenerse temporalmente en el índice un sitemap de las URL antiguas, no para indexarlas, sino para observar cómo salen del índice de GSC mientras las nuevas URL toman el relevo. El objetivo son los informes por segmento.

La mejora de eficiencia de rastreo que suele esperarse de la división no existe. El valor de los informes sí, y el índice debe diseñarse en torno a ese objetivo.

Un índice de sitemaps mínimo válido

Esta es la estructura completa de un archivo de índice de sitemaps: una raíz <sitemapindex>, luego un bloque <sitemap> por cada sitemap secundario, cada uno con un <loc> y un <lastmod> opcional. Los sitemaps secundarios pueden estar comprimidos con gzip (.xml.gz); el límite de 50 MB se mide sin comprimir.

<?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>

Reglas integradas en ese ejemplo:

• La raíz es <sitemapindex>, no <urlset>, en el espacio de nombres sitemaps.org/schemas/sitemap/0.9; el archivo usa UTF-8.
• Cada <loc> es una URL absoluta del mismo sitio y está al mismo nivel de directorio o en uno inferior que el índice.
• <lastmod> es opcional e indica cuándo cambió el sitemap secundario.
• Ninguna entrada <sitemap> debe apuntar a otro índice: solo se admite un nivel.

Cómo enviarlo

Se presenta solo este archivo de índice. Los motores de búsqueda lo siguen hasta cada sitemap secundario, sin necesidad de presentar esos archivos por separado.

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

La misma URL del índice se añade en el informe Sitemaps de Google Search Console y en Bing Webmaster Tools. Los archivos secundarios quedan incluidos.

Herramientas para crear y comprobar un índice de sitemaps

• Google Index Checker: después de presentar el índice, permite comprobar si URL concretas de un sitemap secundario llegaron al índice de Google sin esperar al número agregado de Search Console.
• Google Search Console — informe Sitemaps: principal lugar para supervisar el estado de recuperación por archivo secundario y comparar URL presentadas e indexadas por segmento.
• Bing Webmaster Tools — Sitemaps: informe equivalente para Bing; se presenta la misma URL del índice.
• Generador de sitemaps o plugin del CMS: la mayoría de los frameworks y plugins de SEO construyen automáticamente el índice y los archivos secundarios a medida que crece la cantidad de URL. El XML manual de la pestaña Scripts sirve para examinar o crear la estructura.

Lista de verificación previa al envío del índice de sitemaps

Debe revisarse esta lista antes de dirigir Search Console o Bing Webmaster Tools a un índice nuevo o reestructurado:

• Cada sitemap secundario está por debajo de 50 000 URL y 50 MB sin comprimir, con margen suficiente.
• El índice enumera solo sitemaps, nunca otro índice.
• Cada <loc> secundario está en el mismo sitio y al mismo nivel de directorio o en uno inferior.
• El índice y los archivos secundarios son XML válido y UTF-8, con <sitemapindex> para el índice y <urlset> para cada archivo secundario.
• robots.txt contiene una línea Sitemap: que apunta al índice.
• Los criterios de división corresponden a segmentos que se supervisarán por separado.
• Solo el índice está preparado para su presentación; no es necesario presentar cada archivo secundario.

Errores que deben evitarse con un índice de sitemaps

• Anidar un índice dentro de otro. El formato no incluye una etiqueta para ello: <loc> solo identifica un sitemap, un archivo Atom o RSS, o un archivo de texto. Debe mantenerse un único nivel de indexación y reorganizar los archivos dentro de la capacidad de 2500 millones de URL.
• Presentar cada sitemap secundario además del índice. No causa daño, pero es redundante. Solo debe presentarse el índice en Search Console y Bing Webmaster Tools.
• Dividir para intentar mejorar el presupuesto de rastreo o el posicionamiento. La división no cambia el rastreo ni la indexación. Deben elegirse segmentos útiles para los informes.
• Apuntar un archivo secundario a otro host, subdominio o directorio superior. Search Console lo marca como “URL not allowed”. Cada archivo debe permanecer en el mismo sitio y al mismo nivel de directorio o en uno inferior.
• Permitir que un sitemap supere 50 000 URL o 50 MB sin comprimir. La división debe realizarse antes de alcanzar el límite.

Problemas comunes con un índice de sitemaps

Síntoma: Search Console muestra “Couldn’t fetch” en el índice. Causa probable: la URL devuelve 404, agota el tiempo de espera o está bloqueada por robots.txt. Solución: se abre la URL exacta en un navegador o en el Sitemap Validator y se confirma que devuelve HTTP 200 con XML válido antes de volver a presentarla.

Síntoma: el índice se recupera, pero un sitemap secundario muestra un error. Causa probable: un <loc> apunta a una URL 404, no canónica o de otro dominio, o el archivo secundario contiene XML mal formado. Solución: se abre el archivo, se comprueban sus entradas <loc>, se corrige o regenera y se espera a la siguiente recuperación.

Síntoma: “Sitemap index file can’t reference another sitemap index” —o la entrada se ignora—. Causa probable: se anidó un índice dentro de otro, estructura que no admite el formato. Solución: se aplana la estructura a un único nivel; el índice superior solo debe apuntar a sitemaps que enumeren URL.

Síntoma: “URL not allowed” en una entrada secundaria. Causa probable: el archivo está en otro host o subdominio, o por encima de la ruta del índice. Solución: se traslada al mismo sitio y al mismo nivel de directorio o en uno inferior. Las referencias entre dominios solo funcionan cuando ambos están verificados en Search Console.

Síntoma: se rechaza un índice o sitemap secundario por tamaño. Causa probable: supera 50 000 URL o 50 MB sin comprimir; el índice también tiene un límite de 50 MB. Solución: se añade otro sitemap secundario —u otro índice en un sitio extremadamente grande— en lugar de forzar más entradas en el mismo archivo.

Cómo demostrar que el nuevo índice de sitemaps se aplicó correctamente

Prueba: cargar directamente la URL del índice —navegador o curl -I—. Resultado esperado: HTTP 200, XML válido y raíz <sitemapindex>. Interpretación del fallo: un 404 o tiempo de espera indica que Search Console tampoco puede acceder al archivo; debe corregirse antes de continuar. Periodo de supervisión: inmediato. Criterio de reversión: ante una respuesta sostenida distinta de 200, se restaura la configuración anterior.

Prueba: presentar el índice en el informe Sitemaps de Search Console —o comprobarlo primero con el Sitemap Validator—. Resultado esperado: recuperación correcta y filas para cada sitemap secundario. Interpretación del fallo: “Couldn’t fetch” indica un problema de URL, alojamiento o robots.txt, no todavía un problema de indexación. Periodo de supervisión: entre unas horas y un día para la primera recuperación. Criterio de reversión: fallos repetidos después de volver a presentar el archivo.

Prueba: comparar el recuento de URL de cada sitemap secundario con las URL reales del segmento. Resultado esperado: los recuentos se aproximan a los de esa sección o tipo de contenido. Interpretación del fallo: una diferencia grande suele indicar que el generador incluye URL obsoletas, no canónicas o duplicadas. Periodo de supervisión: inmediatamente después de la generación. Criterio de reversión: ninguno; debe corregirse la lógica del generador y regenerar el archivo.

Prueba: comprobar en el informe Sitemaps los recuentos de URL presentadas frente a indexadas por sitemap. Resultado esperado: el recuento de URL indexadas se acerca con el tiempo al de las presentadas en cada segmento. Interpretación del fallo: un segmento que permanece muy por debajo de su recuento presentado indica un problema específico, como contenido escaso, duplicación o noindex accidental, no un problema del índice. Periodo de supervisión: entre 2 y 4 semanas para obtener una tendencia significativa. Criterio de reversión: el recuento indexado de un segmento cae después del cambio, no solo se mantiene estable.

Prueba: confirmar que robots.txt conserva la línea Sitemap: correcta. Resultado esperado: la línea resuelve a la URL actual del índice. Interpretación del fallo: una línea ausente u obsoleta no impide el descubrimiento para motores que ya conocen el índice, pero elimina una señal para rastreadores nuevos. Periodo de supervisión: inmediato. Criterio de reversión: se restaura la línea si falta o apunta a un archivo retirado.

KPI permanentes para un índice de sitemaps

Métrica: recuento de URL presentadas frente a indexadas por segmento de sitemap. Qué indica: qué sección, tipo de contenido o región tiene una indexación insuficiente, en lugar de mostrar una única cifra combinada para todo el sitio. Cómo se obtiene: informe Sitemaps de Search Console, consultado por sitemap presentado. Referencia o rango realista: no existe un objetivo universal. Un estado saludable muestra un recuento indexado que se aproxima al presentado; una brecha grande y persistente en un solo segmento es la señal que debe investigarse. Cadencia: semanal durante una migración o un lanzamiento grande; mensual en los demás casos.

Métrica: estado de recuperación del sitemap por índice y archivo secundario. Qué indica: si los motores pueden leer los archivos presentados, condición previa para las demás métricas. Cómo se obtiene: columna de estado del informe Sitemaps o el Sitemap Validator para una comprobación bajo demanda. Referencia o rango realista: «Success» es el único estado aceptable; «Couldn’t fetch» y «Has errors» requieren corrección inmediata. Cadencia: cada vez que se modifica el código de generación o se añade un archivo secundario; en los demás casos, una comprobación mensual.

Métrica: cantidad de URL y tamaño de archivo por sitemap frente a los límites. Qué indica: cuánto margen queda antes de volver a dividir un segmento. Cómo se obtiene: recuentos del generador de sitemaps. Referencia o rango realista: debe mantenerse un margen amplio por debajo de 50 000 URL y 50 MB sin comprimir por archivo. Cadencia: a medida que aumenta la cantidad de URL; el segmento se divide antes de alcanzar el límite.

Prompts de IA para un índice de sitemaps

Prompt: comprobar una propuesta de división. Se proporciona una breve descripción de las secciones del sitio y la cantidad aproximada de URL de cada una, y se solicita a una IA que compruebe los criterios antes de crear el í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.

Resultado esperado: una propuesta para agrupar las secciones en sitemaps secundarios, con una nota sobre cualquier sección demasiado pequeña para justificar un archivo separado.

Prompt: revisar errores estructurales en un índice existente. Se proporciona el XML del índice —o un extracto representativo— y se solicita una revisión estructural:

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.

Resultado esperado: una lista línea por línea de las entradas que infringen las reglas de anidamiento o ubicación, para corregirlas antes de volver a presentar el índice.

Recursos que vale la pena consultar

Artículos relacionados de Patrick Stox

• When Should You Worry About Crawl Budget? — función de los sitemaps completos en la eficiencia de rastreo de sitios grandes.
• Website Migration: The Pre- and Post-Launch Checklist — conservación temporal de un sitemap de URL antiguas para observar su salida del índice en GSC.
• Enterprise Technical SEO — automatización de sitemaps y diagnóstico de URL presentadas frente a indexadas a escala.
• The Beginner’s Guide to Technical SEO — lugar de los sitemaps y el descubrimiento en el SEO técnico.

Documentación oficial

• Google — Manage large sitemaps with a sitemap index file.
• sitemaps.org protocol — especificación de <sitemapindex> y sus límites.

Otras fuentes

• r/TechSEO — comunidad para depurar sitemaps, rastreo e indexación.
• Bing Webmaster Tools — Submit a sitemap — guía de Bing para presentar índices y verificarlos.
• Search Engine Journal — Sitemaps coverage — cobertura textual de declaraciones de Mueller y artículos sobre rastreo e indexación.
• Onely — Sitemap resources — análisis técnicos de problemas de sitemaps a gran escala.

Evaluación: índice de sitemaps

Cinco preguntas breves sobre qué es un índice de sitemaps y cómo se utiliza. Se selecciona una respuesta para cada pregunta y luego se comprueba el resultado.

Registro de cambios