Learn / sitemap

Shopify sitemaps and the “could not fetch” error

You open your sitemap and it loads. Search Console insists it could not fetch it. Both statements are true, because you and Google are not asking the same question. This guide explains where the Shopify sitemap lives, the four causes behind nearly every fetch failure, and the exact fix order.

Where the Shopify sitemap lives

Shopify generates the sitemap automatically at the store root — an index file pointing at child sitemaps for products, collections, pages and blog posts. You do not build it and you cannot edit entries by hand; it mirrors the catalogue. Submit the exact root path in Search Console, on the property matching your real domain rather than the myshopify subdomain, and reference it from robots.txt. Most “my sitemap is broken” stories begin with a submitted path that no longer matches what the store serves.

The four causes of “could not fetch”

  • Wrong submitted path. A stale URL, a trailing variant, or a subdomain property — the request 404s while the real file sits elsewhere. The most common version by far.
  • A dead child inside a healthy index. The index fetches fine, but one child sitemap it lists fails. Search Console reports the whole submission as unfetchable.
  • Bot protection answering differently. You are a warm browser session; the crawler is a cold request from an unknown network. A 403 to the crawler and a 200 to you look identical from your desk.
  • Stale Search Console state. The report keeps the old status until the next fetch, so a fixed sitemap still reads as failing for a while. Not every red status is a live problem.

“Success” with zero URLs

The crueler sibling: Search Console accepts the file and discovers nothing. Google fetched it but could not process the content — malformed XML from a third-party app, a server timeout on very large catalogues, or robots rules that let the index through while blocking what it points at. Open a child sitemap directly; an index that lists dead children reports as unfetchable, and an index of empty children reports success with nothing inside.

The fix order

  1. Confirm the exact path the store serves at the root, and submit that — no guesses, no remembered URLs.
  2. Open a child sitemap directly and confirm it lists live URLs.
  3. Check the response to an outside request, not your browser — status code, timing and blocks.
  4. Remove the submission in Search Console, wait a few minutes, and resubmit to clear the cached state.
  5. Give it time. The report updates on Google schedule, not yours; a fixed sitemap reads as failing until the next fetch.

Dead URLs and crawl budget

A sitemap is a hint, not a guarantee — its job is to save the crawler time. Every dead or redirecting URL inside it does the opposite, spending crawl budget on pages that cannot rank instead of on products. Keep the sitemap honest and it compounds; let it rot and even healthy products get crawled less often.

Find out if this is happening to you

Shipwork fetches your sitemap from outside your network, follows the first child when it is an index, samples the URLs inside, and reports exactly what came back. Free, no account, no signup — paste your store address.

Check my sitemap

Questions

Why does Search Console say “could not fetch” when the sitemap loads for me?
The three live causes are a wrong submitted path, a dead child sitemap inside the index, or bot protection answering the crawler differently — plus stale report state after a fix. Check in that order.
Should I submit sitemap.xml or each child sitemap?
The root index. Submitting children individually is for diagnosis, not routine setup.
How long after fixing until the error clears?
Until Google next fetches — often days. The report keeps the old status meanwhile, so judge by a fresh outside fetch, not the dashboard.
Do I need a manual sitemap for Shopify?
Rarely. The automatic one mirrors the catalogue correctly for most stores; manual files add a second source of truth to maintain. Fix the underlying cause instead.

Keep reading