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
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 sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. by type (products / categories / brands / static) under one sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and know why: it’s a monitoring tool for Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. and Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility., 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, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., 4xx, and noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed.. 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 IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. for fast price/stock changes. The differentiator most guides skip: out-of-stock and discontinued productsA discontinued product is an item you'll never sell again — the manufacturer stopped making it, or you dropped the line. The SEO decision is end-of-life: 301-redirect the URL to a genuinely similar replacement or the closest relevant category if it earned links or traffic, 404/410 it if it didn't, or keep it live as a Discontinued tombstone page only when it still helps users. This is distinct from a temporary out-of-stock product, which you keep live at 200. 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-duplicateThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling. 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 indexA sitemap index is a sitemap of sitemaps — a single file that lists your other sitemap files instead of listing URLs directly. It's how large sites stay under the 50,000-URL / 50MB-per-sitemap limit while submitting just one file. 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 fileA sitemap index is a sitemap of sitemaps — a single file that lists your other sitemap files instead of listing URLs directly. It's how large sites stay under the 50,000-URL / 50MB-per-sitemap limit while submitting just one 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 ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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.

TIP

Check the generated file against XML syntax and sitemap protocol limits with the XML Sitemap Validator Free

  1. Paste the XML, upload the file, or fetch the deployed sitemap URL.
  2. Split files that exceed 50,000 URLs or 50 MB uncompressed and list the parts in an index.
  3. Validate the deployed index and each child sitemap before submitting them to search engines.
A sitemap over the protocol limit must be split into smaller URL sitemaps and referenced from a sitemap index.

The completed XML Sitemap Validator result reports that the sitemap contains more than 50,000 URLs and recommends splitting it into files with no more than 50,000 entries, then listing the parts in a sitemap index.

Segmentation strategy — and what it’s actually for

Split the catalog into logical sitemap files — products, categories/collections, brands, static/CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. pages — referenced by a single index. Here’s the part most guides get wrong: they imply that splitting the sitemap by type improves crawl budgetThe number of URLs an engine will crawl in a timeframe. 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., 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 reportThe Google Search Console report where you submit sitemaps and watch how Google processes them — type, last read date, status, and how many URLs were discovered. It confirms Google read your list; it doesn't prove anything got indexed. and Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. 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 + noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed.) 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. (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 sitemapAn image sitemap is a sitemap (or an extension added to an existing sitemap) that lists the images on your pages using Google's image namespace, helping Google discover images it might otherwise miss. 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 crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. 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 linkingLinks between pages on the same site. (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 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. 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 linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. 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 404sA soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing.. 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 IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. 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 contentThin content is web content that provides little or no value to users. Google's spam policies name it 'thin content with little or no added value' — and it's about value per page, not word count., blocked variants, canonical issues).
  • Bing Webmaster Tools — the same segment-level view on Bing’s side, plus IndexNow submission status.
  • GSC Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. — 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.
TIP Diagnose the submitted-versus-indexed gap

Once the sitemap itself is valid, compare the submitted inventory with observable indexability signals using my free Indexation Reconciler Free

  1. Load a sitemap segment or URL set and reconcile it against the available indexability evidence.
  2. Group missing or excluded products by status, canonical, noindex, and other observable blockers.
  3. Prioritize the repeated causes, then confirm Google-specific indexing decisions in Search Console.

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 crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 a quote first.