Why Search Console reports a sitemap that does not exist, and where it actually is

What the error means

The submitted sitemap URL returns a 404, a redirect, an HTML page instead of XML, or nothing at all. Google reports the sitemap as not found, and the site keeps getting crawled without its URL roadmap.

Why Google rejects it

Shopify stores generate the sitemap automatically at /sitemap.xml, but submissions fail when the path submitted is not the path served — an old domain, a trailing variant, a WordPress-style /sitemap_index.xml guess — or when bot protection answers the crawler with a block your browser never sees.

How to fix it

1. Open the exact URL you submitted in a private window. A 200 starting with or is the requirement; anything else explains itself.
2. On Shopify, submit exactly https://yourstore.com/sitemap.xml — the platform-served path. Do not guess alternate paths.
3. Check what an outside request receives, not your browser: a 403 to a crawler reads as not found.
4. If the sitemap is an index, make sure the child sitemaps it lists are fetchable too — one dead child fails the set.
5. After fixing, expect Search Console to keep the old status until the next successful fetch; resubmit once and give it time.

Common causes

Submitted a guessed path

Search Console requests the exact sitemap URL you entered. A site may use /sitemap.xml, /sitemap_index.xml, /wp-sitemap.xml, or a platform-specific path. A plausible filename is not enough: if the server returns 404 at that location, Google reports the sitemap as not found even if another sitemap exists.

Wrong property or hostname

The sitemap may exist on the canonical domain while Search Console is trying a protocol, subdomain, or old domain that no longer serves it. Redirects do not always make a stale sitemap submission a good long-term address. Compare the submitted URL with the public site's canonical host and sitemap link in robots.txt.

Store or site is unpublished

Some hosted platforms restrict the generated sitemap while a site is private, in preview mode, or password protected. An administrator can still see the storefront and settings, but an anonymous request receives a login or unavailable page. Test in a private window with no platform session.

The generator is disabled or its route changed

A CMS update, plugin removal, SEO setting, or migration can change which component owns the sitemap endpoint. The old route may now be a normal 404 while a new generator publishes a different address. Check the active sitemap generator and its current public output.

Rewrite or deployment changed routing

On self-hosted sites, rewrite rules or a deployment can stop a virtual sitemap route from resolving. The XML may not be a physical file; WordPress and SEO plugins commonly generate it dynamically. Test the route after a rewrite change and check server logs before uploading a static file that could conflict with the generator.

Fix it on your platform

On Shopify

1. Use the primary public storefront hostname and open /sitemap.xml. Shopify creates this file automatically; you normally do not upload or edit a sitemap file in the theme.
2. If /sitemap.xml gives 404, check whether the storefront is published and whether the domain is connected and resolving to the intended store. Test the primary domain, not an old campaign or myshopify address that redirects elsewhere.
3. Check the store's password or private mode. Disable it for a public storefront before asking Google to read its sitemap, then retry in a logged-out browser.
4. In Search Console, remove or replace an obsolete submitted address with the live root sitemap for the matching property. Avoid adding a second submission that points to the same old host.

On WooCommerce

1. Try the sitemap URL advertised by the active generator. WordPress core commonly uses /wp-sitemap.xml; many SEO plugins publish /sitemap_index.xml. Do not assume both are active.
2. In the SEO plugin's sitemap settings, confirm XML sitemaps are enabled and that the plugin is active. If the plugin was recently changed, update the Search Console submission to the new index URL.
3. Go to Settings > Permalinks and save the existing settings to refresh rewrite rules if virtual sitemap routes return 404 after a migration or permalink change.
4. Check caching, security, and redirect plugins for a rule that rewrites or blocks the sitemap route. Purge stale caches and test the exact public address again.

On other platforms

1. Find the generated sitemap URL in the platform's SEO settings or help documentation, then test that exact route while logged out. Hosted builders may generate the sitemap only after the site is published.
2. For Wix, BigCommerce, and Squarespace, verify the public site's custom domain is connected and that the sitemap address belongs to that domain rather than the editor or preview host.
3. On a custom site, confirm the sitemap route is deployed and returns HTTP 200 with XML. If generated dynamically, check the route handler and web server rewrite rules.
4. Update Search Console to submit the live sitemap URL after a migration. Keep redirects from old page URLs where appropriate, but do not rely on an obsolete sitemap address as the permanent submission.

How to confirm it is fixed

1. Copy the sitemap URL from the platform's public output or robots.txt and open that exact address in a private window. Confirm it returns XML, not a 404, login page, or HTML storefront.
2. Check the hostname, protocol, and path against the Search Console property and the canonical URL used by the site.
3. Open child sitemap URLs listed by an index. Confirm they also resolve and are not stale paths from an earlier domain or CMS migration.
4. Run the sitemap check to fetch the public URL and validate its structure, then submit the confirmed address in Search Console.
5. Check the Sitemaps report for a new fetch result. A successful status confirms retrieval and parsing, not guaranteed indexing of listed pages.

A worked example

Hypothetical case: a WooCommerce shop changes SEO plugins during a redesign. The previous plugin published /sitemap_index.xml, but the new setup relies on WordPress core at /wp-sitemap.xml. Search Console continues requesting the old address and reports that the sitemap was not found. The owner checks the live robots.txt and sitemap settings, confirms the core index and its child files return XML, then replaces the stale submission with the address that is actually served. They also save Settings > Permalinks to refresh the site's rewrite rules after the redesign. The report clears on a later fetch; the product URLs are reviewed separately for indexing.

Other errors like this