Sitemap: qué es, XML frente a HTML y por qué no garantiza la indexación

El término sitemap agrupa dos herramientas distintas que comparten nombre pero no público. El sitemap XML es un archivo con extensión .xml que lista las URLs del sitio en un formato legible por máquinas, pensado para que los rastreadores de los motores de búsqueda, Googlebot entre ellos, descubran las páginas sin depender solo de los enlaces internos. Cada URL puede llevar metadatos adicionales, sobre todo la fecha de última modificación, que ayudan al rastreador a decidir qué revisar primero.

El sitemap HTML es justo lo contrario: una página normal del sitio, visible para cualquier visitante, que enlaza a las secciones o URLs más relevantes. Durante años fue habitual colocarlo en el pie de página como red de seguridad para la navegación, sobre todo en sitios con una arquitectura de menús pobre. Ningún rastreador lo trata de forma especial; para Google es una página más, con los mismos enlaces internos que cualquier otra.

Hoy el sitemap HTML ha perdido buena parte de su razón de ser. Un menú bien diseñado, un buscador interno funcional y un enlazado interno cuidado cubren la misma necesidad de navegación sin necesitar una página dedicada. Sigue teniendo sentido en sitios muy grandes con cientos de secciones, o en proyectos donde la accesibilidad exige una vía clara para llegar a cualquier página en pocos clics.

Cuando alguien en SEO dice simplemente sitemap, casi siempre se refiere al XML. Es el que se envía a Search Console, el que aparece en robots.txt y el que tiene reglas técnicas propias: límites de tamaño, formatos alternativos y un informe de seguimiento dedicado. El resto de este artículo se centra en ese formato y señala las diferencias con el HTML solo cuando son relevantes.

La documentación oficial de Google es explícita sobre lo que un sitemap hace y lo que no hace. En la guía de creación y envío de sitemaps se lee textualmente: "Ten en cuenta que enviar un sitemap es solo una sugerencia; no garantiza que Google vaya a descargar el sitemap ni que lo use para rastrear las URLs del sitio." Esta cita está verificada directamente contra la documentación de Google Search Central, consultada el 09.08.2026.

La página de introducción a los sitemaps repite la idea con otras palabras: "un sitemap ayuda a los motores de búsqueda a descubrir las URLs de tu sitio, pero no garantiza que todos los elementos del sitemap vayan a rastrearse e indexarse." Google decide de forma independiente qué URLs visita y cuáles incorpora a su índice, basándose en la calidad del contenido, los enlaces internos y externos, y señales técnicas como el código de estado o el canonical de cada página.

Esta distinción explica un malentendido habitual: publicar y enviar un sitemap no hace que una página aparezca en Google al día siguiente. Un sitemap facilita el descubrimiento cuando el enlazado interno es débil o el sitio es nuevo, pero no sustituye a un contenido rastreable, indexable y enlazado desde dentro del propio sitio. Si una URL listada en el sitemap no se indexa, la causa casi nunca está en el sitemap en sí, sino en la calidad de la página o en su indexación técnica.

Los campos opcionales del sitemap XML refuerzan esta idea de sugerencia y no de orden. Google ignora por completo los valores priority y changefreq, pensados originalmente para indicar la importancia relativa de cada URL y su frecuencia de cambio. El único campo que Google puede llegar a usar es lastmod, y solo cuando es preciso y verificable: cuando refleja un cambio real de contenido, no una fecha que se actualiza sola cada vez que se regenera el archivo.

En esto tropiezan muchos CMS sin que nadie se dé cuenta. Buena parte de los plugins de sitemap configuran lastmod por defecto con la fecha en que se generó el archivo, no con la fecha real del cambio de contenido. Quien no corrige ese ajuste a mano acaba mandando una señal falsa a Google durante meses, y luego se pregunta por qué el campo parece haber dejado de tener efecto. Basta una comprobación rápida para detectarlo: si lastmod cambia en cada rastreo aunque nadie haya tocado el contenido, el problema está ahí.

Cada archivo de sitemap tiene un límite técnico fijado por el propio protocolo: un máximo de 50.000 URLs o 50 MB sin comprimir, lo que se alcance primero. El límite aplica a todos los formatos aceptados, XML, texto plano con una URL por línea, o los feeds RSS y Atom, aunque estos dos últimos ofrecen muchas menos posibilidades y no admiten, por ejemplo, el campo lastmod con el mismo detalle.

Cuando un sitio supera ese límite, la solución no es forzar un único archivo enorme sino dividir las URLs en varios sitemaps más pequeños y agruparlos en un sitemap index: un archivo que no lista URLs de páginas, sino las rutas a los demás sitemaps. Solo hace falta enviar a Google ese archivo índice; el rastreador sigue las referencias internas hasta llegar a cada sitemap individual.

Esta estructura es habitual en catálogos de e-commerce grandes, en portales de noticias con archivo histórico extenso o en cualquier sitio con más URLs indexables que el límite de un solo archivo. También es buena práctica dividir por tipo de contenido, un sitemap para productos, otro para artículos de blog, otro para páginas de categoría, aunque el sitio no llegue al límite numérico: facilita detectar en qué bloque aparecen los problemas cuando algo falla.

El límite de 50 MB se refiere siempre al archivo sin comprimir. Se puede servir comprimido en formato gzip para ahorrar ancho de banda, y Google lo descomprime antes de aplicar el límite real. Esto permite acercarse a las 50.000 URLs incluso en sitios con nombres de URL largos, sin que el peso del archivo comprimido sea un problema práctico. En la práctica, conviene dividir el sitemap bien antes de llegar al límite en vez de apurarlo hasta el último byte, ya que un sitio ya de por sí grande suele crecer en varios frentes a la vez y puede superar la frontera sin que nadie se dé cuenta.

• Incluye solo URLs que devuelvan 200, sean canónicas y estén pensadas para indexarse.
• Envía el sitemap desde el informe de Sitemaps en Search Console, o referencíalo en robots.txt si no tienes permisos de propietario.
• Usa lastmod solo cuando refleje un cambio real de contenido, nunca como fecha automática de regeneración.
• Divide el sitemap en varios archivos con un sitemap index en cuanto te acerques a las 50.000 URLs o los 50 MB.
• Separa por tipo de contenido, productos, artículos, páginas estáticas, para localizar problemas más rápido en sitios grandes.
• Revisa con regularidad el estado en el informe de Sitemaps: Correcto, No se pudo obtener o Con errores.
• Actualiza el sitemap de forma automática cuando se publica o elimina contenido, no de forma manual y esporádica.
• Comprime el archivo en gzip en sitios grandes para reducir el peso de transferencia sin afectar al límite real de URLs.
• Prescinde de un sitemap HTML dedicado si el menú y el enlazado interno ya cubren la navegación con claridad.

• Dejar en el sitemap URLs marcadas con noindex: Google recibe una señal contradictoria y pierde algo de confianza en el archivo.
• Incluir URLs que redirigen, 301 o 302, en lugar de la URL final a la que apuntan.
• Listar URLs que devuelven error 404 o 500 tras un cambio de estructura sin haber actualizado el sitemap.
• Meter URLs no canónicas junto a sus versiones canónicas, generando señales contradictorias sobre qué versión indexar.
• Rellenar priority y changefreq esperando influir en el rastreo: Google los ignora por completo.
• Olvidar regenerar el sitemap tras una migración de dominio o una reestructuración de URLs.
• Superar el límite de 50.000 URLs o 50 MB en un único archivo sin dividirlo en un sitemap index.
• No enlazar el sitemap desde robots.txt ni enviarlo en Search Console, dejando que Google dependa solo del rastreo espontáneo.