Shopify Custom Development für CRO: Wann Themes nicht mehr reichen

Themes sind gut, bis sie es nicht mehr sind

Ich halte Shopify aktuell für das beste E-Commerce-System am Markt. Ein großer Grund dafür ist die grundsätzlich performante Theme-Architektur. Moderne Themes sind schnell, sauber aufgebaut und lassen sich über den Theme-Editor ohne eine einzige Zeile Code anpassen. Für viele Shops ist das in der Anfangsphase genau richtig.

Das Problem beginnt später. Ein Shop wächst, die Ansprüche steigen, und plötzlich gibt es Anforderungen, die das Theme nicht abbildet. Die Variantenauswahl soll anders funktionieren. Ein Mengenrabatt soll direkt auf der Produktseite sichtbar werden. Der Warenkorb soll eine bestimmte Information zeigen, die das Theme nicht vorsieht. An dieser Stelle greifen die meisten Shops zu einer App, dann zur nächsten, dann zu einem Page Builder, und nach zwei Jahren hängen zwanzig Erweiterungen am Shop, die niemand mehr vollständig überblickt.

Ich bin ein großer Fan von Custom-Entwicklung, weil Themes zwar viele Möglichkeiten bieten, aber im Detail immer Grenzen haben. Gerade in der Conversion-Optimierung kommt es oft auf Nuancen an, die sich nur über individuellen Code umsetzen lassen. Gleichzeitig weiß ich aus vielen Audits, dass schlecht gemachte Custom-Entwicklung einer der häufigsten Gründe für langsame und fehleranfällige Shops ist.

Dieser Artikel beantwortet deshalb nicht nur die Frage, wann Themes nicht mehr reichen, sondern auch, wie Custom Development aussehen muss, damit es deinem Shop hilft statt schadet. Wenn du dich grundsätzlich fragst, welche Hebel in einem Shopify-Shop den größten Unterschied machen, findest du einen Überblick in Conversion Rate Optimierung für Shopify.

Was ein Theme kann und wo es aufhört

Um die Grenze zu verstehen, hilft ein kurzer Blick auf die Architektur. Shopify-Themes bestehen aus Templates, Sections und Blocks. Händler können diese Bausteine im Theme-Editor anordnen, ein- und ausblenden und über vordefinierte Einstellungen anpassen. Shopify beschreibt diese Struktur ausführlich in seiner Entwicklerdokumentation zu Theme-Blocks.

Der entscheidende Punkt: Was im Editor einstellbar ist, hat der Theme-Entwickler vorher festgelegt. Du kannst Farben ändern, Reihenfolgen verschieben, Texte austauschen und Elemente ein- oder ausblenden. Du kannst aber nichts tun, was das Theme nicht vorgesehen hat.

Für ein solides Grundniveau ist das völlig ausreichend. Wenn ein Shop noch am Anfang steht, halte ich es sogar für sinnvoll, sich an bewährten Standards zu orientieren, statt alles individuell zu bauen. Sobald ein Shop aber wächst und systematisch optimiert wird, entstehen Anforderungen, die genau in der rechten Spalte liegen. Denn gute Hypothesen richten sich nach den Problemen deiner Nutzer, nicht nach den Einstellungen deines Themes.

Die Warnsignale: Wann Themes nicht mehr reichen

Aus unseren Projekten kenne ich eine Reihe klarer Signale, dass ein Shop über das hinausgewachsen ist, was ein Theme mit Bordmitteln leisten kann.

1. 01Hypothesen scheitern an der Umsetzung. Die Analyse zeigt klar, was Nutzer brauchen, aber das Theme lässt es nicht zu. Wenn die Antwort auf eine gute Idee regelmäßig „Das geht mit unserem Theme nicht“ lautet, ist das ein deutliches Signal.
2. 02Die App-Liste wächst schneller als der Umsatz. Für jede Anforderung kommt eine neue App dazu. Jede lädt eigenes JavaScript, oft auf allen Seiten, und die Ladezeit steigt mit jeder Installation.
3. 03Ein Page Builder hat das Theme ersetzt. Landingpages und Produktseiten werden nicht mehr im Theme gebaut, sondern über einen Drittanbieter. Das ist bequem, aber in meiner Erfahrung einer der größten Performance-Killer überhaupt.
4. 04Apps kollidieren miteinander. Ein Upsell-Tool überschreibt die Variantenauswahl, ein Review-Widget verschiebt das Layout, zwei Apps greifen in den Warenkorb ein. Fehler tauchen nur auf bestimmten Geräten auf und sind schwer zu reproduzieren.
5. 05Das Angebot passt nicht mehr ins Standardschema. Bundles, Staffelpreise, Abo-Optionen, Konfiguratoren oder erklärungsbedürftige Produkte lassen sich in Standard-Produktseiten nur mit Kompromissen darstellen.
6. 06A/B-Tests werden über den Visual Editor gebaut. Wenn Testvarianten per Drag-and-drop im Testing-Tool entstehen, weil der Shop selbst keine sauberen Alternativen zulässt, leidet die Qualität der Tests.

Wenn zwei oder mehr dieser Signale zutreffen, lohnt sich ein ehrlicher Blick auf die technische Basis. Das heißt nicht automatisch, dass alles neu gebaut werden muss. Oft reicht es, gezielt einzelne Bausteine durch schlanken, individuellen Code zu ersetzen. Wann dagegen ein vollständiges Redesign sinnvoll ist, beschreibe ich in Shopify Redesign oder Optimierung.

Apps, Page Builder, Custom Code: drei Wege im Vergleich

Wenn das Theme nicht reicht, gibt es grundsätzlich drei Wege. Jeder hat seinen Platz, und keiner ist immer richtig.

Apps sind sinnvoll für Funktionen, die echte Infrastruktur brauchen und sich nicht sinnvoll selbst bauen lassen. Bewertungssysteme mit Moderation, Abo-Logik mit Zahlungsabwicklung oder ein serverseitiges Tracking-Setup sind gute Beispiele. Hier kauft man nicht nur Code, sondern einen laufenden Dienst.

Page Builder sehe ich sehr kritisch. Sie versprechen Flexibilität ohne Entwicklung und erzeugen dafür Markup, das kein Entwickler so schreiben würde. Von Drittanbieter-Page-Builder-Apps bin ich kein Freund, weil sie den Page Speed stark negativ beeinflussen können. Für kurzfristige Kampagnenseiten mag das vertretbar sein. Für Produktseiten und Kernbereiche des Shops halte ich es für den falschen Weg.

Custom Code ist die richtige Wahl, wenn eine Anforderung zentral für die Conversion ist, wenn sie individuell auf deine Zielgruppe zugeschnitten sein muss oder wenn sie getestet werden soll. Eine gezielt entwickelte Lösung ist in der Regel schlanker als eine App, die den gleichen Zweck generisch für zehntausende Shops erfüllen muss. Wie sich Apps und Page Builder konkret auf die Ladezeit auswirken, zeige ich in Shopify Page Speed optimieren.

Warum Custom Code für A/B-Testing entscheidend ist

Der wichtigste Grund, warum wir bei Convertlab mit einem spezialisierten Entwicklerteam arbeiten, ist das A/B-Testing. Und hier wird der Unterschied zwischen Bordmitteln und individuellem Code besonders deutlich.

Viele Testing-Tools bieten einen Visual Editor, mit dem sich Änderungen ohne Entwicklung per Drag-and-drop umsetzen lassen. Ich halte davon wenig. Aus meiner Erfahrung sind solche Lösungen fehleranfällig und führen zu technischen Problemen oder inkonsistenter Darstellung. Selbst kleinere Änderungen sollten sauber von Entwicklern umgesetzt werden, weil fehlerhafte Experimente zu falschen Entscheidungen führen.

Dazu kommt ein technisches Problem, das in vielen Setups übersehen wird. Wenn zu viel Code über das Testing-Tool geladen wird, kann das die Ladezeit verschlechtern oder sogenannte Flicker-Effekte erzeugen. Dabei sehen Nutzer kurz die Originalversion, bevor die Variante erscheint. Das verschlechtert nicht nur die Nutzererfahrung, es verfälscht auch die Ergebnisse. Wenn eine Variante systematisch später sichtbar wird als die andere, misst du nicht deine Hypothese, sondern deine Implementierung.

Dieses Vorgehen hat einen zweiten, oft unterschätzten Vorteil: Gewinner gehen schnell live. Weil die Variante bereits als sauberer Code im Shop liegt, muss sie nach einem erfolgreichen Test nicht neu entwickelt werden. Sie wird einfach aktiviert. Das verkürzt die Zeit zwischen Erkenntnis und Umsatz erheblich und ist für mich ein wichtiger Bestandteil eines effizienten CRO-Prozesses.

Und noch etwas: Im A/B-Testing kommt es oft auf Nuancen an. Bei einem Warenkorb-Test hat eine Variante, die in vielen Bereichen verbessert war, zunächst schlechter abgeschnitten, weil eine einzige Versandkosten-Information fehlte. Erst als wir sie wieder ergänzt hatten, performte die Variante insgesamt deutlich besser. Solche Feinheiten lassen sich nur testen, wenn man die volle Kontrolle über den Code hat. Wie wir Tests in Shopify technisch aufsetzen, beschreibe ich ausführlich in A/B-Testing für Shopify.

Was schlanker Code wirklich bedeutet

Custom Development ist kein Freifahrtschein. Der häufigste Einwand gegen individuellen Code ist berechtigt: Er kann einen Shop genauso verlangsamen und fehleranfällig machen wie zwanzig Apps. Der Unterschied liegt nicht darin, ob man Code schreibt, sondern wie.

Für mich bedeutet schlanker Code, dass wir unnötige Komplexität vermeiden und nur das implementieren, was wirklich notwendig ist. Wir achten darauf, moderne Standards zu nutzen, Performance zu optimieren und die Core Web Vitals möglichst wenig zu beeinflussen. Effizienz steht dabei immer im Vordergrund.

Konkret heißt das in der Umsetzung:

Der letzte Punkt wird am häufigsten vernachlässigt. Ich sehe in Audits regelmäßig Shops, in denen Code von Apps steckt, die seit Langem nicht mehr installiert sind, oder Fragmente von Tests, die vor einem Jahr beendet wurden. Das ist Ladezeit ohne Gegenwert. Ich bin überzeugt, dass gutes Testing und gute Entwicklung niemals auf Kosten der Performance gehen dürfen.

Typische Custom-Entwicklungen im CRO-Kontext

Damit das Thema greifbar wird, hier eine Auswahl von Anforderungen, die in unseren Projekten regelmäßig individuelle Entwicklung erfordern, weil Themes sie nicht oder nur unzureichend abbilden.

Angebotslogik auf der Produktseite. Mengenrabatte, Staffelpreise, Bundles oder die Wahl zwischen Einmalkauf und Abo. Gerade bei Supplements und Beauty-Produkten ist die Darstellung des Angebots oft der größte Hebel. Bei einem Kunden im Subscription-Bereich konnten wir bereits im ersten Test die Abo-Rate um knapp 40 Prozent steigern. Solche Ergebnisse entstehen fast immer aus einer individuell gestalteten Angebotsdarstellung.

Variantenauswahl und Produktkonfiguration. Größenberatung, visuelle Farbwähler, Hinweise zur Passform oder Konfiguratoren für erklärungsbedürftige Produkte. Wenn die Auswahl unklar ist, entstehen Fehlkäufe und Abbrüche.

Warenkorb-Anpassungen. Konkrete Lieferdaten, transparente Versandkosten, gezielte Ergänzungsprodukte oder bewusst das Entfernen von Elementen. Bei Löwenkind haben wir eine Versand-Progress-Bar aus dem Warenkorb entfernt, und der Umsatz pro Nutzer stieg um etwa 11 Prozent. Optimierung bedeutet nicht immer, etwas hinzuzufügen.

Vorbereitung für Checkout-Tests. Seit der Umstellung auf Checkout Extensibility läuft eigener Code im Shopify-Checkout nur noch in einer abgeschotteten Sandbox. A/B-Testing-Tools können dort keine Elemente mehr direkt verändern. Damit Testing im Checkout trotzdem möglich ist, müssen Informationen teilweise bereits im Warenkorb vorbereitet werden. Das erhöht die technische Komplexität deutlich und ist ohne individuellen Code nicht machbar.

Verbindung von Frontend und Backend. Technisch anspruchsvoll wird es immer dann, wenn Testvarianten Auswirkungen auf Bestellungen oder Datenstrukturen haben, etwa wenn eine neue Option im Warenkorb in der Bestellung korrekt ankommen muss. Hier reicht reine Oberflächengestaltung nicht mehr aus.

Was alle diese Beispiele verbindet: Sie entstehen nicht aus dem Wunsch, etwas Besonderes zu bauen, sondern aus einer konkreten Hypothese. Erst kommt das Problem der Nutzer, dann die Lösung. Wie Probleme im Warenkorb identifiziert werden, zeige ich in Warenkorbabbrüche reduzieren.

Die Risiken, und wie du sie beherrschst

Jetzt der ehrliche Teil. Custom Development hat reale Risiken, und ich sehe die Folgen dieser Risiken regelmäßig in Shops, die zu uns kommen.

Die größten technischen Probleme in Shopify-Shops entstehen selten durch Shopify selbst, sondern durch individuelle Anpassungen. Ich sehe häufig unsauberen oder veralteten Code, der später zu Fehlern oder Performance-Problemen führt. Und das Tückische daran: Wenn Änderungen nicht sauber entwickelt werden, können spätere Anpassungen bestehende Funktionen wieder beschädigen. So entsteht über Jahre eine Schicht aus Workarounds, die niemand mehr vollständig überblickt.

Die wichtigste Gegenmaßnahme ist Quality Assurance. Sie ist für mich eines der wichtigsten Elemente im gesamten Prozess, und sie wird fast überall unterschätzt. Bevor eine Änderung oder ein Test live geht, prüfen wir unterschiedliche Einstiegspfade, also über Anzeigen, Kategorien und Navigation, nachgelagerte Schritte wie Warenkorb und Checkout, verschiedene Bildschirmgrößen sowie verschiedene Betriebssysteme und Browser. In vielen unserer Projekte liegt der mobile Traffic-Anteil bei über 90 Prozent, deshalb ist die mobile Prüfung auf realen Geräten Pflicht. Nur wenn alles sauber funktioniert, geht eine Änderung live.

Entscheidungshilfe: Theme, App oder Custom Code?

Zum Abschluss eine verdichtete Entscheidungshilfe. Sie ersetzt keine Analyse deines konkreten Shops, gibt dir aber eine ehrliche erste Orientierung.

Die erste Zeile verdient eine Betonung. Wenn ein Shop gerade startet, empfehle ich, sich nicht zu stark auf Optimierung zu fokussieren. Der wichtigste Schritt ist der Product-Market-Fit. Ein funktionierender Shop, erste konstante Verkäufe und ein validiertes Angebot sind die Grundlage. Individuelle Entwicklung lohnt sich erst, wenn klar ist, was genau optimiert werden soll.

Und noch eine Einordnung: Erfolgreiche Optimierung erfordert Kompetenzen in mehreren Bereichen gleichzeitig, nämlich Datenanalyse, Psychologie, Design, Entwicklung und Statistik. Wann es sich lohnt, diese Kompetenzen extern dazuzuholen, ordne ich auf der Seite Conversion-Optimierung Agentur ein. Custom Development ist nur einer dieser Bausteine. Ein Entwickler ohne datenbasierte Hypothese baut schöne Features, die nichts bewegen. Eine Hypothese ohne sauberen Entwickler bleibt ein Konzept. Erst das Zusammenspiel erzeugt Ergebnisse. Wie die Analyse und Priorisierung dahinter aufgebaut sind, beschreibe ich im Double Diamond Framework.

Häufig gestellte Fragen

Dein Theme bremst deine besten Ideen aus?

Im kostenlosen Erstgespräch schauen wir gemeinsam auf deinen Shop und zeigen dir, wo schlanke Eigenentwicklung und A/B-Testing den größten Hebel haben.

Erstgespräch anfragen

Chris Dengler

Gründer, Convertlab

Über den Autor: Chris Dengler

Chris ist CRO-Stratege und Gründer von Convertlab. Mit über 1.000 durchgeführten A/B-Tests und dem selbst entwickelten Double Diamond Framework hat er Shopify Brands im DACH-Raum zu nachweislich messbarem Wachstum verholfen.

Mehr über Chris Dengler →Chris Dengler kontaktieren →