Shopware SEO

TL;DR — Shopware is an ecommerce platform (built in Germany) that comes with a lot of SEO built in: it can build your product URLs, write your sitemap, handle canonical tags, and set up hreflang for multiple languages. The two things to know going in: which features you get depends on your Shopware version (some arrived only recently), and a few tasks — like tidying up duplicate variant pages — still need a plugin or a developer.

What “Shopware SEO” means

Shopware is an open-source-core ecommerce platform. The current version is Shopware 6. Unlike Shopify or BigCommerce — which host everything for you — Shopware is usually installed on your own hosting (or Shopware’s cloud), which means you get more control and more responsibility.

“Shopware SEO” is just the normal work of getting your products and category pages found, crawled, indexed, and ranked — applied to a store that runs on Shopware. It’s worth its own guide because Shopware makes a lot of SEO choices for you out of the box, and you need to know which boxes it already ticks, which it leaves empty, and which ones only appear if you’re on a recent-enough version.

What Shopware does for you

• Clean URLs. Shopware builds “SEO URLs” for your products and categories using templates you can edit in the admin. You control the format.
• Sitemap. Shopware generates an XML sitemap of your products and categories and keeps it at https://yourdomain.com/sitemap.xml. You just submit it to Google.
• Canonical tags. For categories, Shopware picks the right main URL automatically when a product sits in more than one category.
• hreflang for languages. If you sell in multiple languages, Shopware can add the tags that tell Google which language version to show — built from your “sales channel” and domain setup.
• robots.txt (newer versions only). From Shopware 6.7.1.0 onward you can edit your robots.txt right in the admin.
• Structured data (newer versions only). From Shopware 6.7.9.0 onward Shopware can output modern JSON-LD “rich result” data for products.

What you still have to do yourself

• Fill in your titles and descriptions. Shopware gives you the fields; you write the copy. There’s no native way to bulk-set them by a pattern across thousands of products.
• Handle duplicate variant pages. Every product variant (each size, each color) gets its own URL, and their descriptions are often near-identical, so they can compete with each other. Shopware doesn’t fully fix this for you.
• Check your version. Because robots.txt and JSON-LD are recent additions, advice you read online may be out of date for your store — or ahead of it.

The thing most people get wrong

People assume that because Shopware “has good SEO,” everything is handled. Two catches trip up nearly everyone. First, changing a URL template doesn’t update your existing URLs until you rebuild Shopware’s SEO index — a step that’s easy to forget. Second, if you go “headless” (a modern Vue/Nuxt storefront), almost none of the admin SEO settings apply the same way — SEO becomes a job for your developer to build in the new frontend.

Want the practitioner version — the exact Twig templates, the variant-canonical fix, the sitemap strategies and CLI commands, the version gates, and the headless catch? Switch to the Advanced tab.

TL;DR — Shopware 6 ships more native technical SEO than most self-hosted platforms — but “native” is heavily version-gated. SEO URLs are Twig templates per entity type (product / category / landing page), configurable globally or per sales channel; change a template and you must rebuild the index (dal:refresh:index) or existing URLs won’t update. Canonical is a separate system from URL templates: automatic for categories, semi-manual for variants (you can point one variant at another as canonical, but not straight at the parent without a template override). The XML sitemap has three refresh strategies (scheduled / live / manual, with sitemap:generate for manual) and Shopware explicitly disclaims any indexing guarantee. robots.txt is nothing-automatic before 6.7.1.0 (manual file + server rewrite) and native per-domain admin editing after. Structured data just migrated from Microdata to JSON-LD in 6.7.9.0 behind the JSON_LD_DATA flag. hreflang comes from the Sales Channel > Domain model, with a cross-sales-channel gap that spawned paid plugins. And going headless (Composable Frontends, Vue + Nuxt) moves the whole SEO checklist into the Nuxt rendering layer.

The frame: native, version-gated, and where you still do the work

Most Shopware SEO content is either a screenshot walkthrough of the admin settings or a pitch from a Shopware agency. Neither tells you the two things that actually matter: what Shopware ships natively depends on your version, and the remaining gaps are specific and predictable. Sort every task into three buckets — native-and-current, native-only-if-you’re-on-a-recent-version, and still-your-job — and the platform stops being mysterious.

Shopware itself frames the native side generously: it says the platform “includes many SEO features out of the box – from country- and language-specific URLs to meta data, hreflang, and performance optimizations, allowing you to build strong SEO without additional plugins.” That’s largely true — with the version caveats below, and with a short list of things (bulk meta, variant canonicals, cross-channel hreflang, headless rendering) that still need plugins or code.

Because Shopware is self-hosted and open-source-core, it sits differently from the hosted platforms. Where Shopify forces /products/ and /collections/ prefixes and won’t let you natively edit robots.txt, and BigCommerce hands you an editable robots.txt and custom URL structures on a managed stack, Shopware gives you more control than any of them — you can override storefront templates directly — at the cost of owning more of the outcome, including your own hosting, indexing rebuilds, and (on headless) your own rendering pipeline. It’s closer in spirit to Magento or a self-hosted WooCommerce store than to Shopify.

URL structure: SEO URL templates

SEO URLs live at Settings > Shop > SEO, and they’re configurable per sales channel or globally. There are three separately-templated entity types — product detail pages, category pages, and landing pages — and the templates use Twig syntax. Shopware’s docs put it plainly: “In the SEO settings you can define the structure for the SEO URLs of the product detail pages and categories. For this purpose you have a variety of variables at your disposal.”

The mechanics worth knowing:

• The default product template is {{ product.name }}, and there are 50+ product variables available (product number, EAN, manufacturer name, breadcrumb/categories, custom fields, release date, and more).
• Multi-level variables must be typed by hand. Clicking the variable picker only inserts the incomplete parent token — {{ product.translated.name }} has to be finished manually.
• You can truncate long names. For a product name longer than, say, 50 characters, Shopware documents {{ product.translated.name[:50] }} to shorten it in the URL.
• The category default uses the breadcrumb: {% for part in category.seoBreadcrumb %}{{ part }}/{% endfor %}.
• Twig filters work for normalization — for example {{ product.translated.name|lower }}/{{ product.productNumber }} — and Shopware notes “in general you can use the available Twig filters.”
• Conditional (IF) logic handles missing fields; the docs give a variant-aware example using {% if product.canonicalProductId is not null %}.

The trap almost everyone hits: “After you have made changes to the SEO template, it is necessary to rebuild the index so that the URLs are updated. You can do this from the console using the command php bin/console dal:refresh:index.” Editing a template only affects newly generated URLs — existing products keep their old slugs until you rebuild. If you change the template and “nothing happened,” this is why.

Under the hood, SEO URLs live in a seo_url database table with a dual-URL concept: a technical path_info (the real route) and a human seo_path_info (the slug), plus sales_channel_id, language_id, is_canonical, and is_deleted/is_modified flags. Custom or dynamic SEO URL routes are added by developers via a SeoUrlRouteInterface implementation registered with the shopware.seo_url.route container tag. You don’t need this for a normal store, but it explains the scale behavior in the pitfalls section below.

Canonical tags

Canonicalization on Shopware is a separate mechanism from the URL templates — this is the single most misunderstood part of Shopware SEO. Shopware’s own docs even define the concept the way Google does: “A canonical URL is the URL of the page that the search engine assumes is the most representative of several duplicated pages on your site.”

Three things to keep straight:

• Categories are canonicalized automatically. When a product is reachable through multiple categories (and therefore multiple URLs), Shopware’s marketing describes it as detecting this and “automatically marks the correct URL, automatically preventing technical SEO issues.” Treat the marketing phrasing as a claim to confirm on your own store, but the automatic-category behavior is real.
• Variants are only semi-manual. Each variant gets its own SEO URL, and the built-in “Variant for Canonical URL” picker lets you nominate one variant as the canonical target. What it does not do is let you canonicalize a variant straight back to the parent product — a gap practitioners fix by overriding product-detail/meta.html.twig (or with a plugin) so variants canonicalize to the parent’s SEO URL when one exists. If your variant pages are near-duplicates competing with each other, this is the fix.
• There’s a global 301 behavior toggle. Under “Forwarding behavior,” Shopware can “output an HTTP 301 redirect when URLs are changed” rather than leaving old URLs live after a template edit — the setting that pairs with the dal:refresh:index rebuild above.

This maps directly onto Google’s own stance that canonicalization is a hint and that duplicate variant/parameter URLs are normal in ecommerce — the general mechanics are in canonicalization, which this article is the Shopware-specific companion to.

XML sitemap

The sitemap lives at Settings > Shop > Sitemap. Shopware “generates a standard sitemap that is compressed and cached in the file system,” and for large catalogs “the sitemap is divided into several files and can be generated in the background” — the multi-file split that keeps each file inside the sitemaps.org / Google limits of 50,000 URLs and 50 MB uncompressed.

There are three refresh strategies, and the difference matters:

1. scheduled — generated automatically on a scheduled task at a set interval.
2. live — created when none exists, and recreated once the refresh time elapses.
3. manually — automatic generation is off entirely; “the sitemap will only be created if you call the following command manually: php bin/console sitemap:generate. In this case, it is necessary to run this command again each time a new URL is added or an old one is removed.”

Two things people miss:

• The public URL is sitemap.xml, and there’s no human-facing /sitemap page. Shopware is explicit: “Shopware 6 does not provide a visitor sitemap (suffix /sitemap after your domain). The index file sitemap.xml is created for evaluation by Google.”
• A sitemap guarantees nothing. Shopware states outright that it “cannot guarantee that every URL will be crawled and indexed. This always depends on the search engine provider.” A sitemap is a discovery aid, not an indexing promise — same as on every other platform.

Adding or excluding custom URLs (beyond products/categories) isn’t an admin toggle — it’s developer work via custom UrlProvider classes, documented in Shopware’s developer sitemap guides.

robots.txt — check your version first

This is the most version-sensitive part of Shopware SEO, so date-stamp it before you advise anyone.

• Before 6.7.1.0 (most older installs): nothing is generated automatically. Shopware’s docs say “the robots file is not created automatically in Shopware 6, but has to be created manually as a text file” placed in /public/. For multi-domain setups you serve a per-domain file with a server rewrite — Apache RewriteRule ^robots\.txt$ robots/%{HTTP_HOST}.txt [NS] or the NGINX equivalent rewrite ^/robots\.txt$ /robots/$host.txt — pointing at a /public/robots/<domain>.txt structure.
• From 6.7.1.0 onward (July 2025 release): native per-domain robots.txt management shipped in the admin — you “can define individual robots.txt rules for each domain in the Admin under Settings > General > Basic information.” This started as a Hacktoberfest 2024 community contribution.

So the myth “Shopware doesn’t let you edit robots.txt” is only true pre-6.7.1.0. Confirm the store’s version before telling someone to “just edit it in the admin” — older stores still need the manual-file-plus-rewrite approach. The admin field (“Rules for robots.txt” under Settings > General > Basic information) is a free-text area merged straight into that domain’s robots.txt, so it accepts full User-agent: / Allow: / Disallow: blocks, not just flat rules — confirmed both in Shopware’s current docs and in a 6.7.10.0 fix (avoid duplicate robots.txt directives for user-agent blocks) that specifically reproduces the bug using per-user-agent blocks in that field.

Structured data: the Microdata → JSON-LD migration

Shopware went through a real architecture shift here in 6.7.9.0: the storefront moved from scattered inline Microdata to JSON-LD emitted as a <script type="application/ld+json"> block in the <head>. It’s behind a feature flag, JSON_LD_DATA, and is off by default — with the flag on, JSON-LD is injected and the old Microdata is removed. The Microdata is deprecated and slated for removal in 6.8.0.0.

Once you flip the flag, the JSON-LD output is substantially richer than the old Microdata:

• Product — all product images, VideoObject for product videos, AggregateRating with ratingCount, up to the 10 most recent Review items, OfferShippingDetails/ShippingDeliveryTime for single-price products, Dimensions as QuantitativeValue, itemCondition, typed seller info, and gtin13 (EAN) / mpn when present.
• WebSite with SearchAction (enables Google’s Sitelinks search box).
• Top-level Organization (shop logo).
• ItemList on category / search-result pages, plus BreadcrumbList.

Each schema type lives in its own overridable Twig template under storefront/layout/structured-data/. The same 6.7.9.0 release also added per-product Open Graph fields in the admin SEO tab — custom og:title, og:description, and og:image, defaulting to the product’s meta title/description/cover image when unset — so social shares and some search-result previews can now diverge intentionally from the meta tags without a plugin.

The practical takeaway: this is a myth-buster. Plenty of practitioner posts and paid Store extensions (“JSON-LD Rich Snippets for product pages”) predate the native feature. If you’re on 6.7.9.0+, check whether you still need that plugin before buying it — and if you’re on an older version, that’s exactly when a plugin still earns its keep. Google’s Product structured data guidelines are the spec this output targets, and Google requires structured data to reflect visible page content — so fill the fields you want in the markup.

International SEO: hreflang via Sales Channel + Domain

Shopware doesn’t have a standalone hreflang editor. hreflang is derived from the Sales Channel > Domain model: each sales channel can have multiple domains, and each domain maps to one language, one currency, a snippet set, and a unit system — set up with its “own virtual URL, language, currency, snippet set and its own unit system.”

Two settings do the SEO work:

• A localization mode dropdown with two options: ISO standard, “useful, for example, if you use different (country-specific) language variants that may use their own country-specific terms,” which produces full region-language codes like en-US vs en-GB; and browser language localization, which is language-only (plain en). Use ISO standard when you genuinely have regional variants.
• A default domain that, after you enable the hreflang meta tag, “will serve as a fallback for all languages” — Shopware’s version of Google’s x-default.

The known weak spot: this works within a single sales channel’s domains, but cross-sales-channel hreflang — separate sales channels per country/TLD running near-duplicate catalogs — is not natively linked. That gap is exactly what paid “Hreflang Manager” store extensions exist to solve. I’d treat the cross-channel gap as a strong community/marketplace signal rather than a documented Shopware limitation, but it’s a recurring pain point on the forums.

One thing Shopware’s own docs don’t spell out that Google requires: hreflang must be bidirectional (return tags) and include an x-default. If you’re new to the return-tag requirement, the general mechanics are in hreflang — Shopware’s default-domain setting handles the x-default side, but you still want to verify the return tags resolve.

Headless: Composable Frontends (Shopware Frontends)

Shopware’s headless option is “Shopware Frontends” (formerly “Composable Frontends” / “PWA”) — a Vue.js + Nuxt toolkit that consumes the Shopware Store API, distinct from the default Twig/Symfony storefront. It ships a component library, an API client, reusable “composables,” and generated TypeScript types; the reference “Vue Demo Store” is built on Nuxt + Tailwind.

Here’s the part every other guide skips: going headless moves essentially all SEO responsibility into the Nuxt layer, and none of the admin SEO settings apply the same way. The SEO URL templates, the canonical settings, the sitemap admin toggle, and the new robots.txt admin panel are all Symfony-storefront (Twig) features. A Composable Frontends build needs its own:

• Rendering mode that produces crawlable HTML — Nuxt SSR (or hybrid / ISR / edge rendering) for SEO-relevant pages. A pure client-side-rendered (SPA) build reintroduces the classic JavaScript-rendering SEO risk, so headless is not automatically better for SEO — a badly configured headless storefront can be worse than the default Twig one.
• Sitemap generation, canonical tags, structured data, and meta-tag injection implemented in the Nuxt app (typically via Nuxt’s head/SEO-meta composables), usually still pulling slugs and product data from the same Shopware SEO URL / Store API data.

So the myth “going headless with Shopware fixes/improves SEO” is false as stated. SEO outcome depends entirely on how you configure rendering in Nuxt. This is the same trap as any headless build — the platform-agnostic version lives in JavaScript SEO and headless CMS SEO.

Common pitfalls at scale

The practitioner pain points cluster in three places:

• Default misconfigurations. Practitioner audits flag that “Remove Category ID from URL” ships set to No by default (worth enabling for cleaner URLs), that pagination signals are off by default, and that blog/archive pagination pages are worth noindex-ing because they “add no value; they only take up crawl budget.” One widely repeated claim — that Shopware auto-adds nofollow to all external links — I’d verify against a real install before repeating; it wasn’t confirmed against Shopware’s own docs.
• Product-variant duplicate content. This is the single most recurring Shopware SEO complaint. Each variant gets its own URL (/SW10000.1, /SW10000.2, …) with inherited, near-identical descriptions, so variants compete unless you canonicalize them — and, per the canonical section above, the built-in picker can’t point straight at the parent without a template override.
• seo_url table growth on large multilingual catalogs. Row count roughly follows (parent + active variants) × number of languages — a practitioner deep dive puts a 9-variant product across 17 languages at ~153 rows for a single product family. Frequent template edits multiply history rows further. At scale the fixes are: generate SEO URLs for parent products only (not every variant), prune soft-deleted / non-canonical rows periodically, and add composite indexes. This is why a large Shopware store can feel slow and accumulate odd duplicate SEO URLs.

When native tools are enough vs. when you need a plugin or dev work

The rough threshold echoed across practitioner sources: native tools are enough for small, simple catalogs (on the order of a few hundred products), and plugins or custom development become necessary at meaningful scale — thousands of SKUs, deep variant matrices, many languages, or cross-sales-channel international setups. Concretely, reach for a plugin or code when you need bulk title/meta patterns, canonical-to-parent for variants, cross-sales-channel hreflang, custom sitemap entries, or JSON-LD on a pre-6.7.9.0 version. Everything else — SEO URL templates, category canonicals, the sitemap, single-channel multi-domain hreflang, and (on current versions) robots.txt and JSON-LD — is native.

Shopware vs the hosted platforms — the honest version

All of them rank fine. Shopware’s genuine advantage is control — Twig-templated URLs, overridable storefront templates, and a large native feature set that keeps growing by version. Its genuine cost is that you own more of the pipeline: your hosting, your index rebuilds, your version awareness, and — if you go headless — your entire rendering and SEO-tag layer. Like Magento and self-hosted WooCommerce, and unlike Shopify or PrestaShop’s simpler defaults, that trade favors teams with development capacity.

AI summary

A condensed take on the Advanced version:

• Shopware 6 is a self-hosted, open-source-core ecommerce platform (Symfony/PHP + Vue.js storefront) with a large native SEO feature set — more control than Shopify or BigCommerce, but you own more of the pipeline.
• “Native” is version-gated. Per-domain robots.txt only from 6.7.1.0 (the admin field is free text, so User-agent: blocks work, not just flat rules); JSON-LD structured data (replacing Microdata) and per-product Open Graph fields only from 6.7.9.0, behind the JSON_LD_DATA flag for JSON-LD (Microdata sunsets in 6.8.0.0). Always check the store’s version before advising.
• SEO URLs are Twig templates per entity type (product / category / landing page) at Settings > Shop > SEO. Change a template → rebuild the index (php bin/console dal:refresh:index) or existing URLs won’t update.
• Canonical is a separate system: automatic for categories; for variants you can nominate one variant as canonical but can’t point straight at the parent without overriding product-detail/meta.html.twig. A global “Forwarding behavior” toggle emits 301s on URL change.
• Sitemap: three strategies (scheduled / live / manual, with php bin/console sitemap:generate); public URL sitemap.xml; no human /sitemap page; Shopware disclaims any indexing guarantee.
• hreflang comes from the Sales Channel > Domain model (one domain = one language/currency), with an ISO-standard vs browser-language toggle and a default domain as x-default. Cross-sales-channel hreflang isn’t natively linked — the gap paid plugins fill.
• Headless (Composable Frontends, Vue + Nuxt) moves the entire SEO checklist (sitemap, canonical, meta, structured data) into the Nuxt rendering layer — admin SEO settings don’t apply, and a poorly configured headless build can be worse for SEO.
• Scale pitfalls: variant duplicate content, seo_url table growth (~variants × languages), and default misconfigurations (category ID in URL, pagination signals). Native tools suffice for small catalogs; plugins/dev work for scale.

Official documentation

Primary-source docs from Shopware and Google.

Shopware

• SEO settings (SEO URL templates, canonical, forwarding behavior) — the core admin SEO page; Twig variables, truncation, filters, and the dal:refresh:index rebuild note.
• Sitemap settings — the three refresh strategies, sitemap:generate, the sitemap.xml URL, and the no-indexing-guarantee disclaimer.
• Sales channel (domains / hreflang) — the Sales Channel > Domain model, hreflang localization modes, and the default-domain fallback.
• Creation of robots.txt (legacy / manual method) — the pre-6.7.1.0 manual file + server-rewrite approach.
• Add Custom SEO URLs (developer) — the seo_url table, SeoUrlRouteInterface, and the shopware.seo_url.route container tag.
• Sitemap plugin guide (developer) — custom UrlProvider classes for adding/removing sitemap entries.
• Release notes 6.7.1.0 (native robots.txt) — the version that added per-domain robots.txt in the admin.
• Release notes 6.7.9.0 (JSON-LD structured data) — the Microdata → JSON-LD migration, the JSON_LD_DATA flag, and the schema types.
• Shopware Frontends (headless docs) and the Nuxt module — the Vue + Nuxt Composable Frontends toolkit.
• SEO in Shopware (marketing overview) — Shopware’s own summary of native SEO features.

Google

• Product structured data — required/recommended Product fields the JSON-LD output targets.
• Structured data intro — why JSON-LD is recommended over microdata.
• URL canonicalization — the “hint, not a rule” framing behind Shopware’s canonical handling.
• Managing multi-regional and multilingual sites (hreflang) — the bidirectional return-tag and x-default requirements Shopware’s default-domain setting maps onto.

Quotes from the source

On-the-record statements from Shopware’s own documentation and marketing. Each link deep-links to the quoted passage on the source page.

Shopware — SEO URL templates (docs)

• “In the SEO settings you can define the structure for the SEO URLs of the product detail pages and categories. For this purpose you have a variety of variables at your disposal.” Jump to quote
• “After you have made changes to the SEO template, it is necessary to rebuild the index so that the URLs are updated. You can do this from the console using the command php bin/console dal:refresh:index.” Jump to quote

Shopware — canonical (docs)

• “A canonical URL is the URL of the page that the search engine assumes is the most representative of several duplicated pages on your site.” Jump to quote

Shopware — sitemap (docs)

• “Shopware 6 does not provide a visitor sitemap (suffix /sitemap after your domain). The index file sitemap.xml is created for evaluation by Google.” Jump to quote
• “Shopware cannot guarantee that every URL will be crawled and indexed. This always depends on the search engine provider.” Jump to quote
• On manual mode: “the sitemap will only be created if you call the following command manually: php bin/console sitemap:generate.” Jump to quote

Shopware — robots.txt (docs)

• “The robots file is not created automatically in Shopware 6, but has to be created manually as a text file.” (Legacy / pre-6.7.1.0 method.) Source

Shopware — native SEO (marketing)

• “Shopware includes many SEO features out of the box – from country- and language-specific URLs to meta data, hreflang, and performance optimizations, allowing you to build strong SEO without additional plugins.” Source

Shopware-specific SEO audit checklist

A pass tuned to Shopware’s actual mechanics — not a generic ecommerce list.

Version check (do this first)

• Note the exact Shopware version — it decides what’s native.
• robots.txt: on 6.7.1.0+ manage it per-domain in Settings > General > Basic information; on older versions confirm a manual /public/robots.txt (with a per-domain server rewrite if multi-domain).
• Structured data: on 6.7.9.0+ decide whether to enable the JSON_LD_DATA flag; on older versions confirm whether a JSON-LD plugin is still needed.

URL structure

• SEO URL templates set per entity type (product / category / landing) at Settings > Shop > SEO; deliberate, not the bare default.
• Index rebuilt after any template change (php bin/console dal:refresh:index) so existing URLs actually update.
• “Remove Category ID from URL” reviewed (ships set to No by default).
• “Forwarding behavior” set so URL changes emit a 301 rather than leaving old URLs live.

Canonical & variants

• Category canonicalization confirmed correct (automatic, but verify).
• Variant duplicate content handled — either “Variant for Canonical URL” set, or a product-detail/meta.html.twig override / plugin canonicalizing variants to the parent.

Sitemap

• Refresh strategy chosen deliberately (scheduled / live / manual); if manual, php bin/console sitemap:generate runs whenever URLs change.
• sitemap.xml submitted in Google Search Console and Bing Webmaster Tools.

International (multi-language / multi-domain)

• hreflang enabled with the right localization mode (ISO standard for regional variants; browser-language otherwise).
• Default domain set as the x-default fallback.
• Return tags verified as bidirectional; cross-sales-channel setups checked for the native linking gap (plugin if needed).

Scale & performance

• Large multilingual catalogs: SEO URLs generated for parents only where possible; soft-deleted / non-canonical seo_url rows pruned; composite indexes considered.
• Blog/archive pagination pages noindexed where they add no value.

Headless (Composable Frontends only)

• Nuxt rendering mode produces crawlable HTML (SSR / hybrid / ISR, not pure CSR).
• Sitemap, canonical, meta tags, and structured data implemented in the Nuxt app (admin SEO settings do not carry over).

The mental models

1. Three buckets, not two — because of versions. Sort every Shopware SEO task into native-and-current, native-only-on-a-recent-version (robots.txt ≥ 6.7.1.0, JSON-LD ≥ 6.7.9.0), or still-your-job (bulk meta, variant→parent canonical, cross-channel hreflang, headless rendering). On Shopware the version bucket is the one that catches people out — always check the version before you trust a tip.

2. Templates generate, the index publishes. Editing an SEO URL template changes future URLs only. Nothing is live until you rebuild (dal:refresh:index). Whenever “the template change didn’t work,” this is the first thing to check.

3. Canonical is a separate system from URLs. Don’t reason about Shopware canonicals through the URL templates — they’re unrelated mechanisms. Categories canonicalize automatically; variants are semi-manual and can’t reach the parent without a template override. Keep the two systems separate in your head.

4. hreflang lives in the domain model. There’s no hreflang editor — it’s a consequence of how you structure Sales Channels and Domains. One domain = one language/currency; the default domain is your x-default. If hreflang is wrong, look at the domain setup, not a hreflang field.

5. Headless resets the whole checklist. The moment you go Composable Frontends, the admin SEO settings stop being the source of truth — sitemap, canonical, meta, and structured data all move into Nuxt. Headless isn’t “the same SEO checklist, faster”; it’s a different checklist owned by your frontend.

Shopware SEO cheat sheet

Where things live in the admin

Version gates

CLI commands

Sitemap strategies

Don’ts

• Don’t change a URL template and expect existing URLs to update without a rebuild.
• Don’t assume “Variant for Canonical URL” points variants at the parent — it doesn’t.
• Don’t advise “edit robots.txt in the admin” without checking for 6.7.1.0+.
• Don’t buy a JSON-LD plugin on 6.7.9.0+ before checking the native flag.
• Don’t assume headless (Composable Frontends) inherits the admin SEO settings.

Shopware SEO mistakes to avoid

Editing an SEO URL template without rebuilding the index

Why it’s wrong: Existing URLs keep their old generated values, so the admin change appears to have done nothing. Do this instead: run php bin/console dal:refresh:index, then crawl old and new product URLs and confirm the forwarding behavior.

Assuming Variant for Canonical URL points to the parent

Why it’s wrong: The native picker nominates another variant, not the parent product. Near-identical variants can therefore remain split across URLs. Do this instead: use a product-detail/meta.html.twig override or a suitable plugin when the parent product is the intended canonical.

Giving version-blind robots.txt advice

Why it’s wrong: Admin-based per-domain robots.txt management starts at 6.7.1.0; older stores require a file and server rewrite. Do this instead: record the exact Shopware version before choosing the implementation path.

Buying a JSON-LD plugin before checking the native feature

Why it’s wrong: Shopware 6.7.9.0 introduced native JSON-LD behind the JSON_LD_DATA flag. A second source can duplicate or conflict with markup you already have. Do this instead: check the version and flag, validate the current output, then fill only genuine gaps.

Expecting admin SEO settings to carry into a headless storefront

Why it’s wrong: Composable Frontends moves rendering, metadata, canonicals, sitemaps, and structured data into Nuxt. Do this instead: treat headless as a new frontend SEO implementation and verify its server response independently.

Prove an SEO URL template change took effect

Rebuild and inspect representative URLs

Test to run: After saving the template, run php bin/console dal:refresh:index, then open representative product, category, and landing-page URLs covered by the change.

Expected result: Existing entities use the new SEO URL pattern rather than only newly created items receiving it.

Failure interpretation: The index rebuild did not complete, the wrong sales channel template was changed, or the route is using a different entity template.

Monitoring window: Immediate after the index command finishes and caches are refreshed.

Rollback trigger: Restore the previous template and rebuild again if the new pattern creates collisions, missing routes, or malformed paths.

Confirm old URLs preserve their destination

Test to run: Request a sample of the previous SEO URLs after the rebuild and inspect the HTTP status and Location header.

Expected result: Each changed old URL returns the configured permanent redirect to the matching new canonical URL.

Failure interpretation: Forwarding behavior is disabled, the old route was not retained, or two URL rules conflict.

Monitoring window: Immediate after deployment; repeat after cache invalidation.

Rollback trigger: Roll back if important old URLs return 404, loop, chain, or redirect to the wrong product or category.

Verify canonical and sitemap agreement

Test to run: Inspect the new page’s canonical tag and locate the entity in sitemap.xml after the sitemap refresh strategy has run.

Expected result: Both signals name the same new SEO URL.

Failure interpretation: Canonical configuration, sitemap generation, and the URL index are out of sync.

Monitoring window: Immediate for the canonical; after the scheduled, live, or manual sitemap regeneration for sitemap output.

Rollback trigger: Roll back the URL release if canonical pages point at old or missing destinations after regeneration.

Tools for Shopware SEO

• Shopware Console (bin/console) — the two commands that actually run Shopware SEO: dal:refresh:index (rebuild SEO URLs after a template change) and sitemap:generate (manual sitemap builds).
• Google Search Console — sitemap submission, URL Inspection (verify the canonical Google chose, and how variant pages render), and the International Targeting / hreflang view. Your ground truth for what Google actually does.
• Bing Webmaster Tools — second sitemap submission, crawl control, and site scan.
• Screaming Frog / Ahrefs Site Audit — crawl the store to catch the variant-URL explosion, seo_url duplicates at scale, redirect behavior after template changes, and pages the sitemap misses. This is how you find the Shopware-specific gaps.
• Rich Results Test / Schema Markup Validator — confirm the 6.7.9.0 JSON-LD output is valid and matches visible content once you enable the JSON_LD_DATA flag.
• Shopware Store extensions — where the native gaps get filled: cross-sales-channel hreflang managers, bulk meta / SEO URL managers, advanced sitemap providers, and (on pre-6.7.9.0 stores) JSON-LD rich-snippet plugins.
• Storefront template overrides — for the variant-canonical fix, override product-detail/meta.html.twig rather than reaching for a plugin if you have dev capacity.

Resources worth your time

On-site, related

• Canonicalization — the platform-agnostic mechanics behind Shopware’s category-automatic / variant-manual canonical behavior.
• hreflang — the bidirectional return-tag and x-default requirements Shopware’s Sales Channel / default-domain model maps onto.
• JavaScript SEO and headless CMS SEO — why a Composable Frontends (Nuxt) build needs its own SSR/rendering discipline.

Shopware official

• SEO settings, Sitemap settings, and Sales channel / domains.
• Release notes 6.7.1.0 (robots.txt) and 6.7.9.0 (JSON-LD).
• Shopware Frontends (headless).

From around the industry

• Conductor Academy — Shopware SEO best practices — practitioner checklist of default-setting gotchas (category ID in URL, pagination signals, blog pagination noindex).
• BrocksiNet — Deep dive into Shopware SEO URLs — the seo_url table internals and the variants × languages growth math.
• EXWE — SEO optimization in Shopware 6: canonicals for product variants — the variant-canonical problem and the template-override fix.
• elgentos — shopware-seo-canonical-url (GitHub) — an open-source plugin for canonicalizing variants back to the parent.
• Qualimero — Shopware SEO guides — current EU/German-market Shopware SEO and AI-readiness coverage.
• Kickbyte — Shopware Frontends: headless storefront with Nuxt — how the Nuxt layer shapes headless SEO.
• Shopware — SEO in Shopware (marketing overview) — the vendor’s own summary of native SEO features.

Test yourself: Shopware SEO

Five quick questions on how SEO works on Shopware 6. Pick an answer for each, then check.

Shopware SEO

Shopware SEO is the technical, on-page, and international work you do on a store built on Shopware 6 — a German-built, open-source-core ecommerce platform (Symfony/PHP + Vue.js storefront) that ships a large amount of native SEO out of the box (Twig-templated SEO URLs, canonical handling, XML sitemaps, hreflang via its Sales Channel/Domain model, and — in recent versions — native robots.txt and JSON-LD structured data), while still leaving bulk meta management, variant-canonical edge cases, cross-sales-channel hreflang, and headless (Composable Frontends) rendering to you.

Related: Canonicalization, Hreflang, Faceted Navigation

Shopware SEO

Shopware is an open-source-core ecommerce platform built in Germany. Shopware 6 — the current major version — runs on Symfony 6 / PHP with a Vue.js-capable storefront and a headless-capable “Composable Frontends” architecture. Unlike a hosted SaaS platform such as Shopify or BigCommerce, Shopware is typically self-hosted (or run on Shopware’s own cloud), which puts more of the infrastructure — and more of the SEO levers — in your hands.

“Shopware SEO” is the regular crawl → index → rank work applied to a Shopware store, plus the platform-specific mechanics that make Shopware different. The core controls are native: SEO URLs are Twig-templated per entity type (product, category, landing page) at Settings > Shop > SEO; canonical handling is a separate mechanism (automatic for categories, semi-manual for product variants); XML sitemaps generate on three strategies (scheduled/live/manual); and hreflang is derived from the Sales Channel > Domain model rather than a standalone hreflang editor.

What varies most on Shopware is version. Native per-domain robots.txt management only arrived in 6.7.1.0 (July 2025); native JSON-LD structured data (replacing legacy Microdata) arrived in 6.7.9.0 behind the JSON_LD_DATA feature flag. Where Shopware still leaves work to you: bulk title/meta patterns at scale, canonicalizing product variants back to the parent, cross-sales-channel hreflang, and — for a headless build — reimplementing sitemap, canonical, and meta-tag handling in the Nuxt layer, since none of the Twig-storefront admin SEO settings apply the same way.

Related: Canonicalization, Hreflang, Faceted Navigation

Changelog