"Couldn't fetch" on your Shopify sitemap: what Google actually failed to read

Short answer. "Couldn't fetch" is a statement about one URL, not about your store. Shopify generates the sitemap for you and keeps it current, so the causes worth ruling out first are the ones that put Google in front of an address that never returns XML — a child sitemap, a domain that redirects, or a storefront still behind its password. Read the "Last read" column first: it tells you whether the file was ever readable at all.

You submit your sitemap, and Search Console answers with a red row: Couldn't fetch. Sometimes the same failure arrives worded as Sitemap could not be read, or as a General HTTP error. The file opens fine in your own browser, and there is nothing in Shopify admin to consult about it.

Two dated threads show the shape of it. In one, from 28 November 2024, a merchant reports that the sitemap "has been showing as 'couldn't fetch' / 'Sitemap could not be read' in Google search console which has resulted in many pages becoming de-indexed" after a month of troubleshooting; the single reply suggests server logs, third-party sitemap validators and contacting Google, and the thread ends there. In another, from 12 December 2023, the merchant writes that Search Console "discovers the pages but then throws a 'General HTTP error'. My sitemap is readable (not password protected)" — and that one resolved itself in about a day with no change made.

Those two threads are the whole problem in miniature: the same red row can mean a real misconfiguration or nothing at all, and the report does not distinguish them. What follows is how to tell which one you have, in the order that rules out the most for the least effort.

What Search Console is actually saying

The Sitemaps report has a small, fixed vocabulary. Google's documentation for the report defines the three outcomes plainly: "Success" means "The sitemap was fetched and read without any errors"; "Sitemap had X errors" means it "could be fetched and partially read, but encountered some errors"; and "Couldn't fetch" means "Google couldn't retrieve the sitemap file itself".

That last definition is narrower than it looks, and the distinction matters for where you go looking. "Had errors" is a statement about the contents of a file Google successfully read. "Couldn't fetch" is a statement about a request that never produced a readable file — so nothing inside the sitemap can be the cause, and validating the XML proves nothing. The question is only ever: what happened when Google asked for that address?

The same page documents one field that answers most of the question before you touch anything. "Last read" is defined there as "The last time the sitemap was fetched by Google. Only present if Google could fetch the sitemap." So a failing row with no Last read date has never been read successfully — the address is wrong, or has been unreachable since the day it was submitted. A failing row that still shows a date was readable until that date and stopped, which points at a change rather than a mistake. Two very different investigations, separated by one column that sits to the right of the status word.

Why a Shopify sitemap is easier to submit wrongly than most

On a platform where you write the sitemap yourself, a fetch failure points back at something you did. On Shopify you did not write it. Shopify's own documentation states that "Sitemap files are generated automatically. You can find them at the root directory of your Shopify store's domains, such as example.com/sitemap.xml", that "The generated sitemap files link to separate sitemaps for your products, collections, blogs, and webpages", and that they are "automatically updated when you add a new webpage, product, collection, image, or blog post".

Two consequences follow. The good one is that the file's contents are rarely the problem: you cannot forget to regenerate something the platform regenerates for you. The awkward one is that what you submit is a URL you did not choose, in a structure you did not design — and the structure has more than one valid shape.

I fetched the sitemap of six live storefronts as Googlebot on 16 September 2026, followed every redirect by hand and read what came back. Of the six: three answered the request at the bare domain with a 301 to a different host, two on a www subdomain and one on an entirely separate subdomain; two served Shopify's native sitemap index, listing children of the form sitemap_products_1.xml?from=…&to=…; one served a different structure altogether, sixteen children at paths like /sitemap/products/1.xml with no query parameters; and one was not running on a Shopify storefront at all. Six stores is a small sample and I am not presenting it as a rate — what it establishes is only that more than one sitemap shape is in the wild, and you cannot know which one you have without opening the file.

The detail that matters most came out of testing those child URLs directly. On both stores serving Shopify's native index, the child product sitemap returned HTTP 200 with its from and to parameters and HTTP 400 with an empty body when those parameters were removed — the same result under a Googlebot user agent and under a desktop browser one, and the same for the pages sitemap as for the products sitemap. The parameters are not tracking. They are part of the address.

Want to know whether Google can reach your catalogue at all? Our scan reads your public storefront the way a crawler does, including whether /sitemap.xml answers with valid XML and whether the product URLs it lists resolve — read-only, no admin access, about 2 minutes. → free scan

How to confirm it yourself in five minutes

In this order, because each step is cheaper than the one after it.

1. Read the Last read column. Empty means never successfully read; a date means it worked until then. Do this before changing anything, because the answer decides whether you are looking for a wrong address or for a recent change.
2. Look at the exact URL you submitted. Compare it character by character with your primary domain plus /sitemap.xml. A child sitemap path, a domain you no longer use, or the bare domain on a store that serves www all produce a fetch failure on a perfectly healthy store.
3. Open that same URL in a private window and watch the address bar. If the host changes, Google was asked to read a URL that redirects. If XML appears, the file is readable from where you are sitting, which narrows the problem to what stands between Google and the file rather than to the file.
4. Confirm the storefront is not password-protected. Shopify states that you must "deactivate private mode for your online store" for Google to reach the sitemap. This is worth checking early precisely because it makes every other check misleading: a password page answers requests happily, it simply does not answer them with your sitemap.
5. Run the URL through URL Inspection and press Live Test. A live fetch asks Google to go and get the file now, rather than replaying a stored result. If the live fetch succeeds while the Sitemaps report still shows red, the failure is historical.

Five steps and no code. If all five come back clean, the honest reading is that nothing is currently wrong and the report has not caught up — which is a real outcome, not a cop-out, and is what happened in the December 2023 thread above.

What can stop Google reading a Shopify sitemap

These are ordered by how quickly you can rule each one out. They are not ordered by frequency, and I want to be straight about why: our scanner checks whether a store serves a valid sitemap, but it reads that file from our own crawler, not from Googlebot. We have no data on how often Google specifically fails to fetch a Shopify sitemap, so ranking these by prevalence would be a number I do not have.

You submitted a child sitemap instead of the index

This is the one to check first because it is invisible from the inside: the URL is real, it appeared in your own sitemap index, and it names the product sitemap specifically rather than the parent that merely points at it. Google's guidance is the opposite — its sitemap documentation says you can "optionally create a sitemap index file and submit that single index file to Google", and on a store where the platform maintains the index for you, that is the only entry point worth submitting.

On Shopify's native structure, submitting the child is not merely redundant, it fails outright: strip the generated from and to parameters and the request answers 400, as measured above. And since those parameters encode a range of product IDs, they change as the catalogue changes — so even a child URL copied correctly today is an address with a shelf life. The index has no such problem.

The URL you submitted redirects somewhere else

Three of the six domains I tested answered the sitemap request with a 301. That is entirely normal for a storefront — it is how a store that runs on www handles the bare domain — but it means the URL you submit has to be the one that actually serves the file, not the one you say out loud. Shopify's documentation makes the same point from the other direction for multi-domain stores: "All of your domains are discoverable by search engines, unless they redirect to your primary domain". A sitemap submitted on a domain that redirects is a sitemap submitted at an address with nothing at it.

This one can also outlive the change that caused it. A Search Console property survives a domain migration, and a property still pointed at a previous domain keeps reporting a fetch failure that has nothing to do with the store now serving your customers.

The store is in private mode

Shopify states that search engines cannot reach the sitemap while the online store is in private mode, and that you must "deactivate private mode for your online store" for Google to read it. It survives on stores that were relaunched, or that switched the password on for a private sale and never switched it back off.

An app has replaced the native sitemap

One of the six stores served a structure that is not Shopify's default: sixteen child sitemaps at /sitemap/products/1.xml and similar paths, with no query parameters, all returning 200. That shape comes from something other than the platform's own generator, and it changes the rules in a way worth knowing about. Google notes that "You can host your sitemaps anywhere on your site, but unless you submit your sitemap through Search Console, a sitemap affects only descendants of the parent directory" — so a sitemap living under /sitemap/products/ and discovered through robots.txt rather than submitted directly would, by that rule, cover only URLs beneath that path, which is not where your products live.

A replaced sitemap is also the mechanism behind a quieter failure we have written about separately: a sitemap app that drops products it considers unworthy — briefly out of stock, say — and never re-adds them, leaving a live, purchasable product missing from the sitemap while the file itself fetches perfectly. A green row in the Sitemaps report says the file was readable. It says nothing about whether the right URLs are in it, or about whether they still resolve — a sitemap can just as easily keep listing a product you deleted weeks ago.

Something in front of the domain refused the request

If the file is readable from your browser and the URL is right, what remains is the layer between Googlebot and the file: a bot-filtering or fraud-prevention app, a proxy or CDN in front of the storefront, a certificate that expired between two crawls, a country restriction. The December 2023 thread went down exactly this list — one reply asked whether bot-filtering apps were installed, another reported that renewing an SSL certificate had fixed the identical symptom on their own domain.

This is the same cast of characters that produces a "Blocked due to access forbidden (403)" status on Shopify URLs, and we have covered how to identify each of them there rather than repeating it here. The difference worth holding on to is the reporting: a refusal on a page shows up in the Page indexing report with a status code attached, while a refusal on the sitemap shows up in a different report with no status code at all. Same cause, two symptoms, and no screen that connects them.

Or nothing is wrong and Google has not been back

Google states that after a sitemap is crawled successfully it "will continue to recrawl the sitemap at a pace independent of the site crawl schedule", and the report shows the outcome of the last attempt rather than a live check. A row can therefore stay red for a while after the cause is gone. The Last read column and a Live Test are what confirm it.

The fix, cause by cause

• Wrong URL submitted. Delete the failing entry and submit your primary domain plus /sitemap.xml, nothing deeper — then leave it alone, because Google recrawls a sitemap it has read on its own schedule. Removing an entry from the Sitemaps report does not remove anything from Google's index; it only stops Google checking an address that was never going to work.
• Redirecting domain. Submit the sitemap on the host that actually serves it — the one your address bar settles on — and make sure the Search Console property matches the domain customers reach.
• Private mode. Deactivate the storefront password.
• App-generated sitemap. Decide which sitemap you want Google to have, and have exactly one. If you keep the app's, submit it directly in Search Console rather than relying on discovery, and check that the product URLs it lists are the ones you expect. Check separately whether the same app is applying a noindex rule to any of those products: the sitemap and the indexing rule are two different settings, and a URL can be listed in one while being excluded by the other. If you do not need it, removing the app returns you to the platform's file, which updates itself.
• Something refusing the fetch. Work the access list in the 403 piece, then re-run a Live Test rather than waiting on the report.
• Nothing wrong. Leave it. Check the row again in a few days, and judge it by the Last read date rather than by the status word.

Why this one comes back

A sitemap fetch failure is not a defect in your catalogue, which is precisely why it survives so long. Every one of the causes above is produced by an ordinary event that happens to somebody else's component: a domain migration, an app installed for an unrelated reason, a certificate renewal, a password switched on for a private sale, a fraud rule tightened after a bad week. None of them is announced, and none of them appears in Shopify admin, which has no sitemap status anywhere in it.

The reporting makes it worse in a specific way. The Sitemaps report is a screen you have to remember to open — the same pull-only pattern we mapped across Google's own reporting, where account-level enforcement gets an email and everything else waits for you to come and look. And when the cost finally lands, it lands somewhere else: products that are never revisited do not appear as a sitemap problem, they appear weeks later in the Page indexing report as "Discovered - currently not indexed" — a label that describes the consequence and says nothing about the cause. If you want the map of how these statuses relate to each other, every status in the Page indexing report is laid out separately, and the broader set of ways a Shopify product quietly loses Google visibility puts this one in context.

Being clear about our own boundary: StoreCanary does not read your Search Console, so it cannot tell you what Google's last fetch of your sitemap returned. What our scanner does check, from the outside and on a schedule, is whether /sitemap.xml answers with valid XML at all, and whether the product URLs listed in it still resolve rather than 404ing or redirecting away — the storefront-side half of the same question, on the store's public surface. The half that lives inside Search Console stays a screen you open. Put it on the short list of things you look at after a domain change, an app install or a theme migration, alongside what your robots.txt is currently allowing — two minutes, at the moments when something in front of your store has just changed.