Part of the SiteMap Series
In the previous lesson, you saw why sitemap setup depends on site type. E-commerce sites are the clearest example of this. The sitemap principles from Modules 1 to 3 (include canonical URLs, accurate lastmod, exclude what should not be indexed) all hold, but the application creates more decisions than any other site type.
Product catalogues with faceted navigation generate URLs by the thousand. Inventory and pricing change constantly. Sales come and go. Categories evolve. Each of these creates a sitemap decision that the spec does not address directly.
This lesson walks through the e-commerce sitemap decisions that consistently come up in real implementations. Which URLs belong in your sitemap and which do not. How to handle out-of-stock products without losing valuable URLs.
How to handle faceted navigation without producing a sitemap bloated with non-canonical filter combinations. How to set lastmod when product content changes for trivial reasons most of the time. How to implement all of this on the major e-commerce platforms.
By the end of the lesson, you will know how to construct an e-commerce sitemap that surfaces your canonical product and category URLs cleanly, avoids the most common sources of URL bloat, signals freshness in a way the engines can trust, and works with the platform you are on.
What makes e-commerce sitemaps different
Three characteristics of e-commerce sites create sitemap complications that simpler sites do not have.
1. URL volume scales fast
A modest e-commerce site with 500 products, 50 categories, and faceted navigation can easily generate 50,000+ URLs once you count every filter combination. Most of these URLs are not canonical landing pages, but some are. Sorting which is which is the first decision.
2. Content changes constantly
Product details, prices, stock levels, customer reviews, and availability all change frequently. Not all changes warrant a freshness signal to the engines, but some do. Distinguishing between meaningful changes (revised product description, new images) and trivial changes (stock count fluctuations, view counts) is the second decision.
3. Categories and collections drift
Categories get reorganised. Products move between categories. Sale collections come and go. Seasonal pages launch and retire. The sitemap needs to reflect the current state of your catalogue without lagging behind every reorganisation.
The rest of this lesson works through how to handle each of these.
Which URLs belong in your e-commerce sitemap
E-commerce sitemaps should include the canonical landing pages where customers can find products and where you want the engines to find them too. Five categories of URL generally qualify.
Product pages. The canonical product URL for each in-stock or recently in-stock product. One URL per product, not one URL per variant. Variants (size, colour, style) typically share a canonical URL and use product schema to communicate variant information.
Category and collection pages. The main category pages (e.g., /category/running-shoes/) and curated collection pages (e.g., /collections/winter-essentials/). These often rank for higher-volume search terms than individual products.
Brand pages. If you carry multiple brands and have dedicated brand pages (e.g., /brands/nike/), these are usually canonical landing pages worth indexing.
Selected faceted navigation pages. Most faceted URLs do not belong in the sitemap (more on this below), but some legitimate filter combinations have standalone search intent and deserve inclusion. “Red trainers” is a search query people type; /category/trainers/colour/red/ might legitimately be a sitemap entry. The rule of thumb: if the filter combination has a real audience searching for it, treat it as a landing page.
Sale and seasonal collection pages. Active sale collections (/sale/, /sale/winter-2026/) and seasonal collections (/collections/christmas-gifts/) belong in the sitemap while they are active. The treatment when they retire is covered later in this lesson.
What to exclude:
- Most faceted URL combinations (covered in detail below)
- Internal search result URLs
- Cart, checkout, and account pages
- Wishlist and comparison pages (unless these have organic search value, which is rare)
- Duplicate variants of the same product
- Test or staging URLs
- URLs that resolve to permanent redirects (the destination should be in the sitemap instead)
How to handle out-of-stock products
Out-of-stock product handling is the most contested decision in e-commerce sitemap strategy. Three approaches exist, each with trade-offs.
Approach 1: Keep the URL in the sitemap with availability schema marking it out of stock. This preserves any authority the URL has built and gives customers a chance to see related products or sign up for restock notifications. The engines see the URL is still canonical content, just temporarily unavailable. This works well for products that will be restocked.
Approach 2: Remove the URL from the sitemap but leave the page live with a noindex or 410 status. This signals that the product is no longer being actively promoted. Use this when a product has been permanently discontinued and there is no equivalent replacement.
Approach 3: 301 redirect the URL to a replacement product or category. This consolidates authority into a still-valid URL. Use this when a product has been replaced by a successor (newer model, equivalent product) and the redirect destination is a reasonable answer to the original search intent.
The right approach depends on three factors:
- Is the product temporarily or permanently out of stock? Temporary calls for Approach 1; permanent calls for 2 or 3.
- Has the URL built ranking authority? A URL ranking well for branded or product-specific queries is worth preserving (Approach 1) rather than discarding.
- Does the page provide value when out of stock? A page with restock notifications, related products, and rich product information serves the user even without inventory. A page that says only “Sorry, out of stock” does not.
Pick one approach, document it, and apply it consistently. Mixed handling across your catalogue confuses the engines and creates inconsistent ranking signals.
How to handle faceted navigation
Faceted navigation is where most e-commerce sitemap mistakes happen. The volume of URLs faceted navigation generates is enormous, and treating all of them as canonical landing pages produces sitemap bloat that hurts indexing rather than helping.
Three rules cover most situations.
Rule 1: Single-facet filters with standalone search intent can be included. “Red trainers”, “size 10 trainers”, “Nike trainers” are real search queries. The corresponding faceted URLs are reasonable landing pages and can be in the sitemap.
Rule 2: Multi-facet combinations almost never belong. “Red trainers, size 10, under £100” is not a search query people type. The URL exists in your faceted navigation, but it is not a canonical landing page. Multi-facet combinations should be excluded from the sitemap and typically blocked from indexing through robots.txt or noindex tags.
Rule 3: Sort orders, view options, and pagination parameters are never canonical. URLs that differ only by sort order (?sort=price-asc), view mode (?view=grid), or pagination beyond page 1 (?page=2) should never appear in the sitemap. These are display variations, not distinct content.
The implementation pattern: configure your e-commerce platform to surface only the promoted faceted URLs to the sitemap, and use robots.txt or meta robots noindex to handle the rest. The exact mechanism depends on the platform, covered in the implementation section below.
How to handle sale and seasonal collections
Sale and seasonal collections create a particular sitemap challenge: they have legitimate canonical URLs while active but become awkward when they retire.
While active, include them in the sitemap normally. A /sale/black-friday-2026/ URL is a real landing page during November 2026, and excluding it would be a missed opportunity.
When the sale ends, three options apply.
Option 1: 301 redirect to the next equivalent. Redirect /sale/black-friday-2026/ to /sale/black-friday-2027/ when that becomes active, or to a general /sale/ page in the meantime. Update the sitemap to reflect the new URL.
Option 2: Keep the URL with updated content. Some sites maintain seasonal URLs year-round with refreshed content (e.g., /collections/christmas-gifts/ updates yearly rather than being replaced). The URL stays in the sitemap permanently; the lastmod gets updated when content refreshes.
Option 3: Allow it to 404 or noindex it. Use this when the URL was tied to a one-off sale that will not recur. Remove it from the sitemap when it goes inactive.
The pattern to avoid is leaving expired sale URLs in the sitemap with content that no longer exists. This sends signals about pages that are no longer canonical, which wastes crawl budget and confuses the engines about your active catalogue.
Setting lastmod for e-commerce content
Lastmod on e-commerce sites is harder than it sounds because content changes constantly, but most changes do not warrant a freshness signal.
Update lastmod for:
- New product descriptions or major description revisions
- New product images
- Significant price changes (a markdown for a sale, not minor adjustments)
- New customer reviews that change the rating or review count visibly
- Category page changes (products added or removed)
- Sale collection updates (new products added to a sale)
Do not update lastmod for:
- Stock level fluctuations (5 units becomes 4 units does not warrant a signal)
- Minor price changes (£19.99 to £19.95 is not a meaningful update)
- View counts, click counts, or other analytics-driven metrics
- Cache regeneration that does not change visible content
- Automated re-indexing of variants
The principle: lastmod should indicate when the engines would benefit from re-crawling the page because something visible has changed. If a customer would not notice the change, the engines probably do not need to be told about it either.
For platforms that automate lastmod updates, check the configuration. Some default to updating lastmod on any database write to the product record, which produces noisy freshness signals. Adjust the trigger conditions where possible.
How to implement on the main platforms
Four platform contexts cover most e-commerce sitemap implementations.
1. Shopify
Shopify generates a sitemap automatically at /sitemap.xml. The sitemap includes product, collection, page, and blog post URLs, organised through a sitemap index that references separate sub-sitemaps for each content type. Customisation options are limited compared to other platforms. You cannot exclude individual products from the auto-generated sitemap without third-party apps, and lastmod follows Shopify’s own update logic, which tends to be on the noisy side.
For Shopify Plus, additional control is available through theme customisation, but the core sitemap structure remains platform-managed. Faceted navigation handling depends on the collections setup and any filter apps installed; Shopify’s native collections produce canonical URLs that are sitemap-eligible.
2. WooCommerce on WordPress
WooCommerce relies on your WordPress SEO plugin for sitemap generation. Yoast SEO with the Yoast WooCommerce SEO add-on, Rank Math, and All in One SEO all generate WooCommerce-aware sitemaps.
Configuration lives in your SEO plugin’s sitemap settings, where you control which post types are included (typically products, product categories, and product tags), how variations are handled, and whether out-of-stock products appear. WooCommerce’s product visibility settings (Catalog/Search/Hidden) integrate with the sitemap output: hidden products are excluded automatically.
For faceted navigation, the SEO plugins generally do not produce faceted URLs in the sitemap by default. Filtered URLs are excluded from indexing unless you specifically enable them, which matches the recommended treatment.
3. Magento and Adobe Commerce
Magento includes built-in sitemap generation under Stores > Configuration > Catalog > XML Sitemap. The configuration covers categories, products, and CMS pages, with options for changefreq, priority, and image inclusion. Magento can split large sitemaps automatically when they exceed the protocol limits.
For faceted navigation, Magento’s layered navigation produces filtered URLs that the platform can be configured to canonicalise or noindex. Implementation usually involves either platform configuration or an SEO extension.
4. Custom and headless commerce
Headless commerce setups (commerce on a custom frontend, often Next.js or similar) require sitemap generation in the build pipeline. The commerce backend (Shopify Storefront API, BigCommerce, Commercetools, custom) exposes product, category, and content data; the frontend build process queries that data and generates sitemap files at build time or through a scheduled job.
Implementation patterns vary. For Next.js sites, next-sitemap with a custom transform that pulls from the commerce API is the common approach. For other static or hybrid frameworks, the equivalent sitemap plugin handles the generation; the work is in the data fetching and transformation.
Common gotchas to avoid
Five issues come up regularly in e-commerce sitemap implementations.
1. Including every faceted URL in the sitemap
The most common e-commerce sitemap mistake. Faceted navigation can generate tens of thousands of URLs that are not canonical landing pages. Including them in the sitemap bloats the file, wastes crawl budget, and sends mixed signals about what your canonical pages are. The fix is to include only the promoted faceted URLs (those with standalone search intent) and exclude the rest.
2. Bumping lastmod on inventory changes
Some platforms update lastmod every time a product’s stock count changes, even by one unit. This produces a freshness signal for changes the engines do not need to know about. Over time, this trains the engines to discount your lastmod signal because it has been noisy. The fix is to configure lastmod to update only on meaningful content changes.
3. Inconsistent out-of-stock handling
Some out-of-stock products stay in the sitemap with availability schema; others get removed; others get 301 redirected. Mixed handling across the catalogue creates confusing ranking signals. The fix is to pick one approach per category of out-of-stock scenario (temporary, permanent, replaced) and apply it consistently.
4. Sale collection URLs lingering after sales end
A /sale/black-friday-2026/ URL that still appears in the sitemap in March 2027 with no content sends the wrong signal. The fix is to either redirect expired sale URLs to current equivalents, update them with refreshed content, or remove them from the sitemap when the sale ends.
5. Cart, checkout, and account pages in the sitemap
Sometimes the platform’s sitemap generator includes user-flow pages that should never be indexed. Cart, checkout, login, account, and wishlist pages do not belong in the sitemap. The fix is to verify your sitemap output and exclude these page types explicitly if the platform includes them by default.
Where this leaves us
You can now make the e-commerce-specific sitemap decisions that the spec does not cover: which URLs to include, how to handle out-of-stock products, where faceted navigation belongs, when to update lastmod, and how to implement on your platform. Applied consistently, these decisions produce an e-commerce sitemap that surfaces your canonical landing pages cleanly without bloating the file or signalling false freshness.
JavaScript-heavy sites come next. They share some friction with e-commerce (dynamic URL generation, content that changes after the initial page load) but the underlying problem is different. On a JavaScript site, the question is not “which of these URLs are canonical” so much as “do the engines see the URLs at all”. Client-side routing, hydration timing, and dynamic route discovery introduce their own decisions, which the next lesson walks through.
Up next: How to Create a Sitemap for a JavaScript Site or Single-Page App →
This is Module 4: Lesson 2 of The Sitemap Series, a Technical SEO series on sitemaps from first principles, built for the AI Search era.