17 Shopware shop mistakes we see most often

By Daniel Bohusz, Shopware developer since 2014 · Published October 2026 · Updated October 2026

We have worked with Shopware since 2014 and look after around 20 shops in Germany, Austria and Switzerland. When we take over a shop – from the owner or from another agency – we often find the same problems.

Most of them are not dramatic on day one. They cost money slowly: through licences nobody needs, slow pages, failed updates or an outage at the worst moment. Here are 17 mistakes we see in practice, why each one hurts and how to fix it.

Why it hurts: Every plugin adds code that runs on each request, can break on updates and often costs a monthly licence. After a few years many shops pay for plugins nobody uses any more, or for three plugins that each solve a small part of one problem. Each extra plugin is also one more thing that can block a Shopware update.

How to fix it: List every plugin with its purpose, cost and last update. Remove what you do not use. Where several subscriptions cover one process, one custom plugin built for that process is often cheaper and easier to maintain in the long run.

How we can help: Get a free plugin audit – we check every plugin and show which licences you can drop.

Why it hurts: Shopware updates, plugin updates and PHP upgrades can change behaviour in the checkout, the theme or integrations. If you update directly on production, your customers find the bugs first – often on a Friday evening.

How to fix it: Keep a staging copy of the shop with current data. Run every update there first, test the key flows, then repeat the same steps on production with a backup in place and a planned rollback.

How we can help: See our Shopware update service: every update is tested on staging first.

Why it hurts: Many shops have “some backup at the hosting company” but nobody knows how old it is, what it includes or how to restore it. Without monitoring, an outage or a broken checkout can go unnoticed for hours.

How to fix it: Back up the database and the media files daily and keep copies off the server. Test a restore regularly. Add uptime monitoring and, ideally, a check that the checkout still works, with alerts that reach a real person.

How we can help: Backups, monitoring and updates are part of our Shopware care plans.

Why it hurts: Edits in the vendor directory or in Shopware core files are overwritten by the next update. The shop then breaks or the change silently disappears, and nobody remembers why it was there.

How to fix it: Put every customisation into your own plugin or theme: use events, decorators, subscribers and template inheritance. Keep the code in version control (Git) so every change is documented.

How we can help: Need the change done properly? See custom Shopware features.

Why it hurts: If you change the files of a theme you bought, the next theme update overwrites your changes – or you stop updating the theme and miss bug fixes and compatibility with new Shopware versions.

How to fix it: Create your own theme that inherits from the purchased theme and put all changes there. Template overrides, styles and configuration then survive updates of the parent theme.

Why it hurts: When URLs change during a migration – for example from Shopware 5 to Shopware 6, or from another shop system – old links from Google, ads, newsletters and other websites lead to 404 pages. Rankings and traffic can drop for months.

How to fix it: Export all old URLs (products, categories, CMS pages, images) before the migration. Map each one to its new URL and set up 301 redirects. After go-live, monitor 404 errors in Google Search Console and fix gaps quickly.

How we can help: Planning a move? See Shopware 5 to 6 migration – with a full redirect plan.

Why it hurts: Product photos uploaded straight from the camera or the photographer make pages slow, especially on mobile. Slow pages cost conversions and are a weaker signal for search engines.

How to fix it: Upload images in a sensible size, use modern formats such as WebP, check that Shopware thumbnails are generated correctly, and load images below the fold lazily. Measure before and after with PageSpeed Insights.

How we can help: See Shopware page speed and SEO optimisation, measured before and after.

Why it hurts: Without a working HTTP cache, every page view is rendered from scratch by PHP and the database. The shop feels slow and reaches its limits at the first campaign or newsletter.

How to fix it: Enable and configure the Shopware HTTP cache, use a reverse proxy where it makes sense, and move cache, sessions and locks to Redis on larger shops. Check that cache invalidation works after product and price updates.

How we can help: See Shopware page speed and SEO optimisation, measured before and after.

Why it hurts: Shopware processes many things in the background: indexing, emails, sitemaps, imports, cleanup. If the scheduled tasks or the message queue workers do not run, orders stay without emails, search results are outdated and the database keeps growing.

How to fix it: Run scheduled tasks and the message queue via cron or a process manager on the server (bin/console scheduled-task:run, bin/console messenger:consume), and disable the admin worker in production. Monitor that the queue does not grow.

Why it hurts: Debug mode slows down the shop, can show error details and file paths to visitors and fills the logs. It is often left on after a quick fix and then forgotten.

How to fix it: Production runs with APP_ENV=prod and debug switched off. Debug only on staging or locally. Check the .env settings after every deployment.

Why it hurts: The Shopware admin gives access to customer data, orders and prices. Shared accounts, simple passwords and old users of former staff or agencies are a common way in for attackers.

How to fix it: Give each person their own admin account with only the rights they need, use strong unique passwords and two-factor authentication, remove old users and, where possible, limit admin access by IP or VPN.

How we can help: See Shopware security checks and hack clean-up.

Why it hurts: Old PHP versions no longer receive security updates and block newer Shopware versions. The longer you wait, the bigger the jump – and the more expensive the update.

How to fix it: Check the system requirements of your Shopware version and plan PHP, database and server updates together with your Shopware updates. Test on staging first.

How we can help: See our Shopware update service: PHP, server and Shopware updates planned together.

Why it hurts: A small change to the theme, a new plugin or an update of a payment plugin can break the checkout. Without a test, you only notice when orders stop coming in.

How to fix it: After every change, run a short test plan: add to cart, register and guest checkout, each payment and shipping method, vouchers, order confirmation email. Write the steps down so anyone on the team can repeat them.

How we can help: We also offer Shopware testing and UX reviews.

Why it hurts: Products in several categories, variants, filters, language versions and sales channels can create many URLs with the same content. Search engines then have to guess which page to show, and your strongest page loses weight.

How to fix it: Check the SEO URL templates, canonical tags and the indexing of filter and sorting parameters. Keep one main URL per product and category, and write unique titles and descriptions for important pages.

How we can help: See Shopware page speed and SEO optimisation.

Why it hurts: Since December 2024 the EU General Product Safety Regulation (GPSR) requires information such as the manufacturer and safety notes for products sold online. Missing legal information can lead to warnings, marketplace issues and lost trust.

How to fix it: Add the required fields to your products (for example with custom fields or a plugin), fill them in for the whole catalogue and show them on the product page. Have your legal texts checked by a lawyer – we handle the technical side.

How we can help: Our extension Extended Product Tabs (FAQ, Media, GPSR) shows GPSR information on the product page – see Goodday extensions.

Why it hurts: If order confirmations and password emails are sent without proper authentication, they land in spam or are rejected. Customers think the order failed and call or order twice.

How to fix it: Send shop emails via SMTP or an email service on your own domain and set up SPF, DKIM and DMARC records for it. Then send test emails to several providers and check the headers.

Why it hurts: Hosting, domain and DNS, Shopware account, payment providers, ERP connections – often only one person knows the logins. If that person or agency leaves, simple tasks turn into days of searching.

How to fix it: Keep all access in a shared password manager and write a short document: where the shop runs, how it is deployed, which plugins and integrations are used and who to call. Update it after every larger change.

If you only have ten minutes, check these points first:

• Do you know every plugin in the shop, what it does and what it costs?
• Is there a staging copy, and are updates tested there first?
• When was the last backup restored as a test?
• Do scheduled tasks and queue workers run, and is debug mode off?
• Does every admin user have their own account and two-factor authentication?
• Did someone place a test order after the last change?
• Is all access documented in one place?

Not sure about some of the answers? Our free plugin audit is a good starting point. If something is broken right now, use our Shopware emergency support – written first assessment within 4 hours on working days, from €390 (excl. VAT).