Languages

Ecommerce XML Sitemaps

Generic sitemap advice breaks down at catalog scale. This is how to segment an ecommerce sitemap by type, stay under the 50,000-URL/50MB limits with a sitemap index, decide what happens to out-of-stock and discontinued product URLs, keep lastmod honest as inventory turns over daily, and pair sitemaps with IndexNow — plus why splitting by category is for monitoring, not crawl budget.

First published: Jul 3, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #3 in Architecture & Crawl Control#24 in Ecommerce SEO#325 on the site
AIAuthored byAI v2
1 evidence signal on this page

An ecommerce XML sitemap lists the canonical URLs a store wants crawled, split by content type (products, categories, brands, static pages) under one sitemap index. The hard limits you design around: 50,000 URLs / 50MB per file, up to 50,000 files per index. Segmentation is for monitoring in Search Console and Bing Webmaster Tools — not a crawl-budget or ranking lever (Mueller). Only include canonical, indexable, 200-status URLs; keep lastmod honest to the last significant change and ignore priority/changefreq (Google ignores both). The differentiator most guides skip is out-of-stock and discontinued products: handle them with a documented decision tree (permanent vs. temporary vs. unknown) and sync sitemap removal with internal-link cleanup, not blanket 404s. Automate generation so the file never goes stale, and pair lastmod with IndexNow for fast price/stock changes.

TL;DR — Segment an ecommerce sitemap by type (products / categories / brands / static) under one sitemap index, and know why: it’s a monitoring tool for Search Console and Bing Webmaster Tools, not a crawl-budget or ranking lever (Mueller). The limits you design around: 50,000 URLs / 50MB per file, up to 50,000 files per index, and — for the enterprise ceiling — GSC accepts up to 500 sitemaps and Bing states its index model scales to billions of URLs. Only include canonical, indexable, 200-status URLs; exclude facets, tracking params, thin variants, redirects, 4xx, and noindex. lastmod is the only attribute both engines use — keep it honest to the last significant change; ignore priority and changefreq (Google explicitly ignores both). Automate generation so the file never goes stale, and pair lastmod with IndexNow for fast price/stock changes. The differentiator most guides skip: out-of-stock and discontinued products need a documented decision tree (permanent vs. temporary vs. unknown), with sitemap removal synced to internal-link cleanup — not blanket 404s.

Why generic sitemap advice breaks at catalog scale

Every “how to make a sitemap” article covers the same things: the 50,000-URL limit, splitting into an index, excluding junk URLs, keeping lastmod accurate. That’s all true, and none of it is where an ecommerce store actually struggles. The store-scale problems are operational: a catalog that turns over daily, out-of-stock and discontinued SKUs by the thousand, near-duplicate size/color variants, and automation that quietly stops running. This piece assumes you already have a sitemap and need to handle those.

The reason sitemaps earn their keep more as a store grows is straightforward. 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.” A sitemap is how you make sure a product that’s under-linked internally still gets discovered. John Mueller has called XML sitemaps “a minimal baseline for any serious website.” The Mueller “minimal baseline” line is relayed via Search Engine Roundtable’s coverage of an X/Twitter reply; treat it as reported, not a self-fetched primary quote.

The hard limits you’re designing around

The sitemap protocol caps a single file and gives you a sitemap index to get past it:

  • Per file: 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.” 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
  • Sitemap index: “A sitemap index file may have up to 50,000 loc tags” — i.e. it can reference up to 50,000 child sitemaps. You can “submit up to 500 sitemap index files for each site in your Search Console account.”
  • Bing’s stated ceiling is more generous still: up to 50,000 URLs per file and 50,000 child files per index, so “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.”

For nearly every store, the practical takeaway is: 50,000 URLs per file, split by type, one index. The billions/trillions figures only matter if you’re architecting for tens of millions of SKUs — but they tell you the protocol will not be your bottleneck.

Segmentation strategy — and what it’s actually for

Split the catalog into logical sitemap files — products, categories/collections, brands, static/CMS pages — referenced by a single index. Here’s the part most guides get wrong: they imply that splitting the sitemap by type improves crawl budget or gets more pages indexed. It doesn’t. Mueller is explicit that this is a diagnostic choice, not a crawl lever:

  • “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…”
  • “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually…” Both relayed via Search Engine Journal’s report of a Reddit AMA; the split-for- monitoring point is the operative one.

So the payoff of a products sitemap separate from a categories sitemap is that GSC’s Sitemaps report and Bing Webmaster Tools show you a submitted-vs-indexed ratio per segment. When “product pages” shows 40% indexed but “category pages” shows 95%, you know exactly where to look. Segmentation surfaces the problem; it doesn’t fix it, and it doesn’t buy you crawl budget.

What belongs in the sitemap — and what doesn’t

Google’s rule is the whole filter: “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.” So a sitemap URL should be canonical, indexable, and return a 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

Include: canonical product pages (PDPs), category/collection pages you want ranked, brand pages, indexable static pages.

Exclude:

  • Faceted / filtered / sorted URLs — ?sort=, ?color=, filter combinations. These belong in your facet strategy (block or canonical), not the sitemap. Joshua Hardwick’s Ahrefs sitemap guide flags the ecommerce-specific version of this: it’s “worth checking for duplicate and near-duplicate pages on ecommerce sites as these often slip through the net.”
  • Session IDs and tracking parameters.
  • Redirects (3xx) and errors (4xx / 410) — a sitemap of redirect URLs is a sitemap of URLs you’re telling Google not to show.
  • noindex pages — contradicting yourself (submit + noindex) just wastes crawls.
  • Thin near-duplicate variants. A separate size/color URL with no unique content shouldn’t be a separate sitemap entry — list the canonical product URL. Google’s 2024 product-variants structured data (ProductGroup / hasVariant / variesBy) is the modern way to express that a set of size/color options is one product with variants rather than N near-duplicate pages; let that, not the sitemap, carry the variant relationship.

Product images ride on the owning page entry, not a separate list. Don’t build a standalone sitemap of image URLs — add an <image:image> block to the canonical product URL’s own <url> entry using the image sitemap extension. Google: “Each <url> tag can contain up to 1,000 <image:image> tags” — plenty for a PDP’s gallery. 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 Two crawlability requirements that are easy to miss at catalog scale: don’t disallow the image paths in robots.txt, and if product images are served from a separate domain or CDN, verify that host in Search Console or the images won’t be picked up. Which variant’s image gets the entry follows the same canonical-architecture call as the URL itself — attach images to the canonical product entry, not to every thin variant URL you’ve already excluded above.

The out-of-stock and discontinued product decision tree

This is where an ecommerce sitemap article can actually differentiate, because almost none of them handle it with any nuance — and it’s the exact decision that determines whether a URL belongs in the sitemap. I’ve written the full framework on the Ahrefs blog (How Should You Handle Out-of-Stock Products? It Depends), and there’s a reason it’s called “it depends.” There’s no perfect solution — the job is to establish consistent rules aligned with your business goals, not to memorize one answer.

The decision splits on two axes: is it gone permanently or temporarily, and does the page still have value (traffic, reviews, useful info)?

  • Temporarily out, confirmed returning → keep the page live and in the sitemap. Offer a restock estimate, a waitlist, a notify-me. Don’t churn it in and out of the sitemap on every stock toggle — that’s noise.
  • Temporarily out, status unknown → deprioritize it in the UI and internal linking (reorder, filter it down) rather than pulling it from the sitemap immediately. Premature removal risks Google treating the page as abandoned and losing rankings that are hard to win back.
  • Permanently gone, good replacement exists → 301 redirect to a similar product to preserve link equity, and remove it from the sitemap.
  • Permanently gone, no replacement, but the page still earns traffic or has useful content (reviews, a buying guide) → it can stay live and in the sitemap.
  • Permanently gone, no value → delete and return 404/410, and remove it from the sitemap.

A critical operational point: removal is a coordinated cleanup, not a single sitemap edit. As I put it in that article, “when redirecting a page, many systems will automatically remove internal links from categories, facets, sitemaps, and internal search pages” — so pull the URL from the sitemap and clean up the internal links that point at it (category modules, related-product widgets, internal search) in the same workflow. A dead URL that’s gone from the sitemap but still linked from twenty category pages hasn’t really been cleaned up.

And the thing Google’s own guidance warns against: don’t reflexively mass-404 every discontinued product. Google favors keeping the URL live with alternatives, or redirecting to a relevant category, over blanket 404s — and it warns against generating large numbers of soft 404s. A wall of newly-404’d product pages is exactly the pattern that triggers that.

Update frequency, lastmod, and automation

Automate generation. This is non-negotiable on a catalog that changes daily. My standing advice on enterprise sites is: “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.” Bing has documented the exact failure mode — “Too often, Bing discovers stalled sitemaps which have the same URLs listed for months – sometimes years” — and recommends the sitemap “should ideally be automatically generated at least once a day.”

lastmod is the one attribute that matters. Both Google and Bing actively use it; nobody uses the others. Keep it honest:

  • Google: “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” And it should “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.”
  • Bing is blunt about the anti-pattern: “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.” Use ISO 8601 with a time component.

Here’s a genuine gray area worth flagging: is a price change or a stock-status flip a “significant” update? By Google’s definition (main content / structured data / links), a bare price change is arguably not — but if it changes your Product structured data (availability, price), that’s closer to significant. My honest read: don’t try to be clever about it. Don’t bump lastmod on every trivial toggle (that just adds noise), and don’t rely on lastmod alone to propagate a time-sensitive price drop fast.

Pair lastmod with IndexNow for fast-moving changes. Bing frames the two as complementary, not either/or: “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.” And for AI-powered surfaces specifically: “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.” So: sitemap for coverage and daily freshness, IndexNow (Bing/Yandex/others — not Google) to push individual price/stock flips without waiting for the next recrawl cycle.

Ignore priority and changefreq

Don’t spend engineering time maintaining these. Google is unambiguous: “Google ignores <priority> and <changefreq> values.” Gary Illyes reportedly called the priority field “essentially a bag of noise.” The Illyes line is relayed via Search Engine Roundtable’s SMX Advanced 2017 coverage, not a self-fetched primary source; the point stands regardless because Google’s docs now say both fields are ignored. Whatever value your platform auto-populates for these is harmless; just don’t build logic to compute them.

Monitoring and diagnosis

This is what the segmentation was for:

  • GSC Sitemaps report — per-segment submitted-vs-indexed. A product-sitemap ratio that’s much worse than your category sitemap points you straight at a product-page problem (thin content, blocked variants, canonical issues).
  • Bing Webmaster Tools — the same segment-level view on Bing’s side, plus IndexNow submission status.
  • GSC Page Indexing report — watch the excluded buckets for facet/parameter URLs ballooning, which means your facet strategy is leaking into discovery.
  • Site crawl / audit (Ahrefs Site Audit, Screaming Frog) — catch products still showing an out-of-stock message, orphaned products no longer linked from anywhere, and the broken internal links left behind after a redirect or removal.

Enterprise-scale architecture — a worked shape

For a catalog in the millions of SKUs, plan the hierarchy around your actual volume and the submission ceilings rather than bolting on files reactively:

/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)

At 5M products that’s ~100 product sitemap files plus a handful of others — well within the 50,000-files-per-index limit and GSC’s 500-sitemap acceptance. If you somehow exceed a single index (50,000 × 50,000 = 2.5B URLs), you split into multiple index files and submit each. The point is to size the chunks up front so daily regeneration just rewrites each file’s contents, and you never have to re-architect the tree because you outgrew a guess.

Where this sits

Ecommerce sitemaps overlap heavily with the pages they list. What belongs in the sitemap is decided by your category-page and faceted-navigation strategy (which filtered URLs are canonical and indexable). What happens to a URL when a product sells out is the out-of-stock and discontinued-product decision. And the sitemap is one of several ways crawlers discover a store — alongside internal links, IndexNow, and (for Google Shopping) a Merchant Center product feed. The sitemap doesn’t replace any of those; it’s the coverage backstop that makes sure nothing gets stranded.

Add an expert note

Pin an expert quote

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