Sind Page Builder im KI-Zeitalter tot?

Key Takeaways

• Drag-and-Drop Page Builder lösten ein Problem aus dem Jahr 2015 – Händler, die nicht programmieren können – mit einer 2015er-Architektur: Widget-Runtimes, per App gerenderte Seiten und JavaScript, das bei jedem Besuch mitgeliefert wird.
• KI hat die Einschränkungen verändert, nicht den Bedarf. Wenn einfaches Englisch nativen Theme-Code erzeugen kann, ist die Drag-and-Drop-Ebene nicht länger das Interface, sondern reiner Overhead.
• Shopify selbst drängt von unten nach. Die KI-Blockgenerierung von Horizon und das Theme-Editing von Sidekick decken jetzt Aufgaben ab, für die Händler früher einen Builder installiert haben.
• “Tot” ist immer noch übertrieben. Visuelle Kontrolle ist ein echtes Interface, das Vertrauen in Prompts ist nicht universell, und ausgereifte Builder-Ökosysteme lösen sich nicht in einem Jahr in Luft auf.
• Die ehrliche Antwort: Die Kategorie wird neu aufgebaut, nicht beerdigt – rund um Prompt-to-Native-Code-Generierung mit visuellem Feinschliff obendrauf.

Alle paar Monate erklärt jemand eine Software-Kategorie für tot, und die Kategorie ignoriert das meistens. Lass mich also bei der Behauptung, dass KI-Seitengenerierung Drag-and-Drop-Builder obsolet gemacht hat, präzise sein, denn die Hälfte davon ist wahr und die andere Hälfte ist Marketing.

Die wahre Hälfte: Die Architektur, auf der die meisten Drag-and-Drop-Page-Builder aufgebaut wurden – eine Widget-Runtime, die deine Seiten durch das JavaScript der App rendert – veraltet, und KI ist der Grund dafür. Die falsche Hälfte: Dass Händler keine visuelle Kontrolle mehr über ihre Storefronts haben wollen. Das wollen sie weiterhin.

Volle Transparenz vor dem ersten Argument: Wir entwickeln Fudge, den KI-Operator für Shopify-Stores mit einer 4.9-Sterne-Bewertung im Shopify App Store, und dessen Page Builder tritt in dieser Kategorie an. Du solltest alles Folgende mit dem Wissen lesen, dass wir an der Antwort ein eigenes Interesse haben. Wir haben versucht, dein Vertrauen zu gewinnen, indem wir die stärksten Argumente der Gegenseite fair darstellen.

Warum du uns vertrauen kannst

Wir haben über vier Jahre im Shopify-Ökosystem verbracht und jeden großen Drag-and-Drop-Builder für unsere veröffentlichte Vergleichsmatrix installiert, getestet und gebenchmarkt. Die Behauptungen hier darüber, wie sie funktionieren, stammen also aus dokumentierten Tests, nicht aus einem Bauchgefühl.

Wo eine Behauptung eine Meinung ist, wird sie als Meinung gekennzeichnet. Wo es ein Fakt ist, gibt es eine Fußnote.

Wofür Page Builder eigentlich da waren

Spulen wir zurück auf etwa 2015. Shopify-Themes waren starr, “Sections Everywhere” gab es noch nicht, und ein Händler, der eine individuelle Landingpage wollte, hatte zwei Optionen: einen Entwickler anheuern oder eben nicht.

Page Builder lösten das mit dem besten Interface, das es damals gab: einem visuellen Canvas mit ziehbaren Blöcken. PageFly, Shogun, GemPages, Replo und der Rest ließen einen Marketer eine Seite von Hand zusammenstellen, ganz ohne Code, und die Kategorie hat sich ihren Erfolg ehrlich verdient.

Aber das Interface kam im Paket mit einer Architektur. Um beliebige Block-Layouts über einem beliebigen Theme zu rendern, liefern die meisten Builder ihre eigene Runtime mit: Seiten werden durch das JavaScript der App zusammengebaut oder rehydriert, die gehostete Logik lebt auf der App-Ebene, und die Seite ist davon abhängig, dass die App installiert und bezahlt bleibt. Das war 2015 ein vernünftiger Kompromiss. Die Frage ist, ob es das immer noch ist, jetzt, wo Code selbst so billig ist.

Die Argumente für “Page Builder sind tot”

Hier ist die stärkste Version der pessimistischen Sicht (Bear Case). Teile davon sind unsere Meinung; die tragenden Fakten sind mit Quellen belegt.

1. KI produziert jetzt das, wofür Builder ein Workaround waren

Die gesamte Drag-and-Drop-Kategorie existiert, weil Händler keinen Theme-Code schreiben konnten. KI hat erste Entwürfe in nativem Code drastisch billiger und schneller gemacht – die Einschränkung ist schwächer geworden, nicht verschwunden, aber sie ist so weit abgeschwächt, dass sich der Workaround seinen Platz neu verdienen muss.

Im Jahr 2026 ist es nicht spekulativ, eine Seite in einfachem Englisch (oder Deutsch) zu beschreiben und funktionierendes, natives Liquid zurückzubekommen – so arbeiten General-Purpose Coding-Agents, so funktioniert unser Produkt, und das ist die Richtung, in die Shopifys eigenes Tooling geht. Wir haben das vollständige Argument in Das neue Shopify KI-Entwicklungsmodell dargelegt: Wenn natürliche Sprache zu nativem Code kompiliert, muss sich jeder Abstraction-Layer, der nur existierte, um Code zu vermeiden, neu rechtfertigen.

Ein Drag-and-Drop Canvas war nie das Ziel. Er war das beste verfügbare Interface für ein Ergebnis, das Händler nicht selbst produzieren konnten. Sobald ein Satz den Output liefert, ist der Canvas nicht mehr das einzige Interface, und die Runtime, die ihn antreibt, ist kein notwendiger Kostenfaktor mehr.

2. Shopify baut den Ersatz direkt in die Plattform ein

Das ist der Teil des Bear Cases, an dem konkrete Daten hängen.

In der Summer ‘25 Edition hat Shopify Horizon veröffentlicht, seine neue Theme-Basis, zusammen mit KI-Theme-Generierung („beschreibe deine Marke und generiere ein personalisiertes Theme“) und KI-Blockgenerierung – „Sag einfach, was du willst, und KI macht es wahr“, in Shopifys eigenen Worten.¹ Das ist Prompt-to-Theme-Block, First-Party, kostenlos.

Die Winter ‘26 Edition ging noch weiter: Sidekick bearbeitet Themes jetzt per Prompt und kann Custom Blocks in jedem Theme Store-Theme erstellen, nicht nur in Horizon.² Die einfachen Jobs, die für viele Builder-Installs gesorgt haben – eine neue Section hier, eine Styling-Änderung da – werden zu einer Chat-Nachricht im Admin-Bereich.

Unsere Einschätzung, als Meinung deklariert: Shopify wird die Page-Builder-Kategorie nicht selbst töten, weil First-Party-Tools historisch gesehen bei „gut genug“ aufhören und den Apps den Tiefgang überlassen. Wir haben darüber geschrieben, wo Sidekick an seine Grenzen stößt, im Stand der Shopify-KI 2026. Aber Shopify komprimiert unerbittlich das untere Ende des Marktes – und genau dort haben Widget-Builder die meisten ihrer Kunden gewonnen.

3. Die Architekturkosten summieren sich auf eine Weise, die sie 2015 nicht hatten

Der Trade-off bei der Widget-Runtime hat sich im Laufe der Zeit aus drei gut dokumentierten Gründen verschlechtert.

Die Seitengröße hat mittlerweile einen messbaren Preis. App-Layer-Builder rendern Seiten über ihr eigenes JavaScript, was jeden Page Load schwerer macht. Google hat bestätigt, dass die Core Web Vitals von seinen Ranking-Systemen genutzt werden – mit Zielwerten von LCP unter 2,5s, INP unter 200ms und CLS unter 0,1³. Das ist nur ein Faktor für Search und User Experience, mal ganz abgesehen davon, was langsame Seiten mit der Conversion Rate machen. So oder so: Eine Runtime, für die du bei jedem einzelnen Besuch für immer in Millisekunden bezahlst, ist etwas, das man 2015 noch akzeptiert hat, aber definitiv nicht mehr 2026.

Lock-in ist der Standard, nicht die Ausnahme. Bei PageFly, Replo, GemPages und Shogun sind die Seiten vom App-Layer abhängig: Wenn du die App deinstallierst, werden die Seiten entweder nicht mehr angezeigt oder sie frieren ein und lassen sich nicht mehr bearbeiten. Diesen Trade-off haben wir Tool für Tool in unserem Vergleich dokumentiert. Zehn Jahre an veröffentlichten Seiten, die an ein Abo gebunden sind, sind ein Risiko, das immer weiter wächst.

Das Limit beim Bearbeiten hat sich nie verschoben. Eine Block-Library ist wie eine Speisekarte. Wenn das Layout, das du willst, nicht auf der Karte steht, musst du doch wieder einen Entwickler anheuern – genau das Problem, das der Builder eigentlich lösen sollte. KI-Generierung hat keine Block-Library, weil sie Code schreibt; das Limit ist nur das, was dein Theme rendern kann.

Nimm diese drei Punkte zusammen und der Bear Case schreibt sich von selbst: Das Interface ist austauschbar, die Plattform übernimmt die einfachen Aufgaben, und die Architektur ist ein Asset, das stetig an Wert verliert. Das ist keine Kategorie, die ein entspanntes Jahrzehnt vor sich hat.

Die Gegenargumente: Warum “tot” zu kurz gedacht ist

Jetzt die andere Seite, ehrlich argumentiert – denn wenn du nur den Abschnitt oben liest, würdest du auch schlechte Entscheidungen treffen.

1. Visuelle Kontrolle ist ein Interface, keine Krücke

Schau einem Marketer beim Fine-Tuning einer Hero-Section zu – Abstände anpassen, den Bildausschnitt tauschen, drei Headline-Größen testen – und du siehst nicht jemanden, der eine Qualifikationslücke umgeht. Du siehst Direct Manipulation, was für manche Bearbeitungen wirklich das schnellste Interface ist, das die Menschheit je erfunden hat.

Ein Prompt ist ein wunderbarer Weg, um eine Seite zu erstellen. Es ist aber ein extrem ungeschickter Weg, um einen Button um vier Pixel zu verschieben. Jeder Bericht über die Zukunft der Kategorie, der damit endet, dass „alle für immer nur noch Sätze tippen“, überspringt das letzte Jahrzehnt der Interface-Forschung. Der Canvas hat sich seinen Platz für den Feinschliff verdient und behält diesen Platz auch.

2. Das Vertrauen in Prompts ist nicht universell, und die Skeptiker haben nicht unrecht

Viele Händler haben schon mal erlebt, wie ein KI-Tool mit voller Überzeugung etwas absolut Falsches produziert hat. Ihre Schlussfolgerung – „Ich will sehen und anfassen, was in meinem Store landet, bevor es live geht“ – ist rational, nicht rückständig.

Drag-and-Drop bietet eine Art von Sicherheit, die sich KI-Generierung erst noch verdienen muss: Der Output ist exakt das, was du geklickt hast. Die Varianz zwischen zwei Durchläufen desselben Prompts ist real, auch wenn sie schrumpft. Für einen Store-Betreiber, dessen Storefront sein gesamtes Business ist, ist „vorhersehbar und langsamer“ gegenüber „schnell und wahrscheinlichkeitsbasiert“ im Jahr 2026 eine absolut vertretbare Präferenz.

3. Ausgereifte Ökosysteme verschwinden nicht einfach

Allein PageFly hat eine Bewertung von 4.9 bei 5.917 Reviews im App Store (Stand Oktober 2026).⁴ Hinter solchen Zahlen stehen Template-Bibliotheken, Integrations-Ökosysteme, Agenturen mit tiefem Muscle-Memory und Tausende von Stores, deren Seiten heute einwandfrei funktionieren.

Kategorien mit einer so großen Nutzerbasis sterben nicht einfach an einer These. Sie bröckeln an den Rändern, während sich die Platzhirsche anpassen – und die Platzhirsche passen sich an, indem sie KI-Generierung an ihre Editoren anflanschen (GemPages’ Image-to-Layout, Shoguns KI-Sections, Replos KI-Generierung). Ob KI-oben-auf-einer-Widget-Runtime ausreicht, ist die offene Frage, aber es ist der Beweis, dass die Kategorie sich weiterentwickeln und nicht aussterben will.

Was sie wirklich ersetzt

Also: Nicht tot. Neu gebaut. So sieht unserer Meinung nach die neu gebaute Kategorie aus – und ja, das ist der Teil, wo unsere Produktthese und die These dieses Artikels ein und dasselbe sind. Werte das entsprechend.

Das Tool, das das nächste Jahrzehnt gewinnt, kombiniert drei Eigenschaften:

1. Prompt-to-Page als Erstellungsebene. Eine Seite zu beschreiben ist schneller als sie zusammenzubauen, Punkt. Erste Entwürfe sollten Sekunden dauern, und die Describe-Refine-Schleife sollte die 80 % der Änderungen übernehmen, die eher semantisch (“straffe den Hero, füge eine Testimonial-Zeile hinzu”) als räumlich sind.

2. Nativer Code als Ausgabeebene. Die Seite, die veröffentlicht wird, sollte Liquid, CSS und HTML in deinem Theme sein – kein Runtime-JavaScript, das sie im Browser zusammenbaut, keine Abhängigkeit, die bei der Deinstallation kaputtgeht, nichts zwischen deinem Kunden und der Seite. Hier geht die 2015er-Architektur in Rente, und das ist die Eigenschaft, die KI-Page-Builder von KI-Features in Widget-Buildern trennt.

3. Visueller Feinschliff obendrauf. Klick auf das Element, ändere die Sache, sieh dir das Ergebnis an – denn das Argument für direkte Manipulation ist absolut richtig. Der Canvas verschwindet nicht; er ist nicht mehr die Rendering-Architektur und wird zu dem, was er immer hätte sein sollen: eine Bearbeitungsoberfläche für Code, der dir gehört.

Diese Kombination behält das, was Drag-and-Drop richtig gemacht hat (visuelle Kontrolle, kein Code erforderlich), und lässt weg, was falsch war (die Runtime, der Lock-in, die Begrenzungen durch Block-Bibliotheken). Hier positioniert sich Fudge, hier konvergieren Shopifys eigene First-Party-Tools von unten, und hierhin werden sich unserer Wette nach auch die überlebenden Platzhirsche entwickeln – falls sie ihre Rendering-Architektur austauschen können, ohne ein Jahrzehnt an Kundenseiten kaputtzumachen. Das ist eine weitaus schwierigere Migration, als einfach ein Prompt-Feld hinzuzufügen.

Es gibt noch eine vierte Eigenschaft, die wir hinzufügen würden, und das ist die Richtung, in die sich die Kategorie unserer Meinung nach danach entwickelt: Dir zu sagen, wie die Seite performt hat. Die meisten Builder machen beim Veröffentlichen Schluss. Manche zeigen Analytics, aber die Entscheidung, was du ändern und welche Seite du als Nächstes bauen sollst, bleibt an dir hängen. Fudge berichtet dir die Visits, Conversion Rate und Käufe jeder Seite, schlägt anhand dieser Zahlen vor, was du ändern oder als Nächstes bauen sollst, und kümmert sich um SEO, Quizzes und Bundles im selben Tool. Meinung, klar gekennzeichnet: Das ist die Grenze zwischen einem Page Builder und einem Tool, das dir hilft, deinen Store wachsen zu lassen.

Ein alternativer Pfad verdient seinen eigenen Entscheidungsprozess: komplett auf Custom-Lösungen umzusteigen. Unser Guide zu headless Shopify mit Hydrogen behandelt, wann dieser Sprung gerechtfertigt ist und wann es reines Over-Engineering ist.

Worauf du achten solltest, egal für welche Seite du dich entscheidest

Du musst unsere These nicht abkaufen, um eine gute Wahl zu treffen. Egal, ob du bei einem AI-First-Tool oder einem ausgereiften Drag-and-Drop-Builder landest, dieselben fünf Fragen legen die Kompromisse offen:

• Was ist der veröffentlichte Output? Nativer Theme-Code oder Markup, das durch die Runtime der App gerendert wird? Diese eine Antwort sagt die meisten anderen voraus.
• Was passiert bei einer Deinstallation? Frag den Anbieter direkt und schriftlich. “Seiten funktionieren weiterhin” und “Seiten funktionieren weiterhin, solange unser Script-Tag in deinem Theme bleibt” sind zwei verschiedene Antworten.
• Was kostet es in Millisekunden? Lass Lighthouse auf einer Seite laufen, die mit dem Tool gebaut wurde, und vergleiche es mit deinem puren Theme. Core Web Vitals sind ein Faktor für Ranking und User-Experience unter mehreren,³ also ist das eine Umsatzfrage, keine Nerd-Frage.
• Wo liegt die Grenze bei der Bearbeitung? Für Tools mit Block-Bibliotheken: Was passiert, wenn der Block, den du brauchst, nicht existiert? Für KI-Tools: Was passiert, wenn der Prompt nicht richtig umgesetzt wird – gibt es einen visuellen Weg, das zu beheben, oder nur Re-Rolls?
• Macht Shopify das als First-Party bereits? Nach Horizon und Sidekick sind ein echter Teil der Builder-Use-Cases zu kostenlosen Plattform-Features geworden.¹² Prüfe das, bevor du für ein Abo bezahlst.

Bevor du irgendetwas installierst, kannst du sehen, was prompt-gesteuertes Design in deinem eigenen Store tatsächlich erzeugt: Unser kostenloses Shopify Website Redesign Tool baut drei Homepage-Entwürfe aus deinen echten Produkten und Inhalten, ganz ohne App.

Für bewertete Empfehlungen nach Use Case wendet unser Guide über die besten Shopify Page Builder genau diese Kriterien auf das gesamte Feld an, einschließlich Tools, die uns in bestimmten Bereichen schlagen.

Unser Fazit

Sind Page Builder tot? Nein – aber das, was sie zu einer eigenständigen Kategorie gemacht hat, stirbt.

Der Drag-and-Drop-Canvas als Interface überlebt und wird in das integriert, was auch immer als Nächstes kommt. Die Widget-Runtime als Architektur hingegen nicht, weil beide ihrer Rechtfertigungen auf einmal geschwächt wurden: KI hat nativen Code für Händler dramatisch billiger gemacht, und Shopifys eigene KI hat viele der simplen Aufgaben übernommen, die einst die Installation einer App rechtfertigten.

Meinung, klar gekennzeichnet: In ein paar Jahren wird “Page Builder” ein Tool bedeuten, das nativen Theme-Code generiert und bearbeitet, mit einer visuellen Oberfläche obendrauf – und die Produkte, die Storefronts immer noch durch ihr eigenes JavaScript rendern, werden sich so anfühlen, wie Flash-Seiten im Jahr 2012. Nicht weg. Aber veraltet.

Wir sind voreingenommen, weil wir genau für dieses Ergebnis gebaut haben. Aber wir zeigen dir lieber unsere Gedankengänge und Quellen und lassen dich die Rechnung prüfen, anstatt so zu tun, als wären wir neutral.

FAQ