Veraltete Shopware-Setups
Shopware 5, alte Plugins, gewachsene Themes oder veraltete Serverstrukturen bremsen Entwicklung, Sicherheit und Performance.
Shopware Agentur für Bielefeld, OWL & ganz Deutschland
Shopware 6B2BMigrationPlugin-EntwicklungSchnittstellenPerformanceSEO
Shopware Agentur für komplexe Shops, B2B und technische Entwicklung
Wir entwickeln und optimieren Shopware-Shops, die mehr können müssen als Standard: B2B-Preislogiken, ERP- und PIM-Schnittstellen, individuelle Plugins, performante Storefronts, saubere Migrationen und technische SEO. Für Unternehmen aus Bielefeld, OWL und ganz Deutschland.
5,0· 14 Rezensionen
shopware.log
~$webcellent shopware --scope "commerce system"
->Storefront · Plugin Layer · DAL / API ...
->ERP Sync · PIM Datenmodell · B2B Pricing ...
->SEO Routes · Performance Budget ...
✓deploy ready in 8 weeks
~$
Das Problem
Wenn Shopware nicht sauber geplant ist, wird Wachstum technisch teuer.
Shopware ist stark, wenn Prozesse, Sortimente und Vertriebsmodelle komplexer werden. Aber genau diese Stärke braucht eine saubere technische Grundlage. Ohne klare Architektur entstehen langsame Shops, doppelte Datenpflege, fehleranfällige Schnittstellen und Relaunches, die Sichtbarkeit kosten.
Shopware-Projekt anfragenKomplexe Produktdaten
Varianten, Eigenschaften, Herstellerdaten, Medien, Preise und Verfügbarkeiten müssen sauber strukturiert werden – sonst wird jeder Relaunch zur Datenbaustelle.
Schnittstellen-Chaos
ERP, PIM, Warenwirtschaft, Versand, Marktplätze und Shop laufen nicht sauber zusammen. Das führt zu manueller Pflege, Fehlern und Prozesskosten.
B2B-Logiken im Standard-Korsett
Kundengruppen, individuelle Preise, Freigaben, Angebote, Rollen und Bestellprozesse lassen sich selten mit Standard-Konfiguration allein sauber abbilden.
Performance-Probleme
Langsame Listings, schwere Themes, viele Plugins, große Bilder oder falsche Serverkonfigurationen kosten Rankings und Umsatz.
Leistungen
Was wir als Shopware Agentur für euch entwickeln
Wir unterstützen Shopware-Projekte dort, wo Technik, E-Commerce und Prozesse zusammenkommen: vom neuen Shopware 6 Shop über Migration und Plugin-Entwicklung bis zu Schnittstellen, B2B-Funktionen, Performance und laufender Weiterentwicklung.
Shopware 6 Entwicklung
Wir entwickeln neue Shopware 6 Shops mit sauberer Architektur, performanter Storefront und einer technischen Grundlage, die SEO, Tracking und späteres Wachstum trägt.
StorefrontArchitekturUX
Shopware Relaunch
Wir bringen bestehende Shops technisch und strukturell auf ein neues Niveau – inklusive Konzept, Theme, Datenmodell, Weiterleitungen, Tracking und Qualitätssicherung.
RelaunchThemeTracking
Shopware 5 auf 6 Migration
Wir planen Migrationen von Shopware 5 auf Shopware 6 so, dass Produktdaten, URLs, SEO-Signale, Weiterleitungen, Schnittstellen und Geschäftsprozesse sauber übertragen werden.
MigrationSEO-ErhaltDaten
Shopware Plugin-Entwicklung
Wir entwickeln individuelle Shopware Plugins, wenn Standard-Erweiterungen eure Anforderungen nicht sauber, performant oder wartbar lösen.
PluginsCustom DevWartbar
Shopware Schnittstellen
Wir verbinden Shopware mit ERP, PIM, CRM, Warenwirtschaft, Versand, Payment, Marktplätzen oder individuellen internen Systemen.
ERPPIMAPI
Shopware B2B
Wir entwickeln B2B-Funktionen wie Kundengruppen, individuelle Preise, Freigabeprozesse, Angebotslogiken, Rollen/Rechte und komplexe Bestellabläufe.
B2BPreislogikRollen
Shopware Performance-Optimierung
Wir analysieren Storefront, Plugins, Datenbank, Server, Bilder, Caching und Core Web Vitals – und optimieren dort, wo es messbar wirkt.
Core Web VitalsCachingLCP
Shopware SEO
Wir schaffen technische SEO-Grundlagen für Shopware: URL-Struktur, Canonicals, Weiterleitungen, strukturierte Daten, Indexierung, interne Verlinkung und saubere Kategoriearchitektur.
Technische SEOSchemaURLs
Shopware Betreuung & Weiterentwicklung
Wir begleiten Shopware-Shops langfristig mit technischer Weiterentwicklung, Updates, Monitoring, Bugfixes und kontinuierlicher Optimierung.
RetainerUpdatesMonitoring
Shopware 6 Entwicklung
Wer einen neuen Shopware 6 Shop aufbaut, trifft früh Entscheidungen, die später schwer rückgängig zu machen sind: Wie werden Produktdaten modelliert? Welche Felder werden als Custom Fields gelöst, welche brauchen eine eigene Datenstruktur? Wie viele Plugins sind vertretbar, bevor Wartbarkeit und Performance leiden? Ein häufiger Fehler ist es, Shopware wie einen Website-Baukasten zu behandeln – Theme installieren, Plugins stapeln, fertig. Das funktioniert bei kleinen, einfachen Shops, scheitert aber sobald Produktdaten komplex werden, Schnittstellen dazukommen oder der Shop skalieren soll. Entscheidend ist außerdem die Storefront-Architektur: Setzt ihr auf das klassische Twig-basierte Storefront oder auf einen Headless-Ansatz mit eigenem Frontend? Beide Wege haben echte Vor- und Nachteile in Bezug auf Entwicklungsaufwand, Flexibilität, Performance und laufende Kosten – und diese Entscheidung sollte vor dem ersten Sprint fallen, nicht nachher.
Shopware Relaunch
Ein Relaunch ist das riskanteste Projekt im E-Commerce, weil er gleichzeitig SEO-Sichtbarkeit, Conversion, Tracking und Betriebsstabilität gefährdet. Der häufigste Fehler: URL-Strukturen ändern sich, ohne dass alle Weiterleitungen sauber gepflegt werden – Google verliert Rankings, die sich über Jahre aufgebaut haben. Ein zweiter kritischer Punkt ist Tracking: Wird Google Analytics, Tag Manager oder ein Consent-Tool neu aufgesetzt, brechen Daten oft ab – unbemerkt, wenn es keinen Abnahmetest gibt. Relaunches scheitern außerdem oft daran, dass das Datenmodell nicht neu gedacht wird: Produkteigenschaften, Varianten und Kategoriestrukturen werden einfach übernommen, obwohl sie im alten Shop schon nicht funktioniert haben. Ein sauberer Relaunch beginnt deshalb nicht mit Design, sondern mit einer Analyse des bestehenden Systems – was soll erhalten bleiben, was muss neu gebaut werden, und was kann vereinfacht werden.
Shopware 5 auf 6 Migration
Shopware 5 und Shopware 6 sind technisch grundverschieden – es gibt keinen automatischen Migrationsweg, der alles sauber überträgt. Das offizielle Migration Assistant-Tool von Shopware übernimmt Basisdaten wie Produkte und Kunden, aber keine Theme-Logik, keine Plugin-Funktionen und keine Schnittstellen. Besonders kritisch ist die URL-Struktur: Shopware 6 generiert URLs anders als Shopware 5. Ohne ein vollständiges URL-Mapping und lückenlose 301-Weiterleitungen verliert ein Shop nach dem Launch messbar Sichtbarkeit. Hinzu kommt die Plugin-Inventur: Nicht jedes Shopware-5-Plugin gibt es für Shopware 6 – manche Funktionen müssen neu entwickelt, manche durch andere Lösungen ersetzt werden. Eine Migration ohne vorherige Bestandsaufnahme führt fast immer zu Überraschungen im Produktivbetrieb.
Shopware Plugin-Entwicklung
Plugins sind das mächtigste Werkzeug in Shopware – und gleichzeitig die häufigste Ursache für Performance-Probleme, Update-Konflikte und schwer wartbare Shops. Jedes Plugin greift in den Shopware-Core ein: in Events, in die DAL, in den Storefront-Render-Prozess. Wer zu viele Plugins stapelt, die denselben Checkout-Event abonnieren, baut sich ein System, das bei jedem Shopware-Update potentiell bricht. Die wichtigste Frage vor jeder Plugin-Entscheidung lautet deshalb: Ist ein Drittanbieter-Plugin hier wirklich die beste Lösung – oder ist ein schlankes, selbst entwickeltes Plugin wirtschaftlicher, weil es genau das tut, was gebraucht wird, und nichts anderes? Individuell entwickelte Plugins sind updatefähiger, weil sie nicht auf fremde Release-Zyklen angewiesen sind, und wartbarer, weil der Code bekannt und dokumentiert ist. Der Break-even liegt oft früher als erwartet.
Shopware Schnittstellen
Schlechte Schnittstellen sind einer der häufigsten Gründe, warum E-Commerce-Betrieb teuer bleibt: Daten laufen nicht synchron, Bestände stimmen nicht, Bestellungen müssen manuell nachgepflegt werden. Eine Schnittstelle ist technisch gesehen schnell gebaut – aber eine, die zuverlässig läuft, Fehler behandelt, Wiederholungen verwaltet und nachvollziehbar loggt, ist eine andere Aufgabe. Die wichtigsten Fragen vor der Entwicklung: Welche Daten müssen in welche Richtung fließen? Wer ist das führende System – Shopware oder das ERP? Wie werden Konflikte behandelt, wenn beide Systeme gleichzeitig schreiben? Was passiert bei einem Timeout oder einem API-Fehler? Wer diese Fragen nicht vor der Entwicklung klärt, beantwortet sie später im Produktivbetrieb – unter schlechteren Bedingungen.
Shopware B2B
Shopware 6 bringt solide B2B-Grundfunktionen mit: Kundengruppen, Nettopreisdarstellung, Mindestbestellmengen und einfache Rollen sind im Standard verfügbar. Die Grenze dieser Bordmittel wird jedoch schnell erreicht, sobald Prozesse komplexer werden – etwa bei mehrstufigen Freigabeworkflows, kundenspezifischen Preislisten direkt aus dem ERP oder budgetgesteuerten Bestellprozessen. Ein häufiges Problem: B2B-Anforderungen werden erst nach dem Launch vollständig formuliert – dann ist Nachbauen teurer als vorher richtig planen. Wer B2B mit Shopware aufbauen will, sollte vor dem Projektstart einen klaren Anforderungskatalog haben, der alle Prozesse vom Login bis zur Rechnung abdeckt – inklusive der Frage, welche Daten aus welchem System kommen und wer sie pflegt.
Shopware Performance-Optimierung
Google nutzt Core Web Vitals – LCP, CLS und INP – als Rankingfaktor. Ein Shopware-Shop, der auf einem durchschnittlichen Mobilgerät mehr als drei Sekunden zum Laden braucht, verliert messbar Sichtbarkeit in der organischen Suche. Die häufigsten Ursachen sind nicht fehlende Server-Power, sondern: zu viele JavaScript-Ressourcen durch Plugins und Tracking-Tools, unkomprimierte Bilder im falschen Format, fehlendes oder falsch konfiguriertes HTTP-Caching und datenbankintensive Listing-Abfragen ohne saubere Indizes. Bevor optimiert wird, muss gemessen werden – nicht mit dem PageSpeed-Insights-Score allein, sondern mit echten Nutzerdaten aus dem Chrome User Experience Report und Waterfall-Analysen aus dem Browser. Nur so lassen sich Maßnahmen priorisieren, die im echten Nutzerbetrieb wirken.
Shopware SEO
Technisches SEO in Shopware ist kein einmaliges Setup, weil jede Konfigurationsänderung, jedes neue Plugin und jede Produktdatenänderung SEO-relevante Konsequenzen haben kann. Ein häufiges Problem: Produktvarianten erzeugen in Shopware eigenständige URLs, die ohne saubere Canonical-Konfiguration als Duplicate Content gewertet werden. Ebenso problematisch sind Filterkombinationen in Kategoriepfaden, die tausende indexierbare URLs erzeugen, von denen keine einzelne genug Stärke hat um zu ranken. Strukturierte Daten – insbesondere Product Schema, BreadcrumbList und FAQPage – sind für Shop-SEO inzwischen Pflicht, werden aber in Shopware nicht automatisch korrekt ausgespielt. Wer hier keine klare Indexierungsstrategie hat, verschwendet Crawl-Budget und verwässert die Sichtbarkeit relevanter Seiten.
Shopware Betreuung & Weiterentwicklung
Shopware 6 veröffentlicht regelmäßig Minor- und Major-Updates, die neue Funktionen bringen, aber auch Inkompatibilitäten mit bestehenden Plugins und Anpassungen verursachen können. Wer Updates ohne Test-System einspielt, riskiert Ausfälle im Produktivbetrieb. Ein strukturierter Betreuungsprozess bedeutet deshalb: Updates werden zuerst auf einem Staging-System eingespielt, Funktionen werden getestet, und erst dann folgt der Roll-out auf dem Live-System. Genauso wichtig ist proaktives Monitoring: Fehler im Checkout, abgebrochene API-Calls oder Performance-Einbrüche sollten erkannt werden, bevor sie sich in Umsatzzahlen niederschlagen. Neben dem laufenden Betrieb brauchen Shops außerdem eine Roadmap – wer das nicht strukturiert plant, entwickelt reaktiv statt strategisch.
Eure Anforderung ist dabei?
Shopware-Projekt anfragenUnser Ansatz
Wir denken Shopware nicht als Website, sondern als E-Commerce-Betriebssystem.
Ein guter Shopware-Shop besteht nicht nur aus Design und Produktseiten. Entscheidend ist, wie sauber Daten, Prozesse, Schnittstellen, Performance, SEO und Conversion zusammenspielen.
Klassische Shopware-Agentur
baut Theme und Templates
installiert Plugins
arbeitet seitenorientiert
optimiert nach Bauchgefühl
übergibt nach Launch
betrachtet Shopware isoliert
Oft ausreichend für einfache Setups – aber bei B2B, Schnittstellen, Produktdaten und Wachstum schnell an Grenzen.
Webcellent
entwickelt Shopware als technisches Verkaufssystem
prüft, ob Standard, Plugin oder individuelle Entwicklung sinnvoll ist
denkt in Produktdaten, Prozessen und Systemlogik
verbindet Technik, SEO, Tracking und Conversion
begleitet Weiterentwicklung, Performance und Betrieb
bindet ERP, PIM, Warenwirtschaft und interne Tools ein
Wir verstehen Shopware nicht als Website, sondern als E-Commerce-Betriebssystem, das mit eurem Unternehmen wachsen soll.
Zertifizierungen
Shopware Migration
Shopware 5 auf Shopware 6 migrieren – ohne Datenchaos und Sichtbarkeitsverlust.
Eine Shopware-Migration ist kein technisches Kopieren von A nach B. Produktdaten, Varianten, URLs, SEO-Metadaten, Weiterleitungen, Kundendaten, Bestellungen, Plugins, Schnittstellen und Tracking müssen sauber geplant werden. Sonst wird aus dem Relaunch ein Ranking-, Daten- oder Prozessproblem.
Analyse des bestehenden Shopware-Setups
Plugin- und Funktionsinventur
Datenmodell für Produkte, Varianten und Eigenschaften
URL-Mapping und 301-Weiterleitungen
SEO-Metadaten und strukturierte Daten
Kategorie- und Erlebniswelten-Konzept
Kundendaten, Bestellungen und historische Daten
Schnittstellen zu ERP, PIM, Warenwirtschaft und Versand
Tracking, Consent und Conversion-Messung
Testsystem, Abnahme und Launch-Plan
Praxisbeispiel
Über die Migration
Den WooCommerce-Shop hatten wir Jahre zuvor selbst gebaut – für den Wechsel auf Shopware 6 wurden Produktdaten, Kundenkonten und URLs sauber übernommen und der Shop gleichzeitig an den tatsächlichen Bestellwegen von Schulen ausgerichtet.
„Wir sind super zufrieden mit dem Ergebnis, aber auch der Weg dahin hat für uns gut funktioniert – schnelles Antworten, verständliche Kommunikation, individuelles Eingehen auf unsere Bedürfnisse und ein konstruktives Vorgehen.“
Was bei einer Migration wirklich zählt
Der Migration Assistant überträgt weniger als du denkst
Das offizielle Shopware-Migrationstool überträgt Basisdaten: Produkte, Kategorien, Kunden, Bestellungen. Was es nicht überträgt: individuelle Datenfelder (Custom Fields), Regel-basierte Preise, Shopping Worlds, Theme-Anpassungen, Plugin-Konfigurationen und Schnittstellen-Logiken. In der Praxis bedeutet das: nach dem automatischen Import ist der Shop technisch vorhanden, aber weit davon entfernt, produktionsreif zu sein. Wer das unterschätzt, steht nach dem Import vor dem eigentlichen Projekt.
Shopping Worlds werden zu CMS-Seiten – aber nicht automatisch
Shopware 5 nutzt "Shopping Worlds" für Landingpages, Kategoriebanner und Content-Seiten. Shopware 6 ersetzt dieses System durch "Erlebniswelten" auf Basis eines völlig anderen CMS-Editors. Eine automatische Konvertierung gibt es nicht – jede Shopping World muss manuell in der neuen Struktur aufgebaut werden. Wer viele Kategorie- und Aktionsseiten betreibt, sollte diesen Aufwand explizit im Migrationsplan einkalkulieren.
URL-Strukturen unterscheiden sich grundlegend
Shopware 5 und Shopware 6 generieren SEO-URLs nach unterschiedlichen Regeln. Kategorienamen, Produktpfade und Filterkombinationen sehen in SW6 anders aus als in SW5 – selbst wenn die Inhalte identisch sind. Das bedeutet: jede bestehende URL aus SW5 braucht eine sauber gepflegte 301-Weiterleitung auf die neue SW6-URL. Fehlt auch nur eine relevante Kategorie- oder Produktseite in der Redirect-Map, verliert der Shop dieses Ranking dauerhaft. Ein vollständiges URL-Crawl des alten Shops vor der Migration ist deshalb kein optionaler Schritt, sondern Pflicht.
Shopware 6 kann ohne Optimierung langsamer sein als Shopware 5
Das klingt kontraintuitiv, ist aber eine bekannte Erfahrung aus der Praxis. Shopware 6 basiert auf Symfony und hat durch seine modulare Architektur mehr Overhead als Shopware 5. Ohne korrekt konfigurierten HTTP-Cache, ohne Elasticsearch für die Suche und ohne optimierte Queue-Einstellungen ist ein frisch aufgesetzter Shopware-6-Shop oft langsamer als sein Vorgänger. Performance-Optimierung ist in SW6 kein Feinschliff nach dem Launch – sie muss Teil des Setups sein.
Das Plugin-Ökosystem hat eine Lücke
Nicht jedes Shopware-5-Plugin existiert auch für Shopware 6. Manche Hersteller haben ihre Erweiterungen portiert, andere haben aufgehört oder bieten nur eine eingeschränkte SW6-Version an. Wer vor der Migration keine vollständige Plugin-Inventur macht, entdeckt fehlende Funktionen oft erst, wenn der neue Shop bereits im Aufbau ist – und muss dann entweder Alternativen finden, auf Funktionen verzichten oder individuelle Entwicklung einplanen. Diese Inventur gehört in die allererste Projektphase.
Der Cutover-Zeitpunkt entscheidet über Datenverlust
Bei einer Shop-Migration gibt es ein kritisches Zeitfenster zwischen dem letzten Datenabgleich und dem Go-Live. In diesem Fenster gehen Bestellungen im alten System ein, sind aber noch nicht im neuen vorhanden. Wer diesen Moment nicht explizit plant – mit einem definierten Freeze-Zeitpunkt, einer letzten Delta-Migration und einem klaren Rollback-Plan – riskiert, dass Bestellungen, Kundendaten oder Lagerbestände verloren gehen oder inkonsistent sind. Der Cutover ist der riskanteste Moment einer jeden Migration und verdient einen eigenen Ablaufplan.
Shopware B2B
Shopware für B2B: Wenn Standard-Shops nicht mehr reichen.
B2B-Commerce funktioniert anders als klassischer B2C. Kunden erwarten individuelle Preise, wiederkehrende Bestellungen, Freigabeprozesse, Rollen, Budgets, Angebotslogiken und eine enge Verbindung zu bestehenden Systemen. Wir entwickeln Shopware so, dass diese Prozesse nicht manuell um den Shop herum organisiert werden müssen.
B2B-Anforderungen besprechenIndividuelle Preislisten
Kundengruppen und Rollen
Angebotsanfragen
Freigabeprozesse
Schnellbestellung
Wiederbestellung
Budget- und Kostenstellenlogiken
Kundenspezifische Sortimente
Login-Bereiche
ERP-gesteuerte Verfügbarkeiten
Netto-/Brutto-Logiken
Mehrstufige Bestellprozesse
Was B2B mit Shopware wirklich bedeutet
B2B Suite oder Individualentwicklung – wann lohnt sich was?
Shopware bietet eine kostenpflichtige B2B Suite, die viele Standardfunktionen für B2B-Shops mitbringt. Kundengruppen, Angebotsfunktionen, Schnellbestellung und einfache Freigabeprozesse sind darin enthalten. Der Haken: Die Suite kostet eine monatliche Lizenzgebühr und deckt trotzdem nicht jede individuelle Anforderung ab. Wer zum Beispiel mehrstufige Freigaben nach Kostenstelle braucht, ERP-gesteuerte Preise in Echtzeit oder ein vollständig angepasstes Bestellerlebnis, wird auch mit der Suite noch individuelle Entwicklung benötigen. Die Frage ist also nicht 'Suite oder Custom', sondern: Welche Funktionen deckt die Suite wirklich ab – und was muss trotzdem gebaut werden? Diese Analyse lohnt sich vor der Kaufentscheidung.
Warum Kundengruppen für echtes B2B-Pricing nicht reichen
Shopware-Kundengruppen erlauben prozentuale Auf- und Abschläge sowie feste Preise pro Artikel. Das klingt ausreichend – ist es aber nicht, sobald Preise aus einem ERP kommen. In der B2B-Realität hat jeder Kunde oft einen individuell verhandelten Preis, der sich aus Rahmenverträgen, Jahresmengen und Konditionsgruppen zusammensetzt. Diese Preise leben im ERP, nicht im Shop. Werden sie manuell in Shopware gepflegt, entstehen Inkonsistenzen und Pflegeaufwand. Die einzige skalierbare Lösung ist eine Echtzeit-Schnittstelle: Shopware fragt beim Seitenaufruf oder Warenkorbschritt den aktuellen Preis direkt beim ERP ab. Das erhöht die Systemkomplexität, ist aber für ernsthaften B2B-Commerce nicht optional.
Das Company-Datenmodell in Shopware 6 – und warum es wichtig ist
Shopware 6 unterscheidet zwischen einem 'Customer'-Account (B2C) und einem 'Business'-Account (B2B) auf Datenbankebene. Ein Business-Account kann mehrere Mitarbeiter-Accounts enthalten, mit unterschiedlichen Rollen und Berechtigungen. Das klingt selbstverständlich, ist aber ein grundlegender Unterschied zu vielen Systemen, die B2B nur über Tags oder Kundengruppen abbilden. Wer dieses Datenmodell früh versteht, plant Registrierungsprozesse, Adminbereiche und Schnittstellen von Anfang an richtig. Wer es ignoriert, baut später um. Besonders relevant wird es bei der Frage, wie Bestellungen einem Unternehmen zugeordnet werden – nicht einem einzelnen Mitarbeiter – und wie die Rechnung an die Unternehmensadresse geht, nicht an den eingeloggten User.
Quick Order und Nachbestellung: die meistunterschätzte B2B-Funktion
B2B-Kunden kaufen in der Regel immer wieder dieselben Produkte – oft in festen Intervallen. Ein Standard-Shopware-Katalog mit Suchfunktion ist für dieses Nutzungsverhalten zu langsam. Was B2B-Käufer wirklich brauchen: eine Schnellbestellmaske, in der sie Artikelnummern direkt eintippen oder per CSV hochladen können – und innerhalb von Sekunden zum Warenkorb gelangen. Ebenso wichtig: eine 'Aus Bestellung X nachbestellen'-Funktion, die vergangene Bestellungen als Vorlage nutzt. Wer diese Funktionen nicht hat, verliert Bestellungen an Telefon, E-Mail oder den Außendienst – nicht weil der Shop schlecht ist, sondern weil er zu langsam für den B2B-Alltag ist.
Angebotslogik ist komplexer als ein gespeicherter Warenkorb
Viele Shops bilden Angebote ab, indem sie einen Warenkorb speichern und per Link teilen – das reicht für echtes B2B nicht. Ein B2B-Angebot durchläuft typischerweise mehrere Zustände: Anfrage durch den Kunden, interne Prüfung, individuelle Preisanpassung durch den Vertrieb, Rücksendung an den Kunden, mögliche Nachverhandlung, Annahme und schließlich Umwandlung in eine Bestellung. Jeder dieser Schritte braucht einen Status, eine Benachrichtigung und eine Revisionshistorie. Fehlt diese Logik, wird das Angebot per E-Mail verwaltet – mit allen bekannten Nachteilen für Nachverfolgbarkeit und Fehlerrate. Wer B2B-Angebote im Shop abbilden will, plant dafür einen eigenen Workflow – kein Plugin wird das vollständig lösen.
USt-IdNr.-Validierung bei der Registrierung: der vergessene Pflichtschritt
B2B-Shops stellen Preise meistens netto dar und setzen voraus, dass der Kunde ein Unternehmen mit gültiger USt-IdNr. ist. Aber wer prüft das bei der Registrierung? Viele Shops verlassen sich darauf, dass Kunden ehrlich sind – und aktivieren das B2B-Konto manuell nach Prüfung. Das ist skalierungsfähig, bis zu dem Punkt, wo täglich neue Registrierungen eingehen. Die Alternative: eine automatische Validierung der USt-IdNr. über die VIES-API der EU in Echtzeit. Ist die Nummer gültig, wird das Konto sofort als B2B-Konto eingestuft und Nettopreise werden freigeschaltet. Ist sie ungültig oder fehlt sie, bleibt das Konto im B2C-Modus. Dieser Schritt klingt klein, hat aber erhebliche steuerrechtliche und operative Konsequenzen – und wird in der Projektvorbereitung fast immer vergessen.
Schnittstellen & Produktdaten
Shopware mit ERP, PIM und Warenwirtschaft verbinden.
Je größer ein Shop wird, desto weniger darf Shopware isoliert laufen. Produktdaten, Preise, Lagerbestände, Bestellungen, Kundendaten, Versandinformationen und Marktplatzdaten müssen zuverlässig zwischen Systemen fließen. Wir bauen Schnittstellen nicht nur technisch lauffähig, sondern wartbar, nachvollziehbar und passend zu euren echten Geschäftsprozessen.
JTL-Wawi
Akeneo PIM
SAP-nahe Systeme
Billbee
DHL / Versand
Datev / Buchhaltung
CRM-Systeme
Marktplätze
Payment-Systeme
Interne APIs
ERP-Systeme
externe Datenquellen
Was bei Shopware-Integrationen wirklich entscheidet
Wer ist das führende System – Shopware oder das ERP?
Die wichtigste Frage vor jeder Integrationsplanung ist nicht technischer, sondern organisatorischer Natur: Welches System gilt als Quelle der Wahrheit? Wird ein Produkt im ERP angelegt und dann in Shopware übertragen? Oder wird es im Shop gepflegt und ins ERP synchronisiert? Bei Preisen und Lagerbeständen ist das meistens klar – die kommen aus dem ERP. Bei Produkttexten, Bildern und SEO-Metadaten oft nicht. Wer diese Frage nicht explizit beantwortet, baut eine Schnittstelle, die in beide Richtungen schreibt – und bei Konflikten nicht weiß, welcher Wert der richtige ist. Das führt zu Datenverlust und manuellen Korrekturen im Produktivbetrieb.
Echtzeit-Sync vs. Batch-Import: wann welcher Ansatz richtig ist
Nicht jede Datenart muss in Echtzeit synchronisiert werden – aber manche unbedingt. Lagerbestände, die nur einmal täglich aktualisiert werden, führen im Produktivbetrieb zu Überverkäufen. Preise, die mit zwölf Stunden Verzögerung ankommen, können bei B2B-Kunden zu falschen Angeboten führen. Produkttexte und Bilder hingegen brauchen keine Sekunden-Synchronisation. Ein sinnvolles Integrationskonzept unterscheidet deshalb zwischen zeitkritischen Daten (Echtzeit oder Minuten-Takt) und unkritischen Daten (nächtlicher Batch). Wer pauschal alles per Cronjob synchronisiert, spart Entwicklungsaufwand – und kauft sich dafür operative Probleme.
Was passiert, wenn ein API-Call fehlschlägt?
Die meisten einfach entwickelten Schnittstellen haben keine Antwort auf diese Frage. Ein Timeout, ein HTTP-500-Fehler oder ein temporär nicht erreichbares ERP führt dazu, dass eine Bestellung nicht übertragen, ein Lagerbestand nicht aktualisiert oder ein Preis nicht geladen wird. Ohne Fehlerbehandlung, Retry-Logik und ein Dead-Letter-System – also eine Queue für fehlgeschlagene Vorgänge, die erneut verarbeitet werden können – gehen diese Ereignisse still verloren. In der Praxis bedeutet das: Bestellungen, die im ERP fehlen, werden erst beim nächsten manuellen Abgleich entdeckt. Eine robuste Schnittstelle behandelt Fehler genauso sorgfältig wie den Erfolgsfall.
Das Lagerbestand-Reservierungsproblem
Wann gilt ein Artikel als reserviert – sobald er im Warenkorb liegt, oder erst wenn die Bestellung bezahlt ist? In Shopware wird Bestand standardmäßig erst bei Bestellabschluss reduziert. Im ERP passiert das oft erst, wenn die Bestellung verarbeitet wird – mit weiterer Verzögerung durch die Synchronisation. In diesem Zeitfenster kann derselbe Artikel mehrfach verkauft werden. Die Lösung hängt vom Geschäftsmodell ab: Shops mit hohem Bestellvolumen und knappem Lager brauchen eine Echtzeit-Reservierung direkt beim Bestellabschluss oder sogar beim Checkout-Start. Shops mit breitem Sortiment und hohen Beständen können damit leben. Diese Entscheidung gehört in die Konzeptphase – nicht in den Hotfix nach dem ersten Überverkauf.
Produktdaten-Mapping ist immer aufwändiger als geplant
ERP-Systeme speichern Produktdaten in einer Struktur, die für Warenwirtschaft optimiert ist – nicht für E-Commerce. Artikelnummern, Einheiten, Gewichte, Zolltarifnummern: das passt ins ERP. Mehrsprachige Beschreibungen, Produktvarianten mit Größen- und Farbattributen, SEO-URLs, kategorisierte Bilder in definierten Auflösungen: das erwartet Shopware. Das Mapping zwischen diesen beiden Welten ist fast immer die aufwändigste und fehleranfälligste Stelle einer Integration. Datenfelder haben unterschiedliche Längen, Typen und Pflichtfelder. Sonderzeichen verursachen Importfehler. Fehlende Pflichtfelder blockieren ganze Produkte. Ein sauberes Mapping-Konzept vor der Entwicklung spart Wochen im Projekt.
Integrationen testen ohne Live-Daten zu beschädigen
ERPs haben oft nur eine einzige Produktivinstanz – kein Testsystem, kein Sandbox-Modus. Das bedeutet: Wer eine neue Schnittstelle testet, arbeitet entweder gegen das Live-System (riskant) oder baut sich eine Testumgebung, die Produktivdaten spiegelt (aufwändig). Für Shopware existiert üblicherweise ein Staging-System – aber ohne ERP-Testinstanz ist ein vollständiger End-to-End-Test nicht möglich. Pragmatische Lösung: eine Testphase mit echten Daten in einem kontrollierten Zeitfenster, mit explizitem Rollback-Plan und klaren Kriterien, wann ein Test als bestanden gilt. Dieser Plan gehört genauso ins Projekt wie die Entwicklung selbst – und wird fast immer zu spät erstellt.
Plugin-Entwicklung
Individuelle Shopware Plugins, wenn Standard nicht mehr sauber reicht.
Nicht jede Anforderung sollte mit dem nächsten Plugin gelöst werden. Zu viele Erweiterungen machen Shops schwer wartbar, langsam und abhängig von fremden Update-Zyklen. Wir prüfen, ob eine Standardlösung reicht – oder ob ein individuelles Shopware Plugin langfristig sauberer ist.
Unser Ziel ist nicht, möglichst viel Code zu schreiben. Unser Ziel ist, die richtige technische Lösung zu bauen: schlank, updatefähig und wirtschaftlich sinnvoll.
Plugin-Bedarf besprechenIndividuelle Produktlogik
Preis- & Rabattregeln
Import-/Exportprozesse
B2B-Freigaben
Angebotsfunktionen
Konfiguratoren
Schnittstellenlogik
Spezielle Checkout-Prozesse
Datenvalidierung
Admin-Erweiterungen
Interne Workflows
Was bei Shopware Plugin-Entwicklung wirklich zählt
Plugin, App oder Service Decorator – was ist der richtige Ansatz?
Shopware 6 bietet drei verschiedene Erweiterungswege, die sich grundlegend in Komplexität, Wartbarkeit und Einsatzbereich unterscheiden. Ein klassisches Plugin läuft im selben PHP-Prozess wie Shopware, hat direkten Zugriff auf alle Services und die DAL – ist aber eng mit der Shopware-Version gekoppelt. Eine App läuft extern, kommuniziert über Webhooks und die Admin API und ist deutlich entkoppelter – dafür aber auf die öffentliche API beschränkt und für komplexe Storefront-Eingriffe ungeeignet. Ein Service Decorator ist kein eigenständiges Plugin, sondern ein gezielter Eingriff in einen einzelnen Shopware-Service via Dependency Injection – schlanker, wartbarer und oft die unterschätzte beste Lösung für fokussierte Anpassungen. Wer immer zum klassischen Plugin greift, wählt oft mehr Komplexität als nötig.
Warum jedes Plugin den Shopware-Boot-Prozess verlangsamt
Shopware 6 basiert auf dem Symfony Dependency Injection Container – und jedes Plugin, das installiert ist, wird beim Container-Build berücksichtigt. Das bedeutet: selbst ein Plugin, das gerade nichts tut, trägt zur Startzeit des Containers bei. Bei wenigen Plugins ist das vernachlässigbar. Bei zwanzig oder mehr Plugins, von denen jedes eigene Services, Event-Listener und Twig-Erweiterungen registriert, summiert sich der Overhead messbar. Hinzu kommt der Rendering-Prozess: jedes Plugin, das Twig-Templates erweitert oder überschreibt, verlängert die Template-Kompilierung. Wer einen langsamen Shopware-Shop hat und ihn beschleunigen will, sollte als ersten Schritt alle installierten Plugins auflisten – auch die inaktiven, denn auch die werden geladen.
Update-Kompatibilität ist keine Selbstverständlichkeit
Shopware 6 veröffentlicht regelmäßig Minor-Updates, die interne APIs, Service-Namen und Event-Strukturen ändern können. Plugins, die direkt auf interne Shopware-Klassen referenzieren statt auf stabile Interfaces, brechen bei solchen Updates ohne Vorwarnung. Das ist der entscheidende Unterschied zwischen einem schnell entwickelten Plugin und einem wartbaren Plugin: Wer auf dokumentierte Interfaces und öffentliche APIs aufbaut, hat deutlich weniger Update-Aufwand. In der Praxis bedeutet das: nach jedem Shopware-Minor-Release müssen alle installierten Plugins gegen die neue Version getestet werden – idealerweise auf einem Staging-System, bevor das Update live geht. Wer das nicht tut, entdeckt Inkompatibilitäten im Produktivbetrieb.
Admin-Erweiterungen brauchen Vue.js-Kenntnisse
Viele Backend-Entwickler unterschätzen, dass Shopware-6-Admin-Oberflächen komplett in Vue.js gebaut sind. Wer ein Plugin entwickelt, das eigene Konfigurationsseiten, neue Tabellen oder angepasste Bestellübersichten im Admin zeigen soll, schreibt dafür Vue-Komponenten – nicht PHP. Das Shopware Administration Framework bietet dafür eigene Basiskomponenten, die verstanden und korrekt verwendet werden müssen. Ein Plugin, das nur Storefront-Logik oder API-Endpunkte anpasst, kommt ohne Vue aus. Sobald aber Admin-UI-Elemente gefordert sind, ist Vue.js-Erfahrung keine optionale Qualifikation, sondern Voraussetzung. Dieser Punkt wird in Projekten regelmäßig zu spät erkannt.
Scheduled Tasks und Message Queue: zwei verschiedene Werkzeuge
Shopware 6 hat zwei Mechanismen für asynchrone oder zeitgesteuerte Prozesse – und sie sind nicht austauschbar. Scheduled Tasks laufen zeitgesteuert (z.B. jede Stunde) und eignen sich für wiederkehrende Aufgaben wie Daten-Cleanups, Statusprüfungen oder regelmäßige Exporte. Die Message Queue (basierend auf Symfony Messenger) ist für ereignisgesteuerte, asynchrone Verarbeitung gedacht: eine Bestellung wird aufgegeben, eine Nachricht wird in die Queue geschrieben, ein Worker verarbeitet sie im Hintergrund. Der Vorteil der Queue: sie ist robust bei Fehlern (Retry-Logik, Dead-Letter-Queue), skalierbar und entkoppelt. Wer zeitintensive Operationen direkt im Request-Zyklus ausführt statt sie in die Queue auszulagern, baut sich Performance-Probleme – besonders bei hohem Bestellvolumen.
Plugin vs. Drittanbieter-Extension: die echte Buy-or-Build-Entscheidung
Für viele Anforderungen gibt es bereits Plugins im Shopware Store – die Frage ist, ob sie die Anforderung wirklich sauber lösen. Drittanbieter-Plugins haben einen echten Vorteil: sie sind sofort verfügbar und günstiger als Individualentwicklung. Sie haben aber auch systematische Nachteile: Sie bringen oft mehr Funktionen mit als benötigt, was den Overhead erhöht. Sie werden nach fremden Release-Zyklen aktualisiert, nicht nach eurem. Ihre Konfiguration ist begrenzt – was nicht vorgesehen ist, lässt sich nicht anpassen. Und bei Plugin-Konflikten oder Bugs seid ihr auf den Hersteller angewiesen. Der Break-even kippt zugunsten von Individualentwicklung früher als man denkt: sobald ein Drittanbieter-Plugin angepasst, umgangen oder dauerhaft betreut werden muss, übersteigen die Gesamtkosten oft die einer sauberen Eigenentwicklung.
Performance & technische SEO
Shopware Performance ist kein Feinschliff – sie entscheidet über SEO, Conversion und Skalierung.
Ein langsamer Shopware-Shop kostet Sichtbarkeit, Werbebudget und Umsatz. Wir analysieren nicht nur Pagespeed-Werte, sondern die Ursachen: Storefront, Theme, Plugins, Datenbank, Server, Caching, Bilder, Skripte, Tracking und Drittanbieter-Code.
Performance
Core Web Vitals
Template- und Storefront-Performance
Plugin-Auswirkungen analysieren
Bildgrößen und Medienlogik
JavaScript- und CSS-Last
Caching-Konfiguration
Serverkonfiguration
Datenbankabfragen
Listing- und Filter-Performance
Tracking-Skripte optimieren
Mobile Performance
Suche und Suchindex
Technische SEO
URL-Struktur & Kategorie-Architektur
Canonicals & Duplicate Content
hreflang bei internationalen Shops
Strukturierte Daten (Schema.org)
Indexierungssteuerung
Weiterleitungen & SEO-Erhalt bei Relaunches
Interne Verlinkung
Produktvarianten & Duplicate Content
Technische Produktdatenqualität
Meta Titles & Descriptions
Was bei Shopware Performance und SEO wirklich zählt
PageSpeed Insights zeigt Lab-Daten – Google rankt nach Felddaten
Der PageSpeed-Score, den du im Browser siehst, basiert auf einer simulierten Messung unter kontrollierten Laborbedingungen. Google nutzt für das Ranking jedoch echte Nutzerdaten aus dem Chrome User Experience Report (CrUX) – gemessen auf realen Geräten, in echten Netzwerken, mit echtem Nutzerverhalten. Ein Shop kann einen PageSpeed-Score von 95 haben und trotzdem schlechte Feldwerte aufweisen, wenn viele Nutzer auf langsamen Mobilgeräten unterwegs sind oder wenn JavaScript-intensive Elemente spät interaktiv werden. Umgekehrt kann ein Shop mit Score 60 gute Feldwerte haben. Wer Performance ausschließlich mit dem Insights-Tool misst, optimiert für das Lab – nicht für Google. Die relevante Wahrheit steht in der Google Search Console unter "Core Web Vitals" und im CrUX Dashboard.
Der HTTP-Cache ist der größte einzelne Performance-Hebel in Shopware
Shopware 6 hat einen eingebauten HTTP-Cache auf Basis von Symfony HTTP Cache oder optionalem Varnish – und viele Shops haben ihn nicht korrekt konfiguriert. Ein funktionierender HTTP-Cache bedeutet: vollständig gerenderte HTML-Seiten werden zwischengespeichert und bei Wiederholungsaufrufen direkt ausgeliefert, ohne dass PHP, Symfony und Datenbankabfragen erneut durchlaufen werden. Die Ladezeit sinkt von mehreren Sekunden auf unter 100 Millisekunden. Das Problem: der Cache wird durch viele Ereignisse invalidiert – Produktaktualisierungen, Plugin-Hooks, Custom-Felder, eingeloggte Nutzer und aktive Warenkorbsessions. Ein schlecht konfigurierter Cache ist einer, der ständig geleert wird und deshalb nie greift. Bevor Performance-Optimierung auf Ebene von Datenbankindizes oder Bildkomprimierung beginnt, sollte immer geprüft werden, ob der HTTP-Cache überhaupt korrekt funktioniert – mit dem richtigen Cache-Status-Header in der Server-Antwort.
Warum Shopware-Shops auf echten Mobilgeräten langsamer sind als im Test
Shopware-Storefronts laden standardmäßig das gesamte JavaScript-Bundle des Themes und aller aktiven Plugins auf jeder Seite. Auf einem Desktop-Rechner mit schnellem Prozessor wird dieses Bundle in Millisekunden geparst und ausgeführt. Auf einem zwei Jahre alten Mittelklasse-Android-Gerät dauert derselbe Vorgang mehrere Sekunden – und blockiert währenddessen den Haupt-Thread, sodass die Seite nicht interaktiv ist. Google misst genau diesen Moment: INP (Interaction to Next Paint) erfasst, wie lange es dauert, bis der Browser auf eine Nutzerinteraktion reagiert. Plugins, die für jede Storefront-Seite eigene Event-Listener registrieren oder umfangreiche Drittanbieter-Skripte nachladen, sind die häufigste Ursache. Lösungsansatz: Code-Splitting, Lazy Loading von Plugin-Skripten und ein Audit aller geladenen Third-Party-Ressourcen pro Seitentyp.
Wie Shopware unkontrolliert tausende indexierbare URLs erzeugt
Shopware generiert aus Kategoriepfaden mit aktiven Filtern eigenständige URLs – und indexiert sie standardmäßig. Ein Kategoriepfad mit zehn Filterdimensionen kann mathematisch Tausende von URL-Kombinationen erzeugen: /kategorie?farbe=rot&größe=M, /kategorie?farbe=blau&größe=L, und so weiter. Jede dieser Seiten ist für Google eine eigenständige URL – mit häufig identischem oder sehr ähnlichem Content. Das Ergebnis: Crawl-Budget wird auf Seiten verwendet, die nie ranken werden, relevante Seiten werden seltener gecrawlt, und die Gesamtstärke der Domain wird auf hunderte Seiten mit dünnem Content aufgeteilt. Lösung: eine Indexierungsstrategie, die Filter-URLs per robots.txt oder meta robots noindex aus dem Index hält – und gleichzeitig sicherstellt, dass sinnvolle Kombinations-URLs (z.B. eine Kategorie mit einem wichtigen Filter) weiterhin indexiert werden können.
Canonical Tags in Shopware: wo die Fallstricke wirklich liegen
Shopware 6 setzt Canonical Tags grundsätzlich – aber nicht immer richtig. Das häufigste Problem: Produktvarianten erhalten in Shopware eigene URLs (z.B. /produkt/t-shirt-rot) und referenzieren sich gegenseitig per Canonical. Wenn die Hauptvariante falsch konfiguriert ist oder keine klare Stammvariante definiert wurde, zeigen alle Varianten auf unterschiedliche Canonicals – und Google indexiert alle als eigenständige Seiten mit dünnem Content. Ein zweites Problem betrifft Paginierung: Shopware unterstützt kein rel=prev/next mehr (Google hat es abgeschafft), aber viele Themes rendern paginated Category-URLs ohne klare Canonical-Strategie. Hinzu kommen URL-Parameter durch Tracking (utm_source, etc.), die ohne Canonical-Regel Duplicate-Content-Signale erzeugen. Eine technische SEO-Prüfung eines Shopware-Shops beginnt immer mit einem vollständigen Crawl und Canonical-Analyse.
INP hat FID als Core Web Vital ersetzt – was das für Shopware bedeutet
Seit März 2024 ist INP (Interaction to Next Paint) offiziell Rankingfaktor und hat FID (First Input Delay) abgelöst. FID maß nur die Verzögerung bis zur ersten Interaktion – INP misst die Reaktionszeit auf alle Interaktionen während der gesamten Sitzung, vom ersten Klick bis zum letzten. Das ist ein deutlich härterer Maßstab. Ein Shopware-Shop, der beim Klick auf einen Filter drei Sekunden braucht, um die Ergebnisse zu aktualisieren, hat einen schlechten INP-Wert – selbst wenn LCP und CLS perfekt sind. Besonders betroffen sind Shopware-Shops mit Live-Search-Plugins, AJAX-Filtern, Cart-Updates oder Konfigurator-Logiken, die schwere JavaScript-Operationen im Haupt-Thread ausführen. Die Optimierung von INP erfordert eine andere Herangehensweise als LCP-Optimierung: es geht nicht um schnelleres Laden, sondern um geringere JavaScript-Execution-Zeit bei Nutzerinteraktionen.
Systemwahl
Shopware oder Shopify – welches System passt besser zu eurem Wachstum?
Shopify ist stark, wenn Shops schnell, stabil und standardisiert wachsen sollen. Shopware spielt seine Stärken aus, wenn Produktdaten, B2B-Prozesse, individuelle Preislogiken, Multishop-Strukturen oder Systemintegrationen komplexer werden. Wir helfen euch, die Entscheidung nach Geschäftsmodell, Prozessen und technischer Zukunftsfähigkeit zu treffen.
Shopify passt oft besser, wenn …
schneller Markteintritt wichtig ist
D2C und B2C im Fokus stehen
möglichst wenig technischer Betrieb gewünscht ist
Standardprozesse ausreichend sind
das App-Ökosystem schnell helfen soll
Shopify ist stark für schnell wachsende Shops mit klaren Standardprozessen und wenig individuellem Entwicklungsbedarf.
Shopware passt oft besser, wenn …
individuelle Geschäftslogik wichtig ist
B2B, B2C oder hybride Modelle abgebildet werden müssen
Systemarchitektur und Anpassbarkeit wichtiger sind
ERP/PIM/Warenwirtschaft tief integriert werden müssen
individuelle Plugins und Datenmodelle sinnvoller sind
Shopware spielt seine Stärken bei komplexen Produktdaten, B2B-Prozessen und tiefer Systemintegration aus.
Wir entwickeln beide Systeme und beraten neutral auf Basis von Anforderungen, Prozessen und Wirtschaftlichkeit.
Systementscheidung prüfen lassenShopware Agentur Bielefeld & OWL
Shopware Agentur aus Bielefeld für OWL und ganz Deutschland.
Webcellent sitzt in Bielefeld und unterstützt Unternehmen aus Ostwestfalen-Lippe und ganz Deutschland bei technischen Shopware-Projekten. Viele Abstimmungen laufen effizient remote, bei Bedarf aber auch persönlich in der Region. Besonders stark sind wir für Unternehmen, die Shopware nicht nur als Shop, sondern als zentralen Teil ihrer E-Commerce- und Prozesslandschaft verstehen.
Wenn ihr Shopify und Shopware vergleichen möchtet, findet ihr unsere Shop-Leistungen im Überblick.
Regional erreichbar
Für Unternehmen aus Bielefeld, OWL und ganz Deutschland sind wir als technischer Shopware-Partner nahbar, schnell erreichbar und persönlich im Austausch.
Technisch spezialisiert
Wir verbinden Shopware-Entwicklung mit Schnittstellen, Produktdaten, SEO, Performance und E-Commerce-Prozessen.
Mittelstandsnah
Wir verstehen gewachsene Systeme, interne Prozesse, knappe Ressourcen und die Realität mittelständischer E-Commerce-Projekte.
Remote effizient
Strategie, Umsetzung und technische Abstimmung funktionieren remote schnell und strukturiert – persönliche Termine in OWL sind bei Bedarf möglich.
Shopware-Projekte aus der Praxis
Ein Auszug aus Shopware- und E-Commerce-Projekten, die wir für Unternehmen entwickelt, migriert oder optimiert haben.
Shopware-6-Migration
STG
Shopware-Relaunch
Wacker’s Kaffee
Prozess
So starten wir Shopware-Projekte.
Wir arbeiten nicht nur an Templates, sondern an belastbaren Commerce-Systemen mit einem klaren Ablauf von Analyse bis Optimierung.
1
Analyse
Wir prüfen Shopware-Version, Theme, Plugins, Datenmodell, Schnittstellen, SEO, Tracking, Performance und Geschäftsprozesse.
2
Architektur
Wir definieren, welche Funktionen Standard bleiben, wo individuelle Entwicklung sinnvoll ist und wie Shopware sauber mit euren Systemen zusammenspielt.
3
Entwicklung
Wir entwickeln Storefront-Anpassungen, Plugins, Schnittstellen, B2B-Funktionen und technische Optimierungen.
4
Integration
Wir verbinden Shopware mit ERP, PIM, Warenwirtschaft, Versand, Payment, Marktplätzen oder internen Tools.
5
Testing
Wir testen Performance, Tracking, Checkout, Schnittstellen, SEO-Basics, Datenflüsse und mobile Nutzung.
6
Launch
Wir begleiten Livegang, Weiterleitungen, Tracking, Indexierung, Monitoring und technische Stabilität.
7
Optimierung
Nach dem Launch verbessern wir Conversion, Geschwindigkeit, Datenqualität, Prozesse und technische Skalierbarkeit.
Shops, die beim nächsten Wachstumsschritt nicht wieder umgebaut werden müssen.
Wir bauen keine Templates. Wir bauen Commerce-Systeme mit sauberer Struktur, klaren Daten und einer Architektur, die mit eurem Business mitwächst.
Kein Plugin-Wildwuchs — wir bauen, was langfristig skaliert
Commerce, Technik und Produktdaten aus einer Hand
SEO-Basis, Tracking und Schnittstellen von Anfang an mitgedacht
Saubere Komponenten statt aufgeblasene Themes
Erfahrung aus Shopify- und Shopware-Projekten jeder Größe
Entwicklung, die nach dem Launch weitergeht
FAQ
Häufige Fragen zur Shopware Entwicklung
Was macht eine Shopware Agentur?
Eine Shopware Agentur entwickelt, optimiert und betreut Shopware-Shops. Das umfasst Shop-Aufbau, Shopware 6 Entwicklung, Migration von Shopware 5, Plugin-Entwicklung, Schnittstellen zu ERP/PIM, B2B-Funktionen, Performance-Optimierung, SEO und laufende technische Betreuung. Webcellent geht dabei über reine Theme-Arbeit hinaus und entwickelt Shopware als vollständiges Commerce-System.
Wann ist Shopware die richtige Wahl?
Shopware ist besonders stark, wenn Produktdaten, Geschäftslogiken oder Systemintegrationen komplex werden: B2B-Prozesse, individuelle Preisstrukturen, tiefgreifende ERP/PIM-Anbindungen, Multishop-Strukturen oder Shops mit vielen Varianten und Eigenschaften. Wenn Standardprozesse und schnelles Wachstum im Vordergrund stehen, kann Shopify besser passen – wir beraten offen.
Was kostet ein Shopware-Shop?
Ein technisch sauberer Shopware 6 Shop startet ab ca. 8.000–12.000 €, je nach Umfang, Theme, Datenstruktur und Schnittstellen. Migrationen und komplexere Setups mit B2B-Funktionen oder tiefen Schnittstellen liegen je nach Anforderungen zwischen 15.000 und 80.000 €. Ein technischer Audit oder Konzept startet ab 2.500 €.
Unterstützt ihr Migrationen von Shopware 5 auf Shopware 6?
Ja. Wir begleiten Shopware-5-auf-6-Migrationen von der Analyse des bestehenden Setups über Datenmodell, URL-Mapping, Weiterleitungen, Plugin-Inventur und Schnittstellenplanung bis zum Launch und der technischen Abnahme. Ziel ist eine Migration ohne Datenverlust und ohne SEO-Einbrüche.
Entwickelt ihr individuelle Shopware Plugins?
Ja. Wir entwickeln individuelle Shopware Plugins, wenn Standard-Erweiterungen eure Anforderungen nicht sauber, performant oder wartbar abbilden. Unser Fokus liegt dabei auf schlanken, updatefähigen und wirtschaftlich sinnvollen Lösungen – nicht auf unnötiger Komplexität.
Kann Shopware mit ERP oder PIM verbunden werden?
Ja. Shopware bietet eine umfangreiche API und DAL-Schicht, über die Verbindungen zu ERP-Systemen (JTL, SAP-nahe, etc.), PIM-Systemen wie Akeneo, CRM, Versanddienstleistern und anderen Datenquellen aufgebaut werden können. Wir entwickeln Schnittstellen, die wartbar sind und zu euren echten Betriebsprozessen passen.
Ist Shopware für B2B geeignet?
Ja. Shopware 6 hat eine starke B2B-Grundlage: Kundengruppen, Preislisten, Nettodarstellung und Rollen sind nativ verfügbar. Für komplexere B2B-Anforderungen wie Freigabeprozesse, Angebotslogiken, Budget-Steuerung oder tiefe ERP-Anbindung entwickeln wir individuelle Erweiterungen.
Wie kann man einen Shopware-Shop schneller machen?
Performance verbessern wir durch Analyse der tatsächlichen Ursachen: Theme-Code, Plugin-Auswirkungen, Datenbankabfragen, Bildoptimierung, Caching-Konfiguration, Serversetup und Skript-Last. Wir optimieren dort, wo die größten messbaren Hebel liegen – nicht nach Checkliste.
Macht ihr Shopware SEO?
Wir legen die technische SEO-Basis für Shopware-Shops: URL-Struktur, Weiterleitungen, Canonicals, strukturierte Daten, Indexierungssteuerung, interne Verlinkung und saubere Kategoriearchitektur. Laufende Content-SEO-Betreuung ist nicht unser Hauptfokus.
Arbeitet ihr als Shopware Agentur auch für Unternehmen aus Bielefeld?
Ja. Webcellent sitzt in Bielefeld und unterstützt Unternehmen aus OWL und ganz Deutschland bei technischen Shopware-Projekten. Viele Abstimmungen laufen effizient remote, bei Bedarf sind aber auch persönliche Termine in der Region möglich.
Betreut ihr Shopware-Shops auch nach dem Launch?
Ja. Wir begleiten Shopware-Shops nach dem Launch bei technischer Weiterentwicklung, Updates, Monitoring, Bugfixes, Performance-Optimierung und Conversion-Verbesserungen – projektweise oder über Retainer.
Was ist besser: Shopware oder Shopify?
Das hängt vom Geschäftsmodell ab. Shopify ist stark für schnell skalierende D2C-Shops mit Standardprozessen. Shopware passt besser, wenn Produktdaten komplex sind, B2B-Prozesse abgebildet werden müssen oder tiefe ERP/PIM-Integrationen nötig sind. Wir beraten technisch und wirtschaftlich neutral – und entwickeln beide Systeme.
PROJEKT ANFRAGEN
Lasst uns prüfen, wie euer Shopware-Shop technisch sauber wachsen kann.
Ob Shopware 6 Entwicklung, Migration, B2B-Funktionen, Plugin-Entwicklung, Schnittstellen, Performance oder technische SEO: Wir schauen uns euer Setup an und zeigen euch, welche nächsten Schritte wirklich sinnvoll sind.
Erste Einschätzung zu Idee, Scope und Aufwand
Direkter Austausch mit Entwicklern
Kein Vertriebsdruck, sondern ehrliche Einordnung
Erfahrung aus Software-, Shop- und Schnittstellenprojekten
Dein Ansprechpartner
Christopher Diamant
Geschäftsführer & Inhaber
Deine Anfrage kommt direkt bei mir an. Ich melde mich schnellstmöglich persönlich zurück.
Zertifizierungen