Zu viele Apps
Jeder neue Use Case wird mit einer weiteren App gelöst. Das macht den Shop langsamer, teurer und schwerer wartbar.
Shopify Agentur für Bielefeld, OWL & ganz Deutschland
Wir entwickeln Shopify-Shops für Unternehmen aus Bielefeld, OWL und ganz Deutschland, die technisch sauber aufgebaut sind, schnell laden und verkaufen. Von Shop-Aufbau und Relaunch über individuelle Shopify Apps bis zu ERP-, PIM- und Warenwirtschafts-Schnittstellen schaffen wir Lösungen, die zu euren Prozessen passen – nicht andersherum.
~$webcellent shopify --scope "shop system"
->Shopify API · Custom App Layer ...
->ERP/PIM Sync · Checkout Flows ...
->Performance Budget · Conversion Tracking ...
✓deploy ready in 8 weeks
~$
Das Problem
Shopify ist ein starkes System – aber viele Shops werden mit der Zeit langsam, unübersichtlich oder abhängig von zu vielen Apps. Genau dort setzen wir an: individuelle Lösungen, automatisierte Prozesse, bessere Performance und technische Grundlagen für Wachstum.
Shopify-Projekt anfragenJeder neue Use Case wird mit einer weiteren App gelöst. Das macht den Shop langsamer, teurer und schwerer wartbar.
Produktdaten, Bestellungen, Lagerbestände oder Kundendaten werden manuell gepflegt, obwohl vieles automatisierbar wäre.
Das Design sieht gut aus, aber Ladezeit, Struktur, UX und Conversion-Pfade passen nicht mehr zum Geschäftsmodell.
GA4, Meta, Google Ads oder Consent sind nicht sauber verbunden. Entscheidungen basieren auf unvollständigen Daten.
Shopify funktioniert out of the box gut – aber wachsende Shops brauchen oft individuelle Logik, die kein Standard-Theme liefert.
Leistungen
Von neuen Shopify-Shops über individuelle Funktionen bis zu komplexen Schnittstellen entwickeln wir Lösungen, die technisch sauber, wartbar und auf Wachstum ausgelegt sind.
Wir entwickeln neue Shopify-Shops mit sauberer Struktur, performanten Themes, klarer UX und technischer Grundlage für SEO, Tracking und Wachstum.
Wir überführen bestehende Shops in ein modernes Shopify-Setup – inklusive URL-Konzept, Weiterleitungen, Datenmigration, Theme-Aufbau und Tracking.
Wir passen bestehende Themes an oder entwickeln individuelle Shopify-Frontends, die exakt zu Marke, Sortiment und Conversion-Zielen passen.
Wir bauen individuelle Shopify Apps, wenn Standard-Apps zu teuer, zu langsam oder zu unflexibel sind.
Wir verbinden Shopify mit ERP, PIM, CRM, Warenwirtschaft, Versand, Buchhaltung oder individuellen internen Systemen.
Wir analysieren Ladezeiten, Theme-Code, App-Last, Bilder, Skripte und Core Web Vitals – und optimieren dort, wo es messbar wirkt.
Wir verbessern Produktseiten, Navigation, Warenkorb, Checkout-Vorbereitung, Trust-Elemente und Angebotslogik.
Wir schaffen saubere technische SEO-Grundlagen: Informationsarchitektur, Meta-Daten, strukturierte Daten, Indexierung, Weiterleitungen und interne Verlinkung.
Beim Aufbau eines neuen Shopify-Shops werden früh Entscheidungen getroffen, die später teuer zu ändern sind. Die wichtigste davon: Wie wird die Produktdatenstruktur aufgebaut? Shopify arbeitet mit Metafeldern für strukturierte Produktdaten wie technische Spezifikationen, Maßangaben oder Zertifikate. Wer diese später nachrüstet, muss das Theme umbauen. Mit Online Store 2.0 hat Shopify die Sektionen-Logik grundlegend verändert: Inhalte werden per Drag-and-drop in Templates gepflegt – das gibt Redakteuren mehr Flexibilität, erfordert aber ein Theme, das diese Logik sauber unterstützt. Ein weiterer Entscheidungspunkt ist die Headless-Frage: Shopify als reines Backend mit eigenem React-Frontend (Hydrogen) bietet maximale Flexibilität, erhöht aber Entwicklungsaufwand und laufende Kosten erheblich. Für die meisten Shops ist ein gut entwickeltes Liquid-Theme die bessere Entscheidung – performant, wartbar und ohne unnötige Komplexität.
Ein Shopify-Relaunch ist riskanter als er aussieht – weil drei kritische Systeme gleichzeitig angefasst werden: SEO, Tracking und Datenbasis. Die häufigste Fehlerquelle ist das URL-Mapping: Shopify erzwingt bestimmte URL-Strukturen (/products/, /collections/), die sich von Shopware, WooCommerce oder individuellen Altsystemen unterscheiden. Ohne vollständiges URL-Crawl des alten Systems und lückenlose 301-Weiterleitungen verliert der Shop Rankings, die sich über Jahre aufgebaut haben. Der zweite Schwachpunkt ist Tracking: GA4, Meta Pixel und Google Ads müssen nach einem Relaunch validiert werden – nicht nur eingerichtet, sondern mit echten Testbestellungen überprüft. Conversion-Events, die nach dem Launch still nicht auslösen, werden erst Wochen später in den Werbedaten sichtbar. Ein sauberer Relaunch hat deshalb immer eine explizite Abnahmecheckliste für SEO und Tracking – vor dem Livegang, nicht danach.
Shopify-Themes basieren auf der Liquid-Templatesprache – Shopifys eigenem serverseitigen Rendering-System. Das bedeutet: Jede Seite wird auf Shopifys Servern gerendert und als fertiges HTML ausgeliefert, was grundsätzlich gut für Performance und SEO ist. Das Problem entsteht, wenn zu viele Apps eigene JavaScript-Blöcke in den Theme-Code injizieren – jeder App-Block erhöht die Renderzeit und die JavaScript-Last beim Nutzer. Ein gut entwickeltes Shopify-Theme trennt sauber zwischen Theme-Logik und App-Logik, lädt Skripte lazy und nutzt Shopifys native Section-Architektur für flexible, wartbare Templates. Beim Einsatz des kostenlosen Shopify-Basis-Themes Dawn als Ausgangspunkt empfiehlt sich eine sorgfältige Prüfung: Dawn ist performant und gut strukturiert, aber nicht für jede Marke und jedes Sortiment direkt geeignet – der Anpassungsaufwand sollte realistisch eingeschätzt werden, bevor es als schnelle Lösung verwendet wird.
Shopify unterscheidet zwischen Public Apps (im App Store gelistet, für viele Shops nutzbar), Custom Apps (direkt im Shop installiert, ohne App-Store-Review) und Private Apps (älteres Modell, von Shopify weitgehend abgelöst). Für individuelle Entwicklung ist die Custom App der richtige Ansatz: Sie hat Zugriff auf alle Shopify APIs, benötigt keinen öffentlichen OAuth-Flow und muss keinen App-Store-Prüfprozess durchlaufen. Die wichtigste technische Einschränkung, die oft unterschätzt wird: Shopify hat strikte API-Rate-Limits. Wer mit der Admin REST API arbeitet, hat bei Basic-Plan-Shops nur 2 Anfragen pro Sekunde. Mit der GraphQL Admin API und dem Leaky-Bucket-Algorithmus lässt sich mehr herausholen – aber Bulk-Operationen wie große Produktimporte oder Preisanpassungen müssen explizit mit Shopifys Bulk Operations API geplant werden, nicht als Loop über hunderte Einzelaufrufe.
Shopify bietet zwei grundlegende Integrationsmuster: Webhooks und Polling. Webhooks sind ereignisgesteuert – Shopify sendet eine HTTP-Anfrage an eure Schnittstelle, sobald eine Bestellung eingeht, ein Produkt aktualisiert wird oder ein Kunde sich registriert. Das ist effizient und nahezu echtzeitnah. Polling fragt Shopifys API aktiv in Intervallen ab – einfacher zu implementieren, aber ressourcenintensiver und mit höherem Rate-Limit-Risiko. Das entscheidende Qualitätsmerkmal einer stabilen Schnittstelle ist die Fehlerbehandlung: Was passiert, wenn Shopify einen Webhook sendet, aber das Zielsystem nicht erreichbar ist? Ohne Retry-Logik und eine Queue für fehlgeschlagene Events gehen Daten still verloren. Für große Datentransfers – z.B. den initialen Import von zehntausenden Produkten aus einem ERP – ist Shopifys Bulk Operations API der einzig sinnvolle Weg: Sie arbeitet asynchron und ist explizit für große Datenmengen konzipiert.
Der häufigste Grund für schlechte Shopify-Performance ist nicht das Theme, sondern der App-Stack. Jede installierte App kann eigene JavaScript-Blöcke, externe Schriftarten, Tracking-Pixel oder CSS-Dateien in jede Seite injizieren. Zehn Apps mit je einer kleinen Skript-Datei ergeben zusammen schnell 500 KB zusätzliche JavaScript-Last – und damit mehrere Sekunden zusätzliche Blockierzeit auf Mobilgeräten. Shopify liefert Bilder über sein eigenes CDN aus und unterstützt automatische WebP-Konvertierung – aber nur, wenn das Theme die Shopify-Bild-URL-Parameter korrekt verwendet. Wer Bilder als statische URLs einbettet, verliert diesen Vorteil. Der größte Einzelhebel für LCP auf Produktseiten ist fast immer das Hero-Bild: es muss mit loading='eager' und fetchpriority='high' ausgezeichnet sein, damit der Browser es priorisiert. Das ist eine Zeile Code – und wird in den meisten Themes falsch gemacht.
Conversion-Optimierung bei Shopify beginnt nicht beim Checkout, weil der Shopify-Checkout selbst kaum veränderbar ist – erst ab Shopify Plus sind Checkout-Anpassungen mit der Checkout Extensibility API möglich. Die entscheidenden Hebel liegen vor dem Checkout: Wie ist die Produktseite aufgebaut? Wie schnell kommt der Nutzer von der Kategorie zum Produkt? Wie klar sind Kaufargumente, Lieferinformationen und Rückgabebedingungen kommuniziert? Ein weiterer oft unterschätzter Faktor: die mobile Nutzererfahrung. Mehr als 70 % der Shopify-Shopbesuche kommen auf Mobilgeräten – aber viele Themes sind auf Desktop-UX optimiert. Schlechte mobile Navigation, zu kleine Touch-Targets, langsam ladende Bilder oder ein Warenkorb-Drawer, der auf kleinen Bildschirmen schlecht funktioniert, kosten messbar Conversion. Bevor A/B-Tests starten, sollte eine Grundlage aus sauberem Tracking und ausreichender Datenmenge sichergestellt sein – sonst sind Testergebnisse statistisch nicht belastbar.
Shopify hat eine bekannte strukturelle SEO-Schwäche: Produkte können über mehrere URLs erreichbar sein. Ein Produkt, das in einer Collection eingebettet ist, hat die URL /collections/[collection]/products/[produkt] – zusätzlich zur kanonischen URL /products/[produkt]. Shopify setzt hier automatisch Canonical-Tags, aber nicht alle Themes und Apps respektieren diese Logik konsequent. Das Ergebnis: Google indexiert unter Umständen mehrere URLs für dasselbe Produkt. Eine zweite strukturelle Herausforderung sind Blog-Artikel als SEO-Instrument: Viele Shops betreiben einen Blog, aber die interne Verlinkung zwischen Blog-Inhalten und relevanten Collection- oder Produktseiten ist oft schwach. Google bewertet interne Links als Relevanzsignal – ein gut vernetzter Shop-Blog kann Rankings für Kategorie- und Produktseiten direkt unterstützen. Strukturierte Daten (Product Schema mit Preis, Verfügbarkeit und Bewertungen) sind für Shop-SEO inzwischen ein hygienisches Minimum – und in vielen Shopify-Themes entweder fehlend oder nicht korrekt implementiert.
Eure Anforderung ist dabei?
Shopify-Projekt anfragenUnser Ansatz
Wir kommen aus Entwicklung, E-Commerce und technischer Prozesslogik. Deshalb denken wir Shopify nicht nur als hübschen Shop, sondern als System aus Frontend, Daten, Schnittstellen, Automatisierung und Conversion.
Oft ausreichend für einfache Setups – aber bei Wachstum, Schnittstellen und individuellen Anforderungen schnell an Grenzen.
Wir kommen aus Entwicklung, E-Commerce und technischer Prozesslogik – deshalb verstehen wir Shopify nicht nur als Theme-System.
Custom Apps
Viele Shopify-Shops starten mit Standard-Apps. Das ist sinnvoll – bis der App-Stack teuer wird, Ladezeiten verschlechtert oder wichtige Geschäftsprozesse nur halb abbildet. Wir prüfen, welche Apps bleiben sollten und wo individuelle Programmierung langfristig besser ist.
App-Stack prüfen lassenWas bei Shopify App-Entwicklung wirklich zählt
Public App, Custom App oder Private App – was ist der richtige Ansatz?
Shopify unterscheidet drei App-Typen, die sich in Vertriebsweg, Authentifizierung und erlaubtem API-Zugriff grundlegend unterscheiden. Eine Public App durchläuft Shopifys App-Store-Review, nutzt OAuth für die Installation in beliebig vielen Shops und ist die richtige Wahl, wenn eine Lösung an viele Händler verteilt werden soll. Eine Custom App wird direkt im Admin eines einzelnen Shops erstellt, benötigt keinen Review-Prozess und ist mit einem API-Access-Token sofort einsatzbereit – ideal für shopspezifische Logiken ohne Overhead. Private Apps sind das ältere Modell und werden von Shopify nicht mehr empfohlen; neue Integrationen sollten immer als Custom App gebaut werden. Der entscheidende Unterschied im Alltag: Custom Apps können nicht versehentlich deinstalliert werden wie Public Apps, haben keinen App-Store-Listing-Overhead und lassen sich ohne Wartezeit auf Review-Freigabe deployen. Für individuell entwickelte Lösungen ist das fast immer der schnellere und sauberere Weg.
Wie App-Skripte die Shopify-Performance systematisch verschlechtern
Jede installierte Shopify-App kann über App Blocks, ScriptTags oder Theme-Injektionen eigene JavaScript- und CSS-Ressourcen in jede Seite einspeisen. Das passiert häufig ohne dass der Shop-Betreiber es merkt – denn viele Apps aktivieren ihre Skripte auf allen Seiten, auch wenn sie nur auf einer einzigen gebraucht werden. Ein Bewertungs-Widget, das auf der Startseite nichts tut, lädt trotzdem seine JavaScript-Bibliothek. Ein Chat-Plugin, das nur im Checkout relevant ist, blockiert trotzdem den Haupt-Thread auf Produktseiten. Die Summe dieser Skripte ist der häufigste Grund für schlechte Core-Web-Vital-Werte in Shopify-Shops. Eine sauber entwickelte Custom App lädt ihre Ressourcen gezielt – nur auf den Seiten, wo sie tatsächlich benötigt werden, und erst dann, wenn der kritische Rendervorgang abgeschlossen ist. Das ist kein Luxus, sondern der technische Mindeststandard für Apps, die Performance ernst nehmen.
Shopify API-Rate-Limits: warum naive Integrationen im Produktivbetrieb brechen
Shopifys API begrenzt, wie viele Anfragen eine App pro Sekunde stellen darf – und diese Limits sind strenger als viele Entwickler erwarten. Die REST Admin API erlaubt bei Standard-Plänen nur 2 Anfragen pro Sekunde über ein Leaky-Bucket-Modell mit einem Burst-Limit von 40. Wer eine Schnittstelle baut, die Produktpreise für 5.000 Artikel aktualisiert und das in einer einfachen Schleife über die REST API tut, läuft innerhalb von Sekunden in 429-Fehler. Die richtige Lösung für Massen-Operationen ist Shopifys GraphQL Bulk Operations API: sie nimmt einen einzigen GraphQL-Job entgegen, verarbeitet ihn asynchron auf Shopifys Servern und liefert das Ergebnis als JSONL-Datei zurück. Das ist nicht nur das einzige skalierbare Modell für große Datenmengen – es ist auch das einzige, das Shopify explizit für diesen Use Case empfiehlt. Jede andere Implementierung ist ein technischer Schuldenposten, der spätestens beim nächsten Produktkatalog-Update sichtbar wird.
Webhook-Zuverlässigkeit: warum Shopify keine Garantie auf Zustellung gibt
Shopify-Webhooks arbeiten nach dem Prinzip "at least once" – eine Nachricht wird mindestens einmal gesendet, aber nicht garantiert genau einmal. Das bedeutet: Bei Netzwerkproblemen oder Timeouts kann Shopify denselben Webhook mehrfach senden. Eine App, die auf orders/create reagiert und bei jedem Eingang eine Fulfillment-Logik auslöst, muss idempotent sein – der gleiche Webhook darf nicht zweimal dieselbe Bestellung erzeugen oder den gleichen Lagerbestand doppelt abziehen. Dafür wird üblicherweise die Webhook-ID als Idempotency-Key verwendet: wurde dieser Webhook bereits verarbeitet, wird er still ignoriert. Noch wichtiger ist aber die Frage, was passiert, wenn ein Webhook gar nicht ankommt. Shopify versucht fehlgeschlagene Webhooks 19 Mal über 48 Stunden erneut zu senden – danach verfällt das Event. Eine robuste Integration ergänzt Webhooks deshalb immer mit einem periodischen Reconciliation-Job, der Shopify-Daten und interne Daten aktiv abgleicht und Lücken erkennt.
Der Break-even zwischen App-Abo und Individualentwicklung liegt früher als gedacht
Viele Shopify-Händler zahlen monatlich für fünf bis zehn Apps – ohne je gerechnet zu haben, ab wann individuelle Entwicklung günstiger wäre. Das Rechenbeispiel ist einfach: Eine App für 79 € pro Monat kostet über drei Jahre 2.844 €. Deckt sie die Anforderungen aber nur zu 80 % und muss durch manuelle Prozesse oder eine zweite App ergänzt werden, steigen die Gesamtkosten weiter. Eine Custom App, die genau das tut, was gebraucht wird – nichts mehr, nichts weniger – amortisiert sich oft nach 12 bis 18 Monaten. Hinzu kommen die indirekten Kosten, die in keiner App-Abrechnung auftauchen: Performance-Einbußen durch App-Skripte, die auf jeder Seite laden; Abhängigkeit von fremden Release-Zyklen, bei denen ein Update des Anbieters ungefragt das Verhalten ändert; und Supportaufwand, wenn eine App mit einer anderen in Konflikt gerät. Der seriöse Vergleich stellt nicht App-Abo-Kosten gegen Entwicklungskosten, sondern Gesamtbetriebskosten über 24 bis 36 Monate.
Shopify Functions, Scripts und Checkout Extensions: drei verschiedene Werkzeuge für Checkout-Logik
Wer Checkout-Logik in Shopify anpassen will, stößt auf drei unterschiedliche Mechanismen – die nicht austauschbar sind und unterschiedliche Voraussetzungen haben. Shopify Scripts (das ältere Modell) erlauben Rabatt- und Versandlogiken direkt im Checkout, sind aber auf Shopify Plus beschränkt und werden schrittweise durch Shopify Functions abgelöst. Shopify Functions sind serverseitig laufende WebAssembly-Module, die Discount-, Shipping- und Payment-Logiken definieren können – sie sind ab allen Plänen über Custom Apps nutzbar und deutlich leistungsfähiger als Scripts. Checkout Extensions (UI Extensions) hingegen erlauben visuelle Erweiterungen des Checkouts – zusätzliche Felder, Banners, oder Informationsblöcke – und sind ebenfalls ab Standard-Plänen verfügbar, nicht nur auf Plus. Die häufigste Verwechslung in Projekten: jemand will eine Checkbox im Checkout hinzufügen (UI Extension) und denkt, dafür sei Shopify Plus nötig. Das ist falsch. Was Plus voraussetzt, ist der vollständige Checkout-Umbau mit eigenem Design – nicht jede kleine Erweiterung.
Schnittstellen & Automatisierung
Ein wachsender Shop darf nicht isoliert laufen. Wir verbinden Shopify mit den Systemen, die ihr bereits nutzt – damit Produktdaten, Bestellungen, Lagerbestände, Kundendaten und interne Prozesse automatisiert laufen.
Was bei Shopify-Integrationen wirklich entscheidet
Welches System ist die führende Datenquelle – und warum diese Frage zuerst beantwortet werden muss
Bevor eine Schnittstelle zwischen Shopify und einem ERP oder PIM gebaut wird, muss eine organisatorische Entscheidung fallen: Welches System gilt als Quelle der Wahrheit für welche Daten? Preise und Lagerbestände kommen fast immer aus dem ERP – das ist unstreitig. Aber wo werden Produkttexte gepflegt? Wo liegen Bilder und SEO-Metadaten? Wer entscheidet, welche Produkte im Shop sichtbar sind? Wenn diese Fragen nicht explizit beantwortet werden, baut man eine Schnittstelle, die in beide Richtungen schreibt – und bei Konflikten keinen klaren Gewinner hat. Das führt zu Datenverlusten, die erst Wochen später auffallen: ein Produkttext, der im Shop gepflegt wurde, wird beim nächsten ERP-Sync überschrieben. Eine saubere Integrationsarchitektur beginnt mit einem Datenfluss-Diagramm, das für jedes Datenfeld festlegt, in welche Richtung es fließt – und was bei einem Konflikt gilt.
Warum Shopify-Webhooks für kritische Prozesse nicht allein ausreichen
Shopify sendet Webhooks ereignisgesteuert – sobald eine Bestellung eingeht, ein Produkt aktualisiert wird oder ein Fulfillment-Status sich ändert. Das klingt zuverlässig, ist es aber nur bedingt: Shopify garantiert "at least once"-Zustellung, nicht "exactly once". Bei Netzwerkproblemen oder Timeouts auf der Empfängerseite wird der Webhook wiederholt – bis zu 19 Mal innerhalb von 48 Stunden. Danach verfällt das Event still. Wer Bestellungen ausschließlich per Webhook ins ERP überträgt, riskiert, dass Bestellungen bei einem temporären Ausfall verloren gehen – unbemerkt, weil kein Fehler geloggt wird. Die robuste Lösung kombiniert Webhooks für die Echtzeitverarbeitung mit einem periodischen Abgleich-Job, der Shopify-Bestellungen aktiv gegen den ERP-Bestand prüft und fehlende Einträge nachzieht. Dieser Reconciliation-Mechanismus ist kein Nice-to-have, sondern der Unterschied zwischen einer Schnittstelle, die im Betrieb funktioniert, und einer, die beim nächsten Serverausfall Daten verliert.
Lagerbestände in Echtzeit: warum der Zeitpunkt der Synchronisation über Überverkäufe entscheidet
Wann wird ein Lagerbestand in Shopify reduziert – beim Bestellabschluss, beim Fulfillment oder beim ERP-Sync? In vielen Standard-Integrationen läuft der Lagerbestand per nächtlichem Batch-Import aus dem ERP in Shopify. Das bedeutet: der Stand im Shop ist bis zu 24 Stunden alt. Bei Produkten mit hohem Durchsatz oder knappem Bestand führt das zwangsläufig zu Überverkäufen – Shopify verkauft Artikel, die das ERP längst als vergriffen führt. Die Lösung hängt vom Geschäftsmodell ab: Shops mit schnell drehendem Sortiment brauchen eine nahezu echtzeitnahe Bestandssynchronisation, idealerweise getriggert durch ERP-Events. Shops mit breitem Sortiment und hohen Pufferlagerbeständen kommen mit stündlichen Intervallen aus. Diese Entscheidung muss im Konzept getroffen werden – nicht als Hotfix nach dem ersten Überverkauf im Produktivbetrieb.
Produktdaten-Mapping: die aufwändigste und fehleranfälligste Stelle jeder Integration
ERP-Systeme speichern Produktdaten in einer Struktur, die für Warenwirtschaft optimiert ist – nicht für E-Commerce. Artikelnummern, Einheiten, Zolltarifnummern und Gewichte: das liegt sauber im ERP. Mehrsprachige Produktbeschreibungen, Varianten mit Größen- und Farboptionen, kategorisierte Bilder, SEO-Titel und Collections: das erwartet Shopify. Das Mapping zwischen diesen beiden Welten ist fast immer der aufwändigste Teil einer Integration. Felder haben unterschiedliche Datentypen und Längenbeschränkungen. Sonderzeichen in ERP-Feldern verursachen Importfehler. Pflichtfelder in Shopify, die im ERP optional sind, blockieren einzelne Produkte ohne Fehlermeldung. Varianten, die im ERP als separate Artikel geführt werden, müssen in Shopify zu einem Produkt mit Varianten zusammengeführt werden. Ein sauberes Mapping-Dokument vor dem ersten Code-Commit spart erfahrungsgemäß mehr Zeit als jede andere Vorbereitungsmaßnahme.
JTL-Wawi und Shopify: was die Standardlösung kann – und wo sie endet
JTL bietet einen offiziellen Shopify-Connector für die Wawi, der Produkte, Bestände und Bestellungen synchronisiert. Für viele mittelständische Händler ist das ein solider Ausgangspunkt. Die Grenzen werden aber schnell sichtbar: Produktvarianten mit mehr als drei Dimensionen, kundenspezifische Preislisten, komplexe Bundle-Produkte oder individuelle Versandlogiken lassen sich über den Standard-Connector nicht abbilden. Hinzu kommt die Frage der Synchronisationstiefe: Der Connector überträgt Basisdaten, aber keine Custom-Metafelder, keine Collection-Zuordnungen nach eigener Logik und keine Medien-Assets in strukturierten Ordnern. Wer mit JTL und Shopify arbeitet und merkt, dass der Standard-Connector die Anforderungen nicht vollständig abdeckt, hat zwei Optionen: den Connector mit eigener Middleware erweitern oder eine vollständig individuelle Integration über die Shopify Admin API und JTLs API entwickeln. Welcher Weg sinnvoller ist, hängt vom Umfang der Abweichungen ab – und sollte vor dem Projekt, nicht während, entschieden werden.
Integrationen testen ohne Produktivdaten zu beschädigen
Shopify bietet Development Stores und eine Sandbox-Umgebung für Tests – aber die meisten ERP-Systeme nicht. Das ist das zentrale Testproblem jeder Shopify-Integration: auf der Shopify-Seite lässt sich sauber in einer isolierten Umgebung entwickeln und testen. Auf der ERP-Seite gibt es oft nur eine einzige Produktivinstanz. Wer eine neue Schnittstelle gegen das Live-ERP testet, riskiert Testbestellungen, manipulierte Lagerbestände oder fehlerhafte Preisänderungen im echten System. Die pragmatische Lösung: eine kontrollierte Testphase mit echten Daten in einem definierten Zeitfenster, mit einer klaren Liste von Testfällen, expliziten Rollback-Kriterien und einem Monitoring-Setup, das Fehler sofort sichtbar macht. Dieser Testplan gehört genauso zum Projekt wie die Entwicklung selbst – und wird fast immer zu spät erstellt, nämlich erst dann, wenn die Entwicklung schon fertig ist.
Shopify SEO
Viele Shopify-Shops verlieren Sichtbarkeit nicht wegen schlechter Produkte, sondern wegen technischer Schwächen: unklare Kategoriestrukturen, doppelte Inhalte, langsame Templates, falsche Canonicals, fehlende strukturierte Daten oder schlecht geplante Migrationen.
Was bei Shopify SEO wirklich zählt
Shopifys URL-Struktur ist fest – und das hat SEO-Konsequenzen
Anders als bei Shopware oder WordPress lässt sich die URL-Struktur in Shopify nicht frei konfigurieren. Produkte liegen immer unter /products/, Collections unter /collections/, Blog-Artikel unter /blogs/[blog-name]/. Das ist für die meisten Shops kein Problem – aber es bedeutet, dass eine Migration von einem anderen System fast zwingend URL-Änderungen mit sich bringt. Wer von WooCommerce oder Shopware kommt, hatte dort oft flachere URL-Strukturen wie /kategorie/produkt. In Shopify wird daraus /collections/kategorie und /products/produkt. Ohne vollständiges 301-Redirect-Mapping geht die aufgebaute Linkstärke verloren. Ein weiteres strukturelles Thema: Collections können in Shopify nicht verschachtelt werden – es gibt keine echte Kategoriehierarchie. Wer eine tiefe Kategoriestruktur für SEO braucht, muss das über Collection-Metafelder, interne Verlinkung und strukturierte Daten kompensieren, nicht über URL-Pfade.
Duplicate Content durch Collection-Produkt-URLs: das häufigste technische SEO-Problem in Shopify
Shopify erzeugt für jedes Produkt, das in einer Collection liegt, eine zweite erreichbare URL: /collections/[collection]/products/[produkt] – zusätzlich zur kanonischen /products/[produkt]. Shopify setzt hier automatisch einen Canonical-Tag auf die /products/-URL. Das klingt nach einer sauberen Lösung – ist es aber nur, wenn alle Themes und Apps diese Canonical-Tags korrekt ausgeben und keine eigenen Canonical-Overrides einbauen. In der Praxis gibt es Themes, die auf Collection-Produktseiten keinen oder einen falschen Canonical setzen. Google indexiert dann beide URLs als eigenständige Seiten mit identischem Content. Das Ergebnis: die Linkkraft teilt sich auf, keine der beiden URLs baut nennenswerte Stärke auf. Ein vollständiger SEO-Audit eines Shopify-Shops beginnt deshalb immer mit einem Crawl, der alle Canonical-Tags auswertet und auf Konsistenz prüft.
Strukturierte Daten in Shopify: was automatisch funktioniert – und was nicht
Viele Shopify-Themes geben Product Schema automatisch aus – aber oft unvollständig oder fehlerhaft. Das Mindestset für ein korrekt ausgegebenes Product Schema umfasst Name, Beschreibung, Preis, Währung, Verfügbarkeit, Bild und SKU. Fehlt die Verfügbarkeit oder wird der Preis ohne Währungsangabe ausgegeben, markiert Googles Rich Results Test das Schema als fehlerhaft – und zeigt keine Rich Snippets in den Suchergebnissen. Besonders häufig fehlen Bewertungs-Aggregate (AggregateRating) und Varianten-spezifische Preise. Ein zweites regelmäßig fehlendes Schema ist BreadcrumbList: Breadcrumb-Rich-Snippets in den Suchergebnissen sind für Shop-SEO ein echter Klick-Treiber und werden von den meisten Shopify-Themes nicht korrekt ausgezeichnet. Strukturierte Daten sollten nicht nur einmalig eingerichtet, sondern nach Theme-Updates und App-Installationen erneut validiert werden – beide können Schema-Ausgaben verändern.
Interne Verlinkung als unterschätzter SEO-Hebel im Shopify-Shop
Google bewertet interne Links als Relevanzsignal: eine Seite, auf die viele interne Links zeigen, gilt als wichtiger als eine, die intern isoliert ist. In Shopify-Shops ist die interne Verlinkungsstruktur oft schwach, weil sie selten systematisch geplant wird. Collection-Seiten verlinken auf Produkte, aber Produkte verlinken kaum zurück auf Collections oder verwandte Produkte. Blog-Artikel verlinken nicht auf relevante Collection-Seiten, obwohl genau diese Verbindung Rankings für kommerzielle Keywords unterstützt. Eine einfache Maßnahme mit messbarer Wirkung: jeder Blog-Artikel, der ein Thema behandelt, zu dem ein Shop eine relevante Collection hat, sollte diese Collection mit einem redaktionellen Ankertext verlinken. Und jede Produktseite sollte über Cross-Selling-Blöcke mit thematisch verwandten Produkten verknüpft sein – nicht nur für Conversion, sondern auch für Crawl-Pfade.
Indexierungssteuerung: welche Shopify-Seiten Google nicht sehen sollte
Nicht jede Seite, die Shopify automatisch erzeugt, sollte im Google-Index landen. Suchergebnisseiten (/search?q=...) sind per Standard in Shopifys robots.txt gesperrt – gut. Aber Tag-Seiten (/collections/alle/[tag]) sind es oft nicht, obwohl sie häufig dünnen oder doppelten Content haben. Cart- und Account-Seiten werden von Shopify automatisch mit noindex ausgezeichnet – aber Policy-Seiten (/policies/...) oft nicht, obwohl sie generischen Boilerplate-Text enthalten, der sich kaum von Shop zu Shop unterscheidet. Ein vollständiges Indexierungsaudit prüft: Welche Seiten werden gecrawlt? Welche davon haben ausreichend einzigartigen Content, um indexiert zu werden? Welche verbrauchen Crawl-Budget ohne SEO-Mehrwert? Besonders bei großen Shops mit tausenden Produkten und hunderten Collections ist ein strukturiertes Crawl-Budget-Management der Unterschied zwischen einem Shop, dessen neue Seiten binnen Tagen indexiert werden, und einem, der wochenlang wartet.
Hreflang und internationales SEO: wo Shopify Markets an Grenzen stößt
Shopify Markets ermöglicht es, einen Shop in mehreren Ländern und Sprachen zu betreiben – mit eigenen Preisen, Währungen und Übersetzungen pro Markt. Die technische SEO-Herausforderung dabei: Hreflang-Tags müssen korrekt auf alle Sprachvarianten einer Seite verweisen und dürfen keine Lücken haben. Eine Seite, die auf Deutsch und Englisch existiert, braucht auf der deutschen Version einen Hreflang-Tag, der auf die englische verweist – und umgekehrt. Fehlt einer dieser Tags, wertet Google die Varianten als konkurrierende Seiten statt als Übersetzungen. Shopify Markets setzt Hreflang-Tags automatisch, aber die Implementierung ist nicht in allen Konstellationen fehlerfrei: bei Subdomains pro Markt, bei manuell verwalteten Übersetzungen über Apps oder bei gemischten URL-Strukturen entstehen regelmäßig Hreflang-Fehler. Wer international mit Shopify skaliert, sollte die Hreflang-Implementierung nach jeder Markt-Konfigurationsänderung erneut mit einem Crawl validieren.
Conversion-Optimierung
Nicht jeder Shopify-Shop braucht sofort mehr Werbebudget. Oft liegt das größte Potenzial in besseren Produktseiten, klareren Kaufargumenten, schnellerem Seitenaufbau und weniger Reibung im Kaufprozess.
Was bei Shopify Conversion-Optimierung wirklich zählt
Warum Conversion-Optimierung mit Datenbasis beginnt, nicht mit Hypothesen
Viele CRO-Projekte starten mit Annahmen: die Produktseite ist zu unübersichtlich, der Warenkorb-Button zu klein, der Checkout zu lang. Das mag stimmen – oder auch nicht. Ohne eine valide Datenbasis aus GA4-Events, Heatmaps und Session-Recordings lassen sich diese Fragen nicht beantworten, sondern nur raten. Bevor eine einzige Produktseite umgebaut wird, sollte geklärt sein: Wo steigen Nutzer ab? Auf welchen Seiten verbringen sie wenig Zeit? Welche Produkte werden häufig in den Warenkorb gelegt, aber selten gekauft? Welche Geräte und Browser haben die schlechtesten Conversion-Raten? Diese Fragen beantwortet nur sauber implementiertes Tracking – und das ist in vielen Shopify-Shops nach einem Theme-Wechsel oder einer App-Installation defekt, ohne dass es jemand merkt. Der erste Schritt jedes CRO-Projekts ist deshalb ein Tracking-Audit, kein Design-Briefing.
Die Produktseite ist der wichtigste Conversion-Hebel – und wird am häufigsten unterschätzt
Im Shopify-Shop ist die Produktdetailseite der Moment, in dem Kaufentscheidungen fallen oder nicht. Die häufigsten Schwachstellen: Produktbilder zeigen das Produkt aus einer Perspektive, geben aber kein Gefühl für Größe, Material oder Anwendung. Produktbeschreibungen wiederholen Eigenschaften, statt Fragen zu beantworten, die Käufer wirklich haben. Lieferzeitangaben fehlen oder sind vage. Trust-Elemente – Bewertungen, Rückgabehinweise, Zahlungsarten – sind versteckt oder fehlen komplett. Und der eigentliche Kaufaufruf, der Add-to-Cart-Button, konkurriert optisch mit zu vielen anderen Elementen. Jede dieser Schwachstellen lässt sich ohne A/B-Test beheben, weil sie nicht von Nutzerpräferenzen abhängen, sondern von objektiv messbaren Informationslücken. A/B-Tests sind sinnvoll, wenn es um Feinabstimmung geht – nicht als Ersatz für offensichtliche Korrekturen.
Mobile Conversion ist schlechter als Desktop – und die meisten Shops wissen nicht warum
In den meisten Shopify-Shops ist die Conversion-Rate auf Mobilgeräten deutlich schlechter als auf Desktop – oft um den Faktor zwei oder drei. Das wird häufig als normal akzeptiert, obwohl es das nicht sein muss. Die Ursachen sind fast immer dieselben: Bilder laden zu langsam und blockieren den Scroll. Die Navigation ist für Touch-Gesten zu kleinteilig. Formulare auf der Checkout-Vorbereitung haben zu kleine Eingabefelder. Popups, die auf Desktop gut funktionieren, überdecken auf kleinen Bildschirmen den gesamten Inhalt. Und der Warenkorb-Drawer, der auf Desktop als elegante Lösung wirkt, ist auf einem 375 Pixel breiten Screen schwer bedienbar. Mobile CRO ist keine Variante von Desktop-CRO – es ist eine eigene Disziplin, die eigene Testszenarien, eigene Heatmaps und eigene Session-Recordings auf mobilen Geräten erfordert. Wer CRO nur am Desktop-Bildschirm analysiert, optimiert für eine Minderheit seiner Nutzer.
Cross-Selling und Upselling: wann es hilft und wann es Conversion kostet
Produktempfehlungen, Bundles und Upsell-Angebote können den durchschnittlichen Bestellwert steigern – oder den Kaufprozess unterbrechen und zum Abbruch führen. Der entscheidende Unterschied liegt im Zeitpunkt und in der Relevanz. Cross-Selling-Empfehlungen auf der Produktseite, die thematisch zum betrachteten Artikel passen, unterstützen die Entscheidung. Empfehlungen, die algorithmisch zusammengestellt sind und keinen erkennbaren Zusammenhang haben, wirken willkürlich und lenken ab. Upsell-Angebote im Warenkorb-Drawer funktionieren gut, wenn sie einen klaren Mehrwert kommunizieren – zum Beispiel ein Zubehörteil, das den Hauptartikel vervollständigt. Upsell-Popups, die den Checkout-Einstieg unterbrechen, erhöhen dagegen messbar die Abbruchrate. Die wichtigste Frage bei jeder Cross-Selling-Implementierung ist nicht, wie viele Produkte empfohlen werden, sondern warum ein Nutzer genau dieses Produkt sehen sollte – und ob er das in zwei Sekunden versteht.
Trust-Elemente: was Käufer wirklich überzeugt – und was nur Platz verbraucht
Shopify-Shops setzen Trust-Elemente ein, weil sie Vertrauen aufbauen sollen – aber nicht alle Trust-Signale wirken gleich. Kundenbewertungen sind der effektivste Trust-Hebel, den ein Shop hat – vorausgesetzt, sie sind spezifisch, authentisch und für das jeweilige Produkt relevant. Generische Sterne ohne Textbewertungen überzeugen kaum jemanden. Trust-Badges wie Sicherheitssiegel oder Zahlungsart-Logos haben eine nachweislich geringere Wirkung als oft angenommen – sie werden von vielen Nutzern schlicht nicht wahrgenommen. Was dagegen stark wirkt: konkrete Lieferzeitangaben mit tagesgenauer Aussage, eine klare und unkompliziert formulierte Rückgabepolitik direkt auf der Produktseite, und Antworten auf die häufigsten Kaufbedenken in einer kurzen FAQ unter dem Produkt. Diese Elemente reduzieren Kaufunsicherheit – nicht durch Symbole, sondern durch echte Informationen.
A/B-Tests in Shopify: was funktioniert – und warum die meisten Tests keine validen Ergebnisse liefern
A/B-Tests gelten als das Standardwerkzeug der Conversion-Optimierung – aber die meisten Tests, die in Shopify-Shops laufen, liefern keine statistisch belastbaren Ergebnisse. Das liegt fast immer am fehlenden Verständnis von statistischer Signifikanz und dem nötigen Stichprobenumfang. Ein Test, der nach drei Tagen und 200 Besuchern abgebrochen wird, weil eine Variante vorne liegt, ist kein A/B-Test – es ist Rauschen. Für einen Test mit 95 % Konfidenz und einer erwarteten Conversion-Verbesserung von 10 % braucht eine Variante je nach Ausgangsniveau mehrere tausend Besuche. Shops mit weniger als 10.000 monatlichen Besuchern sollten A/B-Tests deshalb nicht als primäres CRO-Instrument einsetzen, sondern auf qualitative Methoden setzen: Nutzerinterviews, Session-Recordings und Heatmaps liefern bei kleinen Trafficzahlen deutlich mehr Erkenntnisse pro investierter Stunde als statistisch nicht auswertbare Split-Tests.
Shopify Migration
Ob Shopware, WooCommerce oder ein individuelles Altsystem: Eine Migration zu Shopify muss technisch sauber geplant werden. Sonst entstehen Rankingverluste, Tracking-Probleme, Datenfehler und unnötige Reibung im Betrieb.
Eine gute Migration verliert keine technische Substanz – und keinen Suchmaschinen-Traffic.
Migration besprechenWas bei einer Migration zu Shopify wirklich entscheidet
Das URL-Crawl vor der Migration ist keine Option – er ist die Grundlage
Bevor eine einzige Zeile Migrations-Code geschrieben wird, muss die vollständige URL-Struktur des Altsystems dokumentiert sein. Shopify erzwingt feste URL-Pfade: Produkte liegen unter /products/, Collections unter /collections/, Blog-Artikel unter /blogs/. Wer von Shopware, WooCommerce oder einem individuellen System kommt, hatte dort andere Strukturen – oft flachere Pfade, andere Kategorie-URLs, manchmal auch parametrbasierte URLs. Jede dieser alten URLs braucht eine sauber gepflegte 301-Weiterleitung auf die neue Shopify-URL. Shopify erlaubt bis zu 10.000 URL-Weiterleitungen – für die meisten Shops ausreichend, aber nur wenn das Mapping vollständig und korrekt ist. Wer diesen Schritt überspringt oder halbherzig durchführt, verliert genau die Rankings, die er mit der Migration schützen wollte. Denn Google überträgt Linkstärke über 301-Weiterleitungen – aber nur, wenn sie existieren. Eine fehlende Weiterleitung ist ein dauerhafter Ranking-Verlust, kein temporärer.
Produktdaten sind nie so sauber wie erwartet – und das fällt immer erst während der Migration auf
Jede Produktdaten-Migration aus einem Altsystem deckt Probleme auf, die vorher unsichtbar waren. HTML-Tags in Feldern, die in Shopify kein HTML unterstützen, führen zu kaputten Darstellungen. Varianten, die im alten System als separate Produkte geführt wurden, müssen in Shopify zu einem Produkt mit Varianten zusammengeführt werden – was Artikelnummern, Lagerbestände und Preise je Variante erfordert. Shopify hat ein hartes Limit von 100 Varianten pro Produkt und maximal drei Variantenoptionen: wer mehr braucht, muss mit Metafeldern oder einer Custom App arbeiten. Bildpfade aus dem alten System sind oft relativ oder zeigen auf einen Server, der nach der Migration nicht mehr erreichbar ist. Und Produktbeschreibungen enthalten häufig eingebettete Styles, Inline-CSS oder Shop-spezifische Shortcodes, die im neuen System sinnlos oder kaputt gerendert werden. Eine Produktdaten-Migration ohne manuelle Stichprobenprüfung nach dem Import ist keine fertige Migration – sie ist ein unkontrollierter Datenstand.
Kundendaten migrieren: was geht, was nicht – und was die DSGVO vorschreibt
Passwörter können bei einer Migration zu Shopify nicht übertragen werden – das ist keine technische Einschränkung, sondern ein Sicherheitsprinzip. Shopware, WooCommerce und andere Systeme speichern Passwörter als Hashes mit eigenen Algorithmen. Shopify akzeptiert diese Hashes nicht und würde sie auch nicht entschlüsseln können. Das bedeutet: alle migrierten Kunden müssen nach dem Launch ein neues Passwort setzen – entweder über eine E-Mail-Einladung, die Shopify automatisch versenden kann, oder beim nächsten Login über den Passwort-Zurücksetzen-Prozess. Kritischer aus DSGVO-Sicht ist die Frage der E-Mail-Marketing-Einwilligungen: Wer Newsletter-Abonnenten mit in Shopify importiert, muss sicherstellen, dass die ursprüngliche Einwilligung dokumentiert ist und dem Shopify-Kontakt korrekt zugewiesen wird. Fehlt diese Dokumentation, dürfen diese Kontakte in Shopify nicht als Marketing-Empfänger eingestuft werden – unabhängig davon, ob sie im alten System als Abonnenten geführt wurden. Bestellhistorie lässt sich mit der Shopify Admin API importieren, hat aber keine native Oberfläche dafür – das erfordert eine technische Umsetzung und sollte im Migrationsplan explizit eingeplant sein.
Tracking-Kontinuität: der Schritt, der am häufigsten stille Fehler erzeugt
Eine Migration unterbricht fast immer das Tracking – die entscheidende Frage ist nur, ob der Fehler bemerkt wird oder nicht. Das häufigste Szenario: GA4 ist nach dem Launch technisch aktiv, aber Purchase-Events feuern nicht mehr korrekt, weil der Shopify-Checkout eine andere Dankesseiten-URL hat als das alte System. Google Ads läuft weiter, aber Conversion-Tracking meldet null Conversions, weil das Tag auf der alten Domain lag und nicht auf die neue übertragen wurde. Meta Pixel trackt Seitenaufrufe, aber keine Add-to-Cart-Events, weil ein Theme-Update den Pixel-Code-Pfad verändert hat. Diese Fehler sind nicht sofort sichtbar – sie fallen erst nach Tagen oder Wochen auf, wenn Kampagnen-Performance einbricht oder ROAS-Werte abstürzen. Jede Migration braucht deshalb eine dedizierte Tracking-Abnahme mit echten Testbestellungen: Purchase-Event prüfen, Consent-Mode-Verhalten validieren, alle relevanten Standard-Events in GA4 und Ads bestätigen – vor dem Launch, nicht danach.
SEO-Sichtbarkeit schützen: was über 301-Weiterleitungen hinausgeht
Weiterleitungen sind notwendig, aber nicht hinreichend für den Schutz der organischen Sichtbarkeit nach einer Migration. Ein vollständiger SEO-Schutz umfasst mehrere Schritte, die parallel zur technischen Migration laufen müssen. Die neue XML-Sitemap muss unmittelbar nach dem Launch in der Google Search Console eingereicht werden, damit Google die neue Struktur schnell crawlt. Die Search Console Property muss für die neue Domain korrekt eingerichtet sein – wer von HTTP auf HTTPS oder von einer Subdomain auf eine neue Domain wechselt, braucht eine eigene Property. Canonical-Tags auf der neuen Seite müssen korrekt auf sich selbst zeigen, nicht auf die alte Domain. Und der wichtigste Realitätscheck: temporäre Rankingverluste in den ersten zwei bis vier Wochen nach einer Migration sind normal, weil Google Zeit braucht, um Weiterleitungen zu verarbeiten und die neue Struktur zu bewerten. Dauerhafter Rankingverlust nach sechs Wochen ist ein Warnsignal – er zeigt, dass Weiterleitungen fehlen, Canonical-Tags falsch gesetzt sind oder der neue Content für Google schwächer bewertet wird als der alte.
Der Cutover: was in den letzten Stunden vor dem Go-Live über Erfolg oder Chaos entscheidet
Die kritischste Phase einer Migration ist nicht die Entwicklung – sie ist der Moment, in dem der DNS-Eintrag umgestellt wird. Was vorbereitet sein muss, bevor dieser Moment kommt: Die DNS-TTL sollte mindestens 48 Stunden vorher auf einen niedrigen Wert (300 Sekunden) gesetzt werden, damit die Umstellung nach dem DNS-Wechsel schnell weltweit propagiert. Ein letzter Datenabgleich muss stattfinden: Bestellungen, die zwischen dem letzten Produktdaten-Export und dem Livegang im alten System eingegangen sind, müssen manuell oder per Delta-Import ins neue System übertragen werden. Die Staging-Umgebung sollte mit einer echten Testbestellung final abgenommen sein – nicht nur optisch, sondern funktional: Checkout durchlaufen, Bestätigungs-E-Mail empfangen, Tracking-Events in GA4 prüfen. Und der Rollback-Plan muss schriftlich existieren: Was ist zu tun, wenn zwei Stunden nach dem Launch der Checkout nicht funktioniert? Wer ist erreichbar? Was genau wird zurückgesetzt? Ein Rollback-Plan, der erst im Problemfall erstellt wird, ist keiner.
Ein Auszug aus Shopify- und E-Commerce-Projekten, die wir für Unternehmen umgesetzt haben.

Shopify-Relaunch

Shopify & Produktdaten
Prozess
Wir arbeiten nicht nur an Templates, sondern an belastbaren Commerce-Systemen mit einem klaren Ablauf von Analyse bis Optimierung.
Wir prüfen Shop, Technik, Apps, Tracking, SEO, Performance und Geschäftsprozesse.
Wir definieren, welche Funktionen Standard bleiben, wo individuelle Entwicklung sinnvoll ist und welche Struktur langfristig trägt.
Wir entwickeln Theme-Anpassungen, Apps, Schnittstellen und technische Optimierungen.
Wir testen Performance, Tracking, Checkout, Schnittstellen, SEO-Basics und mobile Nutzung.
Wir begleiten Livegang, Weiterleitungen, Tracking, Indexierung und technische Stabilität.
Nach dem Launch verbessern wir Conversion, Geschwindigkeit, Datenqualität und technische Prozesse weiter.
Systemwahl
Shopify ist besonders stark, wenn ein Shop schnell, stabil, skalierbar und international wachsen soll. Shopware kann sinnvoll sein, wenn sehr individuelle B2B-Logiken, komplexe Preisstrukturen oder tiefgreifende Systemanpassungen im Mittelpunkt stehen. Wir helfen euch, die Entscheidung technisch und wirtschaftlich sauber zu treffen.
Ideal, wenn Geschwindigkeit, Betriebssicherheit und Skalierbarkeit wichtiger sind als maximale Systemindividualisierung.
Ideal, wenn Datenmodelle, Prozesslogik und individuelle Erweiterbarkeit stärker im Vordergrund stehen als schneller Betrieb.
Die Systementscheidung treffen wir nicht aus Gewohnheit, sondern auf Basis von Zielbild, Daten, Prozessen, Budget und Betrieb.
System besprechenWir 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
Eine Shopify Agentur entwickelt und optimiert Shopify-Shops für Unternehmen. Das umfasst Shop-Aufbau, Theme-Entwicklung, individuelle Apps, Schnittstellen zu ERP/PIM/CRM, Performance-Optimierung, SEO und laufende technische Betreuung. Webcellent geht dabei über reine Theme-Arbeit hinaus und entwickelt Shopify als vollständiges Commerce-System.
Ein einfacher Shopify-Shop startet ab ca. 5.000 €, wenn Theme-Anpassungen, Tracking, SEO-Grundlagen und Produktstruktur sauber aufgebaut werden. Komplexere Setups mit individuellen Apps, Schnittstellen oder Migrationen liegen je nach Umfang zwischen 10.000 und 50.000 €. Ein technischer Audit startet ab 2.500 €.
Individuelle Apps lohnen sich, wenn Standard-Apps wiederkehrende Kosten von mehreren Hundert Euro pro Monat verursachen, die Ladezeit beeinträchtigen oder wichtige Geschäftsprozesse nur halb abbilden. Wir prüfen im Projekt, ob individuelle Entwicklung langfristig günstiger und besser ist.
Ja, in vielen Fällen. Vor allem bei Preislogiken, Produktkonfiguratoren, Import-Pipelines, B2B-Funktionen und einfachen Integrationsprozessen ist individuelle Entwicklung oft günstiger als monatliche App-Gebühren – und exakt auf eure Anforderungen zugeschnitten.
Ja. Shopify bietet eine umfangreiche API, über die Verbindungen zu ERP-Systemen (SAP, JTL, etc.), PIM, CRM, Versanddienstleistern und Buchhaltungssoftware aufgebaut werden können. Wir entwickeln individuelle Schnittstellen, die genau zu euren Systemen passen.
Shopify B2B ist seit einigen Versionen deutlich stärker geworden – Kundengruppen, Preislisten und B2B-Checkout sind nativ verfügbar. Für sehr komplexe B2B-Logiken mit Genehmigungsprozessen, tiefgreifenden Preisstrukturen oder sehr individuellem Datenmodell kann Shopware sinnvoller sein. Wir beraten euch offen.
Eine saubere Migration umfasst URL-Mapping, 301-Weiterleitungen, Produktdaten-Migration, Kundendaten, Bestellhistorie, Kategoriestruktur, SEO-Metadaten, Tracking-Setup und Testing vor dem Livegang. Wir begleiten den gesamten Prozess, damit keine Sichtbarkeit verloren geht.
Ja. Shopify hat einige Einschränkungen (z.B. URL-Struktur), aber technische SEO ist gut umsetzbar: saubere Meta-Daten, strukturierte Daten, Canonical-Tags, Indexierungssteuerung, Weiterleitungen und Core Web Vitals lassen sich alle optimieren.
Ladezeit wird verbessert durch Theme-Optimierung, Reduzierung unnötiger App-Skripte, Bildoptimierung, Lazy Loading, Reduzierung von Render-Blocking-Ressourcen und Optimierung des Liquid-Codes. Wir analysieren, wo die größten Hebel liegen, und optimieren messbar.
Ja. Wir begleiten Shops nach dem Launch bei Performance-Optimierung, Conversion-Verbesserungen, neuen Funktionen, App-Prüfungen, Schnittstellen und technischer Weiterentwicklung – entweder projektweise oder über Retainer.
Ja. Webcellent sitzt in Bielefeld und unterstützt Unternehmen aus OWL und ganz Deutschland bei Shopify-Projekten. Viele Abstimmungen laufen effizient remote, bei Bedarf sind aber auch persönliche Termine in der Region möglich.
Shopify Agentur Bielefeld & OWL
Webcellent sitzt in Bielefeld und unterstützt Unternehmen aus OWL und ganz Deutschland bei Shopify-Projekten. Viele Unternehmen aus der Region suchen keinen anonymen Dienstleister, sondern einen technischen Partner, der E-Commerce, Entwicklung und Prozesse versteht. Als Shopify Agentur aus Bielefeld begleiten wir euch bei Shop-Aufbau, Relaunch, Schnittstellen, App-Entwicklung, Performance und Conversion-Optimierung – remote, persönlich und mit Verständnis für mittelständische Geschäftsmodelle.
Einen Überblick über unsere Shop-Entwicklung mit Shopify und Shopware findet ihr auf der Shop-Übersicht.
Wir arbeiten mit Unternehmen aus Bielefeld, OWL und ganz Deutschland – persönlich im Austausch, effizient in der Umsetzung.
Wir denken Shopify nicht nur als Shop-Oberfläche, sondern als System aus Theme, Apps, Schnittstellen, Daten und Prozessen.
Besonders stark sind wir für Unternehmen, die mit Shopify professioneller verkaufen, automatisieren oder skalieren wollen.
Ob neuer Shopify-Shop, Relaunch, Schnittstelle, App-Entwicklung oder Performance-Optimierung: Wir schauen uns euer Setup an und zeigen euch, welche technischen Schritte wirklich sinnvoll sind.

Dein Ansprechpartner
Christopher Diamant
Geschäftsführer & Inhaber
Deine Anfrage kommt direkt bei mir an. Ich melde mich schnellstmöglich persönlich zurück.