Un sitemap XML parece una de esas partes del SEO técnico que configuras una vez y puedes olvidar. El CMS lo genera, lo envías a Google Search Console y asunto resuelto. Al menos, esa es la teoría.
En la práctica no siempre es así. He visto sitemaps con redirecciones, páginas eliminadas, URLs noindex, versiones no canónicas y fechas lastmod que cambian cada día aunque el contenido lleve meses exactamente igual. En una web pequeña quizá no sea un drama, pero cuando empiezas a trabajar con miles o cientos de miles de URLs, merece la pena tomárselo bastante más en serio.
Respuesta rápida
Un sitemap XML bien configurado debería incluir las URLs canónicas que queremos que los buscadores descubran y consideren para sus resultados. Conviene evitar URLs redireccionadas, eliminadas, duplicadas o no indexables. Si utilizamos lastmod, la fecha debe corresponder a una modificación significativa y real de la página, no simplemente al momento en que se generó el sitemap.
Puntos clave
- El sitemap ayuda a descubrir URLs, pero no garantiza que Google vaya a indexarlas.
- Google recomienda incluir las URLs que queremos ver en sus resultados, normalmente nuestras URLs canónicas.
- Las páginas noindex, redirecciones, errores 404 y URLs no canónicas normalmente deberían quedarse fuera.
lastmoddebe representar una modificación real y significativa de la página.- No tiene sentido cambiar
lastmodcada día si el contenido no ha cambiado. - Google ignora actualmente
priorityychangefreq. - Un sitemap admite como máximo 50.000 URLs o 50 MB sin comprimir.
- Cuanto mayor sea una web, más importante es mantener limpios y coherentes sus sitemaps.
Índice
- Qué es un sitemap XML y para qué sirve
- Qué URLs debe contener un sitemap XML
- Qué URLs no deberían aparecer
- Qué es lastmod y por qué importa
- ¿Google utiliza realmente lastmod?
- Ejemplo de un sitemap XML correcto
- Qué es un dirty sitemap
- Sitemap, canonical y noindex
- Sitemaps y crawl budget
- Límites de los sitemaps XML
- Cómo enviar un sitemap a Google
- Cómo auditar un sitemap XML
- Errores frecuentes
- WordPress, PrestaShop y otros CMS
- Checklist de sitemap XML
- Preguntas frecuentes
Qué es un sitemap XML y para qué sirve
Un sitemap XML es, simplificando mucho, una forma de decirle a los buscadores: «Estas son las URLs de mi web que quiero que conozcas».
El archivo contiene una relación estructurada de URLs y puede añadir información adicional, como la fecha de última modificación mediante lastmod. Su función principal es facilitar el descubrimiento y rastreo de contenido.
Google explica en su documentación sobre sitemaps que estos archivos resultan especialmente útiles en sitios grandes, webs nuevas con pocos enlaces externos, sitios con mucho contenido multimedia o páginas que pueden estar relativamente aisladas dentro de la arquitectura.
Eso sí, conviene dejar clara una cosa desde el principio: un sitemap es una ayuda para los buscadores, no una lista de órdenes.
Tener una URL en el sitemap no garantiza su indexación
Enviar una URL mediante un sitemap no obliga a Google a rastrearla, indexarla y mucho menos posicionarla. Google deja claro que enviar un sitemap es únicamente una señal y que sus sistemas continúan decidiendo qué URLs rastrear e indexar.
| Un sitemap puede ayudar a | Un sitemap no garantiza |
|---|---|
| Descubrir URLs | Su indexación |
| Comunicar nuestras URLs preferidas | Que Google acepte nuestra canonical |
| Informar de cambios relevantes | Un rastreo inmediato |
| Gestionar sitios con muchas URLs | Mejores posiciones |
Puede parecer una diferencia pequeña, pero es importante. Todavía existe la idea de que meter una URL en el sitemap equivale a pedirle a Google que la indexe. No funciona así.
Qué URLs debe contener un sitemap XML
Mi regla práctica es bastante sencilla: el sitemap debería representar las URLs válidas que realmente queremos presentar a los buscadores.
Google recomienda en su documentación para crear y enviar sitemaps incluir las URLs que queremos ver en sus resultados de búsqueda. Como Google normalmente muestra URLs canónicas, también recomienda proporcionar en el sitemap aquellas que consideramos canónicas.
Y aquí aparece una idea importante: el sitemap también forma parte de las señales de canonicalización.
Incluye las URLs canónicas
Imagina que el mismo contenido puede encontrarse en dos URLs. Una de ellas declara mediante rel="canonical" que la otra es la versión principal, pero metemos las dos dentro del sitemap.
No hemos roto Internet, pero tampoco estamos siendo especialmente claros.
Google explica en su documentación sobre canonicalización que la presencia de una URL en un sitemap es una señal más débil que una redirección o rel="canonical", pero sigue siendo una señal.
Si sabemos cuál es nuestra URL preferida, lo lógico es que canonical, sitemap y enlazado interno apunten en la misma dirección.
Incluye URLs válidas e indexables
Como norma general, una URL del sitemap debería responder correctamente, ofrecer el contenido esperado y ser candidata a indexación.
Esto no es una cuestión de intentar «engañar» o «gustar» a Google. Es simplemente mantener ordenada nuestra propia arquitectura técnica.
Qué URLs no deberían aparecer en un sitemap XML
Un sitemap no debería convertirse en un inventario de todo lo que nuestro servidor es capaz de devolver. Que una URL exista no significa necesariamente que queramos presentarla a los buscadores.
| Tipo de URL | ¿Incluir? | Motivo |
|---|---|---|
| Canónica, válida e indexable | Sí | Es candidata a aparecer en buscadores |
| URL con noindex | Normalmente no | Estamos enviando señales contradictorias |
| Redirección 3xx | No | Deberíamos utilizar el destino final cuando corresponda |
| 404 o 410 | No | El recurso ya no existe |
| Duplicado con canonical hacia otra URL | No | Deberíamos declarar la versión canónica |
| URL parametrizada duplicada | Normalmente no | Puede introducir ruido y duplicación innecesaria |
También hay que evitar el extremo contrario. Una URL no necesita aparecer obligatoriamente en un sitemap para que Google pueda encontrarla. Los buscadores también descubren contenido siguiendo enlaces internos y externos, entre otros mecanismos.
El sitemap es una señal adicional. Importante en determinados contextos, sí. Mágica, no.
Qué es lastmod y por qué importa
Aquí llegamos a una de las partes que más errores genera.
<lastmod> indica cuándo se modificó por última vez una URL. Es un elemento opcional del protocolo oficial de Sitemaps, pero puede proporcionar una señal útil a los buscadores cuando la información es fiable.
La palabra importante es precisamente esa: fiable.
Uno de los errores más habituales consiste en regenerar el sitemap cada día y asignar automáticamente la fecha actual a todas las URLs. Si una página no se ha modificado desde hace seis meses, poner hoy como fecha de última modificación no hace que el contenido sea más fresco. Simplemente hace que el dato sea incorrecto.
Qué cambios justifican actualizar lastmod
Google pone ejemplos bastante claros. Cambios importantes en el contenido principal, en los datos estructurados o en los enlaces de una página pueden justificar actualizar lastmod.
En cambio, cambiar simplemente el año del copyright del footer no significa que todas las páginas de la web hayan sido actualizadas.
Esto parece obvio cuando lo explicamos así, pero en sistemas automatizados es muy fácil terminar haciendo precisamente lo contrario.
¿Hay que actualizar lastmod todos los días?
No. Hay que actualizarlo cuando la página ha sufrido un cambio significativo.
Si un artículo no cambia durante seis meses, mantener su fecha real durante esos seis meses es más útil que decirle cada mañana al buscador que acaba de cambiar.
Bing ya llamó la atención sobre este problema en un análisis sobre la importancia de lastmod. Encontraron sitemaps donde las fechas correspondían al momento en que se generaba el archivo y no a la modificación real de las páginas. Si un buscador detecta que la señal no es fiable, su utilidad desaparece.
¿Google utiliza realmente lastmod?
Sí.
Pero hay un matiz importante. Google indica que utiliza lastmod cuando sus valores son coherentes y verificables. Es decir, puede comprobar si las fechas que declaramos tienen sentido respecto a los cambios observados en las páginas.
Por eso yo no trataría lastmod como un truco para conseguir que Googlebot vuelva antes. Lo trataría como lo que realmente es: información técnica que debería describir correctamente lo que ha ocurrido en nuestra web.
Si una señal es buena, mantenla buena.
Lastmod y los buscadores basados en IA
Esta cuestión se vuelve todavía más interesante con la evolución de los buscadores hacia sistemas basados en inteligencia artificial.
Microsoft explicó en 2025, en un artículo sobre sitemaps y búsqueda impulsada por IA, que disponer de valores lastmod precisos ayuda a Bing a priorizar qué URLs debería volver a rastrear y reindexar, evitando al mismo tiempo rastreos innecesarios de páginas que no han cambiado.
Ahora bien, no debemos dar el salto fácil de afirmar que ChatGPT, Gemini, Claude o Perplexity utilizan lastmod exactamente de la misma manera. No tenemos documentación pública suficiente para demostrarlo.
Lo que sí sabemos es que mantener información técnica fiable facilita el trabajo de los sistemas que dependen de índices web actualizados. Y eso ya es motivo suficiente para hacerlo bien.
Ejemplo de un sitemap XML correcto
No hace falta complicarlo. Un sitemap básico podría tener este aspecto:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.ejemplo.com/</loc>
<lastmod>2026-10-01</lastmod>
</url>
<url>
<loc>https://www.ejemplo.com/servicios/</loc>
<lastmod>2026-09-18</lastmod>
</url>
</urlset>| Elemento | Para qué sirve |
|---|---|
<urlset> | Contiene las URLs del sitemap |
<url> | Agrupa la información de cada URL |
<loc> | Indica la dirección completa de la página |
<lastmod> | Indica cuándo se modificó por última vez |
¿Y qué ocurre con priority y changefreq, dos etiquetas que seguramente habrás visto en muchos sitemaps?
Google indica actualmente que ignora ambas. Puedes encontrarlas todavía en generadores, plugins y documentación antigua, pero no merece la pena diseñar una estrategia SEO alrededor de ellas.
Qué es un “dirty sitemap”
Hace años empezó a utilizarse dentro del sector SEO la expresión dirty sitemap para referirse a sitemaps que contienen URLs que realmente no deberían estar allí.
Redirecciones, páginas eliminadas, URLs noindex, duplicados, versiones no canónicas, parámetros innecesarios o fechas de modificación que no representan cambios reales.
Me gusta el concepto porque describe bastante bien el problema. Un sitemap puede ser técnicamente válido como XML y estar, desde el punto de vista SEO, bastante sucio.
Google no va a dejar de rastrear una web porque encuentre una redirección en el sitemap. El problema es otro: estamos utilizando un archivo destinado a comunicar nuestras URLs preferidas y lo estamos llenando de excepciones.
Sitemap, canonical y noindex deberían contar la misma historia
Este es probablemente el punto que considero más importante de toda la guía.
No deberíamos analizar un sitemap de manera aislada. Hay que cruzar sus URLs con la canonical, las directivas de indexación, la respuesta HTTP y, cuando sea posible, el enlazado interno.
| Sitemap | Canonical | Indexabilidad | Qué tenemos |
|---|---|---|---|
| Sí | A sí misma | Indexable | Señales coherentes |
| Sí | Otra URL | Indexable | Señales de canonicalización contradictorias |
| Sí | A sí misma | Noindex | Señales de indexación contradictorias |
| No | A sí misma | Indexable | Puede ser perfectamente válida |
| Sí | — | 404/410 | Deberíamos retirarla del sitemap |
Una URL puede estar perfectamente indexada sin aparecer en un sitemap. Pero cuando decidimos incluirla, yo intentaría que el resto de señales técnicas fueran coherentes con esa decisión.
Dicho de otra manera: si nosotros mismos no tenemos claro cuál es la URL buena, no tiene demasiado sentido esperar que un buscador interprete siempre nuestras intenciones.
Sitemaps y crawl budget en sitios grandes
Si tienes una web con 100 páginas y accidentalmente mantienes un par de redirecciones en el sitemap, probablemente tengas problemas más importantes de los que preocuparte.
Con 100.000, 400.000 o varios millones de URLs la conversación cambia.
Eso no significa que exista un número mágico a partir del cual Google diga «ahora tienes un problema de crawl budget». No existe ese umbral.
La documentación de Google sobre crawl budget está dirigida principalmente a sitios con más de un millón de páginas que cambian aproximadamente una vez por semana, sitios medianos o grandes de unas 10.000 páginas o más que cambian a diario y webs que tienen una proporción importante de URLs clasificadas como «Descubierta: actualmente sin indexar».
Las propias cifras son orientativas.
Por eso no perdería demasiado tiempo hablando de crawl budget en una web pequeña que Google rastrea sin problemas. En un ecommerce enorme, un marketplace, un periódico o una web con navegación facetada capaz de generar cientos de miles de combinaciones, la situación es muy diferente.
Cuántas URLs puede contener un sitemap XML
Aquí sí tenemos números concretos.
Un sitemap individual puede contener un máximo de 50.000 URLs y no puede superar los 50 MB sin comprimir.
Si superamos cualquiera de esos límites, dividimos las URLs entre varios archivos y podemos agruparlos mediante un índice de sitemaps o sitemap index.
Los archivos pueden comprimirse utilizando gzip, pero el límite se aplica al tamaño una vez descomprimidos. Todos estos límites están definidos en el protocolo oficial de Sitemaps y en la documentación de Google.
Cómo enviar un sitemap a Google
La forma más conocida es hacerlo desde Google Search Console.
Dentro del informe de Sitemaps de Google Search Console podemos indicar la dirección del archivo y consultar posteriormente información sobre su procesamiento.
Otra opción muy recomendable es declarar su ubicación dentro de robots.txt:
Sitemap: https://www.ejemplo.com/sitemap.xmlLa URL debe ser absoluta.
Y volvemos a lo mismo: enviar el sitemap no significa solicitar la indexación automática de todo lo que contiene. Google seguirá decidiendo qué rastrea, qué indexa y qué versión considera canónica.
Cómo auditar un sitemap XML de verdad
En una auditoría SEO, comprobar únicamente que existe sitemap.xml me parece quedarse muy corto.
Lo interesante empieza cuando cruzamos las URLs declaradas con lo que ocurre realmente en la web.
- Extraer todas las URLs declaradas en los sitemaps.
- Comprobar sus códigos de respuesta HTTP.
- Detectar redirecciones.
- Comprobar las directivas de indexación.
- Extraer la canonical de cada página.
- Comparar la URL declarada en sitemap con su canonical.
- Detectar errores 404, 410 y otros problemas HTTP.
- Revisar
lastmody comprobar si las fechas tienen sentido. - Comparar las URLs del sitemap con las descubiertas mediante rastreo interno.
- Localizar URLs declaradas en el sitemap que no reciben enlaces internos observados.
- Buscar duplicados y variantes parametrizadas.
- Contrastar posteriormente los resultados con Google Search Console.
Es precisamente el enfoque que estoy aplicando al desarrollar herramientas propias de auditoría SEO. No me interesa demasiado que una herramienta me diga simplemente «sitemap encontrado». Quiero saber si las URLs que contiene son coherentes con el resto de evidencias que podemos observar.
Una URL puede estar dentro del XML y al mismo tiempo tener una canonical diferente, estar marcada como noindex, devolver una redirección o no aparecer prácticamente en ningún punto de la arquitectura interna.
Ahí empieza el diagnóstico interesante.
Si quieres profundizar en este tipo de análisis, en mi web como consultor SEO técnico también desarrollo contenidos y herramientas relacionados con rastreo, indexación y optimización técnica.
Errores frecuentes en un sitemap XML
Muchos de estos errores no son especialmente sofisticados. Precisamente por eso merece la pena automatizar su detección.
- URLs redireccionadas. El sitemap continúa declarando una dirección que ya no representa el destino definitivo.
- Páginas 404 o 410. Suele ocurrir cuando eliminamos contenido pero el sitemap no se actualiza correctamente.
- URLs noindex. Una parte de la web dice «esta URL es importante» y otra dice «no quiero que aparezca en el índice».
- URLs no canónicas. El sitemap apunta hacia una dirección y la canonical hacia otra.
- Lastmod actualizado todos los días. La fecha deja de representar cuándo cambió realmente el contenido.
- Fechas futuras. Normalmente indican un problema de generación, lógica o zona horaria.
- Obsesionarse con priority y changefreq. Google indica actualmente que ignora ambas etiquetas.
- Superar los límites técnicos. Si el sitemap es demasiado grande hay que dividirlo.
- Utilizar URLs relativas. Las URLs declaradas deben ser absolutas.
- Generarlo una vez y olvidarse. Las webs cambian: desaparecen productos, aparecen categorías, hacemos migraciones y modificamos la arquitectura.
Sitemap XML en WordPress, PrestaShop y otros CMS
Hoy casi cualquier CMS puede generar un sitemap automáticamente. WordPress dispone de funcionalidad nativa y plugins como Yoast SEO pueden encargarse de generar sus propios sitemaps. En PrestaShop también existen módulos para hacerlo.
Automático, sin embargo, no significa infalible.
Después de una migración, cambios en categorías, eliminación de productos, modificaciones de canonical o cambios en las reglas de indexación merece la pena comprobar qué está publicando realmente el sitemap.
He trabajado con PrestaShop y SEO técnico durante años, y en ecommerce esta comprobación tiene todavía más sentido: productos descatalogados, categorías, filtros y cambios de catálogo pueden hacer que el inventario real de URLs cambie constantemente.
Por eso «¿existe el sitemap?» y «¿el sitemap representa correctamente la web?» son dos preguntas muy diferentes.
Checklist: cómo saber si tu sitemap XML está bien configurado
- ☐ El sitemap responde correctamente.
- ☐ El XML es válido y utiliza UTF-8.
- ☐ Todas las URLs son absolutas.
- ☐ No supera las 50.000 URLs por archivo.
- ☐ No supera los 50 MB sin comprimir.
- ☐ Las URLs importantes y canónicas están representadas.
- ☐ No contiene redirecciones innecesarias.
- ☐ No contiene URLs 404 o 410.
- ☐ No contiene páginas
noindexsin una razón justificada. - ☐ No contiene duplicados no canónicos.
- ☐
lastmodrepresenta cambios reales cuando se utiliza. - ☐ No se modifica artificialmente
lastmodal regenerar el XML. - ☐ El sitemap es descubrible por Google.
- ☐ Se actualiza cuando cambia el inventario de URLs.
- ☐ Sitemap, canonicalización e indexabilidad son coherentes.
Mi forma de verlo: un sitemap debe ser una fuente fiable
Después de muchos años trabajando con SEO, cada vez me interesan menos las configuraciones hechas simplemente porque «siempre se ha hecho así» y más entender qué señal estamos enviando realmente.
Para mí, un sitemap es una declaración de intenciones técnica. Si entregamos a un buscador una lista de URLs, intentemos que esa lista sea limpia y fiable.
Una URL que aparece en el sitemap, redirige a otra, declara una canonical diferente y además tiene un noindex probablemente no vaya a provocar por sí sola una catástrofe SEO. Pero estamos obligando al buscador a resolver contradicciones que podríamos haber evitado.
En una web pequeña quizá apenas lo notes. En un ecommerce con cientos de miles de productos, categorías, filtros y URLs históricas, esas pequeñas incoherencias empiezan a multiplicarse.
Y ahí es donde un sitemap limpio deja de ser un detalle para convertirse en una parte más de una buena arquitectura SEO técnica.
Preguntas frecuentes sobre sitemap XML
¿Qué es un sitemap XML?
Es un archivo estructurado que proporciona a los buscadores información sobre las URLs de un sitio web. También puede incluir datos adicionales como la fecha de última modificación de cada página.
¿Es obligatorio tener un sitemap?
No. Google puede descubrir páginas siguiendo enlaces aunque no exista sitemap. Aun así, tenerlo puede facilitar el descubrimiento y la gestión de URLs, especialmente en sitios grandes, nuevos o con arquitecturas complejas.
¿Qué URLs deben incluirse?
Como regla general, las URLs canónicas, válidas e indexables que queremos que los buscadores descubran y consideren para sus resultados.
¿Debo incluir páginas noindex?
Normalmente no. Si estamos indicando expresamente que una página no debe indexarse, incluirla entre las URLs que presentamos al buscador genera una señal innecesariamente contradictoria.
¿Debo incluir URLs que redirigen?
Normalmente no. Lo lógico es actualizar el sitemap para utilizar el destino final cuando este sea la URL canónica e indexable que queremos presentar.
¿Qué significa lastmod?
lastmod indica la fecha de última modificación de una página. Debería representar un cambio significativo y real, no simplemente el momento en el que nuestro sistema ha vuelto a generar el sitemap.
¿Google utiliza lastmod?
Sí. Google indica que puede utilizar lastmod cuando sus valores son coherentes y verificables. Por eso es importante que las fechas reflejen cambios reales.
¿Cada cuánto hay que actualizar un sitemap?
No existe una frecuencia universal. Debe mantenerse sincronizado con los cambios del sitio. Una tienda que añade productos continuamente tendrá necesidades diferentes a una web corporativa que apenas cambia durante meses.
¿Cuántas URLs admite un sitemap?
Un sitemap puede contener un máximo de 50.000 URLs y ocupar hasta 50 MB sin comprimir. Si necesitamos más capacidad, debemos dividirlo en varios archivos.
¿Dónde está el sitemap de una web?
Es habitual encontrarlo en rutas como /sitemap.xml o /sitemap_index.xml, pero esos nombres no son obligatorios. También podemos buscar una declaración Sitemap: dentro de robots.txt.
¿Cómo envío un sitemap a Google?
La forma más habitual es enviarlo desde el informe Sitemaps de Google Search Console. También podemos declarar su URL absoluta dentro del archivo robots.txt.
¿Tener un sitemap mejora el posicionamiento SEO?
No directamente. Tener un sitemap no concede mejores posiciones por sí mismo. Su utilidad está principalmente relacionada con el descubrimiento, rastreo y comunicación de información sobre nuestras URLs.
Conclusión
Un buen sitemap XML no es el que consigue meter más URLs dentro. Es el que representa de forma fiable las URLs que realmente queremos presentar a los buscadores.
Sitemap, canonicalización, indexabilidad, códigos HTTP y lastmod deberían contar la misma historia. Cuanto mayor es una web, más importante resulta mantener esa coherencia.
Así que la próxima vez que audites una web, no te limites a comprobar que existe sitemap.xml. Ábrelo. Mira qué contiene. Comprueba esas URLs y compáralas con lo que realmente ocurre cuando las rastreas.
Porque encontrar el sitemap es fácil. Lo interesante es descubrir si podemos confiar en él.