The complete guide to XML sitemaps for PrestaShop SEO

Last reviewed June 2026, verified against current sitemaps.org limits and PrestaShop's native sitemap module.

Here is the thing most PrestaShop merchants get wrong about XML sitemaps: they treat the file as a ranking tool. It isn't. A sitemap is a discovery tool. It tells Google, Bing and every other crawler which URLs exist on your store, which ones are canonical, and when they last changed, so that the pages you actually want in the index get found and re-crawled instead of sitting in a navigation hierarchy four clicks deep, waiting to be stumbled upon. On a 30-product catalogue you can almost get away without one. On a real e-commerce store, a missing or broken sitemap means pages that simply never enter Google's index, and a page Google never indexed can't rank no matter how good the copy on it is.

This guide is specifically about XML sitemaps on PrestaShop: what the format requires, what sitemap modules generate and where basic setups fall short, exactly which URLs belong in the file (and which quietly poison it), and how to keep the thing accurate as your catalogue changes. It is one layer of a bigger picture, if you want the full technical-SEO map, start with the complete guide to ranking higher and come back here for the sitemap detail.

Why sitemaps earn their keep on an e-commerce catalogue

A blog with internal links between posts gets crawled fine on its own. A PrestaShop store is a harder shape for a crawler to walk, for reasons that are specific to how catalogues are built:

• Products sit deep. A product is often three to five clicks from the homepage, home, category, subcategory, listing page, product. Crawl budget is finite, and the deepest pages are the ones most likely to be skipped. The sitemap hands Google a flat list so depth stops mattering for discovery.
• The catalogue changes constantly. New arrivals, price edits, stock swings, description rewrites. The lastmod date on each URL is the signal that tells a crawler "this one changed, come back", so re-crawls land on the pages that actually moved instead of being spent re-reading static policy pages.
• Faceted navigation generates noise. PrestaShop's layered navigation (the ps_facetedsearch module) spins up thousands of filter-combination URLs, colour, size, price band, brand. A clean sitemap is your chance to state plainly which URLs are the real ones, instead of letting Google guess among the parameter soup. (The wider duplicate-content problem this creates is its own topic, see PrestaShop URL structure.)
• Orphans hide. A product pulled from every category, a seasonal item, a page reachable only through search. These have no internal links pointing at them. The sitemap is sometimes the only way Google finds them at all.

Google's own documentation makes the point: sitemaps are "especially useful if your site has a large archive of content pages that are isolated or not well linked to each other." That describes a lot of PrestaShop catalogues.

What a PrestaShop sitemap actually contains

You don't need to hand-write XML, but you should be able to read it, because a sitemap you can't read is a sitemap whose errors you won't notice. Each entry is a url block with two parts that matter:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/blue-leather-wallet</loc>
    <lastmod>2026-06-15</lastmod>
  </url>
</urlset>

• loc, the absolute, canonical URL. This is the only genuinely required field. It must include https:// and it must match the page's canonical tag exactly: same domain, same www / non-www choice, same trailing-slash convention. A near-match counts as a different URL to Google.
• lastmod, the date the page content last meaningfully changed, in YYYY-MM-DD form. Google has confirmed it uses this when it's trustworthy, and ignores it from sites that lie. On PrestaShop the honest source is the date_upd column on ps_product, ps_category and ps_cms. Not the moment the file was regenerated.

The format also defines changefreq and priority tags. Skip them. John Mueller stated outright that Google uses neither; they add bytes and a false sense of control, nothing more.

What basic PrestaShop sitemap modules give you, and where they stop

PrestaShop core does not ship a sitemap generator on the Shop Parameters → Traffic & SEO screen. Sitemaps come from modules, commonly the community Google Sitemap / gsitemap module or a dedicated sitemap module. A basic module can be enough for a small, stable catalogue. The "So what?" only kicks in once you have scale, because basic sitemap setups have real limits:

• It produces a single monolithic file, no segmentation by content type.
• You have no control over what's included or excluded, so it tends to sweep in URLs that shouldn't be there.
• It doesn't regenerate on its own. Someone has to remember to click the button, which means it goes stale the week you're busiest.
• Its lastmod dates are often the generation date, not the real modification date. Which trains Google to stop trusting them.

There is also a PrestaShop-specific ceiling worth naming. The format itself allows up to 50,000 URLs and 50 MB uncompressed per file, but PrestaShop's native Google sitemap module is more conservative than the spec: it caps each file at 25,000 URLs and works against a roughly 100 MB memory ceiling during generation, splitting into numbered files (sitemap1.xml, sitemap2.xml…) once you cross the URL cap. On shared hosting that memory ceiling is the part that bites first. A large catalogue with images can exhaust it mid-generation and leave you with a truncated or empty file and no obvious error. The other native limitation that surprises multilingual stores: it emits one separate file per language rather than declaring xhtml:link hreflang alternates inside a single set of entries, so Google has to infer the language relationships instead of being told them directly. None of this makes the native module wrong for a small shop; it's the reason a store with scale or multiple languages tends to outgrow it.

The answer at scale is a sitemap index file: a master file that points at several smaller, segmented sitemaps (products, categories, CMS, blog, brands, images). You submit only the index; Google discovers the children. Segmenting also pays off diagnostically, when the index report shows a gap, you instantly know whether it's products or blog posts failing, instead of staring at one useless total.

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-products-1.xml</loc>
    <lastmod>2026-06-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2026-06-14</lastmod>
  </sitemap>
</sitemapindex>

And where the native per-language file approach makes Google guess, a single entry that declares its translations directly leaves nothing to inference. This is the xhtml:link alternate form a multilingual store wants:

<url>
  <loc>https://example.com/en/blue-leather-wallet</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/blue-leather-wallet"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/blaue-lederbrieftasche"/>
  <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/portefeuille-cuir-bleu"/>
</url>

What to include, and what to keep out

This is where most stores quietly sabotage themselves. "Include everything" feels safe and is exactly wrong: every junk URL in the file spends crawl budget that should have gone to a product page.

The two cardinal sins are contradiction sins. Listing a URL you've blocked in robots.txt tells Google "this is important, but you may not look at it", and you get inconsistent indexing as a reward. Listing a noindex page is the same self-contradiction. A good sitemap and your indexing rules have to agree; the file should contain only URLs that are crawlable, canonical and indexable.

Keeping the file accurate without babysitting it

A sitemap you regenerate by hand is a sitemap that goes stale, because the moment you delete 500 products or restructure your categories and forget to rebuild it, Google keeps crawling URLs that now 404, wasting budget and logging errors against your store. The fix is to make regeneration automatic.

For PrestaShop that means a cron job hitting the generator on a schedule. Daily at a quiet hour is a sensible default for most stores; a fast-moving catalogue can run every 6–12 hours. Basic module setups are often too blunt here, which is the practical reason most stores past a hundred products move to a dedicated module. Our Advanced SEO Sitemap Builder was built for exactly this gap. So what does it actually do for you? It crawls your own URLs and verifies each one before it goes in the file, reading the page's canonical tag and its robots meta, and dropping anything marked noindex automatically, so the two contradiction sins above can't happen by accident. It writes a proper segmented sitemap index, includes product images and hreflang for multi-language stores, and regenerates on a token-protected cron without you touching the back office. The benefit in one line: the sitemap stays honest as the catalogue moves, instead of becoming a quietly-broken file nobody noticed. (If you run a blog on Blog Revolution, its posts get picked up in the same index.)

# Daily at 03:15, using the module front controller URL generated in the back office
15 3 * * * /usr/bin/curl -fsS "https://example.com/module/mprsitemapbuilder/cron?token=YOUR_TOKEN" >/dev/null

After it's built: submit, then watch

Generating the file is half the job. Add a Sitemap: line pointing at your index file to the bottom of robots.txt so any crawler can find it, then submit the index URL in Google Search Console under Sitemaps (and in Bing Webmaster Tools, Bing feeds DuckDuckGo and several AI assistants, and supports IndexNow for near-instant submission). Submission isn't a one-and-done task, though: the value is in watching the submitted vs. indexed gap over time. A small gap is normal canonical consolidation; a large one means something is wrong, mass noindex, thin content, server errors during crawl. Diagnosing and fixing those Search Console reports is a topic in its own right, and we cover the whole monitoring workflow in Google Search Console for PrestaShop.

User-agent: *
Disallow: /cart
Disallow: /order
Sitemap: https://example.com/sitemap.xml

How sitemaps sit alongside the rest of your SEO

A sitemap doesn't lift rankings. It lifts discoverability, which is the floor everything else stands on. Your best product description is worthless if Google never crawls the page; the sitemap is what guarantees the page gets seen in the first place. It works hand in hand with the rest of the cluster, each part covering ground this post deliberately doesn't:

• Internal links pass authority and context where a flat sitemap can't. The two are complementary, not interchangeable. See internal linking for e-commerce.
• Image sitemaps are their own discipline once Google Image search matters to you, covered in PrestaShop image optimization.
• Clean canonical URLs decide what can even appear in the sitemap honestly. The canonical tag is what stops the faceted-navigation noise from leaking in.
• Crawl budget is finite, and a slow server burns it before Google reaches your deep pages. Which is why page speed quietly affects indexing too.

XML sitemap FAQ

How many URLs can one PrestaShop sitemap file hold?

The sitemaps.org spec allows up to 50,000 URLs and 50 MB uncompressed per file. PrestaShop's native Google sitemap module is more conservative: it caps each file at 25,000 URLs and runs against roughly a 100 MB memory ceiling during generation, splitting into numbered files (sitemap1.xml, sitemap2.xml…) past the cap. On shared hosting the memory ceiling usually bites before the URL count does. A big catalogue with images can run out of memory mid-build and leave a truncated file. If you've outgrown those numbers, that's the signal to move to a module that segments by content type and generates within a memory budget.

Does PrestaShop's sitemap handle multi-language stores with hreflang?

The native module handles multiple languages, but it does so by emitting one separate file per language rather than declaring xhtml:link rel="alternate" hreflang" alternates inside a single set of URL entries. That works, but it leaves Google to infer which URLs are translations of each other instead of being told outright. If correct language targeting matters to you, a German shopper getting the /de/ page, not the /en/ one, a sitemap that declares the hreflang alternates inline gives Google an explicit map rather than a guess.

How often should the sitemap regenerate?

Daily, at a quiet hour, suits most stores. That keeps the lastmod dates honest without hammering the server. A fast-moving catalogue with frequent stock and price changes can run every 6–12 hours. The key is that it regenerates on a cron, not by someone remembering to click a button. A hand-regenerated sitemap goes stale exactly when you're busiest, and a stale sitemap pointing Google at deleted products costs you crawl budget and logs 404s against the store.

Should I put the sitemap URL in robots.txt or only submit it in Search Console?

Both. Add a Sitemap: line to robots.txt so any crawler, Google, Bing, and others, discovers it without being told, and submit the index URL explicitly in Google Search Console (and Bing Webmaster Tools) so you get the submitted-vs-indexed reporting. The robots.txt line is discovery; the Search Console submission is monitoring. You want both, because the gap between submitted and indexed is the number that tells you whether the rest of your SEO is working.

Why is my submitted count far higher than my indexed count?

A small gap is normal, Google consolidates duplicate and canonicalised URLs, so not every submitted URL needs to be indexed. A large gap means something systemic: pages marked noindex that you still listed in the sitemap, thin or duplicate content Google chose not to index, or server errors during crawl. Open the Pages report in Search Console, filter to the URLs from your sitemap, and read the exclusion reasons, they name the cause directly. Listing noindex or robots-blocked URLs in the sitemap is the most common self-inflicted version of this gap.

None of this is glamorous. But on a PrestaShop store, fixing a broken or stale sitemap is one of the cheapest high-leverage technical jobs you can do: it costs nothing, it takes an hour to set up properly, and it keeps paying off as your catalogue grows. Get the structure right, automate the regeneration, keep the file honest about what's canonical and indexable, and check the Search Console numbers now and then. That's the whole job. The rest is detail, and the detail above is enough to get it right the first time. For the full list of what your store should have set up with Google, the complete Google checklist ties it all together.