The Shopify sitemap bug that breaks your clients' Google fetch

TL;DR

• "Couldn't fetch" in Search Console is a per-URL failure, not a site health score. On Shopify, it's usually caused by submitting the wrong URL, not a broken sitemap.
• Shopify's native child sitemaps (sitemap_products_1.xml?from=...&to=...) return HTTP 400 with an empty body when the generated query parameters are stripped, on both a Googlebot and a browser user agent.
• The fix is almost always: submit only /sitemap.xml (the index), confirm it's on the domain that doesn't redirect, and check the storefront isn't password-protected.

If you maintain Shopify stores for clients, you'll eventually see this in Search Console: a red Couldn't fetch (sometimes worded Sitemap could not be read, or a General HTTP error) on the Sitemaps report. The file opens fine in a browser. There's nothing about it in Shopify admin. And the client is asking why their new products aren't showing up on Google.

The instinct is to assume the sitemap itself is corrupted. It almost never is: Shopify generates and regenerates the file automatically, so the contents are rarely the problem. What breaks is which URL got submitted, and Shopify's sitemap structure makes it easy to submit the wrong one without anyone noticing, especially after a domain migration, an app install, or a theme swap done by someone other than you.

This post covers what "Couldn't fetch" actually means, why Shopify's sitemap shape triggers it, and a five-step checklist you can run on a client's store in a few minutes.

What does "Couldn't fetch" actually mean in Search Console?

The Sitemaps report documentation defines three outcomes: "Success" means the sitemap was fetched and read without errors; "Sitemap had X errors" means it was fetched but had issues in its content; "Couldn't fetch" means Google couldn't retrieve the file itself.

That last one is narrower than it looks. "Had errors" is about the contents of a file Google successfully read. "Couldn't fetch" means the request never produced a readable file at all, so nothing inside the XML can be the cause, and validating it proves nothing. The only question that matters is what happened when Google requested that specific address.

One field in the same report answers most of that before you touch anything: Last read, defined as "the last time the sitemap was fetched by Google. Only present if Google could fetch the sitemap." A failing row with no Last read date has never been read successfully (wrong address, or unreachable since submission). A failing row that still shows a date was readable until then and stopped, which points at a recent change instead of a mistake. Check this before you start debugging.

Why does Shopify's sitemap structure make this so easy to trigger?

On a hand-rolled sitemap, a fetch failure usually traces back to something you wrote. On Shopify you didn't write it. Per Shopify's docs, sitemap files are generated automatically at the root of your store's domain (example.com/sitemap.xml), the generated index links to separate child sitemaps for products, collections, blogs and pages, and those files update automatically as content changes.

That's good news for content accuracy, but it means the URL you submit isn't something you chose, and the structure isn't uniform across stores. I fetched the sitemap of six live Shopify storefronts as Googlebot and followed every redirect by hand:

• Three answered the bare domain with a 301 to a different host (two to www, one to an unrelated subdomain).
• Two served Shopify's native index, with children shaped like sitemap_products_1.xml?from=...&to=....
• One served a non-native structure: sixteen children at paths like /sitemap/products/1.xml, no query parameters.

The detail that matters most: on both stores serving Shopify's native index, requesting the child product sitemap with its from/to parameters returned HTTP 200, and requesting the exact same path without those parameters returned HTTP 400 with an empty body, both under a Googlebot user agent and a desktop browser one. Same result for the pages sitemap. The parameters aren't tracking noise, they're part of the address, and they shift as the catalog changes (they encode a range of product IDs).

So a child sitemap URL, copied out of the index and submitted directly, is an address with a short shelf life even when it works today.

How do you confirm the actual cause in five minutes?

In this order, cheapest checks first:

1. Read the Last read column. Empty means never successfully fetched; a date means it worked until then. This decides whether you're chasing a wrong address or a recent regression.
2. Compare the submitted URL against your primary domain plus /sitemap.xml. A child sitemap path, a stale domain, or the bare domain on a store that serves www are the three shapes that fail while the store itself is fine.
3. Open that exact URL in a private window and watch the address bar. A host change means Google was pointed at a redirecting URL. Valid XML means the file is readable from where you're sitting, which narrows the problem to whatever sits between Google and the file.
4. Confirm the storefront isn't in private mode. Shopify's own docs state search engines can't access the sitemap while the online store is set to private. Check this early: a password page answers requests happily, just never with the sitemap.
5. Run the URL through URL Inspection and hit Live Test. This fetches the file as Google right now, instead of replaying a cached result. If Live Test succeeds while the report still shows red, the failure is historical and the report hasn't caught up yet, since Google recrawls a successfully read sitemap on its own schedule, independent of the site's crawl.

If all five come back clean, the honest read is that nothing is currently wrong. That's a real outcome, not a dodge.

What are the specific causes, and how do you fix each one?

A child sitemap got submitted instead of the index. Google's own guidance says you can optionally submit a single sitemap index rather than individual files. On Shopify's native structure, submitting a child isn't just redundant, it fails outright once its generated parameters are stripped or go stale. Fix: delete the failing entry, submit only your primary domain plus /sitemap.xml, and stop resubmitting after that.

The submitted URL redirects. Common after a domain migration, or on any store that serves www while the bare domain 301s away. Shopify notes that all of a store's domains are discoverable unless they redirect to the primary one. Fix: submit the sitemap on the host that actually serves it, and make sure the Search Console property matches the domain customers land on.

The store is in private mode. Survives on stores that were relaunched or password-protected for a sale and never reopened. Fix: deactivate storefront password protection.

An app replaced the native sitemap. If a sitemap app is installed, you might be looking at a non-default structure, like the /sitemap/products/1.xml shape above, with no query parameters. Google's docs note that a sitemap not submitted directly through Search Console, but only discovered via robots.txt, only affects URLs beneath its own parent directory. If that directory isn't where the storefront's products actually live, submitted or crawled coverage can miss them entirely. Fix: pick one sitemap (the app's or the platform's), submit it directly rather than relying on discovery, and verify the URLs it lists actually resolve. Check separately whether the same app applies a noindex rule to any of those products; sitemap inclusion and indexing rules are two different settings and can disagree.

Something in front of the domain refused the request. A bot-filtering or fraud-prevention app, a proxy or CDN, an expired certificate, a country restriction. If the file reads fine from your own browser and the URL is correct, this is what's left. It's the same cast of characters behind a "Blocked due to access forbidden (403)" status on individual pages, just reported in a different screen with no status code attached.

Nothing is actually wrong. The report shows the outcome of the last attempt, not a live check. Confirm with Live Test and the Last read date, then leave it and check again in a few days.

Why does this bug keep coming back on client sites?

Every cause above gets triggered by an ordinary event on someone else's component: a domain migration, an app installed for an unrelated reason, a certificate renewal, a password toggled on for a sale and left on, a fraud rule tightened after a bad week. None of it is announced, and Shopify admin has no sitemap status screen at all.

The cost also shows up somewhere else, later. A URL that never gets refetched doesn't get flagged as a sitemap problem; weeks afterward it turns up in the Page indexing report as "Discovered - currently not indexed", a label that describes the symptom and says nothing about the sitemap being the cause. Worth putting a sitemap fetch check on the same checklist as robots.txt review after any domain change, app install, or theme migration on a client store.

Have you run into a Shopify sitemap fetch failure that turned out to be something weirder than a redirect or a password page? What was it?

The full version of this article — with screenshots and ongoing updates — lives on the StoreCanary blog.