Wichtigste Erkenntnisse
- Shogun rendert Seiten über seinen App-Layer. Nach der Deinstallation bleiben die veröffentlichten Seiten bei Shogun als statisches HTML live, aber der Inhalt ist eingefroren – wenn du die Seite außerhalb von Shogun bearbeitest, kann das Styling kaputtgehen, und Shogun-Formulare funktionieren nicht mehr, sobald die Daten gelöscht wurden.
- Die zwei Dinge, um die sich Teams beim Wechsel am meisten sorgen, sind Shoguns Page-Analytics und das A/B-Testing. Plane frühzeitig Alternativen, da Shogun alle Analytics- und Testdaten innerhalb von 14 Tagen nach der Deinstallation löscht.
- Der Ablauf ist identisch mit jeder anderen Shopify Page-Builder-Migration: Inventarisiere die Live-Seiten, füttere Fudge mit der URL, baue sie in einem Dev-Theme nach, teste sie, veröffentliche sie live unter derselben URL und deinstalliere dann die App. Keine neuen Slugs, keine Redirects.
- Fudge baut jede Seite als natives Liquid, CSS und HTML in deinem Theme nach. Das Ergebnis bleibt auch ohne die App vollständig bearbeitbar – kein eingefrorenes HTML.
- Migriere nicht gleich deine Seite mit dem meisten Traffic. Mach den kompletten Prozess zuerst an einer unwichtigeren Seite, um ihn zu testen.
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 der Output-Ownership (die Seiten bleiben bearbeitbar statt eingefroren zu werden) und Page Speed (kein App-Rendering-Layer, der beim Besucher erst noch geladen werden muss).
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)
Dieses Thema betrachten wir deshalb genauer, weil es von diversen Guides immer wieder falsch beschrieben wird.
Anders als bei Apps, die nach einer Deinstallation einfach nur leere Seiten hinterlassen, belässt Shogun die Pages im System und behält die Seiten nach Entfernen der App als statisches HTML online. Die Seiten verschwinden nicht wirklich.
Das Wort “live” ist da aber nicht gleichbedeutend mit “deins”:
- Das HTML ist eingefroren. Die Shogun-Doku weist extra darauf hin, dass man beim Editieren dieser Pages von außerhalb riskieren kann, die Styles einzureißen, was den Re-Publish über Shogun erfordert (das du ja gerade deinstalliert hast).
- Shogun-Formulare gehen kaputt, sobald deine Daten nach der Frist von bis zu 14 Tagen verschwinden, und die App nichts mehr protokollieren kann.
- Übrig gebliebener Code verweilt im Theme. Shogun selbst empfiehlt, restliche Snippets oder alte Sections zu belassen, damit die Render-Outputs weiter angezeigt werden können.
Realistisch bedeutet eine deinstallierte Page ohne Migration bei Shogun also immer: Sie ist da, aber nicht bearbeitbar, mit kaputten Formularen und verwaisten Resten auf Systemebene. Genau darum baut man erst dann um und deinstalliert am Schluss - so machst du sicher, dass alles nutzbar, live und clean ist.
Du brauchst Hilfe bei Cleanups nach all dem Chaos? Wir haben dafür einen Guide:Wie man alte Shopify-App-Codes entfernt.
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 lässt Shogun veröffentlichte Seiten nach der Deinstallation als statisches HTML live. Aber das HTML ist eingefroren – die Bearbeitung außerhalb von Shogun kann das Styling zerstören, Shogun-Formulare funktionieren nicht mehr, sobald die Daten innerhalb von 14 Tagen gelöscht werden, und Code-Reste bleiben in deinem Theme. Wenn du jede Seite zuerst in nativen Code migrierst, vermeidest du all das.
Ja, wenn du sie nicht vorher exportierst. Shopify verlangt von Shogun, gespeicherte Daten – einschließlich der Page-Analytics und A/B-Test-Ergebnisse – innerhalb von 14 Tagen nach Deinstallation aus dem Speicher zu löschen. Mach Screenshots oder exportiere alles, was du behalten möchtest, bevor du die App löschst.
Nein. Fudge enthält kein integriertes A/B-Testing. Da Fudge-Seiten Standard-Theme-Sections sind, kannst du sie mit Shopify-nativen Testing-Tools oder einer eigenen App testen. Beachte, dass Shogun Ende 2025 sein eigenes A/B-Testing in eine separate Standalone-App ausgelagert hat. Neuere Installationen testen also ohnehin schon außerhalb des Page-Builders.
Nein. Fudge baut die Seite in einem Dev-Theme nach 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 weiter funktionieren.
Du fügst die URL der Live-Shogun-Seite in Fudge ein. Der KI-Agent liest die bestehende Seite und erstellt sie als natives Liquid, CSS und HTML auf einem unveröffentlichten Dev-Theme neu. Du iterierst mit Prompts, bis sie exakt passt, und veröffentlichst sie dann unter derselben URL live.
Ja. Der Fokus von Shogun liegt auf Page-Building mit einer eigenen Datenschicht. Fudge ist ein KI-Agent, der auch bestehende Seiten bearbeitet, Quizzes, Bundles und Kampagnenseiten erstellt und durchgängig nativen Theme-Code schreibt. Wenn du mehr als nur einen Page-Builder willst, ist der Spielraum hier 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. ↩
