Skip to main content

Sitemap generation & coverage

How to use it​

  1. Generate a sitemap. Choose which entity types to include.
  2. Check the serving banner. It tells you whether the published URL actually answers on your storefront.
  3. Add the reference to robots.txt using the snippet shown.
  4. Submit to Search Console — the button preflights reachability first.
  5. Turn on auto-regeneration so it rebuilds as your catalogue changes.

⏱ ~5 min setup · 💳 Starter+ · 🎯 Tell Google what to crawl, and find out what it indexed

What goes in it​

EntityIncludedNotes
Products✓Optionally with image entries
Collections✓
Pages✓
Blog articles✓

Large catalogues are chunked into several files behind a sitemap index. The index and its children are all served from the same storefront host — a child file on a different hostname than the index that references it is one Google refuses.

lastmod only moves when something changed​

Each URL's lastmod is derived from a content signature, not from the time of the build. If nothing about a product changed, its date does not move.

This matters because a sitemap that claims your entire catalogue changed today is the exact signal the file exists to avoid — it tells Google your dates carry no information, and it will start ignoring them.

Two behaviours protect that:

  • A partial build merges its signatures rather than replacing them wholesale. Without this, a build where one source failed would re-seed every URL it did not cover with today's date.
  • The product signature uses only fields present in every query variant, so turning the image sitemap on or off does not re-hash your whole catalogue.

Serving and reachability​

Your sitemap is served on your own storefront domain through the app proxy, at a path under /apps/…. That URL is what the tab shows you, what the robots.txt snippet publishes, and what gets submitted to Search Console.

The tab runs a live check against it and distinguishes two very different failures:

ResultMeaningFix
Proxy not routingShopify answered with an HTML 404 — the request never reached the appThe app proxy is not live on this install. Reinstall or re-deploy the app configuration
Not generatedThe app answered, but has no sitemap for this storeGenerate one
ReachableThe URL serves XMLNothing

Telling these apart is the whole point. An HTML 404 from Shopify and an XML 404 from the app look identical in a browser and mean completely different things — one is a configuration problem outside the app, the other is a button you have not pressed.

Submission is blocked when the URL is unreachable

Submitting a dead sitemap URL to Search Console records a fetch error against your property that persists in Google's reporting. The submit action preflights reachability and aborts rather than submitting, and tells you which of the two failures it found.

Auto-regeneration​

With auto-regeneration on, the sitemap rebuilds daily.

"Daily" means daily

A freshness window measured as exactly the cron interval always ratchets to double it: the job fires, finishes two minutes later, and the next tick sees a file two minutes too new to rebuild — so it skips, and rebuilds 48 hours later. Stores on builds before August 2026 saw exactly that pattern. The window now carries a grace period, so a daily schedule regenerates daily.

Expiry, and what it does not do​

A sitemap file has an expiry. Expiry means "stale, rebuild" — it does not mean "delete".

Housekeeping only removes rows that a newer build has superseded. Deleting a merchant's only served file because it aged would make the public URL 404 for Googlebot, and the sitemap you submitted would silently drop out of Search Console — which is what happened to stores without auto-regeneration on older builds, seven days after they generated.

Coverage​

Coverage is the answer to "of the URLs I submitted, how many did Google actually index?" It is fetched from your Search Console property and stored as snapshots so you can see the trend.

Two things you should know about it:

  • It refreshes on a schedule, not only when you press Refresh. Earlier behaviour wrote a snapshot only on a manual submit or refresh, so the panel was usually empty even on well-configured stores.
  • A failure to fetch is reported as a failure, not as "no data yet". A dead Search Console token, a missing property or a Google 5xx each produce a distinct message. Rendering all three as an empty state is how a broken connection stays broken for months.

Snapshots older than 90 days are pruned, but the most recent snapshot per sitemap is always kept — so a store that has not reconciled in a while still has its last known coverage rather than a blank panel.

Generation history​

Every build — background or inline — writes a history row with its outcome, warnings, URL count and whether it was partial. The tab also recomputes whether the current URL count is a regression against the last healthy build, and warns if the file is stale.

Plan tiers​

CapabilityFreeStarterProAgencyEnterprise
Generate + serve a sitemap—✓✓✓✓
Image entries—✓✓✓✓
Chunked sitemap index for large catalogues—✓✓✓✓
robots.txt snippet + reachability check—✓✓✓✓
Search Console submission—✓✓✓✓
Index coverage tracking—✓✓✓✓
Auto-regeneration——✓✓✓

Search Console submission and coverage both require the Search Console connection.

Best practices​

  • Reference it from robots.txt. Generating a sitemap nothing points at achieves very little; the snippet is on the tab for a reason.
  • Do not include everything. Filtered collection URLs and tag archives in a sitemap dilute the signal you are trying to send.
  • Turn on auto-regeneration if your catalogue moves. A stale sitemap is worse than a smaller current one.
  • Check coverage monthly, not daily. Google's indexing decisions move slowly; the value is in the trend.
  • If the serving check says "proxy not routing", stop. Nothing downstream — submission, coverage, the robots reference — can work until that is fixed, and it is fixed outside this tab.

See also​