Das Wichtigste in Kürze
- Die Migration folgt einem Standardablauf: Seiten inventarisieren, jede URL mit Fudge teilen, in einem Dev-Theme neu aufbauen, testen, live schalten (unter derselben URL), und dann GemPages deinstallieren. Keine neuen Slugs, keine Redirects.
- Der strukturelle Grund, warum Teams wechseln, sind Kontrolle über den Output und Page Speed. GemPages-Seiten werden über die Runtime der App gerendert. Fudge schreibt nativen Theme-Code.
- Migriere nicht während einer wichtigen Sales-Phase. Wähle ein ruhiges Zeitfenster von zwei bis vier Wochen ohne größere Kampagnen.
- Plane 1-2 Stunden pro Seite für den Neuaufbau plus QA ein. Es geht schneller, sobald der Brand-Kontext in Fudge geladen ist.
Dieser Guide behandelt den Wechsel von GemPages zu Fudge AI in einem Live-Shopify-Store. Das Ziel: Jede Seite wird Teil deines Themes, ohne App-Runtime beim Laden der Seite durch den Kunden.
GemPages ist ein fähiger Drag-and-Drop-Builder. Teams wechseln eher aus strukturellen Gründen (Seiten bleiben nach der Deinstallation erhalten, kein Runtime-JavaScript), und nicht, weil GemPages schlecht funktioniert hat.
Warum du uns vertrauen kannst
Vier Jahre tief im Shopify-Ökosystem, dutzende erfolgreiche Migrationen von GemPages, PageFly, Replo, Shogun und eigenen Buildern. Wir entwickeln Fudge – den AI-Agenten auf der Zielgeraden dieser Migration. Schau dir auch GemPages vs. Fudge an für einen umfassenderen strategischen Vergleich.
Der Ablauf
- Inventur. Liste jede aktuell live geschaltete GemPages-Seite samt URL, Zweck, Traffic und aktivem Ad-Spend-Status auf. Gruppiere sie nach Priorität.
- Wähle eine Startseite. Nimm eine Seite mittlerer Prioritätsstufe (keine High-Traffic Ad-LP) für den ersten Migrationsdurchlauf.
- Rebuild in Fudge. Kopiere die Live-URL von GemPages in Fudge. Die KI liest die Seite aus und stellt sie als nativen Theme-Code in einem noch nicht veröffentlichten Dev-Theme auf derselben URL nach. Iteriere anschließend das Design mit Prompts: “kürzerer Hero”, “mit UGC austauschen”, “Sticky ATC hinzufügen”.
- Testen auf einem Developement-Theme. Lighthouse Mobile (Ziel LCP < 2,5s, INP < 200ms, CLS < 0,1). Spiele Add-To-Cart komplett bis hin zum Checkout durch. Nutze die Slow-4G-Simulation.
- Live schalten. Die URL ändert sich bei alldem nicht – dein Theme-Code liefert jetzt einfach den Slug aus, anstatt den Umweg über die GemPages-Runtime zu nehmen. Fudge übernimmt den Slug automatisch; du musst ihn in GemPages vorher gar nicht erst depublizieren und es bedarf keiner 301-Redirects.
- Für 24-48 Stunden genau beobachten. Stelle sicher, dass die Conversion Rate in den Analytics und Reportings der Ad-Plattformen stabil bleibt.
- In Reihenfolge der Priorität wiederholen. 2-5 Seiten pro Woche sind ein gesundes Tempo.
- GemPages deinstallieren. Und zwar erst, wenn jede Seite migriert ist und deine
theme.liquidkomplett frei von GemPages-Skript- und CSS-Importen ist.
Die zwei kritischen Punkte bei der Migration
Sections, die sich nicht 1:1 übertragen lassen
Wenn deine GemPages-Seite eine Block-Art verwendet, für die es kein direktes Gegenstück in Fudge gibt (z. B. eine “GP Form” in GemPages mit benutzerdefinierter Logik), hast du drei Optionen:
- Baue den Block in Fudge mit einer etwas simpleren Variante nach
- Setze ihn zusammen mit einem Entwickler als Custom Theme Section neu um (Fudge kann das Grundgerüst dafür vorbauen)
- Nutze das native Formular von Shopify / eine Form-Builder-App ganz unabhängig vom Page-Builder
Die meisten alten GemPages-Blöcke haben passendere Fudge-Gegenstücke, als es zunächst den Anschein macht.
Tracking und Pixel-Events
Stelle sicher, dass dein Tracking (GA4, Meta Pixel, Klaviyo Active on Site) auf den neuen Fudge-Seiten weiterhin gefeuert wird. Die meisten Stores haben seitenübergreifende Pixel in der theme.liquid, sodass diese automatisch übernommen werden – es lohnt sich jedoch, dies auf der ersten migrierten Seite zu überprüfen, bevor du den Rest umstellst.
Was macht Fudge vs. GemPages anders?
- Output. Fudge schreibt direkt Liquid + CSS + HTML in dein Theme. GemPages hingegen rendert die Seite bei jedem Besuch deiner Kunden über seine eigene Runtime.
- Bleibt auch nach Deinstallation bestehen. Fudge-Seiten bleiben da, auch wenn die App einmal weg ist. GemPages-Seiten fallen normalerweise auf eine Standardseite von Shopify oder einen 404-Fehler zurück.
- Page Speed. Fudge fügt kein Runtime-JavaScript hinzu. Von GemPages gerenderte Seiten werden zwanghaft zusammen mit der App-Runtime geladen.
- Workflow. Fudge ist promptgesteuert; GemPages läuft via Drag-and-Drop. Das erfordert eine gewisse Umstellung deiner Gewohnheiten.
Weitere Hintergründe findest du unter Die besten Shopify Page Builder, AI vs. Drag-and-Drop und Die besten AI Page Builder für Shopify.
Für Migrationen aus anderen Tools: PageFly zu Fudge, Replo zu Fudge und Instant zu Fudge. Wenn du als Agentur Tools für verschiedene Kunden gegenüberstellst, lies hier weiter: Der beste Shopify Page Builder für Agenturen.
FAQ
Nein – die Seite bleibt unter derselben URL. Du tauschst nur den Renderer aus (GemPages-Runtime → dein Theme-Code), nicht die URL. Solange der Inhalt im Wesentlichen gleich bleibt, musst du dir keine Sorgen um Ranking-Einbußen machen.
Ja, während der Migration. Nachdem jede Seite umgezogen ist, deinstallierst du GemPages, um den Page Speed wieder zu verbessern.
Für einen Katalog mit 10-20 Seiten solltest du 3-6 Wochen bei 2-5 Seiten pro Woche einplanen. Größere Kataloge skalieren linear. Der Flaschenhals ist die QA-Kapazität, nicht die Build-Geschwindigkeit.
Ja, sonst zerschießt du die noch nicht migrierten Seiten. Migriere oder archiviere jede aktive GemPages-Seite bewusst, bevor du die App deinstallierst. Migrierte Seiten sind davon nicht betroffen – sie bestehen ja bereits aus Theme-Code unter derselben URL.
Drei Optionen: Einfacher neu bauen, als Custom Theme Section erstellen (Fudge kann das Grundgerüst liefern) oder GemPages für diese einzelne Seite behalten, während du alles andere migrierst. Die meisten Blöcke haben bessere Fudge-Entsprechungen, als es anfangs scheint.
