Wichtigste Erkenntnisse
- Shogun rendert Seiten über seine App-Ebene. Nach der Deinstallation hält Shogun veröffentlichte Seiten als statisches HTML live, aber der Inhalt ist eingefroren – bearbeitest du ihn außerhalb von Shogun, kann das Styling kaputtgehen, und Shogun-Formulare funktionieren nicht mehr, sobald Daten gelöscht wurden.
- Die zwei Dinge, um die sich Teams am meisten Sorgen machen, sind Shoguns Page-Analytics und A/B-Testing. Plane Alternativen, bevor du wechselst, denn Shogun löscht Analytics- und Testdaten innerhalb von 14 Tagen nach der Deinstallation.
- Der Ablauf entspricht jeder Migration eines Shopify Page-Builders: Live-Seiten inventarisieren, jede URL an Fudge übergeben, auf einem Dev-Theme neu bauen, testen, unter derselben URL live schalten und dann deinstallieren. Keine neuen Slugs, keine Redirects.
- Fudge baut jede Seite als natives Liquid, CSS und HTML in deinem Theme neu auf. Das Ergebnis bleibt vollständig bearbeitbar, nachdem die App weg ist – kein eingefrorenes HTML.
- Migriere nicht zuerst deine Seite mit dem meisten Traffic. Führe den kompletten Zyklus erst bei einer weniger kritischen Seite durch, um ihn zu validieren.
Dieser Guide behandelt den Wechsel von Shogun zu Fudge AI auf Shopify. Shogun ist ein fähiger Drag-and-Drop-Builder mit echten Stärken bei Page-Level-Analytics und A/B-Testing. Die strukturellen Gründe, warum Teams wechseln, sind Datenhoheit (Seiten, die bearbeitbar bleiben statt einzufrieren) und Page-Speed (keine App-Rendering-Ebene, wenn Kunden die Seite laden).
Warum du uns vertrauen kannst
Vier Jahre direkt bei Shopify, Dutzende Page-Builder-Migrationen von Shogun, PageFly, Replo, GemPages, Instant und eigenen Buildern. Wir bauen Fudge – den KI-Agenten auf der anderen Seite dieser Migration. Er liest deine bestehende Seite aus und generiert sie als nativen Theme-Code neu.
Der Ablauf
Gleicher Ablauf wie bei jeder Page-Builder-Migration, mit ein paar Besonderheiten wegen Shogun.
Schritt 1: Inventarisiere jede Live-Seite von Shogun
Öffne das Shogun-Dashboard und liste alles auf, was momentan veröffentlicht ist. Notiere für jede Seite:
- URL und Seitentyp (Landingpage, Blog post, PDP-Section, Homepage-Section)
- Monatlicher Traffic und ob die Seite Ad-Spend (Werbebudget) erhält
- Aktive A/B-Tests – Welche Seiten haben laufende Experimente, die du zuerst abschließen musst?
- Letztes Bearbeitungsdatum – Seiten, die seit mehr als 6 Monaten nicht mehr angefasst wurden, sind eher Kandidaten für ein Archiv statt für eine Migration.
Zwei Shogun-spezifische Dinge, die du jetzt sichern solltest, weil Shogun sie innerhalb von 14 Tagen nach der Deinstallation löscht: dein Analytics-Verlauf (Click-through, Conversion, Bounce Rate) und sämtliche A/B-Test-Ergebnisse. Exportiere oder scrape das, was du behalten willst, bevor du die App löscht.
Schritt 2: Baue zuerst eine unwichtigere Seite um
Starte nicht gleich mit der Landingpage, die am besten konvertiert. Wähle eine Shogun-Seite mit mittlerem Traffic und wenig Risiko, und spiele den kompletten Prozess durch: Gib Fudge die URL, baue sie in einem Dev-Theme nach, stell sie online, beobachte die Daten.
So kriegst du ein Gefühl für die Abläufe, bevor es später um die wichtigeren Seiten geht.
Schritt 3: Nachbau in Fudge
Kopiere die URL der Live-Shogun-Seite in Fudge. Es liest die existierende Seite und generiert sie komplett als natives Liquid + CSS + HTML in einem noch unveröffentlichten Dev-Theme unter der identischen URL neu. Iteriere mit Prompts, bis alles passt.
Ein Tipp am Rand: Shogun-Seiten werden häufig aus dem CMS und diversen Drag-and-Drop-Blöcken zusammengeklickt, typischerweise ist die Struktur für unsere KI also extrem clean und leicht zu verstehen. Nutze den Umbau direkt als Möglichkeit, alles zu entfernen, was du damals nur reingenommen hast, weil der Editor es hergegeben hat – zu große Hero-Stacks, redundante Sections oder Deko-Blöcke, die de facto keinen Wert haben.
Schritt 4: Testen
Lighthouse Mobile. Add-to-Cart bis zum Checkout, falls relevant. Pixel-Events (Meta, GA4, TikTok). Simulation von langsamem 4G.
Stelle sicher, dass die Seite in der Dev-Theme-Vorschau identisch gerendert wird, bevor du sie veröffentlichst. Da sich die Live-URL nach der Veröffentlichung nicht ändert, muss in anderen Systemen (Ad-Creatives, internen Links, Sitemaps) nichts aktualisiert werden.
Schritt 5: Live veröffentlichen und Daten checken
Veröffentliche das Dev-Theme. Die URL bleibt die gleiche. Dein eigener Theme-Code bedient jetzt den Slug anstelle des Shogun-App-Layers. Es braucht keine 301-Redirects, keine neu konfigurierten Analytics-Einträge und keine Anpassung der Ad-Creatives.
Beobachte Traffic und Conversion Rate für 24 bis 48 Stunden. Wenn dir etwas komisch vorkommt, geh der Sache noch mal auf den Grund, bevor du im großen Stil an die weiteren Seiten rangehst.
Schritt 6: Repeat für den Backlog
Geh nach Priorität vor. Versuch gar nicht erst, in einem Sprint alles zu erzwingen. Schließe alle laufenden A/B-Tests ab, bevor du diese Seiten migrierst – wähle den Gewinner, migriere die Gewinnervariante und stampfe das Experiment ein.
Schritt 7: Shogun deinstallieren
Erst dann, wenn wirklich alle Seiten stehen, du die Analytics und Historien deiner Tests, die du künftig noch brauchst, weggespeichert hast, über 14 Tage Live-Daten bestätigen, dass es keine Einbrüche gegeben hat, und das Theme wirklich clean von alten Shogun-Sections und Snippet-Leichen ist.
Was du verlierst – und wie du es ersetzt
Der Fairness halber: Das, was Teams bei Shogun hält, ist oft nicht der Page Builder selbst. Es ist der Data-Layer. Vor allem zwei bestimmte Features.
Page-Level-Analytics
Shogun misst Click-through, Conversion und Bounce Rate direkt für jede Page innerhalb der App. Ohne Hilfe von Drittanbietern. Sehr bequem.
Als Alternative kommt GA4 in Kombination mit deinem Theme ins Spiel. Bei Seiten, die nur aus deinem Theme-Code bestehen, greifen GA4 oder Tools wie Microsoft Clarity oder Hotjar wie bei jedem anderen Template. Die All-in-One-Lösung des Shogun-Dashboards ist weg; der Zugriff auf den Content deiner Zahlen bleibt. Für Teams, die ohnehin schon mit GA4 arbeiten, ändert sich im Prinzip gar nichts.
A/B-Testing
Das ist der dickere Brocken, bei dem Genauigkeit zählt. Seit Ende 2025 hat Shogun das A/B-Testing in eine separate Standalone-App verlagert, und das im Page-Builder integrierte Testing ist für neue Shogun-Setups so ohnehin nicht mehr da.1 Je nachdem, wie alt dein Account also ist, hängt dein A/B-Testing ohnehin nicht (mehr) unmittelbar im Page Builder mit drin.
Fudge selber hat kein eingebautes A/B-Testing. Weil mit Fudge generierte Seiten als Theme-Sections gelten, kannst du aber ganz klassisch mit allen Shopify-nativen Testing-Tools und entsprechenden Apps mit A/B-Experimenten angreifen. Sieh dir unseren A/B-Testing-Guide an, um die besten Optionen zu entdecken. Wenn Live-Testing absolut entscheidend für deinen Flow ist, plane den Übergang bewusst, bevor du migrierst.
Content-Scheduling
Shogun kann geplante Pages zu bestimmten Daten bereitstellen. Wenn du für geplante Product-Drops regelmäßig Vorlaufzeiten brauchst, planst du diese mit klassischen Theme-Launch-Routinen oder einer Scheduling-App. Ein Feature, was am Ende eh nur hin und wieder und kaum täglich gebraucht wird.
Ein Hinweis zur Deinstallation (weil Shogun das anders löst)
Es lohnt sich, hier genau zu sein, da viele Ratschläge zur Migration das falsch darstellen.
Im Gegensatz zu Buildern, deren Seiten bei der Deinstallation komplett leer werden, hält Shogun deine veröffentlichten Seiten als statisches HTML live, nachdem du die App entfernt hast. Die Seiten verschwinden nicht.
Aber “live” ist nicht das Gleiche wie “deins”:
- Das HTML ist eingefroren. Die Shogun-Docs weisen darauf hin, dass die Bearbeitung dieser Seiten außerhalb von Shogun das Styling zerstören kann. Dann müsstest du sie über Shogun neu veröffentlichen – was du aber gerade deinstalliert hast.
- Shogun-Formulare funktionieren nicht mehr, sobald deine Daten (innerhalb von 14 Tagen) gelöscht werden, da die App keine Einsendungen mehr speichern kann.
- Code-Reste bleiben in deinem Theme. Shogun empfiehlt, die Section- und Snippet-Dateien an Ort und Stelle zu belassen, damit die eingefrorenen Seiten weiterhin gerendert werden.
Der realistische Zustand einer nicht migrierten Shogun-Seite nach der Deinstallation ist also: sichtbar, aber nicht bearbeitbar, mit funktionslosen Formularen und verwaistem App-Code in deinem Theme. Deshalb migrierst du jede Seite zuerst zu nativem Code und deinstallierst danach – so ist jede Live-Seite wirklich bearbeitbar und sauber.
Für eine umfassendere Bereinigung, schau dir unseren Guide zum Entfernen von App-Code-Resten aus Shopify an.
Warum sich diese Migration lohnt
Für die meisten Stores gibt es zwei entscheidende Vorteile:
- Page Speed. Ohne den Rendering-Layer von Shogun bleibt deinem Kunden das Laden von App-JavaScript auf der Seite erspart. Auf Mobile hilft das in der Regel dem LCP – siehe dazu unsere Page-Builder-Speed-Methodik. Schnellere Seiten sorgen direkt für eine bessere Conversion Rate.
- Output-Ownership. Aus deinen Seiten werden vollwertige Theme-Sections – versionierbar, veränderbar für jeden Developer, unabhängig gegenüber Updates und niemals eingefroren. Also das genaue Gegenteil von statischem HTML, das du nicht mit ruhigem Gewissen anfassen kannst.
Für den gesamten Vergleich zu Alternativen in der Kategorie, lies dir die Analyse zu Fudge AI vs Shogun oder das Ranking der besten Shopify Page Builder durch. Falls das Feld noch neu für dich ist, kannst du dir unter Shopify Page-Builder und Shopify Store-Editor ein Bild des Tools und seiner echten Anwendungsbereiche fernab der Migration machen.
FAQ
Nicht sofort. Im Gegensatz zu manchen Buildern hält Shogun veröffentlichte Seiten als statisches HTML nach der Deinstallation live. Aber das HTML ist eingefroren – bearbeitest du es außerhalb von Shogun, kann das Styling verloren gehen, Shogun-Formulare funktionieren nicht mehr, sobald Daten innerhalb von 14 Tagen gelöscht werden, und Code-Reste verbleiben in deinem Theme. Wenn du jede Seite zuerst zu nativem Code migrierst, vermeidest du all das.
Ja, wenn du sie nicht vorher exportierst. Shopify verlangt von Shogun, gespeicherte Daten – einschließlich Page-Analytics und A/B-Test-Ergebnisse – innerhalb von 14 Tagen nach der Deinstallation zu löschen. Mache Screenshots oder exportiere alles, was du behalten möchtest, bevor du die App entfernst.
Nein. Fudge hat kein eingebautes A/B-Testing. Da Fudge-Seiten Standard-Theme-Sections sind, kannst du sie mit Shopify-nativen Testing-Tools oder einer speziellen App testen. Beachte, dass Shogun sein eigenes A/B-Testing Ende 2025 in eine separate, eigenständige App ausgelagert hat. Neuere Installationen führen Tests also ohnehin außerhalb des Page-Builders durch.
Nein. Fudge baut die Seite auf einem Dev-Theme neu und veröffentlicht sie unter derselben URL. Es gibt keine neuen Slugs und keine 301-Redirects, sodass Ad-Creatives, interne Links und Sitemaps unverändert weiterfunktionieren.
Du fügst die Live-URL der Shogun-Seite in Fudge ein. Der AI-Agent liest die bestehende Seite und generiert sie als natives Liquid, CSS und HTML auf einem unveröffentlichten Dev-Theme neu. Du verfeinerst sie mit Prompts, bis sie passt, und schaltest sie dann unter derselben URL live.
Ja. Shogun konzentriert sich auf Page-Building mit einem Data-Layer. Fudge ist ein AI-Agent, der auch bestehende Seiten bearbeitet, Quizzes, Bundles und Kampagnenseiten baut und durchgehend nativen Theme-Code schreibt. Wenn du mehr als einen Page-Builder willst, ist der Anwendungsbereich deutlich größer.
Footnotes
-
Shogun hat das A/B-Testing Ende 2025 in eine eigenständige Shopify-App verschoben; das integrierte Testing steht für neue Installs des Page-Builders nicht mehr zur Verfügung. Quelle: Shogun App Store Listings und Support-Dokumentation, 2026. ↩
