El fichero sitemap.xml [actualización 2026]

[Publicada el 15 de marzo de 2017. Revisada en octubre de 2026]

Esta entrada arrastra sus años a las espaldas y algunas cifras y etiquetas se habían quedado rancias. Mantengo lo que sigue en pie, corrijo lo que la realidad ha dejado desfasado y añado cambios que en 2017 ni existían. Cuando algo sea distinto a lo que afirmé en su día, te lo señalo directamente en su apartado.

Sigo adelante con esta trilogía sobre archivos de configuración en servidores web. Si en las entregas anteriores me detuve en .htaccess, ahora le toca el turno al sitemap.xml, un elemento que camina de la mano de robots.txt (del que hablo en otro artículo).

Mapa visual del sitio frente a sitemap.xml

Antes de entrar en harina conviene deshacer un lío terminológico recurrente. En clase veo a menudo que mis alumnos confunden el mapa del sitio tradicional con el sitemap.xml. Es un despiste comprensible porque ambos términos significan lo mismo y persiguen un fin similar: mostrar cómo se organiza la web. Pero sus diferencias son notables.

Un mapa del sitio visual forma parte de lo que Rosenfeld, Morville y Arango (2015) clasifican como sistemas de navegación complementarios. Es decir, mecanismos pensados para un fin concreto dentro del esquema de navegación del portal. Eso implica una serie de rasgos propios:

• Queda expuesto directamente al usuario, que puede consultarlo a través de un enlace situado en la interfaz.

• Su maquetación utiliza HTML (o formatos gráficos, aunque esta última opción entorpece la indización) y respeta las decisiones tipográficas y el diseño general de la web.

• El buscador lo indiza como cualquier otra página, por lo que influye en la visibilidad del sitio.

• No responde a un tamaño fijo; depende de la arquitectura de la información del proyecto. Conviene organizarlo bien (mediante sangrías o bloques) y evitar desplazamientos verticales excesivos.

• Tampoco resulta obligatorio. Solo tiene sentido cuando la estructura del sitio alcanza cierta complejidad y conviene ofrecer un atajo directo. Aporta una panorámica completa de un vistazo e incluso favorece la serendipia al descubrir contenidos en una primera visita. Un apunte al margen: revisando webs institucionales para buscar ejemplos de estos mapas, salta a la vista que portales de varios ministerios han regresado al diseño de hace una década. Son desastrosos en lo visual y presentan una arquitectura de la información inexistente.

Por el contrario, el sitemap.xml es un documento en formato XML que suele ubicarse en la raíz del servidor. Y digo que suele porque en 2017 afirmé que funcionaba igual de bien alojado en cualquier subdirectorio, algo cierto solo a medias: según la documentación de Google, un sitemap alojado en una carpeta secundaria solo ampara a las direcciones que cuelgan de esa ruta, salvo que lo registres expresamente desde Search Console. De ahí que lo más sensato sea mantenerlo en la raíz. Su formato delata su propósito: no está pensado para ser leído por personas, sino consumido por rastreadores web.

Función del archivo

Su cometido básico es trazar un mapa claro para que los motores de búsqueda identifiquen las rutas completas de todos los documentos del servidor. Al disponer de este listado, el bot mantiene un control preciso sobre qué URLs ha procesado y cuáles tiene pendientes.

En una web pequeña, con un sistema de enlaces coherente y una estructura bien jerarquizada, este fichero no sería imprescindible. Sin embargo, facilita el trabajo de rastreo. En 2017 sostuve que tener un sitemap garantizaba de forma demostrada un mejor posicionamiento. Hoy modero esa afirmación: el buscador interpreta el sitemap como una sugerencia, jamás como una orden, y que una URL aparezca listada no asegura que termine en el índice.

Resulta especialmente útil en proyectos con miles de páginas o en sitios donde existen documentos aislados que carecen de enlaces internos que apunten hacia ellos.

El protocolo sitemap

Google presentó la propuesta para facilitar el trabajo a los webcrawlers en junio de 2005, apoyándose en las ideas planteadas en un trabajo publicado en la revista de Sigmetrics en el año 2000. Un año más tarde vio la luz la versión 0.90 del protocolo sitemap.xml. Hoy constituye el estándar indiscutible de la industria. Las especificaciones de este protocolo establecen pautas precisas:

Todas las direcciones incluidas deben pertenecer al mismo dominio y utilizar el mismo protocolo. Los subdominios computan a efectos de SEO como sitios independientes, por lo que no deben mezclarse en el mismo archivo. En 2017 dije que si operabas en HTTP y HTTPS debías mantener dos ficheros separados. La realidad actual es que todo debe transitar bajo HTTPS y el mapa debe listar únicamente la versión final limpia, sin URLs que respondan con redirecciones. Para quienes gestionan redes de portales existe el envío cruzado: Google autoriza incluir direcciones de dominios distintos en un mismo sitemap siempre que todos estén verificados en la misma cuenta de Search Console.

El tope de tamaño fijado en 2017 era de 10 megas. El límite actual alcanza los 50 MB sin comprimir (52.428.800 bytes) y un máximo de 50.000 URLs por archivo. Si tu sitio rebasa esas cifras, debes fragmentar la información en varios archivos sitemap.xml e integrarlos mediante un fichero de índice (sitemapindex). Este índice obedece a las mismas restricciones de tamaño y permite enlazar hasta 50.000 submapas. Su estructura básica es esta:

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

El archivo admite compresión en formato GZIP para reducir la transferencia de datos, aunque el límite de 50 MB sigue evaluándose sobre el fichero descomprimido.

La codificación obligatoria es UTF-8. Si las direcciones contienen caracteres especiales, hay que escapar la sintaxis XML mediante las entidades correspondientes (& por &, ' por ', " por ", < por < y > por >).

Etiquetas básicas y opcionales

El nodo raíz es <urlset>, cada elemento individual se encierra dentro de <url> y la dirección física se especifica en <loc> con su protocolo completo (y un máximo de 2.048 caracteres).

Las etiquetas secundarias que acompañan a cada enlace han corrido distinta suerte:

• <lastmod>: Registra la fecha de la última actualización en formato AAAA-MM-DD (admite también hora y zona horaria). Es la única etiqueta opcional que Google sigue teniendo en cuenta, siempre que la información sea verídica y consistente. Si la cambias sistemáticamente sin haber modificado el contenido, el robot terminará ignorándola.

• <changefreq>: Declara la frecuencia teórica de modificación (always, weekly, monthly, etc.). En 2017 le atribuí un peso decisivo para marcar el ritmo de visita del robot. Fui demasiado optimista. La documentación actual de Google confirma que pasa por alto este campo, y en las notas oficiales de WordPress reconocen que apenas se utiliza.

• <priority>: Pondera la importancia relativa de una URL dentro del sitio en una escala de 0.0 a 1.0. El error habitual consistía en asignar 1.0 a todas las páginas, lo que neutralizaba el criterio de jerarquía. La recomendación de la documentación de Google es descartarla directamente, ya que tampoco la consumen.

Con estas premisas, una estructura limpia para un portal con dos páginas queda de este modo:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.ejemplo.es/</loc>
    <lastmod>2026-10-27</lastmod>
  </url>
  <url>
    <loc>https://www.ejemplo.es/saludo.html</loc>
    <lastmod>2026-03-15</lastmod>
  </url>
</urlset>

Si alguna herramienta te obliga a rellenar los parámetros secundarios, se añaden a continuación de la etiqueta <loc>:

<changefreq>weekly</changefreq>
<priority>0.5</priority>

Generación del archivo

Construir este archivo a mano resulta tedioso y propenso a descuidos. La práctica habitual en entornos de producción es automatizar su generación.

Existen dos caminos habituales:

1. Generadores en línea: Herramientas web que analizan el sitio y entregan el documento empaquetado. Presentan un inconveniente claro: exigen regenerar el archivo manualmente cada vez que publicas o modificas algo. Siguen operativos servicios como XML-Sitemaps.com (gratuito hasta 500 URLs), Xml Sitemap Generator o Small SEO Tools. De la lista que sugería en 2017 he eliminado uno que ha dejado de prestar servicio.

2. Módulos integrados en CMS: Es la vía lógica cuando trabajas con plataformas como WordPress, Drupal o Joomla. En WordPress hay una novedad destacable: desde la versión 5.5 (2020) el propio núcleo genera un sitemap automático en /wp-sitemap.xml. Es una solución básica que no abarca imágenes, vídeos ni noticias, pero resuelve el expediente sin plugins adicionales. Si necesitas funciones avanzadas, tendrás que instalar una extensión específica.

3. Hacerlo a mano: ni se te ocurra. Es una locura.

Sitemaps específicos

Dado que una web alberga recursos más allá del texto, existen variantes orientadas a tipologías concretas:

• Imágenes: Orientados a descubrir recursos gráficos complejos o cargados por JavaScript. En 2017 mencioné que se podían especificar títulos, ubicación geográfica o licencias mediante etiquetas promocionadas por Google. En agosto de 2022, Google retiró el soporte para <image:caption>, <image:geo_location>, <image:title> e <image:license>. En la actualidad basta con emplear <image:image> y su correspondiente <image:loc>, admitiendo hasta 1.000 imágenes por cada dirección.

• Vídeo: Aportan datos sobre la localización de archivos de vídeo. Requieren indicar la miniatura, el título, una descripción y la ruta del reproductor. Google también ha recortado etiquetas en este formato (eliminando precios o categorías) y admite la integración mediante canales mRSS.

• Noticias: Pensados para medios digitales. Exigen incluir el nombre del medio, idioma, título y fecha. Solo deben contener artículos publicados en los últimos dos días, con un tope de 1.000 URLs por archivo.

El protocolo también admite listados en texto plano (una URL por línea) o la lectura de canales RSS y Atom.

Notificación a los buscadores

Una vez generado y subido al servidor, conviene validar la sintaxis con las herramientas de esquema del W3C o la validación automática de Search Console.

Para comunicar su ubicación a los rastreadores dispones de dos vías operativas (la tercera ha pasado a la historia):

1. Paneles de administración para webmasters: En Search Console (lo que antes llamábamos Google Webmaster Tools) o Bing Webmaster Tools puedes registrar la ruta del sitemap. Google solicita expresamente enviarlo solo cuando se genera por primera vez o sufre modificaciones.

2. Directiva en robots.txt: Añadiendo la línea Sitemap: https://www.ejemplo.es/sitemap.xml. En 2017 indicaba que debía colocarse al final del archivo; en realidad es una directiva global que puede situarse en cualquier punto y de la que puedes incluir tantas líneas como sitemaps utilices.

3. La vía descartada: El antiguo mecanismo de ping  fue retirado por Google en diciembre de 2023, devolviendo un error 404. Bing procedió de igual modo y sugiere la adopción de IndexNow, un protocolo sustentado por Bing, Yandex, Seznam y Naver (donde Google de momento no participa) para notificar cambios de URLs en tiempo real.