Shopify Sitemap Generator: Find the File and Check What’s Missing
Shopify generates your sitemap automatically. Find the XML file, investigate missing products, and separate visibility settings from Google indexing problems.
Shopify already includes a sitemap generator: on a standard Shopify Online Store, open https://your-domain.com/sitemap.xml to find the automatically maintained file. You do not need an app to generate it; if a product is missing from Google, first distinguish a missing sitemap entry from an indexing problem.
That distinction changes what you should do next. A product can open perfectly from a link and still be deliberately excluded from discovery. A sitemap can also be readable while Google chooses not to index one of its pages. This guide follows that chain from the file to the product settings to Search Console, so you can identify the actual job before installing another tool.
The generator is already running
Shopify's root sitemap points to separate files for products, collections, pages, and blog content. Open the relevant child file to inspect its entries. Shopify maintains these files as store content changes, and also generates sitemaps for international domains. These are existing platform capabilities, not a new launch. See Shopify's sitemap documentation.
If you open the root file and see only a few addresses, read them before concluding most of your catalog is missing. Addresses containing sitemap_products identify another sitemap, not individual products. Follow the exact addresses in the file, including any query parameters; do not build a child sitemap URL by guessing its filename.
I would start with one product you actively want customers to discover. Copy its public address, open the product child sitemap or files, and search for its handle. Record which file you checked. This turns “our sitemap is broken” into an observation someone else can reproduce.
XML discovery and HTML navigation have different jobs
An XML sitemap gives search engines a list of URLs. An HTML sitemap is a page visitors can browse. Neither is a promise of rankings. Google's sitemap guidance explains that a sitemap helps discovery but does not guarantee crawling or indexing. Well-linked pages can also be discovered without one.
For a normal theme-based store, keep the native XML file as your starting point. Consider an HTML directory only when it solves a navigation problem: perhaps shoppers need an organized list of spare-parts categories that your main menu cannot usefully display. Make that decision with the person responsible for the catalog, not from a generic SEO score.
A generator app can be useful for managing that directory, but ask for a demonstration on your catalog. Which pages does it create? How does it handle unpublished items? Does it update when a collection changes? What remains after uninstalling it? The HTML/XML Sitemap & Robots.txt listing, for example, advertises several different functions. A feature list alone does not establish that your store needs them.
For an HTML directory, inspect the links themselves. Google recommends crawlable <a> elements with an href and meaningful anchor text. A useful category link says what the visitor will find there. Google's link guidance is a better acceptance standard than the number of links an app generates. Our collection-page SEO guide covers organizing those destinations.
Follow a missing product through three checkpoints
Checkpoint one: should this product be publicly discoverable?
In Shopify admin, open Products > the product. Check its status and the Publishing section, including the Online Store channel and intended markets. Shopify treats product status and publication as separate pieces of the product record. Use the product details documentation to interpret those settings.
Pay particular attention to Unlisted. Shopify supports products that remain accessible and purchasable by direct URL while being excluded from its discovery surfaces. A warranty add-on or a product shared with a limited audience may be intentionally configured this way. Opening the product page successfully is therefore not proof that it belongs in the sitemap.
Before changing anything, ask the catalog owner what the intended outcome is. “Make every missing product appear” is a poor instruction when the missing set includes add-ons, draft launches, or items meant for a different channel. Test a single intended public product first, then decide whether the same correction applies elsewhere.
Checkpoint two: was the page deliberately hidden?
Shopify's seo.hidden metafield can exclude a product, page, or blog post from sitemaps and search when its value is 1. Check existing definitions under Settings > Metafields and metaobjects, then the resource's metafields. An app may already own or use this field. Do not create a competing definition just because it is not immediately visible.
If the exclusion was accidental, Shopify documents restoring visibility by clearing the field's value and saving. Check Unlisted status separately: clearing seo.hidden does not cancel an Unlisted product's visibility rules. Both behaviors are covered in Shopify's search-exclusion documentation.
My recommended change note is simple: record the product URL, its intended audience, the original setting, the person authorizing the change, and the observed result afterward. That gives your team a way to reverse an incorrect decision without trying to reconstruct what an SEO app changed last week.
Checkpoint three: is it missing from the file, or from Google?
Return to the actual child sitemap and check the product URL again. If it is present, stop treating generation as the unresolved task. Open Google Search Console, inspect that exact address, and review the indexed result. Then use Test live URL to investigate the current page if you have changed it.
These views answer different questions. The indexed result reflects Google's stored information; the live test checks the current page. Google explicitly says the live test does not check sitemap membership or predict its canonical choice. A successful live test therefore cannot prove that your preferred URL has been indexed. See the URL Inspection documentation.
Keep three observations separate: the URL appears in a child sitemap, the current page can be fetched, and Google's indexed record selects the intended canonical. Put each result beside the same product URL in your investigation. This is more useful than a single “SEO passed” label, because a different person may own each correction.
Submit the file, then read the result accurately
In your verified Google Search Console property, go to Indexing > Sitemaps. Submit the sitemap address; if the form already supplies your domain, enter sitemap.xml. Check that you selected the right domain property before submitting. For separate international domains, follow Shopify's domain-specific submission instructions rather than assuming one submission proves coverage everywhere.
Google's Sitemaps report documentation distinguishes these outcomes:
- Success: Google fetched and processed the file. This is not confirmation that every listed product is indexed.
- Has errors: Open the report details to identify the parsing problem; usable entries may still be processed.
- Couldn't fetch: Investigate the submitted address, access restrictions, robots rules, and possible server failures. Read the last fetch details before changing the store.
For a fetch failure, open the exact submitted address in a signed-out browser and record what appears. XML, a password screen, an error, and a redirect to an unrelated page are different findings. A browser check is supporting evidence, not proof that Google's request succeeded. If your storefront is intentionally private before launch, do not expose unfinished products just to obtain a green report.
A useful support request includes the submitted URL, the affected Search Console property, the last-read date, the reported error, and one example product. “Please regenerate our sitemap” prescribes a solution before establishing whether the problem is generation, access, or indexing.
When the sitemap and Google's preferred URL disagree
A canonical URL is the preferred address for a page among duplicate or similar versions. Google describes sitemap inclusion as a weaker canonical signal than redirects and rel="canonical". Adding another sitemap is not a reliable way to override conflicting signals. Refer to Google's canonicalization guidance.
For one affected product, compare the sitemap address with the page's canonical tag and the Google-selected canonical in the indexed inspection result, where available. Ask your developer to investigate disagreements before applying a catalog-wide change. A market-specific address, an old redirected URL, and a current product address need to be understood in context. For stores selling across regions, our international canonical and hreflang guide explains how those market URLs relate.
If the investigation instead finds a discontinued item, make the merchandising decision first. Should customers still reach useful product information, or is there a genuinely relevant replacement? Our guide to discontinued products and redirects explains why treating every unavailable item as the same SEO problem leads to poor fixes.
The exception: a custom storefront owns its own routes
The native-file advice above is for a Shopify Online Store. If developers operate a headless storefront, confirm what serves the public domain. Hydrogen's base template includes sitemap routes; Shopify documents generating missing routes with npx shopify hydrogen generate route sitemap. Its default sitemap caching is 24 hours. Those are Hydrogen details, not a promised update interval for every Shopify storefront. See Hydrogen's SEO documentation.
For a custom build, ask the development team who owns sitemap generation, which content sources it includes, and how publishing changes reach production. Request evidence from the public domain. A working file on a development deployment does not answer what shoppers and search engines receive on your live store.
What to hand your team before buying a generator
Choose a small sample: a public bestseller, a recently published product, an intentionally hidden add-on if you have one, and a relevant collection. For each, record intended visibility, sitemap membership, public-page behavior, and Search Console findings. Mark unknowns as unknowns. This is an investigation worksheet, not a demand that every URL pass the same test.
Our free Shopify store scanner checks public sitemap reachability. When the root contains <sitemapindex>, our scanner counts its <loc> entries as child sitemap references, not as products; that check does not enumerate every product inside those children. It does not inspect your private visibility settings or establish Google indexing. Use it to start the public-file check, then complete the product and Search Console checks with your team.
If you need help reconciling those results, send Code Kaarigari the affected URLs and observed errors. The useful deliverable is a documented correction to the broken part of the discovery chain. Sometimes that calls for custom sitemap work. Often the native generator is already doing its job, and the next action belongs in product settings, navigation, or indexing diagnostics.