PrestaShop XML and HTML sitemaps: generation, validation and indexing

What we would do

We would keep a working generator until the published files show a requirement it cannot meet. The right route depends on your PrestaShop release, the theme and modules controlling canonical and noindex tags, content modules, catalogue imports, multistore and language setup, markets, and the team responsible for scheduled jobs. A different generator cannot repair an incorrect canonical tag in the page it reads.

Rehearse generator replacements and indexing-rule changes on a protected staging copy with representative data and the same theme and modules. Isolate its imports, emails and scheduled tasks from production, then run controlled tests. Keep staging inaccessible to public crawlers and allow authorised verification requests to reach the test pages. Confirm that staging authentication does not cause valid pages to be excluded from the test output. Agree a publication window after any catalogue import, retain the previous configuration and valid files with restoration steps, and ensure only the intended generator writes the published output.

If discovery or indexing problems persist and you need a diagnosis, the PrestaShop SEO Audit & Action Plan provides findings and prioritised fixes; implementation is separate and indexing is not guaranteed.

Choose XML and HTML sitemaps for different jobs

An XML sitemap lists the public URLs you want search engines to discover. It can help with a large or changing catalogue, pages with few internal links and media discovery. It complements crawlable navigation and internal links. Submission does not guarantee crawling, indexing or ranking. See Google's sitemap overview.

An HTML sitemap is a normal page with readable links for visitors. You can group categories, products, information pages and brands so people can find a route into the catalogue. It is optional. Keep it useful and manageable rather than listing every possible filter combination.

Use the XML index for search-engine submission. Link an HTML sitemap where it helps navigation, such as the footer. Neither format replaces links from relevant categories and content pages. Repair orphaned products instead of relying on a sitemap as their only route.

Use absolute URLs and honest modification dates

Write UTF-8 XML with the sitemap namespace. Each URL entry needs a loc. Use the complete canonical scheme, host and path. An HTTP URL is valid if that is the actual canonical URL; the protocol does not require HTTPS. Keep domain, www preference, language path and trailing-slash rules consistent.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/en/blue-leather-wallet</loc>
    <lastmod>2026-10-23</lastmod>
  </url>
</urlset>

The URL above is an illustrative catalogue entry. Escape XML special characters, including ampersands in query strings. A relative path such as /en/blue-leather-wallet is insufficient.

lastmod is optional. It describes a meaningful page change, rather than the time the generator ran. A date such as 2026-10-23 or a complete W3C datetime with timezone is valid. Use a trustworthy content timestamp. Omit the element when you cannot determine one.

Check timestamp fields by entity and PrestaShop version. Products and categories have modification fields, but you cannot assume every CMS model has date_upd. In multistore, check the page and language actually served. A routine database update does not always mean the public page changed.

changefreq and priority are optional protocol fields. Google ignores them. Keep effort focused on correct URLs and accurate dates. The sitemap protocol defines the format; Google's build guidance explains its handling.

Choose the pages that belong in your XML output

Use the same preferred URLs in internal links, canonical tags and sitemap entries. Build the list from your indexing policy, then inspect the pages as an anonymous visitor.

A temporary stock shortage does not automatically make a useful product page unsuitable. Base inclusion on whether the page remains public, canonical and intended for indexing. For discontinued products, use your replacement or removal policy and list only final URLs that remain indexable.

A deliberately created, useful filter landing page can belong in the sitemap when it has its own indexing and canonical policy. Do not indiscriminately publish every faceted-navigation URL. Read the URL and redirect guide for URL changes and duplicates.

Audit robots.txt separately. A URL can appear in a sitemap while robots.txt prevents the crawler from reading it. A noindex directive also needs to be accessible for a crawler to process it. Sitemap inclusion cannot override either rule.

Split files within protocol and hosting limits

A single sitemap is limited to 50,000 URLs and 50 MB uncompressed. Split before either limit is exceeded. Compression reduces transfer size but does not increase the permitted uncompressed size. A sitemap index points to the child files so you can submit the index URL.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap_1_1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap_1_2.xml</loc>
  </sitemap>
</sitemapindex>

This example uses numbered chunks. An index does not imply separate product, category, CMS and blog files. Content-type segmentation is an optional generator feature that can make monitoring easier. Check what your generator actually produces.

Keep referenced files accessible and within the applicable site and directory rules. Use Google's sitemap-index guidance if you publish across sites. For large catalogues, check generation time, memory, writable storage and whether every child file completes.

What the official Google Sitemap module already does

PrestaShop sitemap generation comes from a module, such as gsitemap. Its output already supports splitting, page exclusions and a cron generation route. The implementation described here uses a 25,000-link chunk threshold and a memory-usage threshold around 100 MB. Confirm both in your installed release. These trigger writing and continuation; they are separate from PHP's memory_limit.

The official module also excludes several private and transactional controllers. Its language-specific files are not the same feature as hreflang annotations. Evaluate your installed version, extra module URLs and scheduling needs before choosing a generator. The official gsitemap implementation documents those behaviours.

Keep gsitemap or change the generator?

Add language alternatives and images where useful

Different languages need their own public URLs. Separate language sitemap files do not, by themselves, declare that two URLs are translations. Hreflang can be provided in HTML, HTTP headers or sitemap annotations. Keep the chosen method consistent.

When using sitemap hreflang, declare the XHTML namespace and include the page itself plus its available equivalents. Each language version needs the corresponding set of alternates. Use valid language and region codes and fully qualified URLs. Do not invent a translation URL for a page that does not exist.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <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"/>
  </url>
</urlset>

This excerpt shows one URL entry; the German entry needs the same alternate set. Follow the PrestaShop hreflang guide for mapping and validation.

For product-image discovery, you can add image entries to a regular sitemap or publish an image sitemap. Declare xmlns:image="http://www.google.com/schemas/sitemap-image/1.1" and put image:loc inside an image:image child of the page's url entry. Use image URLs that crawlers can fetch. See Google's image sitemap format and the PrestaShop image guide.

Work through a catalogue import

Suppose a supplier import replaces the blue leather wallet from the XML example, while the old address should redirect to its replacement. On the staging copy, run the representative import through an isolated integration and record the intended final URL in each available language. Generate after the import completes: the replacement belongs in the output when indexable, while the redirecting address does not.

Compare the before and after lists by content type and language. An unchanged total can hide a missing replacement balanced by an obsolete entry. Follow the generated replacement URL through the storefront and check its canonical tag, rather than assuming the imported address is correct. If a translated page or blog article is absent, check its publication state and the generator's integration with that content module before changing the inclusion policy.

Automate generation and check the result

Choose a schedule based on how quickly your public catalogue changes and how long a generation takes. Daily outside busy hours can be a starting policy. A rapidly changing catalogue may need more frequent runs. Scheduling does not justify changing every lastmod value on every run.

Generated-file acceptance checklist

1. Configure only the public content types and languages you intend to include. Record expected coverage for each shop, including pages supplied by other modules.
2. Generate once and open the index and each child file. Every referenced child must exist and be readable without an admin login.
3. Check XML parsing, counts, absolute URLs, status codes and timestamps. Reject login, error or storefront HTML returned in place of XML. Check each child's URL count and uncompressed size against the limits above, and compare coverage with your expected lists.
4. Use the generator's documented scheduling mechanism. Protect any private regeneration credential and keep it out of public pages. Run the actual scheduled route on the copy, rather than testing only the back-office button.
5. Record successful completion and failures. Avoid overlapping builds. On staging, confirm that a failed build leaves the previous valid publication usable, using the generator's supported publication process rather than exposing partially written files.
6. Regenerate after substantial catalogue removals, URL changes or changes of domain. Repeat these checks before accepting the replacement output.

Test a sample of product, category, CMS, article and translated URLs. Check the HTTP response, final location, canonical tag, robots meta and X-Robots-Tag. A browser showing a styled XML document is not enough to establish that every entry is suitable.

The Advanced SEO Sitemap Builder help covers its optional HTTP, canonical and noindex verification, count/size chunking with an index, image and hreflang output, scheduled regeneration and HTML sitemap, whose page is noindex.

Verification must be enabled and completed if you rely on it. Check robots.txt separately. Review CMS modification dates too: a generator can emit a technically valid date without that date representing a content edit. Confirm extra module content, such as blog articles, appears in the completed output.

Use the hosting scheduler when it already runs the job reliably. If you lack a server scheduler or need central task history and failure visibility, assess Cron Manager for the generator's supported route. Scheduling success still needs a completed-file check.

Spot failures hidden behind a successful response

Submit the index and investigate specific exclusions

1. Fetch the published index without an admin login.
2. Add its full URL as a Sitemap: directive in robots.txt.
3. Submit the same index in the correct Google Search Console property and in Bing Webmaster Tools if you use it.
4. Check the submission status, last read time and parsing errors.
5. Inspect representative URLs in the indexing reports, including newly added products and translated pages.

Sitemap: https://example.com/sitemap_index.xml

The line is an example of the syntax. Point it at the actual index you generated. Keep your existing robots rules appropriate to the shop; do not replace them with a generic sample.

The Search Console Sitemaps report helps you find fetch and parsing failures. A successful submission means the file was processed, rather than a promise that every listed page will appear in search.

Submitted and indexed counts do not need to match. Canonical consolidation or indexing selection can be legitimate. Read exclusion reasons and inspect affected pages before deciding there is a systemic problem. If a product redirects, list its final URL; if it is intentionally noindex, remove it from the XML output; if a useful page is inaccessible, repair the underlying access or server error.

Use the PrestaShop SEO guide for the wider indexing audit and the internal-linking guide to improve the paths into your catalogue.

What to ask your developer or agency

• Which module release and settings were tested, and which public content types or custom module pages are unsupported?
• Where are the expected URL lists, exclusion reasons and completed-file evidence for each shop and language?
• Which job runs generation, how is it ordered after imports, and who receives failures?
• During the switch, which process publishes the files, which old jobs stop, and how do we restore the previous valid publication?

At cutover, generate for the live domain and validate the published index and children before updating the advertised sitemap address. If that address changes, update robots.txt and search-engine submissions, then retire old files only after removing their advertised references. Confirm that an old scheduled job cannot overwrite the replacement.

Questions owners ask

Will removing a URL from the sitemap remove it from Google?

No. Google can discover it through other links. Choose the appropriate page-level indexing or removal action for the page's purpose. Sitemap omission is not access control: private content needs protection even if it has never appeared in a sitemap.

Can I reuse the same files for every shop in multistore?

Do not copy them unchanged just because the shops share products. Check each shop's public domain, enabled languages and catalogue associations, then generate and validate output for that context. Follow the cross-site rules linked above if you deliberately centralise publication.

Who should control the Search Console property?

Keep verified ownership under the business's control and grant the agency the access needed for its work. At handover, confirm that your team can read sitemap reports and manage access without depending on an individual supplier's account.