SEO URLs in Shopware: plan templates, protect your URLs

The SEO URL templates in Shopware determine which parts make up the address of every product page, every category and every landing page. They are often set up when the shop launches and rarely touched afterward. That works well until someone changes a template: once the index is rebuilt, every affected page gets a new address in one go. This guide shows which variables are suitable for lasting URLs, how length, letter case, variants and category paths interact, and how a change can be carried out without visitors and search engines landing on dead URLs. It is based on the Shopware documentation, the Shopware source code and the recommendations of Google Search Central. If you would like the templates reviewed as part of technical SEO support, you will find an overview of how we approach this at the end.

What an SEO URL template in Shopware defines

The templates are located in the Administration under the settings in the SEO section. There are three fields there: one for the product detail page, one for the landing page and one for the category page (Shopware documentation). By selecting the sales channel, you decide whether a template applies to all sales channels or only to a specific one (Shopware documentation). The variables are written in double curly braces, for example {{ product.translated.name }}, because the templates use the Twig template language.

Note that the variables must be specified in Twig format.

Shopware documentation, SEO settings

Next to each field, the Administration shows whether the variables can be resolved: a green tick for correct variables, a red X for at least one variable that cannot be resolved, in which case the setting can only be saved after a correction (Shopware documentation). The tick says nothing about the consequences for existing URLs.

Out of the box, Shopware uses the template {{ product.translated.name }}/{{ product.productNumber }} for products, the category path via {% for part in category.seoBreadcrumb %}{{ part }}/{% endfor %} for categories, and the address maintained in the landing page via {{ landingPage.translated.url }} (Shopware source code).

Before an address is stored, Shopware passes every output value through a slug function and encodes it for the URL (Shopware source code). Exactly which characters result depends on the configuration of the installation; looking at a few real product URLs of the shop shows it fastest.

Why a template change affects the entire catalog

Shopware does not generate the URLs when a page is requested. It writes them into the seo_url table: one row per page, language and sales channel with the readable path and a flag that marks which address is currently valid (Shopware source code). After a template change, the documentation states that the index has to be rebuilt so that the URLs are updated (Shopware documentation). This run recalculates the URLs of all pages the template applies to.

If the template produces a different path for a page than before, Shopware creates a new row as the valid address and removes the flag from the old row (Shopware source code). The old row stays in the table, so Shopware still knows which page an old URL belongs to. What happens the next time that URL is requested is controlled by a setting described further below.

For search engines, such a change is a move within the same domain. Google explicitly counts changed paths among site moves with URL changes and expects ranking fluctuations with larger changes while the pages are recrawled and reindexed (Google Search Central). According to Google, a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer (Google Search Central). A template change is therefore not a quick task in between, but a small migration project.

Choosing variables: stable, unique, readable

The documentation lists a long series of variables for products. For the other available variables, Shopware gives a clear warning: they provide content that leads to regular changes of the URL, and this has a negative influence on the ranking (Shopware documentation). For landing pages and categories, Shopware explicitly recommends not using such variables (Shopware documentation). The choice therefore follows one question: does this value only change when someone changes it on purpose?

Google also recommends using words in the language of your audience in the URL, so German words for a German-speaking audience (Google Search Central). product.translated.name does this because Shopware generates URLs per language and inserts the translated name. If you want to put an optional value such as the manufacturer in front, secure it so that products without a manufacturer still get a clean path:

{# Default setting #}
{{ product.translated.name }}/{{ product.productNumber }}

{# Manufacturer in front, only if present #}
{% if product.manufacturer is not null %}{{ product.manufacturer.name }}/{% endif %}{{ product.translated.name }}/{{ product.productNumber }}

Length, letter case and separators

Long product names create long URLs. The documentation shows a way to shorten them: if a product name is longer than, for example, 50 characters, it can be shortened in the URL with {{ product.translated.name[:50] }} (Shopware documentation). The square brackets are the shorthand for the Twig filter slice, which works with the PHP function mb_substr for strings (Twig documentation).

The cut therefore counts characters, not words. A name with a word running across position 50 ends in the URL with a word stump. If you shorten, look at the longest product names first and choose the limit so that the URLs remain readable. The product number at the end keeps the URL unique, even when several names start the same way.

A second topic is letter case. If you want URLs in lowercase throughout, the documentation suggests the Twig filter lower, and for categories inside the loop as {{ part|lower }} (Shopware documentation). This is more than cosmetics: Google treats URLs as case sensitive and handles /APPLE and /apple as two distinct URLs with their own content (Google Search Central). Shopware, by contrast, compares paths in seo_url without regard to letter case (Shopware source code). If a template only changes the letter case, Shopware overwrites the existing row, and the old spelling keeps serving the page without a 301 redirect (Shopware source code). For servers that treat both cases the same, Google advises converting all text to the same case (Google Search Central). When testing the old URLs, expect no redirect here.

{# Product: name shortened, all lowercase #}
{{ product.translated.name[:50]|lower }}/{{ product.productNumber|lower }}

{# Category: path in lowercase #}
{% for part in category.seoBreadcrumb %}{{ part|lower }}/{% endfor %}

For separators, Google recommends hyphens instead of underscores because hyphens clearly signal a word boundary (Google Search Central). Your own separators between variables should therefore be a hyphen or a slash. A slash in the template itself is kept, because Shopware only passes the output values through the slug function (Shopware source code).

Variants, main category and category paths

In Shopware, variants are products of their own and receive their own URLs during indexing; the SEO URL update also covers the variants of a parent product (Shopware source code). With the product number in the template, every variant gets a unique URL. Whether all of these URLs should be indexed is a separate decision: in the SEO section of a product with variants, you can specify that all variants use the same canonical URL and select which variant provides it (Shopware documentation). Our article on product variant SEO describes the trade-offs behind this.

If you include the category path in the product URL, you need to know which category is meant. The documentation shows a breadcrumb expression that sorts the product's categories by position and takes the first one (Shopware documentation). If a product is assigned to several categories, a main category can also be set per sales channel in the product's SEO section (Shopware documentation). Without a clear rule as to which category determines the URL, the product URL can shift whenever the category tree is re-sorted.

For category pages, Shopware uses the breadcrumb, meaning the category structure, by default (Shopware documentation). This produces descriptive URLs that grow longer with each level and depend on the names of all parent categories: if someone renames a top-level category, the URLs of the entire branch change. For products, the documentation shows an example that skips the first category via |slice(1), for instance if it only serves as an entry point (Shopware documentation). How seasonal categories without a year in their name keep their URL at the turn of the year is described in our article on the year in page titles and URLs.

• How often are categories renamed or moved during day-to-day operations?
• Are products assigned to several categories, and is a main category maintained for each of these products?
• How deep is the tree, and how long do the URLs on the lowest level become?
• Are there filter or campaign categories that do not belong in a lasting URL? For filter URLs, see our article on faceted navigation.

What Shopware does with old URLs

When someone requests a URL that is no longer marked as valid, Shopware still finds the matching page via the seo_url table and determines its current URL (Shopware source code). What happens next is controlled by an option in the SEO settings that redirects changed URLs to the most recent URL via HTTP 301 instead of relying on canonical URLs. According to the documentation, it allows an HTTP 301 redirect to be sent when URLs have changed; if it is disabled, the browser receives no indication of a redirect (Shopware documentation).

Google rates both approaches as a strong signal for the preferred URL; in Google's order, the redirect comes before the canonical tag (Google Search Central). If a URL is to be replaced permanently by another one in search results, Google recommends a permanent server-side redirect; the status codes 301 and 308 mean that a page has permanently moved to a new location (Google Search Central). Under the HTTP standard, 301 indicates that the resource has been assigned a new permanent URI and that future references ought to use one of the new URIs (RFC 9110). This is exactly what applies to a URL replaced by a template change; we therefore recommend checking the option beforehand and, as a rule, enabling it.

A template change step by step

Technically, a template change is a single line in the Administration. The actual work lies before and after it. The following order has proven effective:

1. Back up the inventory. Export all currently valid URLs with page type, language and sales channel from seo_url. This list is the basis for the comparison and for the tests afterward.
2. Change it in a test environment. Adjust the template on a copy of the shop, rebuild the index and export the new URLs. Such a copy should work without real customer data, as described in our article on the Shopware staging environment.
3. Compare old and new. Join both lists by page, language and sales channel. Duplicate paths, empty segments, cut-off words and unintentionally long URLs show up here, not only in the live shop.
4. Enable the redirect. Check and enable the option that redirects changed URLs via HTTP 301 in the live shop before the first URL changes.
5. Change the template and rebuild the index. Set the template globally or per sales channel and rebuild the index; only this run updates the URLs (Shopware documentation).
6. Test the old URLs. Request the backed-up URLs and check that each one answers with a 301 to the new URL of the same page.
7. Sitemap and Search Console. Regenerate the sitemap, submit it in Search Console and then watch the page indexing report.

-- Currently valid URLs per page, language and sales channel
SELECT
  route_name,
  LOWER(HEX(foreign_key))      AS page_id,
  LOWER(HEX(language_id))      AS language_id,
  LOWER(HEX(sales_channel_id)) AS sales_channel_id,
  seo_path_info,
  is_modified
FROM seo_url
WHERE is_canonical = 1
  AND is_deleted = 0
ORDER BY route_name, seo_path_info;

The command dal:refresh:index rebuilds the index; the documentation names it explicitly for the case of a changed template (Shopware documentation). The --only option restricts the run to individual indexers (Shopware source code). The SEO URLs of products, categories and landing pages are created when their indexers run (Shopware source code). For large catalogs, the run belongs in a quiet time window. For site moves, Google recommends timing them to coincide with lower traffic where possible anyway (Google Search Central).

Depending on the strategy, Shopware generates the sitemap on a schedule, live or only on command; with manual generation, sitemap:generate has to be run again after every change to the URLs (Shopware documentation). Submitting the new sitemap helps Google learn about the new URLs (Google Search Central).

After the switch: test and monitor

The comparison with the backed-up list shows whether the switch worked. Every old URL should answer with a redirect to exactly the new URL of the same page, not to the home page and not to a category. Google warns against redirecting many old URLs to a single irrelevant destination such as the home page; this can confuse users and might be treated as a soft 404 error (Google Search Central). For a spot check, requesting the headers is enough:

Redirect chains usually do not arise within Shopware itself. An old URL leads directly to the currently valid one, even if the template has been changed several times, because Shopware determines the current URL of the same page for every old row (Shopware source code). Chains arise where rules in the web server or from an earlier migration also apply and point to a URL that has since been replaced itself. Googlebot follows up to 10 redirects in a chain, but Google advises redirecting to the final destination directly (Google Search Central). Where that is not possible, there should ideally be no more than 3 and fewer than 5 redirects (Google Search Central). Redirect rules from earlier migrations therefore need a review as well, for example from a switch from WooCommerce to Shopware.

The redirects should stay in place for as long as possible; as a guideline, Google names generally at least one year so that all signals can transfer to the new URLs (Google Search Central). For Shopware, this means in practice: leave the old rows in seo_url and keep the option enabled.

In Search Console, the old URLs gradually appear in the page indexing report as pages with redirect. This is intended: such a URL redirects to another page and is therefore not indexed (Search Console Help). Old URLs that answer with a 404, on the other hand, are critical. For pages that have moved, Google recommends a 301 redirect to the new location (Search Console Help). Our article on crawled but not indexed shop pages shows how to classify pages that are crawled but not indexed.

• A sample of old product, category and landing page URLs per language and sales channel answers with a 301 to the new URL
• No old URL ends in a 404 or on the home page
• The canonical tag of the new pages points to the new URL
• The sitemap contains the new URLs
• Hard-coded links in shopping experiences, descriptions, newsletters and ads are updated
• Product feeds and exports output the new URLs

Links that Shopware generates itself, for example in the menu, follow the new URL after the rebuild; hard-coded URLs do not. Google recommends updating your own links because redirects are slow for users (Google Search Central). If you are reworking the product feed anyway, for example for questions and answers in Merchant Center, check the URLs in the same round.

Multiple sales channels and languages

In shops with several sales channels, each template can be set globally or per sales channel (Shopware documentation). This increases the number of places where URLs can change. An overview of which template applies in which channel therefore belongs in the shop's documentation. Our article on Shopware multistore setups describes how several shops work together in one installation.

Each language gets its own URL because Shopware stores URLs per language (Shopware source code). Translated names in the template result in translated URLs, which matches Google's recommendation on the audience's language (Google Search Central). One thing is easily overlooked: adding translations later changes the URLs of the affected language. That is also a URL change for which the redirect option should be enabled.

When a change is worth it

Not every unattractive URL justifies a switch. The following overview classifies typical starting points:

Once the decision for a change has been made, it should not coincide with other major changes. For site moves, Google advises changing one thing at a time rather than everything at once (Google Search Central). If you are planning an update such as to Shopware 6.8 anyway, it is better to separate the upgrade and the template change in time so that causes of fluctuations can be told apart. With a platform switch, on the other hand, the URLs change anyway; there, the template should be settled before launch so that there is only one move. In a Shopware migration, we therefore plan the templates from the start.

How we support the planning

In Shopware projects of our Shopware agency, the SEO URL templates are among the settings we define together with you before launch and before any major change. The work is divided into three stages:

In ongoing operations, the template belongs in regular Shopware maintenance: after updates and new extensions, a comparison with the backed-up URL list shows whether URLs have changed unnoticed.