Sitemap index y sitemaps de imágenes y vídeo: límites, lastmod y errores que frenan el rastreo

Un sitemap de más de 50.000 URLs no se indexa: se corta. Y si el generador de tu web sigue rellenando changefreq, priority o image:caption, está escribiendo campos que Google dejó de leer. Estas son las reglas de un sitemap index que todavía cuentan en 2026.

Conviene empezar con la letra pequeña: enviar un sitemap es una recomendación, no una orden. La guía oficial lo dice sin rodeos: ayuda a descubrir URLs, pero no garantiza que Google lo descargue ni que rastree lo que hay dentro.

Qué resuelve un sitemap index (y cuándo no hace falta)

Un sitemap index es un archivo XML que no lista páginas, sino otros sitemaps. Usa el mismo espacio de nombres del protocolo (http://www.sitemaps.org/schemas/sitemap/0.9) y una estructura casi idéntica: cada entrada va dentro de <sitemap> con su <loc> y, si quieres, su propio <lastmod>.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://ejemplo.com/sitemap-paginas.xml</loc>
    <lastmod>2026-10-26</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://ejemplo.com/sitemap-videos.xml</loc>
  </sitemap>
</sitemapindex>

Hay tres razones reales para usarlo: superaste las 50.000 URLs o los 50 MB en un solo archivo; quieres separar por tipo (páginas, imágenes, vídeo, noticias) para ver en Search Console qué sitemap falla; o publicas a diario y prefieres reescribir solo el hijo pequeño que cambió.

Y hay un caso en el que no hace falta: Google admite que un sitio de 500 páginas o menos, bien enlazado desde la portada, probablemente no necesita sitemap. El índice no te daría nada que el enlazado interno no esté haciendo ya.

Los cuatro límites que casi nadie revisa

Los límites vienen del protocolo de sitemaps.org, no de Google, y no se han movido en veinte años:

• Por sitemap: 50.000 URLs y 50 MB sin comprimir (52.428.800 bytes). Puedes servirlo con gzip, pero el límite se mide al descomprimir.
• Por índice: hasta 50.000 etiquetas <loc> (es decir, 50.000 sitemaps listados) y también 50 MB.
• Por propiedad en Search Console: 500 archivos de índice por sitio.
• Por extensión: hasta 1.000 <image:image> dentro de cada <url> y hasta 1.000 <news:news> por sitemap de noticias.

Cuándo dividir de verdad

El techo técnico es 50.000, pero el límite que rompe antes es el de peso: URLs con parámetros largos agotan los 50 MB mucho antes de llegar a las 50.000 entradas, y el archivo se trunca sin avisar. La regla práctica es dividir por secciones o por año de publicación, no por mitades arbitrarias. Y si divides, el que envías a Google es el índice: con un solo envío descubre los hijos.

Dónde debe vivir el índice: la regla del directorio

Dos condiciones que la documentación de sitemaps grandes deja explícitas. Los archivos referenciados deben estar alojados en el mismo sitio que el índice, y deben colgar del mismo directorio o de uno inferior.

De ahí sale el error más común: un sitemap en https://ejemplo.com/blog/sitemap.xml no puede listar la portada, solo /blog/ y lo que está por debajo. Search Console lo marca como "URL no permitida" y el archivo se descarta. La higiene básica es la misma de siempre: UTF-8, URLs absolutas y completas (Google rastrea exactamente lo que escribes, incluidas mayúsculas y protocolo) y publicación en la raíz del dominio siempre que sea posible.

lastmod: el único campo de fecha que Google usa

Es la parte con mejor relación esfuerzo-beneficio del artículo. Google usa <lastmod> si es coherente y verificable, y desde 2023 lo describe como señal para programar rastreos. El formato es W3C: 2026-10-26 o 2026-10-26T09:30:00-03:00; si no es válido, Search Console lo avisa al enviar el archivo.

¿Qué cuenta como modificación significativa? Cambiar el texto principal, los datos estructurados o los enlaces internos de la página: sí. Cambiar la fecha del pie de página o el banner de una promoción: no. Esa distinción es la que separa un campo útil de un ruido.

El lastmod que miente (y cómo se rompe)

El fallo clásico es de CMS: cada vez que se publica algo, el generador pone la fecha del deploy a las 50.000 URLs. A la tercera vez Google deja de creer ese campo y pierdes la única señal de programación que tenías. Si el 100% de tus URLs comparten el mismo lastmod, ese campo no está midiendo modificaciones.

La solución honesta es ponerlo solo en las URLs de las que estás seguro y omitirlo en páginas agregadas (portada, categorías, listados) donde no existe una fecha real. Omitir es válido; mentir, no.

changefreq y priority: cero efecto, y por qué

Google ignora <priority> y <changefreq>. Lo dejó escrito en el anuncio de junio de 2023: changefreq se solapa conceptualmente con lastmod, y priority es un valor subjetivo que no refleja la prioridad real de una página. Tenerlos no penaliza, pero ocupan espacio y dan una falsa sensación de control. En su lugar: enlazado interno bien pensado y un lastmod honesto. La prioridad de rastreo la decide Google con sus propios datos.

Sitemap de imágenes: lo que sobrevivió a la limpieza de 2022

Un sitemap de imágenes sirve, sobre todo, para las imágenes que Google no descubriría de otra forma: típicamente las que carga por JavaScript. Va como extensión dentro de un sitemap normal, con el espacio de nombres http://www.google.com/schemas/sitemap-image/1.1, y la sintaxis mínima es <image:image> con <image:loc>. Caben hasta 1.000 por cada <url>.

En la limpieza de mayo de 2022, efectiva el 6 de agosto de ese año, Google retiró image:caption, image:geo_location, image:title e image:license: no tienen efecto en la indexación. Muchísimos plugins siguen generándolas. No rompen nada, simplemente no aportan. Si tus imágenes viven en un CDN con otro dominio, verifica también ese dominio en Search Console y comprueba que su robots.txt no las bloquea.

Sitemap de vídeo y de noticias: requisitos que se incumplen

En vídeo, los campos obligatorios son <video:video> con <video:thumbnail_loc>, <video:title>, <video:description> (máximo 2.048 caracteres) y <video:content_loc> o <video:player_loc>. Ese último nunca puede ser la misma URL que el <loc> de la página. <video:duration> va en segundos, entre 1 y 28.800. En la misma limpieza cayeron video:category, gallery_loc, price, tvshow y los atributos de player_loc.

En noticias, las reglas son de caducidad: solo artículos de los últimos dos días, máximo 1.000 bloques <news:news> por sitemap, y <news:name> idéntico al nombre que aparece en news.google.com. <news:publication_date> es la fecha de publicación original, no la de alta en el archivo. Si el sitemap queda vacío unos días, Search Console avisa de "sitemap vacío" y no pasa nada: es el comportamiento esperado.

Cómo enviarlo en 2026: el ping ya no existe

El endpoint ping del protocolo se deprecó en junio de 2023 y hoy devuelve 404. Si un plugin "hace ping" a Google, no hace nada útil ni rompe nada: puedes desactivarlo sin miedo. Las vías vigentes son el informe Sitemaps de Search Console, su API, la línea Sitemap: en robots.txt y WebSub si publicas feeds.

robots.txt o Search Console: cuál usar

robots.txt es descubrimiento pasivo: sirve para que el archivo no se pierda, pero no te dice nada del resultado. Search Console da estado, última lectura y errores por sitemap, con una limitación importante: solo los sitemaps enviados por la interfaz o por la API aparecen en el informe. Lo correcto es usar los dos, cada uno para lo suyo.

Diagnóstico: los errores que sí importan

El informe maneja tres estados: Correcto, No se ha podido obtener y "el sitemap tenía X errores", que significa lectura parcial. Las causas reales del segundo, según la ayuda de Search Console, son un robots.txt que bloquea el archivo, una acción manual sin resolver (mientras exista, los sitemaps no se leen), un 404 en la URL del sitemap o un servidor caído.

Los errores de análisis más frecuentes son "URL no permitida" (nivel superior al del sitemap o dominio distinto), "no se han seguido las URLs" (redirecciones, meta-refresh o rutas relativas) y "algunas URLs no son accesibles". La otra mitad del trabajo es no ensuciar el archivo: fuera las URLs con noindex, redirecciones, 404 y duplicados no canónicos. Para saber si Google lo descarga de verdad, el análisis de logs te lo dice mejor que cualquier informe.

Checklist de 7 puntos

1. Cuenta URLs y megas: si pasas de 50.000 o de 50 MB, necesitas un índice.
2. Comprueba que índice e hijos están en el mismo sitio y que ningún hijo cuelga por encima del índice.
3. Verifica que todas las URLs son absolutas, canónicas y en UTF-8.
4. Revisa que lastmod refleje cambios reales y no la fecha del deploy.
5. Elimina changefreq, priority, image:caption e image:title si siguen generándose.
6. Confirma que está enviado en Search Console y referenciado en robots.txt, sin errores de lectura.
7. Valida las etiquetas obligatorias de los sitemaps de imágenes y vídeo.

Para otras vías de descubrimiento, el artículo sobre IndexNow explica por qué Google no lo usa; y si vienes de cero, el tutorial clásico de sitemaps cubre la instalación básica.