Sitemap XML: qué incluir, errores frecuentes y cómo comprobarlo

El formato XML está definido en el protocolo de sitemaps.org. Es una lista de direcciones en UTF-8, y cada una puede llevar la fecha de su última modificación. Los buscadores la leen como una pista: estas son las páginas que consideramos importantes.

Conviene entender los límites de esa pista. Un sitemap ayuda al descubrimiento, sobre todo en sitios grandes, dominios nuevos y webs con pocos enlaces internos. Pero listar una URL no obliga a Google a rastrearla y mucho menos a indexarla. Si una página es pobre, duplica otra o está bloqueada para la indexación, el sitemap no cambia nada.

Un sitio pequeño con buenos enlaces internos puede funcionar sin él. Aun así es un seguro barato: el archivo se genera de forma automática y Google Search Console informa de cuántas URL de la lista ha encontrado. Por eso cualquier web pública se beneficia de tener uno, siempre que alguien lo mantenga al día. Para ver el conjunto de revisiones técnicas, consulta la lista de comprobación de SEO técnico.

El sitemap válido más sencillo tiene este aspecto:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-10-24</lastmod>
  </url>
  <url>
    <loc>https://example.com/pricing</loc>
    <lastmod>2026-09-02</lastmod>
  </url>
</urlset>

Solo es obligatorio loc dentro de url. Las reglas del protocolo son estas:

• el archivo va en UTF-8 y los caracteres especiales de las URL se escapan (& en lugar de &);
• las URL son absolutas, con protocolo y host: https://example.com/page y no /page;
• un archivo admite como máximo 50 000 URL y 50 MB sin comprimir;
• puede comprimirse como .xml.gz, pero el límite de 50 MB se aplica al contenido descomprimido;
• un sitemap situado en un subdirectorio solo puede describir URL de ese directorio y de los inferiores.

El protocolo y el host de las URL deben coincidir con los del sitio. Si la web funciona en https://example.com, las entradas con http:// o con www. son un error.

La regla es simple: lista solo las URL que quieres tener en el índice. Cada una debe cumplir varias condiciones.

• Responde con código 200. Nada de redirecciones ni 404.
• Es indexable: no lleva noindex en la metaetiqueta ni en la cabecera X-Robots-Tag.
• Es la dirección canónica. Si una página apunta su canonical a otra URL, el sitemap debe incluir esa otra. La guía de la etiqueta canonical lo explica.
• No está bloqueada en robots.txt. De lo contrario pides a los rastreadores que encuentren una página y les prohíbes abrirla. La guía de robots.txt muestra cómo escribir las reglas.
• No es una dirección de servicio: resultados de búsqueda interna, combinaciones de filtros con parámetros, páginas del carrito o borradores.

Qué se incluye por error con más frecuencia

Suelen colarse la paginación que añade el CMS de forma automática, los archivos de etiquetas con una sola entrada, los duplicados con parámetros como ?utm_source= y las páginas de agradecimiento tras un formulario. Si dudas de que una página deba aparecer en las búsquedas, tampoco debe estar en el sitemap.

Existen extensiones del protocolo para imágenes, vídeo y noticias. Úsalas solo si ese contenido es importante para tu negocio.

El campo lastmod contiene la fecha del último cambio relevante de la página en formato W3C datetime: 2026-10-24 o una marca de tiempo completa con zona horaria. Según la documentación de Google, solo usa ese valor cuando es coherente y verificablemente exacto. Es decir, si la fecha sigue de verdad los cambios de contenido, puede ayudar a decidir qué volver a rastrear.

Un error habitual es poner en lastmod la fecha de compilación. Entonces cada despliegue renueva todas las URL, incluso las que llevan meses sin tocarse. Los buscadores notan que la señal no se corresponde con la realidad y dejan de creerla.

Qué cuenta como cambio relevante: texto nuevo, un precio distinto, una página reestructurada, datos estructurados actualizados. Corregir una errata o editar el pie de página normalmente no lo es.

Google ignora priority y changefreq, y lo indica en su documentación. Puedes conservarlos si otro sistema los exige, pero no esperes ningún efecto en las búsquedas. Un archivo sin ellos no es peor.

Si no dispones de fechas fiables, es mejor omitir lastmod que rellenarlo con la fecha de hoy.

Cuando superas las 50 000 URL o los 50 MB, hay que dividir el archivo. Se crea un archivo índice que apunta a los sitemaps individuales:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-10-24</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-10-20</lastmod>
  </sitemap>
</sitemapindex>

Dividir resulta útil incluso antes de llegar al límite. Archivos separados para páginas, artículos del blog y productos permiten ver en Search Console qué grupo de URL tiene problemas. El índice puede declararse en robots.txt y enviarse a Search Console igual que un sitemap normal, y los archivos hijos no hace falta enviarlos de nuevo. Los detalles están en la documentación de Google sobre sitemaps grandes.

Para un sitio pequeño de unas decenas de páginas basta un solo archivo. No añadas estructura que no necesitas.

En un sitio multilingüe puedes describir los vínculos entre versiones en el sitemap en lugar de en el head de cada página. Se declara el espacio de nombres xhtml y cada entrada url enumera todas las alternativas, incluida ella misma. Este es un ejemplo con la versión ucraniana en la raíz y las versiones /en y /es:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/pricing</loc>
    <xhtml:link rel="alternate" hreflang="uk" href="https://example.com/pricing"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
  <url>
    <loc>https://example.com/en/pricing</loc>
    <xhtml:link rel="alternate" hreflang="uk" href="https://example.com/pricing"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
  <url>
    <loc>https://example.com/es/pricing</loc>
    <xhtml:link rel="alternate" hreflang="uk" href="https://example.com/pricing"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
</urlset>

La regla clave es la reciprocidad: si la página A apunta a B, B debe apuntar a A. El código del ucraniano es uk, no ua. El resto de errores típicos, incluido x-default, está reunido en la guía de hreflang. Evita mantener dos métodos para la misma página sin motivo: bastan las etiquetas en el head o las entradas del sitemap.

Estos son los que aparecen con más frecuencia.

• URL obsoletas. Una página se eliminó o se movió, pero sigue en el archivo. El rastreador recibe un 404 o una redirección y confía menos en toda la lista.
• Protocolo o host incorrectos. El sitio pasó a HTTPS, pero el sitemap aún enumera http://. Lo mismo ocurre con www frente al dominio sin www.
• Fecha de compilación en lugar de fecha de cambio. Ya descrito: todos los lastmod son idénticos y se renuevan en cada despliegue.
• URL bloqueadas. Las páginas con noindex o prohibidas en robots.txt no deben aparecer en el archivo.
• URL con parámetros. Filtros, ordenaciones e identificadores de sesión crean cientos de duplicados.
• HTML en lugar de XML. En /sitemap.xml el servidor devuelve una página 404 con código 200 (un soft 404) o redirige a la portada. Para un visitante parece una página; para un rastreador es un archivo roto.
• Archivo demasiado grande. Más de 50 000 URL o 50 MB, de modo que parte de las entradas se ignora.
• Nadie lo conoce. El archivo existe, pero no está ni en robots.txt ni en Search Console.

Cómo anunciar el sitemap

Además de Search Console, lo más sencillo es una línea en robots.txt:

User-agent: *
Disallow: /admin/

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

La línea Sitemap no pertenece a ningún grupo User-agent y debe contener una URL absoluta completa.

No hacen falta herramientas caras. Sigue esta rutina.

1. Abre el archivo en el navegador. Debes ver XML, no una página del sitio.
2. Revisa las cabeceras de respuesta con curl -I https://example.com/sitemap.xml. Espera código 200 y un tipo de contenido XML:

HTTP/2 200
content-type: application/xml

1. Añade el archivo al informe de Sitemaps de Google Search Console y compara el número de URL enviadas con las descubiertas. Una diferencia grande es motivo para investigar.
2. Elige entre cinco y diez URL de distintas partes del archivo, ábrelas y confirma que devuelven 200, no llevan noindex y su canonical apunta a ellas mismas.
3. Asegúrate de que el sitemap está declarado en robots.txt.

El escáner gratuito automatiza una parte. Busca un sitemap en /sitemap.xml y en un sitemap del mismo host declarado en robots.txt, e informa si el archivo falta, está vacío, no está declarado o carece de lastmod. También señala URL con http o de otro host y solicita tres URL del archivo (la primera, la central y la última) para ver si responden. Es pasivo: lee como máximo 200 KB del archivo, no lo valida contra el esquema y no rastrea cada dirección. Considéralo una revisión rápida, no un sustituto de Search Console. El análisis forma parte de la auditoría SEO, los aspectos de seguridad están en la comprobación de seguridad y la página de visibilidad en IA trata la preparación para la búsqueda con IA.