¿Qué es un sitemap XML y qué debería llevar el tuyo?

Un buscador descubre las páginas de tu web siguiendo enlaces, como haría una persona que navega sin prisa. Funciona bien en un sitio pequeño y bien enlazado, y regular en todo lo demás: una tienda con miles de productos, un blog con años de archivo o una página nueva que todavía no enlaza nadie.

El sitemap XML es la lista que le entregas al buscador para no depender solo de esa exploración: «estas son las URLs que quiero que conozcas, y esta es la fecha en que cambió cada una».

¿Qué aspecto tiene?

Es un archivo XML con una estructura muy sencilla, definida en el protocolo público de sitemaps.org que comparten Google, Bing y el resto de buscadores:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://tudominio.com/servicios/</loc>
    <lastmod>2026-03-14</lastmod>
  </url>
  <url>
    <loc>https://tudominio.com/blog/como-elegir-un-hosting/</loc>
    <lastmod>2025-11-02</lastmod>
  </url>
</urlset>

Cada <url> lleva obligatoriamente su <loc>, la dirección completa con https:// y dominio. Las URLs relativas no sirven. Y como es XML estricto, un carácter mal escapado (el clásico & de una URL con parámetros, que debe escribirse &) invalida el archivo entero.

Lo habitual es publicarlo en /sitemap.xml y declararlo en el robots.txt con una línea Sitemap:, además de enviarlo desde Search Console y Bing Webmaster Tools. Así lo encuentra cualquier rastreador sin tener que adivinar.

¿Garantiza que Google indexe mis páginas?

No, y conviene ajustar las expectativas. El sitemap es una sugerencia: ayuda a que el buscador descubra URLs y decida cuándo volver a visitarlas, pero no obliga a indexar ninguna. Google sigue evaluando cada página por su cuenta, y una página débil, duplicada o mal enlazada puede quedarse fuera aunque esté en el sitemap.

Dicho eso, para un sitio con contenido que cambia o que crece, un sitemap bien mantenido es de las mejoras técnicas con mejor relación entre esfuerzo y resultado.

¿Cuándo hace falta un índice de sitemaps?

El protocolo pone dos límites por archivo: 50.000 URLs y 50 MB sin comprimir. Se puede servir comprimido con gzip para ahorrar transferencia, pero el límite se mide sobre el tamaño descomprimido.

Cuando un sitio supera esas cifras, o simplemente cuando conviene organizarlo, se usa un índice de sitemaps: un archivo que en lugar de URLs de páginas lista otros sitemaps.

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://tudominio.com/sitemap-productos.xml</loc>
    <lastmod>2026-04-30</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://tudominio.com/sitemap-blog.xml</loc>
  </sitemap>
</sitemapindex>

Partirlo por tipo de contenido tiene una ventaja práctica aunque no superes ningún límite: en Search Console ves por separado cuántas URLs de cada sitemap están indexadas, y eso te dice enseguida si el problema está en los productos, en el blog o en las categorías.

¿Qué campos importan de verdad?

El protocolo define cuatro etiquetas por URL, pero no todas pesan lo mismo:

Etiqueta	Para qué se pensó	Qué hace hoy
<loc>	La dirección de la página	Obligatoria
<lastmod>	Fecha de la última modificación	La usan Google y Bing para decidir qué volver a rastrear, si es fiable
<changefreq>	Cada cuánto cambia	Google la ignora
<priority>	Importancia relativa (0,0 a 1,0)	Google la ignora

lastmod es la que merece cuidado. Debe reflejar cuándo cambió de verdad el contenido de la página, en formato ISO 8601 (2026-03-14, o con hora y zona horaria). Y aquí está la trampa: muchos generadores ponen la fecha del día en todas las URLs cada vez que se regenera el sitemap. Si el buscador detecta que tus fechas no se corresponden con cambios reales, deja de fiarse de ellas, y pierdes justo la señal que hacía útil el archivo. Lo mismo pasa con las fechas futuras.

Cambiar el pie de página o la fecha del copyright no es una modificación de contenido. Corregir un precio, añadir una sección o reescribir un párrafo, sí.

¿Qué URLs no deberían estar en el sitemap?

La regla de fondo es simple: el sitemap solo debería listar URLs canónicas que respondan 200 y que quieras ver en Google. Todo lo demás le manda al buscador señales contradictorias.

Por tanto, fuera:

• URLs que redirigen. Si /oferta-verano redirige a /ofertas/, la que va en el sitemap es la segunda.
• Páginas que dan 404 o 410. Es lo más frecuente después de borrar productos o artículos sin regenerar el archivo.
• Páginas con noindex. Pides que la indexen y a la vez que no la indexen.
• URLs bloqueadas en el robots.txt. El buscador no puede leerlas, así que tampoco puede valorarlas. Está explicado en qué es el robots.txt.
• Versiones no canónicas. Variantes con parámetros de seguimiento, con filtros de tienda, con http:// en un sitio que sirve https://, o con y sin www mezcladas.
• URLs de otro dominio. Un sitemap solo puede declarar direcciones de su propio host; las demás se descartan.

Un sitemap con muchas URLs sobrantes no te penaliza como tal, pero hace más difícil leer los informes de cobertura y diluye la utilidad del archivo como señal.

¿Cómo se mantiene al día?

Un sitemap escrito a mano envejece en semanas. Lo sensato es que lo genere el propio sitio a partir de su contenido publicado: casi todos los CMS y frameworks lo hacen de serie o con un complemento. La pregunta que hay que hacerse no es si existe, sino si refleja la realidad:

• ¿Desaparecen las URLs cuando se borra o despublica una página?
• ¿lastmod sale de la fecha real de edición o de la fecha de generación?
• ¿Las URLs coinciden con las canónicas que declara cada página?

Después de una migración es especialmente importante revisarlo, porque es frecuente que el sitemap nuevo conserve rutas antiguas o que el antiguo siga publicado. Es una de las comprobaciones fijas en una migración bien planificada.

¿Cómo comprobar el tuyo?

El comprobador de sitemap busca el sitemap de un dominio (en las rutas habituales y en el robots.txt), recorre el índice si lo hay, cuenta las URLs y revisa lo que este artículo describe: XML válido, direcciones absolutas y del mismo dominio, fechas lastmod ausentes, mal formadas o en el futuro, duplicados y etiquetas que Google ya no usa. Además pide una muestra de las URLs para ver cuáles responden de verdad y cuáles redirigen o dan error.

Si tu sitemap se declara en el robots.txt, el probador de robots.txt te confirma que esa línea está bien escrita y que no estás bloqueando lo mismo que pides indexar.

---

Un buen sitemap es aburrido: solo URLs vivas y canónicas, con fechas que dicen la verdad, generado solo cada vez que cambia algo. Si el tuyo es así, el buscador lo tratará como una fuente fiable y no como ruido.