Sitemap

vue-starter-template serves the sitemap files Shopware generates for the sales channel from the storefront's own host.

Link:

http://<your_domain>/sitemap.xml

Routes

/server/routes/sitemap.xml.ts

This route builds a sitemap index. It asks the Store API /sitemap endpoint for the files of every language of the sales channel. The list is cached for ten minutes, because a crawler fetches every file right after the index.

/server/routes/sitemap/[...path].get.ts serves each listed file under /sitemap/<path>. It reads the file from the Store API /sitemap/{filePath} endpoint, so it needs Shopware 6.6.7 or later. A path that is not in the list gets a 404, so the route is not an open proxy.

The files contain dynamic Shopware pages such as:

• Product pages
• Category pages
• CMS pages

Shopware owns the contents of these files. The proxy passes them through and does not rewrite any URL inside.

The starter has no sitemap for routes that only exist in the storefront. To list them, serve your own sitemap file and add it to the index.

Sales channel domain

Shopware builds every page URL inside the files from the sales channel domain. Point that domain (Settings > Sales Channel > Domains) at the storefront's public URL and regenerate the sitemap. Otherwise the files list pages on another host.

Shopware can also use that domain to link the files themselves, so the listed file URLs can point at the storefront. The proxy ignores those URLs and always reads the files from the Store API, so it never fetches itself.

Every language of the sales channel needs a domain. On a storefront-type sales channel with the refresh strategy "Live", Shopware rejects a language without one. The starter skips that language, logs a warning and lists the others.

On a headless (API-type) sales channel from Shopware 6.7.15, also turn on External storefront for the domain. Shopware skips a language without such a domain silently, so the index lists no files for it and there is no warning.

Links in the index

The <loc> links in the index use NUXT_PUBLIC_SITE_URL when it is set. Without it they use the request URL, like useRequestURL. Set it when a proxy in front of the app rewrites the Host header, for example nginx with its default proxy_set_header Host $proxy_host. Otherwise the index lists internal URLs that crawlers cannot reach.

Canonical URLs

Shopware-generated sitemaps prefer the canonical SEO URL when one exists. A technical URL such as /detail/{id}, /navigation/{id}, or /landingPage/{id} is a valid fallback only when no canonical SEO mapping is available.

More about the Shopware sitemap can be found here.

Detect and clean up technical sitemap URLs

Inspect the sitemap index and every referenced sitemap file for URLs whose path starts with:

/detail/
/navigation/
/landingPage/

If a technical URL has a canonical SEO mapping, it should not be published in the sitemap. Determine which system generated it before applying a fix:

• For a custom Frontends sitemap, load authoritative SEO URL data and publish the seoPathInfo value.
• For a Shopware-generated sitemap, verify SEO URL generation and indexing, regenerate the sitemap, and clear sitemap or CDN caches.
• If no canonical SEO mapping exists, keep the technical URL as the only available route.

After cleanup, verify that sitemap URLs return 200 directly. A sitemap should not rely on redirects for canonicalization, even though Frontends redirects a mapped technical request to protect clients when an outdated URL is crawled.

Do not use robots.txt to canonicalize sitemap URLs. Blocking a technical URL can prevent crawlers from observing its redirect and delay index cleanup.