---
title: "Shopify-App-Hacks 2026: Phishing und App-Sicherheit"
description: "Was hinter den Checkout-Angriffen auf Shopify-Apps steckt: entfernte Apps, die PHP-Warnung und konkrete Schritte für deine App-Sicherheitsbewertung."
url: https://shoplab.cc/shopify-news/shopify-app-hacks-checkout-phishing-2026
datePublished: 2026-10-21T10:40:00Z
---

[Zurück](https://shoplab.cc/blog)

Shopify News

# Shopify-App-Hacks 2026: Phishing und App-Sicherheit

21\. Oktober 2026 · 20 Minuten Lesezeit

![Porträt von Mark Chang, Gründer und CTO von shoplab](https://shoplab.cc/images/team/mark.jpg)

Mark Chang

Founder & CTO

Ein Kunde legt ein Produkt in einem Shopify-Shop in den Warenkorb, öffnet den Warenkorb und klickt auf den vertrauten Checkout-Button. Die nächste Seite wirkt plausibel. Vielleicht zeigt sie sogar die richtigen Produkte, Mengen und Preise. Doch der Browser hat den vorgesehenen Kaufprozess verlassen und eine Phishing-Seite erreicht.

Genau darin liegt das zentrale Risiko der im Oktober 2026 gemeldeten Checkout-Manipulationen über Shopify-Apps. Öffentliche Untersuchungen und Stellungnahmen von Entwicklern beschreiben schädliches Verhalten im Storefront, das über die Konfiguration von Drittanbieter-Apps ausgeliefert wurde. Für dich als Händler ist entscheidend, welche App den Weg deiner Kunden zum Checkout beeinflussen kann und ob dieser tatsächliche Weg in deinem Shop geprüft wurde.

Dieser Artikel erklärt die Berichte, die Funktionsweise zweier von uns untersuchter Codebeispiele, unsere frühere Erfahrung mit einem manipulierten HTML-Übersetzungsfeld und die separate PHP-Sicherheitsankündigung vom 20\. Oktober. Außerdem zeigen wir, wie du auf einen Verdacht reagieren kannst und welchen App-Katalog du vor dem nächsten Vorfall aufbauen solltest.

**Recherchestand: 21\. Oktober 2026, 10:35 UTC.** Zu diesem Zeitpunkt war die PHP-Mitteilung noch eine Vorankündigung. Wir unterscheiden im gesamten Artikel zwischen beobachtetem Verhalten, Entwicklerangaben, eigenen Erfahrungen und offenen Fragen. Die Entfernung einer App aus dem App Store belegt für sich genommen keinen Sicherheitsvorfall. Ebenso belegen die verfügbaren Berichte keinen Einbruch in die von Shopify betriebene Kernplattform.

Wenn du herausfinden möchtest, welche Apps auf den kritischen Wegen deines Shops liegen, [buche eine Shopify-App-Sicherheitsberatung mit shoplab](https://app.reclaim.ai/m/shoplab/shopify-app-security-advisory). Wir können deine installierten Apps einordnen, die Beschaffung belastbarer Informationen priorisieren und Änderungen unter Berücksichtigung deiner betrieblichen Abhängigkeiten planen.

[App-Sicherheitsberatung buchen](https://app.reclaim.ai/m/shoplab/shopify-app-security-advisory) 

## Was ist bei den Shopify-Checkout-Angriffen passiert?

In seiner [Untersuchung des Checkout-Hijacks vom 10\. Oktober](https://romanzipp.com/blog/shopify-hit-with-phishing-attack) beschreibt Roman Zipp einen verdächtigen Checkout-Ablauf, auf den er beim Einkaufen stieß. Er verfolgte das Verhalten über die Storefront-Erweiterung von Hulk Product Options bis zu einer Konfiguration zurück, die eine HulkApps-API lieferte. Diese Konfiguration enthielt benutzerdefiniertes JavaScript, das die Checkout-Aktion umleitete.

Diese Unterscheidung ist wichtig. Ein Storefront kann eine Erweiterung von einem vertrauten CDN laden und anschließend trotzdem Verhalten aus einem anderen System erhalten. Eine Prüfung, die nur die Theme-Dateien oder den Hostnamen des zuerst geladenen Skripts betrachtet, hätte die eingeschleuste Konfiguration nicht unbedingt erkannt.

Zipp berichtet außerdem, den externen Checkout mit erfundenen Angaben getestet und beobachtet zu haben, wie Informationen an einen externen Endpunkt gesendet wurden, bevor der Browser zum legitimen Checkout zurückkehrte. Das ist seine dokumentierte Live-Beobachtung. Wir haben die bereitgestellten Beispiele als Text untersucht. Wir haben sie weder ausgeführt noch ihre Zieladressen aufgerufen oder den Versuch mit dem Zahlungsformular wiederholt.

Die öffentliche Chronologie umfasst mehrere unterschiedliche Ereignisse:

| Zeitpunkt 2026 | Was die Quelle belegt | Wie die Angabe einzuordnen ist |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Juli | Unser Team fand einen eingeschleusten Schadcode in einem App-Übersetzungsfeld, das HTML zuließ. | Das ist unsere eigene Erfahrung bei shoplab, die wir weiter unten erläutern. Sie belegt keinen Zusammenhang mit den Oktober-Ereignissen. |
| Juli–August | Qikify beschreibt in seiner Stellungnahme schädliche Inhalte in anpassbaren HTML-Feldern im Juli und erklärt, das Problem sei bis August vollständig behoben worden. | Die Stellungnahme grenzt diesen früheren Vorfall ausdrücklich von der Oktober-Welle ab. |
| 10\. Oktober | Zipp veröffentlichte seine nachvollzogene Beobachtung zu Hulk Product Options. HulkApps beschrieb anschließend unbefugte Konfigurationsänderungen und Weiterleitungen zu externen Checkouts. | Das stützt einen konkreten, über diese App ausgelieferten Vorfall. Es ist keine Aussage über jedes HulkApps-Produkt oder jede Installation. |
| 13\. Oktober | Logbase beschrieb unbefugten Zugriff auf ein internes Werkzeug und veränderte Einstellungen bei einer Reihe von Selleasy-Shops zwischen 07:47 und 15:00 UTC. | Nach Angaben des Anbieters waren die eingeschleusten Skripte um 15:00 UTC entfernt. Diese Aussage bezieht sich auf den damaligen Vorfall und Zeitpunkt. |
| 14\. Oktober | Swym beschrieb unbefugte Konfigurationsänderungen, die eine begrenzte Teilmenge von Storefront-Seiten betrafen. Die Gegenmaßnahmen seien um 16:32 UTC vollständig ausgerollt gewesen. | Daraus folgt nicht, dass jede Swym-Installation oder jede Kundensitzung betroffen war. |
| 20\. Oktober | Das PHP-Sicherheitsteam kündigte eine bevorstehende Veröffentlichung an, die zwei kritische Sicherheitslücken beheben soll. | Das ist eine separate Warnung zur Backend-Sicherheit. Keine der zitierten Quellen stellt einen Zusammenhang zu den Checkout-Manipulationen her. |

Die genannten Entwicklerangaben sind in Zipps [Zusammenstellung der Unternehmensstellungnahmen](https://romanzipp.com/blog/statements-from-companies-involved-in-shopify-checkout-hijack) dokumentiert. Sie liefern hilfreiche Zeitfenster und Aussagen zur Eindämmung. Trotzdem musst du klären, was in deinem eigenen Shop passiert ist. Die Berichte enthalten weder eine verifizierte Gesamtzahl betroffener Shops oder entwendeter Datensätze noch einen belegten gemeinsamen Einstiegspunkt für alle Vorfälle.

### Welche Apps sind bestätigt, welche Meldungen bleiben unbestätigt?

Zu Hulk Product Options, Selleasy und Swym Wishlist Plus liegen konkrete Vorfallsberichte und Entwicklerangaben zu unbefugten Konfigurationsänderungen oder eingeschleustem Code vor. Der Geltungsbereich jeder Aussage ist dabei genauso wichtig wie der Name der App.

HulkApps beschrieb unbefugte Konfigurationsänderungen an der Theme-Erweiterung von Product Options. Laut Stellungnahme gab es keine Hinweise darauf, dass andere Hulk-Apps die Weiterleitungen ausgeliefert hatten. Logbase beschrieb, dass eine unbefugte Person Einstellungen über ein internes Werkzeug geändert hatte. Während die Untersuchung noch lief, meldete der Anbieter zu diesem Zeitpunkt keine Hinweise auf einen Einbruch in das Selleasy-Backend oder dessen Datenbank. Swym meldete keine Hinweise auf einen Zugriff auf Händlerkonten oder auf bei Swym gespeicherte Daten.

Diese Aussagen müssen präzise gelesen werden. Wenn ein Entwickler keine Hinweise auf einen Zugriff auf seine Datenbank findet, belegt das nicht, dass ein Kunde keine Daten preisgegeben hat, nachdem er Angaben auf einer externen Phishing-Seite eingegeben hatte. App-Backend, Händlerkonto, Browser und externe Zielseite sind unterschiedliche Orte, an denen relevante Spuren vorliegen können.

Andere Apps wurden in öffentlichen Diskussionen genannt oder tauchten in Listen entfernter Apps auf, ohne dass eine vergleichbare Bestätigung vorlag. In seiner Übersicht vom 20\. Oktober [unterscheidet Revenue Shield zwischen vom Anbieter bestätigten Fällen und unbestätigten Berichten](https://getrevenueshield.com/security/delisted-shopify-apps). Privy und Boost AI Search & Filter werden dort als in Berichten genannte Apps eingeordnet, ohne dass die dort besprochenen Anbieterinformationen eine Phishing-Ursache bestätigen. Auf dieser Grundlage stufen wir keine der beiden Apps als bestätigten Fall einer Checkout-Kompromittierung ein.

Für dich ist deshalb ein genauerer Datensatz als eine Liste vermeintlich „schlechter Apps“ hilfreich: welches Produkt, welche Belege, welches Vorfallsfenster, welche betroffene Funktion, welche Bestätigung des Entwicklers und welche noch offenen Fragen.

## So funktioniert das erste Beispiel zur Checkout-Manipulation

Das erste Beispiel zeigt, wie schädlicher Storefront-Code den Übergang vom Warenkorb zum Checkout übernehmen kann. Wer den Ablauf versteht, kann eine aussagekräftige Prüfung wählen, ohne den Schadcode zu verbreiten.

### Der Code wartet auf eine gewöhnliche Checkout-Aktion

Der Code registriert Listener für verschiedene Interaktionen, darunter Zeiger-, Touch-, Klick- und Formularereignisse. Er sucht nach erkennbaren Checkout-Bedienelementen. Das geht über den Austausch eines sichtbaren Links hinaus: Der Listener kann in der Ereignisstruktur der Seite weiter oben sitzen und eine Aktion abfangen, die scheinbar zu einem normalen Theme-Button gehört.

Bei einer passenden Interaktion unterbricht er die vorgesehene Aktion und hindert andere Handler daran, sie abzuschließen. Ein Checkout-Button kann deshalb unverändert aussehen, obwohl der Browser nach dem Klick einen anderen Weg nimmt. Die sichtbare Beschriftung oder das hinterlegte Linkziel allein zu prüfen, reicht nicht aus.

### Der echte Warenkorb wird für die Weiterleitung aufbereitet

Das Beispiel liest den aktuellen Storefront-Warenkorb aus und bereitet Informationen zu Produkten, Varianten, Mengen, Bildern, Währung, Summen und Rabatten auf. Vor der Weiterleitung versucht es, einen stabilen Stand des Warenkorbs zu erhalten. Falls diese ausführliche Vorbereitung scheitert, ist ein Ausweichweg vorgesehen.

Die externe Seite erhält dadurch Kontext, der sie wie einen Teil des tatsächlichen Kaufs erscheinen lassen kann. Ein Phishing-Checkout mit dem richtigen Warenkorb wirkt überzeugender als ein unverbundenes Formular. Die Warenkorbinformationen dienen als Tarnung, auch wenn sie selbst noch keine Zahlungszugangsdaten sind.

Das Beispiel behält außerdem einen Rückweg zum echten Checkout. Das erklärt, warum ein später scheinbar erfolgreicher Einkauf eine vorherige Umleitung nicht unbedingt widerlegt. Die verdächtige Seite kann ein zusätzlicher Zwischenstopp im Kaufprozess sein, statt dessen endgültiges Ziel.

### Das Sitzungsverhalten kann einen schnellen Wiederholungstest täuschen

Der Code speichert eine Transaktionskennung und eine Markierung für die bereits erfolgte Weiterleitung im Session-Speicher des Browsers. Nach einer Weiterleitung kann ein späterer Checkout-Versuch innerhalb derselben Sitzung wieder regulär durchgelassen werden. Wenn du zweimal klickst, kannst du also zuerst ein verdächtiges und danach ein unauffällig wirkendes Ergebnis sehen.

Für die Reproduktion dieses konkreten Verhaltens ist deshalb ein frischer Browserkontext wichtig. Das bedeutet weder, dass jedes Beispiel identisch arbeitet, noch dass ein privates Fenster die Erkennung garantiert. Der Test muss den Ablauf und die Sitzungsbedingungen festhalten, nicht nur die zuletzt angezeigte Seite.

### Storefront-Beispiel und Phishing-Seite sind getrennte Bestandteile

Unsere statische Untersuchung belegt das Abfangen von Interaktionen, die Vorbereitung des Warenkorbkontexts und die Navigation zu einer externen Adresse. Sie zeigt nicht, wie die externe Seite Zahlungsinformationen erfasst. Die Aussage über die dortige Datenerfassung stammt aus Zipps separat berichteter Beobachtung.

Wir veröffentlichen bewusst keinen ausführbaren Code, keine kodierten Inhalte und keine Zieladressen der Angreifer. Du kannst die Schwachstelle im Ablauf verstehen und die relevanten Bereiche untersuchen, ohne ein funktionsfähiges Skript zur Checkout-Umleitung weiterzugeben.

## Unser Fund im Juli: Wenn ein Übersetzungsfeld Code ausführt

Im Juli 2026 fand unser Team einen eingeschleusten Schadcode in einem App-Übersetzungsfeld, das HTML zuließ. Eine Einstellung, die als Text für Kunden gedacht war, war zu einem Weg für die Ausführung von Code im Browser geworden.

HTML-Unterstützung ist nicht grundsätzlich eine Sicherheitslücke. Händler benötigen mitunter Formatierungen, Links oder andere kontrollierte Auszeichnungen. Entscheidend ist die Sicherheitsgrenze: Behandelt die App das Feld als eingeschränkten Inhalt und bereinigt es entsprechend, oder gelangen ausführbare Auszeichnungen und Ereignisbehandlung in den Storefront?

Das zweite illustrative Beispiel, das wir für diesen Artikel untersucht haben, nutzt genau eine solche Grenze. Es enthält eine HTML-Hülle, die kodierten Browsercode auslöst und anschließend ihr auslösendes Element entfernt. Die Kodierung erschwert es, das Verhalten bei einer oberflächlichen Durchsicht des Übersetzungswerts zu erkennen. Sie verschlüsselt den Code nicht und macht ihn auch nicht sicher.

Das Beispiel wurde am 21\. Oktober veröffentlicht. Sein Veröffentlichungsdatum und interne Datumsmarkierungen belegen nicht unabhängig, wann ein Händler betroffen war. Unsere zeitliche Einordnung im Juli beruht auf dem Bericht unseres Teams. Wir stellen das veröffentlichte Beispiel nicht als originales, mit einem gesicherten Zeitstempel versehenes forensisches Artefakt dieses Vorfalls dar.

### Eine unsichtbare Ebene kann über dem echten Button liegen

Das dekodierte Beispiel kombiniert mehrere Mechanismen. Es findet ein Checkout-Bedienelement eines Sticky Carts und positioniert darüber eine transparente interaktive Ebene. Optisch sieht der Kunde den legitimen Button; seine Interaktion kann stattdessen auf der eingefügten Ebene landen.

Der Code reagiert außerdem auf Seitenänderungen, Aktivitäten des Warenkorb-Drawers, Scrollen und Größenänderungen. So bleibt die Ebene ausgerichtet, wenn sich die Warenkorboberfläche bewegt. Deshalb kann eine Prüfung des ursprünglichen HTML-Dokuments oder ein Test vor dem vollständigen Öffnen des Drawers relevantes Verhalten übersehen. Moderne Storefronts verändern sich nach dem Laden des ersten Dokuments.

Zusätzlich zur überlagernden Ebene fängt das Beispiel checkoutbezogene Klicks und Formularübermittlungen ab. Es liest den Warenkorbkontext aus, vereinheitlicht ihn, behält das vorgesehene Rücksprungziel zum Checkout, verhindert doppelte Verarbeitung und bereitet die Übergabe an die externe Seite vor. Diese sich ergänzenden Mechanismen machen es anpassungsfähiger als einen einzelnen veränderten Hyperlink. Sie belegen aber weder eine bestimmte Erfolgsquote noch einen gemeinsamen Angreifer.

### Serverprotokolle können nur einen Teil der Übertragung zeigen

Das Beispiel versucht, Kontext über Browserzustand und den Fragmentteil einer Navigations-URL zu übertragen. Ein URL-Fragment wird normalerweise nicht in der HTTP-Anfrage mitgesendet. Code auf der Zielseite kann es jedoch auslesen. Ein Server-Zugriffsprotokoll enthält deshalb unter Umständen nicht den gesamten Kontext, der dem Browser am Ziel zur Verfügung steht.

Auch die Datenschutzmechanismen des Browsers können beeinflussen, wie Browserzustand über verschiedene Ursprünge hinweg behandelt wird. Eine statische Analyse zeigt, was der Code versucht. Sie beweist nicht, dass jede Übertragungsmethode in jedem Browser gleich funktioniert.

Der zentrale Punkt bleibt: Ein schädlicher Inhalt in einem Übersetzungsfeld zeigt, wo er ausgeliefert wurde. Er zeigt nicht, wie ein Angreifer die Berechtigung erlangt hat, dieses Feld zu ändern. Aus einem Feldwert oder einem auffälligen Variablennamen können wir weder eine Authentifizierungslücke noch gestohlene Zugangsdaten oder eine Verbindung zu den Oktober-Vorfällen ableiten.

## Was eine entfernte Shopify-App tatsächlich aussagt

[Das Archiv entfernter Apps von HeyApps](https://heyapps.dev/apps/delisted) hilft dabei, die Verfügbarkeit im App Store nachzuverfolgen und historische Einträge einzusehen. Es unterscheidet außerdem wiederhergestellte Einträge. Wir empfehlen es als Quelle, um die tatsächlich in einem Shop installierten Apps gegenzuprüfen.

Es ist keine Liste nachgewiesener Opfer oder böswilliger Entwickler. Das Archiv umfasst Entfernungen aus unterschiedlichen Gründen und Zeiträumen. Revenue Shield beschrieb in seinem Artikel vom 20\. Oktober 135 Entfernungen seit dem 14\. Oktober. Das ist eine datierte Zahl für einen festgelegten Zeitraum, keine verifizierte Anzahl von Apps, die an dem Angriff beteiligt waren. Weder diese Zahl noch das größere HeyApps-Archiv rechtfertigen eine Schlagzeile, wonach genauso viele Apps gehackt wurden.

Die Entfernung aus dem App Store und die Behebung eines Problems beantworten außerdem unterschiedliche Fragen. Wenn eine App nicht mehr neu installiert werden kann, beweist das nicht, dass ihre bestehende Installation, ihr App Embed, ihre Konfiguration, ihre Zugangsdaten oder zurückgebliebener Theme-Code aus einem Händler-Shop entfernt wurden. Umgekehrt bestätigt die Rückkehr einer App in den App Store nicht, wie ein bestimmter Shop zuvor betroffen war.

Halte für jeden relevanten Eintrag das Beobachtungsdatum, den aktuellen Listing-Status, die Entwicklerstellungnahme und den tatsächlichen Installationsstatus fest. Frage nach dem Grund der Entfernung und danach, ob der Entwickler einen betroffenen Zeitraum oder notwendige Händlermaßnahmen nennt. Ein fehlendes Listing ist kein Grund für eine unbelegte Anschuldigung. Ein wiederhergestelltes Listing ersetzt ebenso wenig die Prüfung deines eigenen Checkouts.

## Die PHP-Warnung im Oktober: ein separat zu prüfendes Thema

Am 20\. Oktober veröffentlichte das PHP-Sicherheitsteam eine [Vorankündigung einer kritischen Sicherheitsveröffentlichung](https://www.php.net/archive/2026.php#2026-10-20-1). Angekündigt wurden Korrekturen für **zwei Sicherheitslücken mit jeweils CVSS v4.0 9,2**, vorgesehen für den 21\. Oktober um 14:00 UTC.

Bei unserer Prüfung am 21\. Oktober um 10:35 UTC enthielt die Mitteilung noch keine CVE-Kennungen, technischen Details, betroffenen Versionsbereiche oder Versionsnummern der Korrekturen. Diese Informationen wurden für die Veröffentlichung angekündigt. Die Aussage, dass die Veröffentlichung bei Hinweisen auf Ausnutzung vorgezogen werden könnte, war eine Bedingung. Sie war keine Meldung über bestätigte aktive Angriffe.

Das ist für Shopify-App-Anbieter relevant, die PHP-Backends betreiben. Ihre Infrastruktur ist von der gehosteten Shopify-Plattform getrennt. Du kannst Shopify nutzen und gleichzeitig externe App-Dienste einsetzen, die auf PHP oder anderen Technologien aufbauen. Für die Pflege dieser Dienste ist der jeweilige Entwickler verantwortlich.

Die Ankündigung belegt weder, dass eine bestimmte Shopify-App verwundbar ist, noch dass ältere Apps zwangsläufig mit PHP gebaut wurden oder die PHP-Probleme die oben beschriebenen Checkout-Vorfälle verursacht haben. Ob eine App betroffen ist, hängt von der vollständigen Sicherheitsmeldung sowie von Laufzeitumgebung und Konfiguration des Anbieters ab. Ein öffentlich sichtbares Storefront-Merkmal belegt solche Backend-Details nur selten.

Stelle den relevanten Anbietern vier konkrete Fragen:

1. Verwendet die App PHP in einer für unseren Shop relevanten Komponente, und ist die tatsächlich eingesetzte Konfiguration laut veröffentlichter Sicherheitsmeldung betroffen?
2. Welche unterstützte Korrektur oder Gegenmaßnahme ist anwendbar, und wann wird sie ausgerollt?
3. Wie wird die Umsetzung überprüft, einschließlich dauerhaft gespeicherter Konfiguration oder Zugangsdaten, falls ein Einbruch vermutet wird?
4. Wer liefert eine datierte Aktualisierung, wenn sich die Bewertung ändert?

[Der offizielle PHP-Support-Lebenszyklus](https://www.php.net/supported-versions.php) ist eine separate Wartungsprüfung. Ein nicht mehr unterstützter Versionszweig ist ein Risiko, auch wenn keine Hinweise vorliegen, dass diese konkreten Sicherheitslücken darauf zutreffen. Ein gewöhnlicher Storefront-Checkout-Test kann nicht beweisen, dass ein App-Anbieter sein Backend aktualisiert hat.

## Was du als Händler jetzt tun solltest

### 1\. Das aktuelle Verhalten des Shops nachvollziehen

Nutze eine frische Browsersitzung und gehe einen realistischen Weg: Öffne ein Produkt, wähle gegebenenfalls die erforderliche Variante, lege es in den Warenkorb, öffne die tatsächliche Warenkorboberfläche und klicke auf deren Checkout-Bedienelement. Dokumentiere Zeitpunkt, Gerät, Produkt, Sprache und getesteten Weg sowie die Zieladressen der Browsernavigation.

Rufe nicht direkt die bekannte Checkout-Adresse auf. Damit würdest du die Storefront-Interaktion umgehen, die diese Beispiele abfangen. Beziehe den Warenkorb-Drawer und gegebenenfalls appbasierte Sticky-Cart-Bedienelemente ein, die deine Kunden tatsächlich verwenden. Wirkt das Ziel verdächtig, stoppe vor der Eingabe persönlicher Daten oder Zahlungsinformationen.

Eine unbekannte Domain muss untersucht werden, ist aber nicht automatisch ein Beweis für Phishing. Legitime Händlerdomains, der Shopify-Checkout, Shop Pay und zugelassene Zahlungsanbieter können im Kaufprozess vorkommen. Vergleiche die beobachteten Ziele mit dem erwarteten Ablauf des Händlers, einschließlich regionaler Unterschiede und unterschiedlicher Zahlungsmethoden.

### 2\. Beweise vor der Bereinigung sichern

Sichere relevante Zeitstempel, Screenshots, App- und Theme-Konfigurationen, verdächtige Ziele und verfügbare Protokolle. Bewahre sensible Belege in einer zugriffsbeschränkten Vorfallsdokumentation auf, nicht in einem öffentlichen Support-Thread. Kopiere oder öffne verdächtige Schadcode-Beispiele nicht in einer gewöhnlichen Browsersitzung.

Wenn du eine Umleitung beobachtest, beziehe Shopify und den betreffenden Entwickler umgehend ein. Befolge aktuelle Anweisungen zur Eindämmung und deaktiviere die betroffene Ausführungsmöglichkeit, soweit das betrieblich sicher möglich ist. Bewahre genügend Belege auf, um das betroffene Zeitfenster nachvollziehen zu können. Wahllos weitere Apps zu entfernen, kann den Shop beschädigen und die Untersuchung erschweren.

### 3\. Über den Theme-Download hinaus prüfen

Prüfe Theme App Embeds und zurückgebliebenen Code, externe Skripte, Einstellungen für benutzerdefiniertes JavaScript, Übersetzungen, Rich-Text- oder HTML-Felder sowie Konfigurationen, die App-Dienste zurückliefern. Untersuche Zugriffe benutzerdefinierter Apps und relevante Webhooks, wenn die Befunde dorthin führen.

Die Oktober-Berichte zeigen, warum ein unauffälliges Theme-Archiv keine vollständige Antwort liefert: Eine App kann nach dem Laden der Seite weiteres Verhalten bereitstellen. Ebenso kann das Löschen eines sichtbaren Schadcodes den Account oder Konfigurationsdienst, aus dem er stammt, weiterhin für den Angreifer zugänglich lassen.

### 4\. Umfang und Eindämmung anhand von Belegen klären

Bitte den Entwickler um das Vorfallsfenster, die Ermittlung betroffener Shops, die beeinträchtigten Funktionen, die Eindämmungsmaßnahmen und die noch offenen Fragen zur Ursache. Kläre, welche Aussagen seine eigene Datenbank betreffen und welche die Interaktion eines Kunden mit einer externen Seite.

Überprüfe administrative Zugriffe und Zugangsdaten mit den zuständigen Verantwortlichen. Eine Passwortänderung entfernt weder dauerhaft gespeicherte Inhalte noch macht sie jeden Token ungültig oder belegt, dass die Quelle unbefugter Änderungen geschlossen wurde. Widerruf und Austausch von Zugangsdaten sollten sich nach dem tatsächlich betroffenen Zugriff richten. Berücksichtige dabei, welche Integrationen dadurch unterbrochen werden können.

### 5\. Auswirkungen auf Kunden klären und die Wiederherstellung prüfen

Wenn Kunden möglicherweise Angaben auf einer externen Seite eingegeben haben, ziehe die zuständigen Fachleute für Sicherheit, Zahlungsverkehr und Datenschutz hinzu. Benachrichtigungspflichten hängen von den Fakten und dem anwendbaren Recht ab. Eine allgemeine Internet-Checkliste kann diese Entscheidung nicht für jeden Händler treffen.

Wiederhole nach der Behebung den betroffenen Ablauf in frischen Sitzungen und über die relevanten Oberflächen. Dokumentiere, was geändert und was erneut geprüft wurde. Halte den Vorfall offen, solange Umfang, dauerhafte Veränderungen oder die Backend-Bereinigung ungeklärt sind, auch wenn ein aktueller Checkout-Test normal aussieht.

[App-Sicherheitsberatung buchen](https://app.reclaim.ai/m/shoplab/shopify-app-security-advisory) 

## Einen App-Katalog nach kritischen Geschäftsabläufen aufbauen

Eine Liste installierter Apps wird dann nützlich, wenn sie erklärt, was jede App tun kann und was von ihr abhängt. Logos oder monatliche Abonnementkosten beantworten nicht, ob eine App den Checkout beeinflussen, Kundendaten lesen oder bei ihrer Entfernung die Auftragsabwicklung unterbrechen kann.

Bei shoplab beginnen wir mit dem Katalog installierter Apps und seiner Verbindung zu den Abläufen im Shop. Dabei bauen wir auf Arbeiten zur App-Inventarisierung für Maniko und Pergolux auf. Diese Referenzen beschreiben unseren Bewertungsansatz, keine Beteiligung an den hier besprochenen Vorfällen.

Für jede App und individuelle Integration sollte der Katalog Folgendes enthalten:

| Bereich | Was wir erfassen | Warum es die Entscheidung beeinflusst |
| ---------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Zweck und Verantwortlichkeit | Geschäftsfunktion, Entwickler, interne Zuständigkeit und aktuelle Nutzung | Klärt, wer die Abhängigkeit erklären und Änderungen freigeben kann. |
| Zugriff | Gewährte API-Berechtigungen, relevante Datenkategorien und Schreibmöglichkeiten | Zeigt die möglichen Folgen eines unbefugten Zugriffs. |
| Ausführung im Storefront | App Embeds, Skripte, Konfigurationsabrufe und bearbeitbare Inhaltsfelder | Identifiziert, wo eine App verändern kann, was Kunden sehen oder anklicken. |
| Kritische Abläufe | Produktauswahl, Warenkorb, Übergang zum Checkout, Kundenkonten, Bestellungen und Fulfillment | Priorisiert die Auswirkungen auf Kunden und Umsatz. |
| Belege des Anbieters | Vorfallsmeldungen, Antwortdaten, Wartungsinformationen und relevante Bestätigungen von Updates | Trennt überprüfte Fakten von unbeantworteten Fragen. |
| Folgen einer Entfernung | Theme-Reste, Datenexport, Abläufe, Ersatzbedarf und Rückfallplan | Macht Eindämmung und geplante Entfernung sicherer. |

Eine Risikobewertung sollte **Befugnisse, Angriffsfläche, geschäftliche Auswirkungen und Beleglage** gemeinsam betrachten. Eine Storefront-App mit weitreichendem Konfigurationszugriff und ungeklärtem Vorfall erfordert eine andere Reaktion als eine ungenutzte App mit eng begrenzten Berechtigungen. Ein unbekannter Patch-Status im Backend ist eine zu klärende Frage, keine bestätigte Sicherheitslücke, die man daraus ableiten dürfte.

Öffentliche Scans sind nur eine Informationsquelle. Eine reine Admin- oder Server-App muss keine sichtbaren Spuren im Browser hinterlassen. Umgekehrt steht eine erkannte Analytics-Domain, ein Zahlungsdienst oder eine gemeinsam genutzte Bibliothek nicht automatisch für eine installierte Shopify-App. Wir gleichen Browserbeobachtungen mit den tatsächlichen Apps, Berechtigungen, individuellen Integrationen und Antworten der Anbieter ab.

Das Ergebnis sollte ein handlungsfähiger Katalog sein: Was ist bekannt, was ist unklar, welche Punkte benötigen sofortige Aufmerksamkeit, wer verantwortet den nächsten Schritt und wie wird seine Umsetzung überprüft? Beginne mit unserem [kostenlosen Shopify-Checkout-Check](https://shoplab.cc/shopify-checkout-check) für einen beobachteten Kaufablauf. Nutze diese Erkenntnisse anschließend zusammen mit dem App-Katalog und der laufenden [Shopify-Betreuung](https://shoplab.cc/shopify-betreuung).

## Was ein schneller Desktop-Checkout-Check nachweisen kann

[Starte unseren kostenlosen Desktop-Checkout-Check](https://shoplab.cc/shopify-checkout-check), um einen Kaufablauf zu beobachten und einen Bericht mit sichtbaren App- und Dienstmerkmalen zu erhalten.

Ein kleiner browserbasierter Check ist als erste Beobachtung sinnvoll. Er kann ein Produkt aufrufen, mit dem Warenkorb interagieren, den tatsächlichen Checkout-Button anklicken, Weiterleitungen dokumentieren und das Ergebnis mit Screenshots zeigen. Ein Bericht kann den zurückgelegten Weg, erwartete und beobachtete Ziele, sichtbare App- oder Dienstmerkmale und nicht abschließbare Schritte enthalten.

Die Ergebnisbezeichnungen müssen ehrlich bleiben. „Erwarteter Checkout in diesem Durchlauf erreicht“ ist eine belegbare Aussage. „Dein Shop ist sicher“ ist es nicht. Ein unerwartetes Ziel muss geprüft werden. Eine Bot-Abfrage, ein nicht verfügbares Produkt oder eine nicht unterstützte Warenkorbinteraktion sollte zu einem nicht abschließenden Ergebnis führen, statt zu einer grünen Erfolgsmeldung.

Ein einzelner Desktop-Durchlauf deckt nicht jedes Gerät, jede Sprache, Region, Kundensituation, verzögerte Auslösung oder Zahlungsmethode ab. Sitzungsabhängiges Verhalten ist hier besonders wichtig. Ein Test, der am Ende den richtigen Checkout erreicht, kann vorher trotzdem über eine unerwartete Seite geführt haben. Deshalb zählt die gesamte Navigationsfolge.

Ebenso wenig kann der Check nachweisen, welche Apps ausschließlich im Backend installiert sind, ob die Infrastruktur eines Anbieters aktualisiert wurde oder ob frühere Kunden betroffen waren. Nach einer begrenzten Prüfung sollten die Befunde untersucht und diese Lücken durch eine App-Bewertung geschlossen werden. Der Browser sollte stoppen, bevor echte Kunden- oder Zahlungsdaten eingegeben oder eine Bestellung ausgelöst werden.

## Das gleiche Risiko nach dem Vorfall verringern

Behandle die App-Prüfung als Teil des Shop-Betriebs. Benenne für jede Integration einen Verantwortlichen, entferne unnötige Zugriffe in einem geplanten Verfahren und prüfe Apps auf kritischen Geschäftswegen erneut, wenn sich Berechtigungen, Zuständigkeiten oder Konfigurationen ändern. Verfolge Sicherheitsmeldungen der Entwickler und lege einen Kontaktweg für Vorfälle fest, bevor du ihn dringend brauchst.

Wenn dein Team eine App entwickelt, muss es Inhalte von ausführbarem Verhalten trennen. Begrenze, wer sensible Konfigurationen ändern darf, prüfe und bereinige unterstützte HTML-Inhalte, schütze administrative Werkzeuge, führe nachvollziehbare Änderungsprotokolle und pflege die Backend-Laufzeitumgebung. Auch eine flexible Übersetzungs- oder Inhaltsfunktion benötigt eine klar durchgesetzte Sicherheitsgrenze.

Bei individuellen Funktionen sollten diese Wartungs- und Betriebsaufgaben zum Umfang der [Shopify-App-Entwicklung](https://shoplab.cc/shopify-app-entwicklung) gehören. Eine Funktion ist nicht allein deshalb fertig, weil der vorgesehene Erfolgsfall korrekt dargestellt wird.

## Häufige Fragen

### Wurde Shopify selbst gehackt?

Die hier besprochenen Quellen beschreiben Checkout-Umleitungen, die über die Konfiguration von Drittanbieter-Apps und Verhalten im Storefront ausgeliefert wurden. Sie belegen keinen Einbruch in die von Shopify betriebene Kernplattform. Diese Unterscheidung macht es nicht weniger schwerwiegend, wenn ein Kunde auf eine externe Phishing-Seite geschickt wird. Sie hilft dabei, die zu untersuchenden Systeme und Anbieter zu identifizieren.

### Bedeutet eine entfernte App, dass mein Shop kompromittiert wurde?

Nein. Die Entfernung ist ein Status im App Store und kann unterschiedliche Ursachen haben. Prüfe, ob die App installiert ist, was der Entwickler bestätigt hat, ob dein Shop in ein genanntes Vorfallsfenster fällt und was deine eigenen Belege zeigen. Ein Archiveintrag wird ohne weitere Belege nicht zu einem Nachweis eines Einbruchs.

### Reicht es aus, die App zu deinstallieren?

Das kann einen wichtigen Teil der Angriffsfläche entfernen. Es belegt für sich genommen aber weder eine vollständige Bereinigung noch den historischen Umfang. Relevante Theme-Reste, gespeicherte Konfigurationen, Zugangsdaten und andere betroffene Systeme müssen möglicherweise weiter untersucht werden. Befolge aktuelle Anweisungen des Entwicklers und von Shopify und überprüfe nach den Änderungen das tatsächliche Verhalten des Storefronts.

### Kann ein Shop einen Check bestehen und trotzdem ein Problem haben?

Ja. Ein Test beobachtet eine bestimmte Sitzung und einen bestimmten Ablauf. Das erste hier untersuchte Beispiel kann spätere Checkout-Versuche nach einer Weiterleitung innerhalb derselben Sitzung wieder durchlassen. Andere Geräte, Warenkorb-Bedienelemente, Regionen oder reine Backend-Probleme können ebenfalls außerhalb eines einzelnen Tests liegen. Ein unauffälliges Ergebnis sollte genau benennen, was geprüft wurde.

### Welche Shopify-Apps sind von der PHP-Ankündigung betroffen?

Die Vorankündigung vom 20\. Oktober nennt keine Shopify-Apps und veröffentlicht keine betroffenen Versionsbereiche. Sobald die Details vorliegen, muss die Anwendbarkeit anhand der vollständigen PHP-Sicherheitsmeldung und der tatsächlich eingesetzten Konfiguration jedes Anbieters geprüft werden. PHP-Nutzung oder das Alter einer App allein belegen weder eine Sicherheitslücke noch einen Einbruch.

### Kann shoplab mit einem öffentlichen Scan jede installierte App erkennen?

Nein. Sichtbare Skripte und Browseranfragen liefern nur einen Teil der Hinweise. Ein vollständiger Katalog erfordert autorisierten Zugriff auf die Informationen zu installierten Apps, Berechtigungen und relevanten individuellen Integrationen. Dazu kommen Antworten der Entwickler, wenn Infrastrukturdetails nicht öffentlich sichtbar sind. Wir unterscheiden bestätigte Installationen von abgeleiteten Dienstmerkmalen.

### Was erhalte ich bei einer App-Sicherheitsbewertung?

Die Bewertung übersetzt deine App-Landschaft in einen priorisierten Maßnahmenplan: installierte Apps und Zuständigkeiten, Berechtigungen und Datenzugriff, Ausführung im Storefront, Abhängigkeiten kritischer Abläufe, relevante Vorfalls- und Patch-Belege, offene Fragen und empfohlene nächste Schritte. Sie schafft eine Grundlage für Entscheidungen und spätere Überprüfungen. Sie ist keine Zertifizierung dafür, dass ein Shop niemals kompromittiert werden kann.

## Shopify-App-Sicherheitsberatung buchen

Wenn du nicht weißt, welche Apps deinen Checkout beeinflussen können, ob eine Entfernung aus dem App Store für deinen Shop relevant ist oder welche Anbieter zur PHP-Warnung Stellung nehmen sollten, beginne mit einem gezielten Gespräch.

Wir nutzen deine App-Landschaft und geschäftlichen Abhängigkeiten, um die passende Bewertung zu definieren. Anschließend können wir vereinbaren, welche Inventarisierung, Zugriffsprüfung, beobachteten Checkout-Tests und Rückfragen an Anbieter für eine sinnvolle Risikobewertung nötig sind. Du erhältst Prioritäten und klar verantwortete nächste Schritte statt einer allgemeinen Liste zu löschender Apps.

Halte möglichst deine Liste installierter Apps, Vorfallsmeldungen von Entwicklern und den ungefähren Zeitpunkt verdächtigen Verhaltens bereit. Sende keine Zahlungsdaten, Passwörter oder ausführbaren Schadcode über ein Buchungsformular.

[App-Sicherheitsberatung buchen](https://app.reclaim.ai/m/shoplab/shopify-app-security-advisory) 

## Quellen und Grenzen der Recherche

* [HeyApps-Archiv entfernter Shopify-Apps](https://heyapps.dev/apps/delisted): Verlauf des Listing-Status, geprüft am 21\. Oktober; keine Liste nachgewiesener Kompromittierungen.
* [PHP-Vorankündigung einer kritischen Sicherheitsveröffentlichung vom 20\. Oktober](https://www.php.net/archive/2026.php#2026-10-20-1): zwei angekündigte Sicherheitslücken und der geplante Veröffentlichungstermin, geprüft vor Bekanntgabe technischer Details.
* [Support-Lebenszyklus der PHP-Versionen](https://www.php.net/supported-versions.php): Wartungsstatus, getrennt vom betroffenen Versionsbereich einer konkreten Sicherheitsmeldung.
* [Von shoplab bereitgestelltes Codebeispiel auf GitHub Gist](https://gist.github.com/mrpacman101/a81c24c0a9e8bda535186ec5010e4860): Referenz für die statische Erläuterung der Manipulation über ein HTML-Übersetzungsfeld. Der Code wird hier weder eingebettet noch ausgeführt; der Upload am 21\. Oktober belegt nicht unabhängig den Zeitpunkt unseres berichteten Funds im Juli.

Unsere technische Erläuterung beruht auf einer statischen Untersuchung der beiden bereitgestellten Beispiele. Wir haben sie nicht ausgeführt und ihre externen Zieladressen nicht getestet. Der Fund im Übersetzungsfeld im Juli ist unser eigener Bericht bei shoplab. Wir behaupten weder einen gemeinsamen Angreifer noch eine verifizierte Gesamtzahl betroffener Händler oder eine unabhängig festgestellte Ursache für jeden Vorfall.

1. [01Was ist bei den Shopify-Checkout-Angriffen passiert?](#was-ist-bei-den-shopify-checkout-angriffen-passiert)
2. [02So funktioniert das erste Beispiel zur Checkout-Manipulation](#so-funktioniert-das-erste-beispiel-zur-checkout-manipulation)
3. [03Unser Fund im Juli: Wenn ein Übersetzungsfeld Code ausführt](#unser-fund-im-juli-wenn-ein-ubersetzungsfeld-code-ausfuhrt)
4. [04Was eine entfernte Shopify-App tatsächlich aussagt](#was-eine-entfernte-shopify-app-tatsachlich-aussagt)
5. [05Die PHP-Warnung im Oktober: ein separat zu prüfendes Thema](#die-php-warnung-im-oktober-ein-separat-zu-prufendes-thema)
6. [06Was du als Händler jetzt tun solltest](#was-du-als-handler-jetzt-tun-solltest)
7. [07Einen App-Katalog nach kritischen Geschäftsabläufen aufbauen](#einen-app-katalog-nach-kritischen-geschaftsablaufen-aufbauen)
8. [08Was ein schneller Desktop-Checkout-Check nachweisen kann](#was-ein-schneller-desktop-checkout-check-nachweisen-kann)
9. [09Das gleiche Risiko nach dem Vorfall verringern](#das-gleiche-risiko-nach-dem-vorfall-verringern)
10. [10Häufige Fragen](#haufige-fragen)
11. [11Shopify-App-Sicherheitsberatung buchen](#shopify-app-sicherheitsberatung-buchen)
12. [12Quellen und Grenzen der Recherche](#quellen-und-grenzen-der-recherche)

Sichere dir eine kostenlose Beratung

Kompetente Beratung, zugeschnitten auf dein Shopify-Business.

Noch Fragen?

## Lass uns das klären!

Wir haben die häufigsten Fragen samt Antworten gesammelt, damit du unsere Services besser einschätzen kannst.

 

![Porträt eines shoplab-Teammitglieds](https://shoplab.cc/images/faq/faq-contact.jpg)

Noch eine Frage offen?

Lass uns telefonieren und sie klären.

### Arbeitet ihr nur mit Shopify?

Ja. Wir arbeiten seit 2020 ausschließlich mit Shopify und Shopify Plus, und dorthin sind wir gekommen, indem wir andere Plattformen abgesagt haben. Der Tausch ist bewusst: Ein Team, das jeden Tag dieselbe Plattform sieht, weiß, welches Problem eine native Lösung hat, welches eine App braucht und welches Custom Code - dadurch fließt weniger von deinem Budget in das Wiederfinden dieser Antwort. Und wir folgen Shopifys eigenen Konventionen, statt Muster aus Magento oder WooCommerce zu übertragen. Genau das hält einen Shop nach der Übergabe updatefähig.

### Welche Services bietet ihr an?

Strategie & Beratung, Custom Shopify Theme-Entwicklung, Custom App-Entwicklung, Shop-Migrationen, UX/UI Design, Integrationen & Middleware, laufendes Store Management und AI E-Commerce Readiness. Die meisten Projekte kombinieren drei oder vier davon: An einer Migration hängen meist eine ERP-Integration und ein Redesign, und ein Redesign legt meist ein Performance-Problem frei. Alles läuft über ein Team, dadurch werden eine Design-Entscheidung und ihre Konsequenz in der Entwicklung gemeinsam geklärt statt zwischen zwei Agenturen verhandelt.

### Könnt ihr meinen bestehenden Shopify Store redesignen?

Absolut, und es ist einer der häufigsten Einstiege zu uns. Wir auditieren zuerst den bestehenden Shop - Conversion-Pfad, Seiten-Performance und die Templates, die den größten Umsatz tragen - und gestalten dann gegen das, was das Audit gefunden hat, statt gegen ein Moodboard. Produkte, Kunden, Bestellungen und URL-Struktur bleiben, wo sie sind, damit Rankings und Shopdaten nicht in Gefahr geraten. Ein Redesign kann auch gestaffelt live gehen: erst die Seiten, die verkaufen, der Rest danach. So siehst du die Wirkung, bevor das ganze Budget gebunden ist.

### Baut ihr Custom Shopify Themes?

Ja, von Grund auf und nicht als umgefärbtes Marketplace-Template. Ein Custom Theme heißt: genau die Sections, die dein Merchandising-Team wirklich braucht, im Theme-Editor pflegbar ohne Entwickler, und kein geerbter Code für Funktionen, die du nie nutzen wirst. Der letzte Punkt ist das Performance-Argument: Themes von der Stange tragen die Summe aller Use Cases mit sich, für die sie verkauft wurden, und du bezahlst das bei jedem Seitenaufruf in den Core Web Vitals. Wir bauen gegen deinen Katalog und dein Content-Modell und übergeben Dokumentation, damit dein Team den Shop selbst betreiben kann.

### Könnt ihr meinen Shop von einer anderen Plattform migrieren?

Ja - WooCommerce, Magento, Shopware und andere Plattformen, in einem gestaffelten Prozess mit minimalem Risiko. Produkte, Varianten, Kunden und Bestellhistorie kommen mit, und jede indexierte URL bekommt einen gemappten 301, damit die Rankings, die du dir erarbeitet hast, den Umzug überleben. Über die Dauer entscheidet selten die Katalogröße: Es sind Datenstrukturen ohne direktes Shopify-Gegenstück (Bundles, konfigurierbare Produkte, kundenspezifische Preise) und die Systeme, mit denen dein Shop spricht. Beides inventarisieren wir, bevor ein Cutover-Datum steht. Deshalb enden unsere Migrationen nicht mit einer Redirect-Liste, die in der Nacht vor dem Launch entsteht.

### Wie lange dauert ein Shopify-Projekt?

Das hängt vom Umfang ab: Fokussierte Optimierungen dauern oft 4-6 Wochen, komplette Custom Builds oder Migrationen typischerweise 8-16 Wochen. Ein Shop auf konfigurierter Theme-Basis ist meist in 4-8 Wochen live, eine vollständig individuelle Storefront eher in 10-16\. Vor dem Start bekommst du eine Timeline mit definierten Meilensteinen, und diese Meilensteine sind gestaffelte Releases statt eines einzigen Launch-Termins am Ende - eine Verzögerung an einer Stelle schiebt also nicht alles Übrige nach hinten. Am stärksten bewegen späte Scope-Erweiterungen und Integrationen, die zu Beginn niemand inventarisiert hat.

### Wird mein Shopify Store für Mobile optimiert?

Immer. Wir designen Mobile-First, weil dort der Großteil des E-Commerce-Traffics liegt und der größte Teil der Conversion verloren geht. Jeder Shop wird auf echten Geräten getestet, nicht nur im verkleinerten Browserfenster, und vor dem Livegang gegen die Core Web Vitals gemessen - Largest Contentful Paint, Interaktionslatenz, Layout Shift. Die meiste Aufmerksamkeit bekommen Bildhandling, Font-Loading und Drittanbieter-Skripte, denn meist sind es Apps, die aus einem schnellen Theme einen langsamen Shop machen. Performance ist hier eine Launch-Bedingung und kein Ticket für danach.

### Bietet ihr laufenden Support nach dem Launch?

Ja. Unsere Store-Management-Pläne decken Shopify- und App-Updates, iterative Verbesserungen, Testing und technischen Support ab, in einem monatlichen Umfang, den du anpassen kannst, wenn sich Prioritäten verschieben. Die meisten Shops brauchen die ersten Wochen nach dem Launch stärker als erwartet: Echter Traffic findet Sonderfälle, die Staging nie erzeugt hat, und die Analytics fangen erst mit Volumen an, die Wahrheit zu sagen. Danach besteht die laufende Arbeit meist aus Conversion-Iterationen auf den umsatztragenden Templates, Support für saisonale Kampagnen und dem Aktuellhalten des Themes, wenn Shopify Plattformänderungen ausliefert.

### Könnt ihr meinen Shop verbessern, ohne alles neu zu bauen?

Auf jeden Fall, und wir sagen es dir auch, wenn ein Rebuild nicht die richtige Entscheidung ist. Wir arbeiten oft in fokussierten Iterationen - ein Conversion-Audit, Performance-Optimierung oder das Redesign der wenigen Templates, die den Großteil des Umsatzes tragen - ausgeliefert als gestaffelte Releases mit messbaren Ergebnissen statt als Big-Bang-Relaunch. Für einen Shop, der bereits konvertiert, ist das meist die bessere Rechnung: Du behältst, was funktioniert, investierst dort, wohin die Daten zeigen, und vermeidest das Risikofenster, das ein kompletter Replatform öffnet. Ein Rebuild lohnt sich, wenn das darunterliegende Theme oder Datenmodell die eigentliche Grenze ist.

### Wie starten wir?

Buche einen kostenlosen Strategie-Call - rund dreißig Minuten, und was dabei herauskommt, behältst du in jedem Fall. Wir fragen, was du heute betreibst: Plattform, Katalogstruktur, angebundene Systeme, und was nach dem Projekt besser sein soll. Daraus bekommst du ein schriftliches Angebot mit Umfang, Timeline und Preis, mit benannten Arbeitsblöcken statt einer einzigen Zahl. Wenn das Gespräch zeigt, dass du weniger brauchst als ein Agenturprojekt, sagen wir dir das auch. Das ist für beide Seiten das günstigere Gespräch, als es im zweiten Monat zu merken.

[Mehr Fragen lesen](https://shoplab.cc/faq)

Weitere Artikel

## Ähnliche Blogartikel

Entdecke weitere Insights, Ideen und praktische Ressourcen für deine E-Commerce-Reise und deinen nächsten Schritt.

[Alle Blogs ansehen](https://shoplab.cc/blog)

* [![Infografik zur Shopify Spring '26 Edition: 150+ Updates, B2B auf jedem Plan, Agentic Commerce, SimGym und Rollouts.](https://shoplab.cc/images/blog/shopify-spring-26-edition-updates.webp)Shopify NewsShopify Spring '26 Edition: Die Updates, die zählen](https://shoplab.cc/shopify-news/shopify-spring-26-edition-updates)
* [![Infografik: natives B2B auf jedem Shopify-Plan - Firmenprofile, Zahlungsziele, 3 Kataloge, 36 Bio. $ B2B-Markt.](https://shoplab.cc/images/blog/shopify-b2b-alle-plaene.webp)Shopify NewsShopify B2B jetzt auf allen Plänen verfügbar](https://shoplab.cc/shopify-news/shopify-b2b-alle-plaene)
* [![Illustrierte Winterlandschaft mit Shopify-Logo, „Winter ’26 Edition“ und schwebenden Storefront- und Produktkarten.](https://shoplab.cc/images/blog/shopify-winter-26-editions-the-renaissance-of-commerce.jpg)Shopify NewsShopify Winter ’26 Editions: The Renaissance of Commerce](https://shoplab.cc/shopify-news/shopify-winter-26-editions-the-renaissance-of-commerce)
* [![Key Visual der Shopify Unite: das Wort UNITE auf dunkelgrünem Code-Muster mit dem Claim „Coding commerce. Together.“](https://shoplab.cc/images/blog/shopify-unite-2022.jpg)Shopify NewsShopify Unite 2022: Zusammenfassung](https://shoplab.cc/shopify-news/shopify-unite-2022)
* [![Abstrakte dunkelgrüne Grafik aus gestrichelten Linien und leuchtenden Kapseln, Key Visual der Shopify Unite 2021.](https://shoplab.cc/images/blog/shopify-unite-2021.jpg)Shopify NewsShopify Unite 2021: der Start von Online Store 2.0](https://shoplab.cc/shopify-news/shopify-unite-2021)