How to tell if your store's sitemap is quietly broken

A store can be fast, secure, and fully stocked, and still lose search visibility for months without anyone noticing. No error page appears. No customer complains. Sales just drift downward, or new products never quite take off the way older ones did. Often the cause is buried in a file almost nobody looks at: sitemap.xml.

Sitemaps don't fail loudly. They fail by quietly telling search engines the wrong thing, or nothing at all, about pages that matter. A product launched last week might sit unindexed for a month because the sitemap listed it with a lastmod date from a year ago, or didn't list it at all. That's not a crash. It's a slow leak.

What your sitemap is actually telling Google

A sitemap is a list of URLs you want search engines to know about, along with metadata like when each page last changed. Google and other crawlers use it as a hint, not a command, but it's an important hint. Google's own documentation on sitemaps describes it as a way to help crawlers find pages efficiently, especially on large sites where not every page gets crawled equally often (developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap).

That efficiency piece matters more than most store owners realize. Google allocates a finite amount of attention to any given site, commonly discussed as crawl budget. A store with 3,000 SKUs doesn't get infinite, instant recrawls. If your sitemap is cluttered with discontinued products, duplicate URLs, or pages blocked by robots.txt, you're spending that limited attention on pages that don't need it, while the product you launched yesterday waits its turn.

This is why sitemap health is an ecommerce SEO problem, not just a technical one. A broken sitemap doesn't just annoy a crawler. It changes which of your products show up in search, and how fast.

Stale lastmod dates: the silent credibility killer

Every URL in a sitemap can include a lastmod tag, a timestamp for when that page last changed. In theory, this helps Google decide whether a page is worth recrawling. In practice, a lot of platforms and themes generate lastmod dates that are wrong, frozen, or meaningless, for example, every single URL showing the same timestamp regardless of when the page actually changed.

Google has been fairly direct about this: if your lastmod values are unreliable, Google may start ignoring them entirely (developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping). That's the quiet part. Nothing breaks. Google just stops trusting a signal you're providing, and falls back to crawling on its own schedule, which is often slower and less responsive to real changes on your site.

To check this yourself, open your live sitemap.xml in a browser and scan the lastmod values across a handful of URLs. If they're all identical, all set to today's date regardless of when you last edited the product, or frozen at a date from months ago even though you've updated pricing and descriptions since, that's a sign the field isn't doing its job. It won't cause a Search Console error. It will just mean your updates take longer to get noticed.

Orphaned URLs and phantom products

Two related problems tend to hide in the same file. The first is phantom URLs: products you've deleted, discontinued, or unpublished that are still listed in the sitemap. Google keeps trying to crawl them, finds a 404 or a redirect, and logs it as an error in Search Console's Pages report. A handful of these is normal. Dozens or hundreds suggest your sitemap generation isn't syncing with your actual catalog.

The second is the inverse: orphaned pages that exist and matter but never made it into the sitemap at all. This happens most often with products created through bulk imports, apps, or custom scripts that bypass the normal publishing flow. The product page loads fine if someone has the direct link, but no sitemap entry means a weaker signal to Google that the page exists and is worth indexing.

A quick way to catch both: export your current product list from your admin, then compare URL counts against what's actually in your sitemap.xml (or the sitemap index if you have multiple files). A meaningful gap in either direction is worth investigating before it becomes a pattern across a whole product line.

Platform quirks that corrupt sitemaps

Shopify, WooCommerce, and BigCommerce each generate sitemaps automatically, which is convenient until the automation runs into an edge case.

On Shopify, the sitemap is generated by the platform and generally can't be edited directly, but theme customizations and certain apps can create duplicate collection or product URLs that end up in the sitemap alongside canonical ones. This is also where sitemap issues can compound with other theme-related problems; if you've read about why Shopify stores lose orders during theme updates, the same kind of update can quietly change URL structures and leave old ones stranded in search results.

On WooCommerce, sitemap generation usually comes from an SEO plugin (Yoast, RankMath, or similar). Running two SEO plugins at once, or switching between them without cleaning up the old configuration, is a common cause of duplicate or conflicting sitemap files, sometimes with two different sitemap.xml paths active at the same time. Worth checking directly rather than assuming just one plugin is in control.

On BigCommerce, sitemap issues most often show up around variant URLs and multi-storefront setups, where a product exists under more than one channel or currency path and the sitemap lists variants inconsistently. If you run more than one storefront, it's worth spot-checking that each one has its own accurate sitemap rather than sharing an outdated combined file.

A five-minute sitemap audit

You don't need a full technical SEO audit to catch the common failures. A short manual check covers most of it:

Open sitemap.xml directly in your browser and confirm it loads without an error. Scan ten or so lastmod values for obvious staleness or uniformity. Pick five recently added products and confirm they appear in the file. Pick five discontinued products and confirm they don't. Then check Google Search Console's Sitemaps report under Indexing, which shows when your sitemap was last read and how many URLs were discovered versus indexed.

A large, growing gap between discovered and indexed URLs is the clearest sign something upstream is off, whether that's a sitemap problem or a broader crawlability issue. It's the same category of quiet failure as the downtime scenarios described in the real cost of an hour of downtime for a small ecommerce store: nothing visibly breaks, but revenue erodes while you're not looking. Cassian™ includes sitemap checks as part of its broader SEO health monitoring, alongside broken-link and page-speed checks, precisely because these issues tend to accumulate slowly rather than announce themselves. The Cassian Score™ rolls signals like this into a single number so a slow sitemap drift shows up as a dip you can investigate, rather than a mystery six months later.

The takeaway

Sitemap problems are unusually easy to ignore because they don't look like problems. Your site works. Customers can browse and buy. The only casualty is how quickly and completely Google understands what's actually on your store, which shows up later as slower growth, not a sudden drop. A short, regular check of lastmod dates, orphaned URLs, and platform-specific quirks is a small habit that protects a much larger part of your traffic than it seems.