"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.

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. Open your own /robots.txt and read the Sitemap: line. Shopify writes that file and puts the sitemap address in it, so the store tells you which host serves the file and what the full URL is. If that line disagrees with what you submitted, you have your answer without changing anything.
3. 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.
4. 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.
5. 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.
6. 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.

Six steps and no code. If all six 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.

What resubmitting can and cannot do

Almost every version of the advice on this error ends in the same instruction: resubmit, or ping Google so it comes back sooner. One half of that no longer exists, and the other half is already configured for you on Shopify.

The sitemap protocol used to define an unauthenticated URL you could call to announce a change. Google retired it. In a post dated 26 June 2023, "Sitemaps ping endpoint is going away", it wrote that "we're deprecating our support for sitemaps ping and the endpoint will stop functioning in 6 months", and that the HTTP requests to it "will result in a 404 error". The stated reason explains why it is not coming back: "in the case of Google Search, the vast majority of the submissions lead to spam". For anyone running a plugin that still calls it, the same post is explicit: "Any existing code or plugins which use this endpoint will not cause problems for Google Search; you don't need to make any changes (but using the endpoint will also not do anything useful)". A tool that reports it has pinged Google about your sitemap is reporting a 404 it did not show you.

What survives, in that post's own words, is that "You can still submit your sitemaps through robots.txt and Search Console". Google's build-a-sitemap page lists three routes: the Sitemaps report, the Search Console API, and a line in robots.txt, where you "Insert the following line anywhere in your robots.txt file, specifying the path to your sitemap" and "We will find it the next time we crawl your robots.txt file".

That last route is the one nobody opens, and on Shopify it is written for you. Shopify's theme documentation states that "Shopify generates a robots.txt file by default", and the template it documents loops over the default rule groups with {% for group in robots.default_groups %}, printing each group's sitemap where one is set. It is the same file that carries the crawl rules deciding which of your URLs Googlebot is allowed to request, so a store that has never opened it is unaware of both halves at once.

I checked what that produces. Twenty-five candidate domains on 26 October 2026: two never answered (one 429, one 403), twenty-three returned robots.txt, and all twenty-three identified themselves as Shopify-served in the response header. Twenty-two of the twenty-three carried at least one Sitemap: line, and on all twenty-two the host named in that line was the host that had just served the file: ten on the bare domain, eleven on www, one on a separate subdomain. Twenty-three stores is a small sample and none of this is a rate. What it establishes is narrower and more useful than a rate would be: the store publishes its own correct sitemap address, in a file anyone can open in a browser, and that address is exactly what the redirect cause above asks you to work out.

Two shapes in that result are worth recognising before you read your own file. Six of the twenty-two repeated the identical Sitemap: line three or four times, once per user-agent group. That is the documented loop doing exactly what it says, and Google explicitly permits it: "You can specify multiple sitemap lines, and there's no limit to the number of sitemaps you can include in your robots.txt file". One store declared twenty-one different sitemaps, one per market and locale, which matters if you submitted only the root one and assumed it covered every storefront. The single store with no Sitemap: line at all is recorded as a shape rather than diagnosed: Shopify documents the per-group sitemap as "An optional sitemap URL", and documents that adding a custom template "replaces Shopify's generated robots.txt output", so an absent line is reachable by configuration. Which of those applies on that store is not observable from outside, and I am not guessing at it.

None of this is a button that forces a re-read, and Google says so in the plainest terms it has: "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site". Resubmitting a URL Google already reads changes nothing. Submitting the right URL after submitting a wrong one changes everything, because what a fetch failure actually costs you is discovery, and that cost lands later and under a label that names the consequence rather than the cause. And if the question underneath the resubmitting is really how long the rest of the pipeline takes once Google has read the file, those clocks run separately and are timed separately.

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.

Is this happening on your store right now?

Search Console will not page you when this happens. The product page loads fine in a browser, the sitemap looks clean, and Google quietly stops crawling or indexing it anyway. The only way to know is to check the pages the way Google sees them.

• 90+ checks, the way Google crawls and indexes your store. Noindex tags, canonicals, redirects, robots.txt, sitemap coverage.
• Read-only. No app to install, no admin access, nothing changes on your store.
• The exact fix for each page, in plain English, so you or your developer can act the same day.

Across full-catalog scans of more than 90,000 Shopify product pages, about 1 in 4 stores had at least one critical Google visibility issue.

Scan my store for free

Free scan: issue types, counts and first fixes. Full report on every product page, not a sample: $49 once, no subscription.