Shopify Sitemap: Fixing the /sitemap.xml Defaults for Better Indexing

Where is Shopify's sitemap?

Every Shopify store - on every plan, from Basic to Plus - serves a sitemap index at yourstore.com/sitemap.xml. You never create it, upload it, or configure it through the admin; it exists the moment your store goes live and updates itself in the background for as long as the store exists. If you run a multi-store setup (separate storefronts for different markets or brands on the same Shopify organisation), each storefront gets its own independent sitemap index at its own domain. There is no shared or combined sitemap across stores, which matters if you're auditing an international rollout and assume one submission covers everything - it doesn't.

What you land on at /sitemap.xml isn't a flat list of URLs. It's a sitemap index file - a small XML document that does nothing but point to other sitemaps. Open it in a browser and you'll see a handful of <sitemap> entries, each with its own <loc> and <lastmod>. Google's crawler fetches the index first, then works through each referenced file in turn. This two-tier structure exists because Shopify stores can have tens of thousands of URLs, and a single flat sitemap file is capped at 50,000 URLs by the sitemap protocol - the index pattern lets Shopify shard large catalogues across multiple product sitemap files automatically once you cross that threshold.

The index nests five distinct sub-sitemap types:

• sitemap_products_1.xml - all published products (shards to _2, _3 etc. past 50,000 URLs)
• sitemap_collections_1.xml - all published collections
• sitemap_pages_1.xml - all published pages (About, Contact, custom pages)
• sitemap_blogs_1.xml - all blog articles across every blog handle on the store
• sitemap_general.xml - the homepage and a small number of generic system entries

Multi-language stores using Shopify Markets expose alternate-language URLs via hreflang annotations inside the same product and collection sitemaps, rather than generating separate sitemap files per language - one more reason a blanket "resubmit the sitemap" fix doesn't always solve international indexing problems on its own.

How Shopify auto-generates the sitemap (line-by-line)

The sitemap isn't rebuilt on a fixed schedule - it's rebuilt in response to events. Publishing a new product, collection, page or blog article triggers a rebuild of the relevant sub-sitemap, typically reflected within about an hour. The same is true in reverse: unpublishing an item, changing its handle (URL slug), or toggling its channel visibility off will remove it from the sitemap on the next rebuild cycle. Bulk operations - importing a large CSV of new products, or running a bulk-edit across thousands of SKUs - can take longer to fully propagate because Shopify batches sitemap regeneration rather than rebuilding on every single row of a bulk update.

A detail that trips up a lot of technical SEOs coming from WordPress: every URL in a Shopify sitemap carries a <priority> value of exactly 0.7, and this cannot be changed through any admin setting, theme edit, or app. There is no mechanism - official or unofficial - to mark your best-selling collection as higher priority than a thin one within the sitemap itself. Google has said for years that it treats the priority attribute as, at best, a very weak signal, and in 2026 the consensus among search engineers is that it's functionally ignored. If you're used to hand-tuning priority values in Yoast, that lever simply doesn't exist on Shopify - internal linking and content depth do the equivalent job instead.

Shopify also doesn't emit a <changefreq> tag at all - another Yoast-era holdover that most SEOs expect and won't find. Instead, Shopify relies purely on an accurate <lastmod> timestamp per URL, updated whenever the underlying resource changes, which is generally what modern crawlers actually use to prioritise re-fetching.

Automatic exclusions from every sitemap build: any entity that is unpublished, hidden from the Online Store sales channel, or explicitly disabled; the standard transactional URL set (/cart, /checkout, /orders, /account, /policies); and anything you've explicitly blocked via robots.txt.liquid - although, as covered below, a robots.txt block and a sitemap exclusion are not automatically the same thing, and mismatches between the two are one of the most common causes of coverage errors in Search Console.

What's included by default

Shopify's default sitemap logic runs one test only: is the entity published? If yes, it goes in. There is no secondary quality gate. Specifically, the default build includes:

• All published products - including permanently out-of-stock products, unless you explicitly noindex them
• All published collections - including empty or near-empty collections, unless you explicitly noindex them
• All published pages (About, Contact, size guides, custom landing pages)
• All blog articles across every blog handle the store has ever created
• The homepage

The gotcha, worth repeating because it's the root cause of most of the fixes in this article: "published" is the only test Shopify applies. It doesn't check inventory levels, content depth, duplicate-content risk, or whether a collection has three products or thirty thousand before deciding to include it. A collection auto-generated by a Shopify Search & Discovery filter combination with zero matching products still gets a sitemap entry if it's published. That default behaviour is sensible for a platform serving millions of stores of wildly different sizes - it just means the burden of quality control sits entirely with you.

What's NOT included (and why it matters)

• Unpublished, hidden or disabled products and collections
• Deleted URLs, even where an active 301 redirect is in place
• Google Merchant Center feed URLs (a separate, feed-specific system entirely)
• Custom /tools/ app URLs and most third-party app-generated pages
• Shopify Plus checkout customisations and checkout extensibility pages
• App proxy pages served under your domain by external apps

This is where the contrarian point that most Shopify SEO guides skip becomes relevant: Shopify blog articles are published under a URL structure the platform itself imposes - /blogs/[blog-handle]/[article-handle] - and that structure is inherited whether you like it or not. There's no way to move editorial content to a flatter, more topically clustered path without a proxy or reverse-proxy workaround. For content-led stores publishing frequently, this limits how cleanly you can organise a content silo purely through URL structure, and it's a genuine reason the sitemap-driven crawl signal for blog content behaves differently from a WordPress or headless CMS setup. If you rely on any of the excluded URL types above for organic traffic - and most stores running app-proxy landing pages or programmatic content do - you need either a Plus-only supplementary sitemap or a manual URL submission workflow through Search Console's URL Inspection tool.

The four sitemap fixes that improve indexing

These four changes are the ones we return to on almost every Shopify technical audit. Across three anonymised client engagements - a homeware retailer, a beauty brand, and a mid-market fashion store - applying all four in combination produced measurable increases in "valid" indexed pages in Search Console within four to six weeks, without any new content being published. None of these clients saw a decline in indexed page count from removing thin URLs; the opposite happened, because crawl budget was freed up for pages that actually deserved it.

{% if template contains 'product' and product.available == false and product.metafields.seo.hide_when_oos %}
  <meta name="robots" content="noindex, follow">
{% endif %}

{% if template contains 'collection' and collection.products_count < 3 %}
  <meta name="robots" content="noindex, follow">
{% endif %}

Interactive sitemap validator

Paste your store's domain below and the validator runs the same four checks we run manually on every technical audit: is the sitemap index reachable, do sampled product URLs return a clean 200, are your high-value pages actually present, and do your canonical tags agree with what's in the sitemap. This is a simulated diagnostic for demonstration - for a full live crawl of your actual sitemap, use the free audit link at the end of this article.

Sitemap index structure, visualised

The nesting described earlier is easier to reason about visually. Everything Google crawls starts from the single index file, which fans out to five sub-sitemaps:

Shopify vs WooCommerce vs BigCommerce sitemap capabilities

A frequent question from merchants weighing a platform migration: how much sitemap control do you actually give up moving to or from Shopify? Here's the honest comparison.

The trade-off is consistent across the table: Shopify gives you a sitemap that works correctly out of the box with zero configuration, at the cost of granular per-URL control that plugin-based platforms offer. For most merchants that trade-off is the right one - you spend engineering time on the noindex workarounds in this article rather than maintaining a plugin.

How to submit your Shopify sitemap to Google + Bing

Google Search Console: verify your store's domain (DNS record verification is preferred over the HTML file method, since Shopify doesn't give simple root-level file access). Once verified, navigate to Sitemaps in the left sidebar and submit sitemap.xml - just the filename, not the full URL. Google will fetch it, usually within a few hours, and begin working through the sub-sitemaps.

Bing Webmaster Tools: the same process applies, or you can import your verified Google Search Console property directly, which also imports your sitemap submission and saves a manual step.

IndexNow (optional): a protocol supported by Bing and a growing number of other engines that lets you push individual URL changes the moment they happen, rather than waiting for scheduled re-crawls. Enable it via a Shopify app or a lightweight webhook that fires on product update events. It's a useful complement to sitemap submission for high-priority, frequently-changing pages - not a replacement for keeping the sitemap itself clean.

Diagnosing sitemap-related indexing issues in Search Console

Once your sitemap is submitted, Search Console's Pages report is where problems surface. Three signals come up again and again on Shopify stores:

• "Discovered - currently not indexed" - Google found the URL via the sitemap but chose not to index it yet. Usually a signal of thin content, a near-duplicate collection, or a crawl-budget constraint on very large catalogues. The four fixes above directly reduce this bucket.
• "Crawled - currently not indexed" - Google fetched the page but decided against including it in the index. This is a quality judgement, not a technical error; improving on-page depth, unique product copy, and internal linking from higher-authority pages is the fix.
• "Duplicate without user-selected canonical" - the sitemap URL and the canonical tag on the page disagree about which version is authoritative. This is the single most common Shopify-specific sitemap error we see, usually caused by filter/sort URL parameters or collection-vs-product canonical conflicts. Fix the canonical, then resubmit.

Cross-reference sitemap coverage against your robots.txt rules before troubleshooting further: a URL blocked in robots.txt but still listed in the sitemap creates a coverage error that nags every week in Search Console until one side of that contradiction is fixed. Canonical mismatches are covered in more depth in our companion article on Shopify canonical tags, and the out-of-stock noindex pattern above is expanded further in our out-of-stock SEO guide.

Six named sitemap mistakes we see repeatedly

1. Assuming sitemap inclusion equals indexing. A sitemap is a discovery hint, not a guarantee. Plenty of sitemap URLs never get indexed if Google judges them low-value.
2. Leaving discontinued products indexable indefinitely. Without a noindex or redirect strategy, dead product pages accumulate and dilute topical relevance for the whole catalogue.
3. Blocking a URL in robots.txt while leaving it in the sitemap. This direct contradiction generates a recurring coverage error and wastes crawl budget on a page Googlebot is told not to fetch.
4. Not resubmitting after a migration or major redesign. Waiting for Google's natural crawl schedule after a large-scale change can cost weeks of stale indexing.
5. Ignoring canonical/sitemap mismatches. Filter and sort parameter URLs are a common source - canonicalised to the clean URL, but still enumerated in the sitemap.
6. Expecting priority values to influence ranking. They don't, on Shopify or anywhere else in 2026. Time spent adjusting them is time not spent on content depth or internal linking.

Frequently asked questions