Validador de sitemap gratuito

¿Qué es un sitemap.xml y por qué es importante?

Un sitemap es un documento XML estructurado que enumera las URLs de un sitio web que quieres que los motores de búsqueda conozcan. Se sirve desde una ruta estable, casi siempre /sitemap.xml, y sigue el Protocolo Sitemap — una pequeña especificación publicada originalmente por Google en 2005 y adoptada como estándar conjunto por Google, Yahoo y Microsoft un año después. El formato es sencillo: un elemento raíz <urlset> que contiene un elemento <url> por página, con metadatos opcionales sobre cuándo se modificó por última vez cada URL, con qué frecuencia cambia y cómo se relaciona en prioridad con otras del mismo sitio.

El objetivo del sitemap es el descubrimiento, no el posicionamiento. Los motores de búsqueda rastrean la web siguiendo enlaces de página en página. En un sitio pequeño con enlaces internos limpios, todas las páginas son accesibles desde la página de inicio en pocos clics, y los rastreadores encuentran todo sin ayuda. En un sitio grande, en uno con paginación profunda, en uno con páginas de destino aisladas a las que ningún enlace interno apunta, o en uno que acaba de publicar contenido nuevo, los rastreadores pueden tardar días o semanas en descubrir las URLs mediante enlaces. El sitemap resuelve esto entregando al rastreador una lista completa de antemano.

Los sitemaps no garantizan la indexación. Google ha declarado esto explícitamente en su documentación desde el lanzamiento del protocolo: una URL en tu sitemap es una señal de que quieres que se indexe, no una orden de que lo será. Las páginas de baja calidad, con contenido duplicado o con información escasa serán ignoradas independientemente de si aparecen en el sitemap. Lo que el sitemap sí cambia es la eficiencia del rastreo. Con un sitemap, Google puede rastrear primero tus páginas nuevas y actualizadas, priorizarlas en función del campo lastmod y evitar desperdiciar solicitudes en URLs obsoletas o archivadas.

Los sitemaps también importan para el long tail. Un sitio con 100.000 páginas de producto, 5.000 artículos de blog y 200 páginas de categorías tiene demasiado contenido para que cualquier patrón de enlaces internos exponga cada URL en pocos clics. Sin un sitemap, el sitio depende del rastreo exploratorio de Googlebot para encontrar las URLs profundas, lo que funciona pero es lento. Con un sitemap, todas las URLs son conocidas por Google de inmediato, y el rastreador puede invertir su presupuesto en comprobaciones de actualidad y calidad del contenido en lugar de en el descubrimiento. Para el comercio electrónico, medios de noticias, marketplaces y sitios con mucho contenido, el sitemap no es opcional.

Cómo usar este verificador

El verificador acepta una URL de sitemap o un dominio raíz y devuelve un informe estructurado sobre validez, completitud y accesibilidad.

Paso 1 — Introduce la URL del sitemap. Pega la URL completa de tu sitemap, o simplemente el dominio — el verificador realizará el autodescubrimiento a través de robots.txt y probará rutas comunes como /sitemap.xml, /sitemap_index.xml y /sitemap.xml.gz. También sigue automáticamente los archivos sitemap-index y recorre todos los sitemaps hijos que contienen.

Paso 2 — Revisa el informe de validez. El verificador valida el XML contra el esquema del Protocolo Sitemap, marca valores de lastmod mal formados, comprueba URLs que superan el límite de 2048 caracteres en la ruta, y verifica que el archivo esté por debajo de los límites estrictos de 50 MB sin comprimir y 50.000 URLs. Cada problema se muestra con la URL exacta o el número de línea que lo provocó.

Paso 3 — Comprueba la accesibilidad. Para una muestra de URLs del sitemap, el verificador realiza una solicitud HEAD e informa del código de respuesta. Las URLs que devuelven 404, 301, 302 o 5xx en tu sitemap son ruido que desperdicia el presupuesto de rastreo; el informe las muestra agrupadas para que puedas corregirlas o eliminarlas.

El protocolo sitemap en profundidad

Un sitemap mínimo válido 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-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Solo <loc> es obligatorio. Los otros tres campos opcionales son <lastmod>, <changefreq> y <priority>, y la práctica moderna trata cada uno de forma diferente.

Límites estrictos y el patrón sitemap-index

Un único archivo sitemap puede contener como máximo 50.000 URLs y debe pesar menos de 50 MB sin comprimir. Estos límites existen en el protocolo desde su lanzamiento y los aplica cada rastreador principal. Los archivos que superan el límite no se truncan — son rechazados por completo por Googlebot, que luego notifica un error en Search Console. Para un sitio con más URLs de las que caben en un único archivo, el protocolo define un formato sitemap-index que enumera múltiples sitemaps hijos:

<?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-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

El índice puede listar hasta 50.000 sitemaps hijos, cada uno con 50.000 URLs, lo que supone un límite teórico de 2.500 millones de URLs en el sitio. En la práctica, organizar por tipo de contenido — páginas, productos, artículos de blog, etiquetas, categorías — produce una estructura mantenible que también permite regenerar solo el sub-sitemap modificado en cada despliegue. La convención es nombrar el índice sitemap.xml o sitemap_index.xml y los hijos con rutas descriptivas.

Precisión de lastmod y cuándo Google la tiene en cuenta

Google ha declarado repetidamente que usa lastmod cuando el valor es preciso, y lo descarta en todo el sitemap cuando parece poco fiable. Un sitio que siempre informa la fecha de hoy para cada URL está reportando una actualidad que no existe; Google detecta el patrón y deja de tener en cuenta el campo. Lo mismo aplica a los valores de lastmod que nunca se actualizan aunque el contenido cambie — la ausencia de señal es en sí misma una señal.

Usa el formato datetime completo ISO 8601, incluyendo el desplazamiento de zona horaria: 2026-04-27T12:00:00+00:00. La forma solo con fecha 2026-04-27 es válida y aceptada, pero el formato datetime es preferible para sitios de alta frecuencia donde la hora del día importa. Establece lastmod a partir del tiempo de modificación real del contenido de la página, no del tiempo de despliegue de tu aplicación. Las páginas que no han cambiado deben mantener su valor antiguo de lastmod, incluso cuando se regenera el resto del sitemap.

changefreq y priority: prácticamente ignorados

Los campos <changefreq> y <priority> se definieron en el protocolo original para dar a los propietarios de sitios una forma de expresar con qué frecuencia cambia una página (always, hourly, daily, weekly, monthly, yearly, never) y una prioridad relativa dentro del sitio (un decimal entre 0,0 y 1,0). Google moderno ignora ambos. El rastreador decide la frecuencia de rastreo a partir de los patrones de cambio observados y decide la prioridad a partir de la calidad del contenido y la equidad de enlaces, no a partir de las declaraciones del sitemap.

La recomendación práctica es omitir ambos campos. Hacen el sitemap más grande y complejo sin cambiar el comportamiento del rastreador. La documentación de Bing sugiere que aún considera changefreq débilmente, pero el impacto es tan pequeño que mantener valores precisos rara vez justifica el coste de ingeniería. Un sitemap limpio con solo <loc> y <lastmod> es el estándar moderno.

Autodescubrimiento via robots.txt vs envío por Search Console

Hay dos formas de informar a Google sobre un sitemap: declararlo en robots.txt o enviarlo a través de Search Console. Ambas funcionan, ambas se recomiendan, y ambas juntas es la práctica moderna recomendada.

User-agent: *
Disallow: /admin/

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

La declaración en robots.txt es leída por todos los rastreadores bien comportados — Googlebot, Bingbot, DuckDuckBot, Yandex y la mayoría de herramientas SEO — sin necesidad de configuración por plataforma. El envío por Search Console es específico de Google, pero desbloquea los informes de indexación que muestran cuántas URLs del sitemap están indexadas, cuántas están excluidas y por qué. Para un sitio que se toma el SEO en serio, envía a través de Search Console para visibilidad y declara en robots.txt para portabilidad.

Extensiones de sitemap para imágenes, vídeos y noticias

El protocolo base tiene extensiones para contenido de imagen, vídeo y noticias. Los sitemaps de imagen añaden un elemento <image:image> que enumera las imágenes de cada página, lo que ayuda a Google a descubrir imágenes en páginas renderizadas con JavaScript donde las URLs de imagen no están en el HTML inicial. Los sitemaps de vídeo añaden un elemento <video:video> con título, descripción, miniatura y duración, y siguen siendo la forma canónica de presentar vídeo a Google Video. Los sitemaps de noticias usan un elemento <news:news> separado con fecha de publicación y el espacio de nombres requerido, y son obligatorios para aparecer en Google News.

Para un sitio de marketing o contenido típico, un sitemap de URLs básico cubre completamente el caso de uso. Las extensiones valen la complejidad solo cuando la descubribilidad de imágenes, el vídeo o la inclusión en noticias son una fuente de tráfico significativa.

Errores comunes que perjudican el SEO

404s y redirecciones en el sitemap. Listar URLs que devuelven 404 o redirigen a una URL diferente contamina el sitemap con ruido. Google marca estos como errores de sitemap en Search Console y puede descontar el resto del sitemap. Audita el sitemap en cada despliegue y elimina las URLs no-200. Las redirecciones deben reemplazarse por la URL de destino.

Incluir URLs no canónicas. Las páginas con rel="canonical" apuntando a una URL diferente no deben aparecer en el sitemap. El sitemap es una lista de páginas que quieres indexar; las páginas canónicalizadas hacia otra son páginas que has indicado explícitamente a los motores de búsqueda que ignoren. Incluirlas genera señales contradictorias.

lastmod siempre actualizado. Establecer lastmod a la fecha de hoy para cada URL en cada regeneración indica a Google que el campo es poco fiable, y el rastreador deja de tenerlo en cuenta. Establece lastmod a partir del tiempo de modificación real del contenido de la página, no del tiempo de despliegue. Las páginas que no han cambiado deben mantener su lastmod anterior.

Sitemap bloqueado por robots.txt. Una línea Disallow: /sitemap.xml, o un Disallow: /sitemap más amplio que coincida con el archivo, impide que los rastreadores obtengan el sitemap. Prueba siempre con curl o un verificador de sitemap después de modificar robots.txt para confirmar que la URL del sitemap es accesible.

Sub-sitemaps dentro de un sitemap-index que devuelven 404. Un sitemap-index que lista diez sitemaps hijos pero solo nueve de ellos resuelven provoca que el que falta se marque como error. Peor aún, si el patrón de ruta cambia entre despliegues, cada URL antigua de sub-sitemap se convierte en un 404 hasta que se regenera el índice. Genera el índice a partir de la misma fuente de verdad que los hijos para mantenerlos sincronizados.

Mezclar protocolos dentro de un sitemap. Un sitemap servido en https://example.com/sitemap.xml debe contener solo URLs con https://. Las URLs con http:// mezcladas se tratan como un host diferente y el procesador de sitemap del host canónico las ignora. Lo mismo aplica a la inconsistencia entre www y no-www: elige uno y úsalo en todo el sitemap.

Olvidar escapar caracteres especiales en las URLs. XML requiere que &, <, >, " y ' se escapen dentro de los valores de atributos y elementos. Las URLs con ampersands sin escapar rompen el analizador XML, y el sitemap completo falla la validación. Genera las URLs a través de una biblioteca que gestione el escapado en lugar de concatenar cadenas manualmente.

Casos extremos que nadie menciona

Un sitemap.xml servido con el tipo de contenido incorrecto rompe algunos rastreadores. El tipo de contenido correcto es application/xml o text/xml. Algunos servidores devuelven text/plain o text/html para archivos .xml cuando el tipo MIME no está configurado, y Bingbot en particular es conocido por rechazar dichas respuestas. El verificador comprueba el tipo de contenido y lo marca como advertencia cuando no coincide.

Los sitemaps comprimidos servidos como .xml.gz ahorran ancho de banda de forma considerable — los sitemaps se comprimen hasta el 5-10% de su tamaño original gracias a la repetición masiva de prefijos de URL. Tanto Google como Bing aceptan sitemaps comprimidos con gzip sin ninguna configuración adicional, y el límite de tamaño se mide contra el tamaño sin comprimir. El único inconveniente es que algunas plataformas de hosting sirven archivos .gz con la codificación de contenido incorrecta, lo que provoca que el rastreador reciba bytes gzip en bruto que no se pueden analizar. Prueba la versión comprimida en un navegador; si ves caracteres binarios en lugar de XML, falta la cabecera Content-Encoding: gzip en la respuesta.