3 · Existing Shopware routes
A canonical page, an existing Shopware redirect and an already resolved platform route preserve the platform’s result.
Own product · Technical case
A Shopware plugin. Built around the URL’s lifecycle.
Product 404 Redirects is my own published extension. This case explains its resolver design and the compatibility updates in 1.1.0 for Shopware 6.7 and 0.1.2 for Shopware 6.6, with documented resolver and integration checks.
The problem starts before the product disappears
A deleted product can still have links in emails, bookmarks and search results. At the moment that address is requested, the product and its category assignment may already be gone. The implementation therefore has two related jobs: capture useful information around deletion and use that information when an old address is requested.
I built the extension around Shopware’s product lifecycle and storefront routing. The outcome is a published, configurable plugin with an administration interface, rather than a separate redirect service outside the shop.
Product deletion
Capture available URL and category data; persist after success.
Shopware SEO resolver
Preserve resolved routes; look up eligible old paths.
Merchant control
Review destinations, rules, notices and activity.
Capture first, save after successful deletion
The deletion subscriber reads product SEO paths, translated names and a candidate category while the necessary records are available. It registers a success callback to write the redirect rules after the deletion succeeds.
The current code skips headless sales channels and skips entries where no category URL is found. The rule identifier is derived from the source path and sales channel, allowing repeated captures to update the same rule. These choices make the relationship to the shop’s actual URLs explicit.
Let Shopware resolve the address first
The extension decorates Shopware’s SEO resolver. It first asks the platform to resolve the address and preserves an existing canonical destination, a canonical route or a path already resolved by Shopware.
Only an unresolved, non-empty path with the plugin enabled reaches the redirect lookup. A matching rule supplies a canonical target for Shopware’s routing. A target equal to the source after slash normalization is ignored to avoid a direct self-redirect.
The lookup checks saved rules and available SEO history. It receives the sales channel and language; the resolver does not request a global fallback for an arbitrary unknown path. Historical recovery remains dependent on the available records.
Give the merchant visibility and control
The administration module exposes rules, destinations, enable/disable controls and hit statistics. The destination remains an editorial decision: a merchant can replace an unsuitable default with a more relevant target.
The response subscriber records a matching redirect and can provide a short-lived cookie for the optional storefront notice. In this release, redirect-log inserts contain the rule, source, target and timestamps, without visitor IP hashes or user agents. The default cleanup period is 30 days.
Compatibility checks for the current releases
On 16 September 2026, release 1.1.0 was checked on an installed Shopware 6.7.14.1 shop and release 0.1.2 on an installed Shopware 6.6.10.25 shop.
The checks covered an existing product redirect, its destination, a readable Secure notice cookie, and native cookie configuration with the default banner enabled and disabled. Stored redirects and category references survived the schema update. A Chromium check also confirmed the visible notice in the 6.6 shop.
Both updates replace an incomplete category foreign key and use YAML configuration. The 6.7 release uses the cookie collection event and native Administration snippet discovery. The 6.6 release keeps its compatible cookie provider and Administration registration, with additional checks for custom cookie groups.
The APIs used by the plugin were reviewed against the minimum supported versions. Full installation tests covered the two releases named above. Functional checks on PHP 8.5 passed, but the 6.6 review shop’s PHP 8.2 Composer lock needs different dependency versions before full deployment on PHP 8.5. The report distinguishes these checks from the historical isolated tests below.
Nine isolated resolver checks
On 8 September 2026 the actual resolver class from the 1.0.11 distribution package was tested with controlled doubles for Shopware’s resolver, configuration and redirect lookup. All nine checks passed.
The checks cover an active canonical page, an existing Shopware redirect, a resolved platform route, a disabled plugin, the homepage, an unknown address, a direct self-redirect and two forms of category target. They also verify that lookup calls receive the language, sales channel and disabled global-fallback flag.
These are isolated code checks. They do not replace full Shopware integration tests, database tests or checks in a merchant’s storefront. No customer revenue, ranking gain or performance benchmark is claimed here.
What the nine resolver tests actually cover
The 8 September report for version 1.0.11 groups the nine passing checks as follows. These groups show which failure cases the resolver was checked against:
3 · Situations without a redirect
A disabled plugin, the homepage and an unknown address without a match must not trigger a new product rule.
3 · Destinations and paths
A direct self-redirect is ignored. A category target and the leading-slash variation are checked separately.
The historical resolver tests use test doubles. The separate 16 September compatibility report documents installed checks on Shopware 6.7.14.1 and 6.6.10.25. Use both reports to assess the evidence before planning tests in your own store.
1.0.11 · Resolver · 2026-09-08 (JSON) · 1.1.0 / 0.1.2 · Shopware · 2026-09-16 (JSON)
Also explore Magento 2 modules and integrations and WooCommerce development.
What this demonstrates for a custom Shopware project
The work combines lifecycle events, SEO routing, persistence, administration and a storefront feature. The same engineering approach is useful when a custom Shopware requirement crosses several parts of the platform.
A project can start with the specific rule, integration or operational problem you need to solve. We can define the supported versions, affected sales channels, acceptance checks and handover before development begins.
Sources and scope
Written by the developer of Product 404 Redirects. Current release information is checked against packages 1.1.0 and 0.1.2, their changelogs and tests on Shopware 6.7.14.1 and 6.6.10.25. The older resolver report remains dated and labelled 1.0.11. Verify the response and destination in your own setup.
Discuss your Shopware project
Send your Shopware version, sales channels and the task you need to solve. We can define the next useful step.