Idiomas

Sitemaps XML para ecommerce

Los consejos genéricos sobre sitemaps se rompen a escala de catálogo. Así se segmenta un sitemap de ecommerce por tipo, se respetan los límites de 50 000 URL/50 MB con un índice de sitemaps, se decide qué pasa con las URL de productos agotados y descontinuados, se mantiene un lastmod honesto mientras el inventario rota a diario y se combinan los sitemaps con IndexNow, además de por qué dividir por categoría sirve para hacer seguimiento y no para el presupuesto de rastreo.

Publicado por primera vez: 3 jul 2026 · Última actualización: 8 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2
1 señal de evidencia en esta página

Un sitemap XML de ecommerce enumera las URL principales que una tienda quiere que se rastreen, divididas por tipo de contenido (productos, categorías, marcas, páginas estáticas) bajo un único índice de sitemaps. Los límites estrictos en torno a los que se diseña: 50 000 URL / 50 MB por archivo y hasta 50 000 archivos por índice. La segmentación sirve para hacer seguimiento en Search Console y en Bing Webmaster Tools, no es una palanca de presupuesto de rastreo ni de posicionamiento (Mueller). Incluya solo URL principales, indexables y con código de estado 200; mantenga lastmod fiel al último cambio significativo e ignore priority/changefreq (Google ignora ambos). El elemento diferenciador que la mayoría de las guías se salta son los productos agotados y descontinuados: gestiónelos con un árbol de decisión documentado (permanente vs. temporal vs. desconocido) y sincronice la eliminación del sitemap con la limpieza de enlaces internos, en lugar de aplicar errores de estado masivos. Automatice la generación para que el archivo nunca se quede obsoleto y combine lastmod con IndexNow para los cambios rápidos de precio y stock.

TL;DR — Segmente el sitemap de un ecommerce por tipo (productos / categorías / marcas / páginas estáticas) bajo un único índice de sitemaps, y sepa por qué: es una herramienta de seguimiento para Search Console y Bing Webmaster Tools, no una palanca de presupuesto de rastreo ni de posicionamiento (Mueller). Los límites en torno a los que se diseña: 50 000 URL / 50 MB por archivo, hasta 50 000 archivos por índice y, como techo empresarial, GSC acepta hasta 500 sitemaps y Bing afirma que su modelo de índice escala a miles de millones de URL. Incluya solo URL canónicas, indexables y con código de estado 200; excluya facetas, parámetros de seguimiento, variantes sin contenido propio, redirecciones, 4xx y noindex. lastmod es el único atributo que usan ambos motores: manténgalo fiel al último cambio significativo; ignore priority y changefreq (Google ignora explícitamente ambos). Automatice la generación para que el archivo nunca se quede obsoleto y combine lastmod con IndexNow para los cambios rápidos de precio o stock. El elemento diferenciador que la mayoría de las guías se salta: los productos agotados y descontinuados necesitan un árbol de decisión documentado (permanente vs. temporal vs. desconocido), con la eliminación del sitemap sincronizada con la limpieza de enlaces internos, no 404 masivos.

Todos los artículos de «cómo crear un sitemap» cubren lo mismo: el límite de 50 000 URL, la división en un índice, la exclusión de URL basura y mantener lastmod exacto. Todo eso es cierto, y nada de eso es donde una tienda de ecommerce se atasca de verdad. Los problemas a escala de tienda son operativos: un catálogo que rota a diario, miles de SKU agotados y descontinuados, variantes de talla y color casi duplicadas, y una automatización que deja de ejecutarse en silencio. Este artículo da por supuesto que ya tiene un sitemap y que necesita resolver esos problemas.

La razón por la que los sitemaps resultan más rentables a medida que crece una tienda es sencilla. Google: “Generally, on large sites it’s more difficult to make sure that every page is linked by at least one other page on the site.” (traducción) «En general, en los sitios grandes es más difícil asegurarse de que cada página esté enlazada por al menos otra página del sitio». Un sitemap es la forma de asegurarse de que un producto con pocos enlaces internos se descubra igualmente. John Mueller ha llamado a los sitemaps XML “a minimal baseline for any serious website.” (traducción) «una base mínima para cualquier sitio web serio». La frase de Mueller sobre la «base mínima» se transmite a través de la cobertura de Search Engine Roundtable de una respuesta en X/Twitter; trátela como información referida, no como una cita primaria obtenida de primera mano.

Los límites estrictos en torno a los que diseña

El protocolo de sitemaps limita el tamaño de un solo archivo y ofrece un índice de sitemaps para superarlo:

  • Por archivo: Google — “All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs. If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps.” (traducción) «Todos los formatos limitan un sitemap individual a 50 MB (sin comprimir) o 50 000 URL. Si su archivo es más grande o tiene más URL, debe dividir el sitemap en varios sitemaps». Evidence for this claim Each Google sitemap file is limited to 50,000 URLs or 50 MB uncompressed. Scope: Protocol and Search Console submission limits are separate constraints. Confidence: high · Verified: Google: Large sitemaps
  • Índice de sitemaps: “A sitemap index file may have up to 50,000 loc tags” (traducción) «Un archivo de índice de sitemaps puede tener hasta 50 000 etiquetas loc»; es decir, puede referenciar hasta 50 000 sitemaps secundarios. Puede “submit up to 500 sitemap index files for each site in your Search Console account.” (traducción) «enviar hasta 500 archivos de índice de sitemaps por cada sitio de su cuenta de Search Console».
  • El techo declarado por Bing es aún más generoso: hasta 50 000 URL por archivo y 50 000 archivos secundarios por índice, de modo que “a single sitemap index file can reference up to 2.5 billion URLs. At scale, multiple index files can support up to 2.5 trillion URLs across a domain, making this approach ideal for large, complex sites.” (traducción) «un solo archivo de índice de sitemaps puede referenciar hasta 2500 millones de URL. A escala, varios archivos de índice pueden admitir hasta 2,5 billones de URL en un dominio, lo que hace que este enfoque sea ideal para sitios grandes y complejos».

Para casi cualquier tienda, la conclusión práctica es: 50 000 URL por archivo, división por tipo, un índice. Las cifras de miles de millones y de billones solo importan si está diseñando para decenas de millones de SKU, pero le indican que el protocolo no va a ser su cuello de botella.

Estrategia de segmentación: para qué sirve realmente

Divida el catálogo en archivos de sitemap lógicos —productos, categorías/colecciones, marcas, páginas estáticas o del CMS— referenciados por un único índice. Esta es la parte en la que la mayoría de las guías se equivoca: dan a entender que dividir el sitemap por tipo mejora el presupuesto de rastreo o consigue que se indexen más páginas. No lo hace. Mueller es explícito en que se trata de una decisión de diagnóstico, no de una palanca de rastreo:

  • “The size & number of sitemap files generally won’t affect the crawling, unless your server is so bogged down that even fetching a handful of sitemap files would slow it down…” (traducción) «El tamaño y el número de archivos de sitemap por lo general no afectan al rastreo, a menos que su servidor esté tan sobrecargado que incluso obtener un puñado de archivos de sitemap lo ralentizara…»
  • “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually…” (traducción) «En general recomiendo dividir un archivo de sitemap en partes lógicas de su sitio para que pueda hacer seguimiento de esas partes de forma individual…» Ambas citas se transmiten a través del informe de Search Engine Journal sobre un AMA en Reddit; el punto operativo es el de dividir para hacer seguimiento.

Así que la ventaja de tener un sitemap de productos separado del de categorías es que el Sitemaps report (Informe “Sitemaps”) de GSC y Bing Webmaster Tools le muestran la proporción entre URL enviadas e indexadas por segmento. Cuando «páginas de producto» marca un 40 % indexado y «páginas de categoría» un 95 %, sabe exactamente dónde mirar. La segmentación saca a la luz el problema; no lo arregla, y no le consigue presupuesto de rastreo.

Qué debe estar en el sitemap y qué no

La regla de Google es todo el filtro: “Include the URLs in your sitemap that you want to see in Google’s search results. Google generally shows the canonical URLs in its search results, which you can influence with sitemaps.” (traducción) «Incluya en su sitemap las URL que quiera ver en los resultados de búsqueda de Google. Google suele mostrar las URL de referencia en sus resultados de búsqueda, y puede influir en ello con los sitemaps». Por lo tanto, una URL de un sitemap debe ser una URL de referencia, indexable y devolver un código de estado 200. Evidence for this claim Google recommends listing the canonical URLs that a site wants shown in Search. Scope: Sitemap inclusion is a canonicalization hint and does not override noindex or response status. Confidence: high · Verified: Google: Build and submit a sitemap

Incluya: páginas de producto de referencia (PDP), páginas de categoría o colección que quiera posicionar, páginas de marca y páginas estáticas indexables.

Excluya:

  • URL con facetas, filtros u ordenación: ?sort=, ?color=, combinaciones de filtros. Estas corresponden a su estrategia de facetas (bloquear o canonicalizar), no al sitemap. La guía de sitemaps de Joshua Hardwick en Ahrefs señala la versión específica de ecommerce de este problema: es “worth checking for duplicate and near-duplicate pages on ecommerce sites as these often slip through the net.” (traducción) «vale la pena buscar páginas duplicadas y casi duplicadas en sitios de ecommerce, ya que a menudo se escapan de la red».
  • Identificadores de sesión y parámetros de seguimiento.
  • Redirecciones (3xx) y errores (4xx / 410): un sitemap de URL redirigidas es un sitemap de URL que le está diciendo a Google que no muestre.
  • Páginas con noindex: contradecirse (enviar + noindex) solo desperdicia rastreos.
  • Variantes casi duplicadas y sin contenido propio. Una URL separada de talla o color sin contenido único no debería ser una entrada de sitemap aparte: incluya la URL principal del producto. Los datos estructurados de variantes de producto de Google de 2024 (ProductGroup / hasVariant / variesBy) son la forma moderna de expresar que un conjunto de opciones de talla y color es un único producto con variantes, en lugar de N páginas casi duplicadas; deje que eso, y no el sitemap, transmita la relación entre variantes.

Las imágenes de producto van en la entrada de la página propietaria, no en una lista aparte. No construya un sitemap independiente de URL de imágenes: añada un bloque <image:image> a la propia entrada <url> de la URL principal del producto usando la extensión de sitemaps de imágenes. Google: “Each <url> tag can contain up to 1,000 <image:image> tags” (traducción) «Cada etiqueta <url> puede contener hasta 1000 etiquetas <image:image>», de sobra para la galería de una PDP. Evidence for this claim Product images can be added to an existing product URL entry with the image sitemap extension instead of a separate image sitemap. Scope: Each <url> entry can carry up to 1,000 <image:image> tags, and the images still have to be crawlable (not blocked by robots.txt) and, if served from another domain, verified in Search Console. Confidence: high · Verified: Google: Image sitemaps Dos requisitos de rastreabilidad fáciles de pasar por alto a escala de catálogo: no bloquee las rutas de las imágenes en robots.txt y, si las imágenes de producto se sirven desde un dominio o una CDN distintos, verifique ese host en Search Console o las imágenes no se recogerán. Qué imagen de qué variante recibe la entrada sigue la misma decisión de arquitectura de referencia que la propia URL: adjunte las imágenes a la entrada de referencia del producto, no a cada URL de variante sin contenido propio que ya ha excluido más arriba.

El árbol de decisión para productos agotados y descontinuados

Aquí es donde un artículo sobre sitemaps de ecommerce puede diferenciarse de verdad, porque casi ninguno lo aborda con matices, y es exactamente la decisión que determina si una URL debe estar en el sitemap. He escrito el marco completo en el blog de Ahrefs (Cómo gestionar los productos agotados: depende), y hay una razón para que se llame «depende». No existe una solución perfecta: el trabajo consiste en establecer reglas coherentes alineadas con los objetivos de su negocio, no en memorizar una única respuesta.

La decisión se divide en dos ejes: ¿desapareció de forma permanente o temporal y la página conserva valor (tráfico, reseñas, información útil)?

  • Agotado temporalmente, con vuelta confirmada → mantenga la página activa y en el sitemap. Ofrezca una estimación de reposición, una lista de espera, un aviso de disponibilidad. No la meta y la saque del sitemap con cada cambio de stock: eso es ruido.
  • Agotado temporalmente, estado desconocido → bájela de prioridad en la interfaz y en el enlazado interno (reordénela, muéstrela más abajo) en lugar de retirarla del sitemap de inmediato. Retirarla antes de tiempo corre el riesgo de que Google trate la página como abandonada y de perder posiciones difíciles de recuperar.
  • Desaparecido de forma permanente, existe un buen reemplazo → redirección 301 a un producto similar para preservar la autoridad de los enlaces, y quítelo del sitemap.
  • Desaparecido de forma permanente, sin reemplazo, pero la página sigue generando tráfico o tiene contenido útil (reseñas, una guía de compra) → puede seguir activa y en el sitemap.
  • Desaparecido de forma permanente, sin valor → elimínelo y devuelva 404/410, y quítelo del sitemap.

Un punto operativo crítico: la eliminación es una limpieza coordinada, no una única edición del sitemap. Como lo expresé en ese artículo, “when redirecting a page, many systems will automatically remove internal links from categories, facets, sitemaps, and internal search pages” (traducción) «al redirigir una página, muchos sistemas eliminarán automáticamente los enlaces internos de las categorías, las facetas, los sitemaps y las páginas de búsqueda interna», así que retire la URL del sitemap y limpie los enlaces internos que apuntan a ella (módulos de categoría, widgets de productos relacionados, búsqueda interna) en el mismo flujo de trabajo. Una URL muerta que ya no está en el sitemap pero sigue enlazada desde veinte páginas de categoría no se ha limpiado de verdad.

Y lo que advierte la propia guía de Google: no aplique de forma reflexiva un 404 masivo a cada producto descontinuado. Google prefiere mantener la URL activa con alternativas, o redirigirla a una categoría relevante, antes que 404 generalizados, y advierte contra la generación de grandes cantidades de Soft 404. Un muro de páginas de producto que acaban de pasar a 404 es exactamente el patrón que provoca eso.

Frecuencia de actualización, lastmod y automatización

Automatice la generación. Esto no es negociable en un catálogo que cambia a diario. Mi consejo habitual para sitios empresariales es: “Add sitemaps. I would make sure this is automated. If you are asked to manually create them, you can do it, but just know that if it’s manual these will rarely be kept up-to-date.” (traducción) «Añada sitemaps. Yo me asegurararía de que esté automatizado. Si le piden crearlos manualmente, puede hacerlo, pero tenga en cuenta que, si es manual, rara vez se mantendrán actualizados». Bing ha documentado el modo de fallo exacto —“Too often, Bing discovers stalled sitemaps which have the same URLs listed for months – sometimes years” (traducción) «Con demasiada frecuencia, Bing descubre sitemaps estancados que tienen las mismas URL listadas durante meses, a veces años»— y recomienda que el sitemap “should ideally be automatically generated at least once a day.” (traducción) «lo ideal es que se genere automáticamente al menos una vez al día».

lastmod es el único atributo que importa. Tanto Google como Bing lo usan de forma activa; nadie usa los demás. Manténgalo fiel a la realidad:

  • Google: “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” (traducción) «Google usa el valor <lastmod> si es exacto de forma coherente y verificable (por ejemplo, comparándolo con la última modificación de la página)». Y debe “reflect the date and time of the last significant update to the page… an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.” (traducción) «reflejar la fecha y la hora de la última actualización significativa de la página… una actualización del contenido principal, de los datos estructurados o de los enlaces de la página se considera generalmente significativa; una actualización de la fecha de copyright, no».
  • Bing es contundente sobre el antipatrón: “Do not set the <lastmod> value set to the time you generate the sitemap. <lastmod> should be the date of the last modification of the content.” (traducción) «No establezca el valor <lastmod> en la hora en que genera el sitemap. <lastmod> debe ser la fecha de la última modificación del contenido». Use ISO 8601 con componente de hora.

Aquí hay una zona gris genuina que merece señalarse: ¿es un cambio de precio o un cambio de estado de stock una actualización «significativa»? Según la definición de Google (contenido principal / datos estructurados / enlaces), un cambio de precio a secas posiblemente no lo sea, pero si modifica sus datos estructurados de Product (availability, price), se acerca más a lo significativo. Mi lectura honesta: no intente ser demasiado listo con esto. No actualice lastmod en cada cambio trivial (eso solo añade ruido) y no confíe solo en lastmod para propagar rápido una bajada de precio sensible al tiempo.

Combine lastmod con IndexNow para los cambios rápidos. Bing plantea ambos como complementarios, no como alternativas excluyentes: “While real-time URL submission protocols such as IndexNow help notify search engines of immediate content changes, sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site.” (traducción) «Aunque los protocolos de envío de URL en tiempo real, como IndexNow, ayudan a notificar a los motores de búsqueda los cambios de contenido inmediatos, los sitemaps siguen siendo una señal fundamental para garantizar una cobertura completa de las URL de su sitio». Y para las superficies impulsadas por IA en concreto: “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn’t changed since the last crawl.” (traducción) «El campo lastmod de su sitemap sigue siendo una señal clave, que ayuda a Bing a priorizar las URL para volver a rastrearlas y reindexarlas, o a omitirlas por completo si el contenido no ha cambiado desde el último rastreo». Así que: el sitemap para la cobertura y la actualidad diaria, e IndexNow (Bing/Yandex/otros, no Google) para empujar cambios individuales de precio o stock sin esperar al siguiente ciclo de rastreo.

Ignore priority y changefreq

No dedique tiempo de ingeniería a mantenerlos. Google es inequívoco: “Google ignores <priority> and <changefreq> values.” (traducción) «Google ignora los valores <priority> y <changefreq>». Según lo publicado, Gary Illyes llamó al campo de prioridad “essentially a bag of noise.” (traducción) «esencialmente un saco de ruido». La frase de Illyes se transmite a través de la cobertura de Search Engine Roundtable de SMX Advanced 2017, no de una fuente primaria obtenida de primera mano; el argumento se mantiene igualmente porque la documentación de Google ya indica que ambos campos se ignoran. El valor que su plataforma rellene automáticamente en estos campos es inofensivo; simplemente no construya lógica para calcularlos.

Seguimiento y diagnóstico

Para esto servía la segmentación:

  • Informe de sitemaps de GSC: URL enviadas frente a indexadas por segmento. Una proporción del sitemap de productos mucho peor que la del sitemap de categorías le apunta directamente a un problema de páginas de producto (contenido escaso, variantes bloqueadas, problemas de canonicalización).
  • Bing Webmaster Tools: la misma vista a nivel de segmento en el lado de Bing, además del estado de los envíos por IndexNow.
  • Informe de indexación de páginas de GSC: vigile los grupos de páginas excluidas por si se disparan las URL de facetas o de parámetros, lo que significa que su estrategia de facetas se está filtrando al descubrimiento.
  • Rastreo o auditoría del sitio (Ahrefs Site Audit, Screaming Frog): detecte productos que siguen mostrando un mensaje de agotado, productos huérfanos que ya no están enlazados desde ningún sitio y los enlaces internos rotos que quedan tras una redirección o una eliminación.

Arquitectura a escala empresarial: un esquema desarrollado

Para un catálogo de millones de SKU, planifique la jerarquía en torno a su volumen real y a los techos de envío, en lugar de ir añadiendo archivos de forma reactiva:

/sitemap-index.xml            ← the one index you submit to GSC + BWT
  ├── /sitemaps/products-1.xml      (URLs 1–50,000)
  ├── /sitemaps/products-2.xml      (50,001–100,000)
  ├── … products-N.xml              (chunk every 50,000 canonical PDPs)
  ├── /sitemaps/categories.xml      (all category / collection pages)
  ├── /sitemaps/brands.xml          (all brand pages)
  └── /sitemaps/static.xml          (homepage, guides, policy pages)

Con 5 millones de productos eso son ~100 archivos de sitemap de productos más unos pocos más: muy por debajo del límite de 50 000 archivos por índice y de los 500 sitemaps que acepta GSC. Si de algún modo supera un solo índice (50 000 × 50 000 = 2500 millones de URL), se divide en varios archivos de índice y se envía cada uno. La idea es dimensionar los bloques desde el principio para que la regeneración diaria solo reescriba el contenido de cada archivo, y nunca tenga que rediseñar el árbol porque se le quedó pequeña una estimación.

Dónde encaja esto

Los sitemaps de ecommerce se solapan mucho con las páginas que enumeran. Lo que debe estar en el sitemap lo decide su estrategia de páginas de categoría y de navegación por facetas (qué URL filtradas son canónicas e indexables). Lo que le pasa a una URL cuando un producto se agota es la decisión sobre productos agotados y descontinuados. Y el sitemap es una de las varias formas en que los rastreadores descubren una tienda, junto con los enlaces internos, IndexNow y (para Google Shopping) un feed de productos de Merchant Center. El sitemap no sustituye a ninguna de ellas; es la red de seguridad de cobertura que asegura que nada quede aislado.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.