Sitemap XML: qué garantiza, formato, límites y errores

Muchas auditorías dan el sitemap por bueno porque «existe y Search Console lo lee». Eso solo prueba que el archivo se descarga y se entiende. No prueba que contenga las URLs correctas, que las fechas sirvan para algo ni que Google vaya a rastrear lo que listas.

Aquí cubro qué es y qué no garantiza un sitemap, el formato y los límites que dice Google, qué etiquetas cuentan, los índices y los sitemaps de imágenes, vídeo y noticias, cómo se envía y diagnostica, los errores más comunes y un análisis sin maquillar de los dos sitemaps de cristofercruz.net.

Qué es un sitemap y qué no garantiza

Un sitemap es un archivo que lista las URLs de tu sitio que quieres que los buscadores conozcan, con datos opcionales como la fecha de modificación. Google admite tres formatos: XML, RSS/mRSS/Atom y texto plano, y declara que no tiene preferencia entre ellos. El XML es el que se usa casi siempre porque admite las extensiones de imagen, vídeo y noticias.

Su límite está en la propia documentación: un sitemap ayuda a encontrar URLs, pero «no garantiza» que todo lo que contiene se rastree y se indexe. Y al enviarlo se dice que es «solo una pista». Es decir, sirve para descubrir, no para forzar nada, y no arregla contenido flojo, duplicado o bloqueado. Tampoco lo trates como una palanca de presupuesto de rastreo: eso solo importa en sitios muy grandes.

Cuándo hace falta y cuándo no

Google lo plantea al revés de lo que se suele oír. Un sitemap te interesa si tu sitio es grande, si es nuevo y tiene pocos enlaces externos, o si tiene mucho contenido multimedia o aparece en Google News. Puede no hacer falta si el sitio es pequeño (la documentación habla de unas 500 páginas o menos), está bien enlazado internamente y no tienes vídeo, imágenes o noticias que quieras destacar.

Mi lectura práctica: en una web pequeña y bien enlazada el sitemap no es la palanca, pero cuesta poco, sirve como inventario de URLs indexables y te da el informe de Search Console. Lo mantengo igualmente, con la condición de que esté bien hecho.

Formato y límites que documenta Google

El mínimo es un urlset con el espacio de nombres correcto y, por cada página, una etiqueta url con su loc. Todo lo demás es opcional según el protocolo en sitemaps.org.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://ejemplo.com/pagina/</loc>
    <lastmod>2026-05-19</lastmod>
  </url>
</urlset>

El escapado importa más de lo que parece. Una URL con parámetros contiene &, y en el XML tiene que ir como &. Un ampersand sin escapar es una causa clásica de error de análisis.

lastmod, changefreq y priority

De las tres etiquetas opcionales, Google lo dice sin rodeos: «ignora los valores de priority y changefreq». Siguen en el protocolo de sitemaps.org (que las define como pistas y las limita a una prioridad relativa dentro del propio sitio), pero para Google no cuentan. No pierdas tiempo calculando prioridades.

lastmod sí se usa, con una condición: Google lo emplea si es coherente y verificable. La fecha debe reflejar la última actualización significativa de la página, no la fecha en que se generó el sitemap. El formato es W3C Datetime, y 2026-05-19 es válido.

Cómo tener un lastmod fiable

• Sácalo del dato real: la fecha de modificación del contenido en tu CMS o base de datos, no la fecha del sistema ni la del despliegue.
• Cámbialo solo con cambios significativos. Corregir una coma o actualizar un pie de página común no lo es.
• No pongas la misma fecha en todas las URLs. Si todas tienen el mismo día, no es información, es ruido.
• Si no puedes garantizarlo, omítelo. Google no pide lastmod, y uno falso lo desacredita.

Sobre la relación con el 304: el protocolo aclara que lastmod es independiente de la cabecera If-Modified-Since y que cada buscador puede ponderarlas de forma distinta. Si te interesa esa parte, la expliqué en caché SEO.

Índices de sitemaps

Cuando superas los límites, divides el sitemap en varios y envías un archivo índice. Un índice puede tener hasta 50.000 etiquetas loc, y según Google puedes enviar hasta 500 índices por sitio en tu cuenta de Search Console. Los sitemaps referenciados tienen que estar en el directorio del índice o por debajo, y alojados en el mismo sitio, salvo que configures el envío entre sitios.

<?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-05-19</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://ejemplo.com/sitemap-blog.xml</loc>
  </sitemap>
</sitemapindex>

Dividir no solo sirve para respetar el techo. Separar por tipo de contenido (páginas, blog, productos) hace que el informe de Search Console te dé una lectura por bloque: si el sitemap de productos tiene un 40 % de URLs excluidas y el del blog un 2 %, ya sabes dónde mirar. La documentación de Google no dice si un índice puede apuntar a otro índice, así que yo no lo hago.

Sitemaps de imágenes, vídeo y noticias

Son extensiones del formato XML. Cada una declara su espacio de nombres en urlset y se puede combinar con las demás en el mismo archivo, aunque Google avisa de que combinar extensiones aumenta mucho el tamaño y los límites siguen aplicándose.

Google ha retirado de su documentación de imágenes las etiquetas image:caption, image:geo_location, image:title e image:license, y de la de vídeo varias como video:category o video:price. Si tu generador aún las incluye, no te perjudican por sí mismas, pero tampoco aportan. En una web de servicios como la mía, sin vídeo propio ni noticias, solo valoraría el de imágenes si las imágenes fueran el negocio; antes iría la optimización de imágenes para SEO.

Una mención sobre hreflang: también se puede declarar en el sitemap con xhtml:link, y cada url debe listar todas las variantes, incluida ella misma. Esos elementos hijos no cuentan para el límite de URLs. El detalle de esa implementación lo trato en el artículo sobre hreflang y aquí no lo desarrollo.

Qué URLs incluir y cuáles no

La regla que aplico: el sitemap es la lista de URLs que quiero indexadas. Cualquier URL que tú mismo desaconsejas en otra señal es una contradicción, y eso incluye las que declaran un canonical hacia otra URL.

Esto conecta con el renderizado: si una URL del sitemap depende de JavaScript para mostrar su contenido, comprueba que Google lo ve renderizado antes de dar por buena su inclusión.

Cómo enviarlo y cómo se diagnostica

Hay dos vías oficiales, y se pueden usar a la vez. La primera es una línea en el archivo robots.txt, en cualquier posición del archivo, con la ruta completa. Google la encuentra la siguiente vez que rastrea el robots.txt, y no hay límite de sitemaps en ese archivo.

Sitemap: https://ejemplo.com/sitemap.xml

La segunda es el informe Sitemaps de Search Console, que necesita permisos de propietario. El procedimiento que describe la ayuda es: publicas el sitemap, compruebas con una inspección de URL en vivo que Googlebot lo alcanza (la carga de página debe figurar como correcta), pegas la URL en el cuadro de nuevo sitemap y le das a enviar. También existe la API de Search Console para hacerlo por programa.

Estados del informe

• Correcto: el sitemap se cargó y se procesó sin errores.
• Tiene errores: se pudo obtener, pero hay uno o más errores de análisis o de URLs.
• No se pudo obtener: el archivo no se descargó. Las causas listadas incluyen bloqueo por robots.txt, una acción manual sin resolver, un 404 y problemas temporales del servidor.

Google obtiene el sitemap enseguida tras enviarlo, pero rastrear las URLs que contiene puede tardar, y no se rastrean necesariamente todas. Tras un fallo reintenta durante unos días. Para errores temporales, la ayuda sugiere reenviar solo si persisten pasadas varias horas. Y «Correcto» no significa que las URLs estén indexadas: eso se mira en el informe de indexación de páginas.

En mi flujo, el informe sirve para saber si el archivo se lee. Para saber qué pasa con las URLs cruzo el sitemap con las páginas indexadas y excluidas. Si quiero saber si Googlebot llega a pedirlas, lo miro con un análisis de logs.

Errores típicos y qué significan

El que más veo en la práctica no genera ningún mensaje: un sitemap con URLs con noindex o que redirigen se lee sin errores y aun así envía señales contradictorias. Solo lo detectas cruzando el sitemap con un rastreo.

Cómo lo tengo en mi web: lo que hay y lo que falta

He revisado el código de cristofercruz.net. Hay dos sitemaps, ambos declarados en robots.txt con líneas Sitemap:: /sitemap.xml y /blog/sitemap.php. No hay un índice de sitemaps que los agrupe.

Lo que hace bien: las URLs son absolutas, con https y el mismo host, el XML se genera con las entidades escapadas (htmlspecialchars) y el sitemap del blog se actualiza solo al publicar y no incluye artículos con fecha futura. El archivo estático lista las páginas que cuelgan del menú y de los servicios.

Lo que no hace bien, sin rodeos:

• El lastmod no es fiable. Las diez fechas del sitemap estático son idénticas, lo que suena a una edición en bloque y no a una fecha por página. Las 14 URLs restantes y las del blog no tienen ninguna. Un lastmod parcial y uniforme no da a Google nada verificable.
• Tengo el dato y no lo uso. Cada artículo tiene un date_modified en su post.json, pero la función que genera el sitemap del blog no lo expone, así que no sale en el XML. Es un arreglo pequeño.
• El sitemap estático no tiene generador. No he encontrado ningún script en el código que lo cree, así que cualquier página fija nueva hay que añadirla a mano y es fácil olvidarla.
• No hay índice ni sitemap de imágenes. Con 30 URLs no lo necesito para los límites. Lo del sitemap de imágenes es una decisión, no una carencia grave, pero hoy no lo uso.
• Una carpeta del blog queda fuera. Existe /blog/google-io-2025/ y no aparece en ninguno de los dos sitemaps. No he comprobado si es intencionado.

Tampoco he verificado desde el código el estado del envío en Search Console: eso solo lo ve quien tiene el acceso a la propiedad. Lo que sí está en el repositorio es la declaración en robots.txt, que a efectos de descubrimiento es suficiente.

Cómo auditar un sitemap

1. Abre el archivo y valida la forma. Respuesta 200, Content-Type XML, UTF-8, espacio de nombres correcto y entidades escapadas. Con curl -I lo ves en segundos.
2. Cuenta URLs y peso. Lejos de 50.000 y 50 MB. Si te acercas, planifica el índice antes del error.
3. Rastrea todas las URLs del sitemap con tu crawler y filtra las que no devuelven 200, tienen noindex, canonical a otra URL o están bloqueadas por robots.txt. Cada una es una contradicción.
4. Compara sitemap y rastreo. Páginas indexables que no están en el sitemap, y URLs del sitemap huérfanas sin enlaces internos, un síntoma habitual de una arquitectura web SEO mal planteada.
5. Revisa lastmod. ¿Hay fechas distintas? ¿Coinciden con la modificación real? ¿Cambian al desplegar sin que cambie el contenido?
6. Lee el informe Sitemaps. Estado, última lectura, URLs descubiertas y errores. Después cruza con el informe de indexación de páginas.

Preguntas frecuentes

Referencias

1. Información general sobre los sitemaps Google Search Central
2. Crear y enviar un sitemap Google Search Central
3. Gestionar sitemaps grandes con un índice Google Search Central
4. Sitemaps de imágenes Google Search Central
5. Sitemaps de vídeo Google Search Central
6. Sitemaps de Google Noticias Google Search Central
7. Versiones localizadas de tu página (hreflang) Google Search Central
8. Informe Sitemaps Ayuda de Search Console
9. Protocolo de sitemaps XML sitemaps.org