Sind Page Builder im KI-Zeitalter tot?

Key Takeaways

• Drag-and-Drop Page Builder lösten ein Problem von 2015 – Händler, die nicht programmieren können – mit einer Architektur von 2015: Widget-Runtimes, App-gerenderte Seiten und JavaScript, das bei jedem Besuch geladen wird.
• KI hat die Einschränkung verändert, nicht den Bedarf. Wenn normales Englisch nativen Theme-Code erzeugen kann, ist der Drag-and-Drop-Layer nicht mehr das Interface, sondern wird zum 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 verschwinden nicht einfach in einem Jahr.
• Die ehrliche Antwort: Die Kategorie wird neu aufgebaut, nicht begraben – rund um die Generierung von Prompt-to-Native-Code mit visuellem Feinschliff on top.

Alle paar Monate erklärt jemand eine Software-Kategorie für tot, und die Kategorie ignoriert das meistens einfach. Lass mich also präzise sein bei der Behauptung, dass KI-Seitengenerierung Drag-and-Drop Builder obsolet gemacht hat, 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 über das JavaScript der App rendert – veraltet, und KI ist der Grund dafür. Die falsche Hälfte: Dass Händler aufhören werden, visuelle Kontrolle über ihre Storefronts haben zu wollen. Werden sie nicht.

Volle Transparenz vor jedem einzelnen Argument: Wir bauen Fudge, einen KI Page Builder für Shopify, und wir konkurrieren in dieser Kategorie. Du solltest alles Folgende mit dem Wissen lesen, dass wir ein eigenes Interesse an der Antwort haben. Wir haben versucht, uns dein Vertrauen zu verdienen, indem wir die Argumente der anderen Seite fair und stark präsentieren (Steel-Manning).

Warum du uns vertrauen kannst

Wir bauen Fudge, einen KI-Shopify Page Builder mit einer Bewertung von 4.9 im Shopify App Store, was bedeutet, dass wir direkt mit den Tools konkurrieren, um die es in diesem Artikel geht – und genau deshalb zeigen wir beide Seiten, anstatt uns selbst zu feiern. Wir haben auch 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, basieren also auf dokumentierten Tests, nicht auf bloßen Gefühlen (Vibes).

Wo eine Behauptung Meinung ist, wird sie als Meinung formuliert. 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 es sein lassen.

Page Builder lösten das mit dem damals besten verfügbaren Interface: einem visuellen Canvas mit ziehbaren Blöcken. PageFly, Shogun, GemPages, Replo und der Rest ließen einen Marketer eine Seite von Hand zusammensetzen, 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 jedem beliebigen Theme zu rendern, bringen die meisten Builder ihre eigene Runtime mit: Seiten werden durch das JavaScript der App zusammengesetzt oder hydratisiert, gehostete Logik lebt im App-Layer, und die Seite ist davon abhängig, dass die App installiert und bezahlt bleibt. Das war 2015 ein vernünftiger Deal. Die Frage ist, ob das immer noch ein guter Deal ist, wenn Code an sich billig geworden 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 Widget-Runtime-Trade-off wurde mit der Zeit schlechter, aus drei dokumentierten Gründen.

Page Weight hat jetzt einen messbaren Preis. App-Layer-Builder rendern Seiten über ihr eigenes JavaScript, was jedem Seitenaufruf zusätzliches Gewicht verleiht. Google hat bestätigt, dass Core Web Vitals von seinen Ranking-Systemen verwendet werden, mit Zielen von LCP unter 2,5s, INP unter 200ms und CLS unter 0,1³ – ein Such- und User-Experience-Aspekt unter mehreren, neben den Auswirkungen von langsamen Seiten auf die Conversion. So oder so: Eine Runtime, für die du bei jedem Besuch für immer in Millisekunden bezahlst, ist eine sehr 2015-mäßige Sache, die man 2026 nur noch schwer akzeptieren kann.

Lock-in ist der Standard, nicht die Ausnahme. Bei PageFly, Replo, GemPages und Shogun werden die Seiten über den App-Layer gerendert und nicht mehr angezeigt, wenn du sie deinstallierst – ein Deal, den wir Tool für Tool in unserem Vergleich dokumentiert haben. Zehn Jahre lang veröffentlichte Seiten, die an ein Abo gebunden sind, sind eine Verbindlichkeit (Liability), die immer weiter wächst.

Das Limit beim Bearbeiten hat sich nie verschoben. Eine Block-Library ist wie eine Speisekarte. Wenn das gewünschte Layout nicht auf der Karte steht, musst du wieder einen Entwickler anheuern – genau das Problem, für das der Builder ursprünglich installiert wurde, um es zu lösen. KI-Generierung hat keine Block-Library, weil sie Code schreibt; das Limit ist alles, was dein Theme rendern kann.

Nimm diese drei zusammen und der Bear Case schreibt sich von selbst: Das Interface ist austauschbar, die Plattform übernimmt die leichten Jobs, und die Architektur ist ein Asset, das an Wert verliert. Das ist keine Kategorie mit einem komfortablen Jahrzehnt vor sich.

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

PageFly allein hat eine 4,9-Sterne-Bewertung bei tausenden von Reviews im App Store.⁴ Hinter solchen Zahlen stecken Template-Libraries, Integrations-Ökosysteme, Agenturen mit tiefem Muscle Memory und tausende von Stores, deren Seiten heute einwandfrei funktionieren.

Kategorien mit einer so großen Installed Base sterben nicht wegen einer These. Sie erodieren an den Rändern, während die Platzhirsche sich anpassen – und die Platzhirsche passen sich an und flanschen KI-Generierung an ihre Editoren an (GemPages’ Image-to-Layout, Shoguns KI-Sections, Replos KI-Generierung). Ob KI-on-top-of-a-Widget-Runtime reicht, ist die offene Frage, aber es ist der Beweis dafür, dass die Kategorie die Absicht hat, sich weiterzuentwickeln, anstatt komplett zu verfallen.

Was sie wirklich ersetzt

Also: nicht tot. Neu aufgebaut. Hier ist die Form, die die neu aufgebaute Kategorie unserer Meinung nach annehmen wird – und ja, das ist der Teil, wo unsere Produkt-These und die These dieses Artikels identisch sind. Urteile selbst entsprechend.

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

1. Prompt-to-Page als Creation-Layer. Eine Seite zu beschreiben ist schneller als eine zusammenzubauen, Punkt. Erste Entwürfe sollten Sekunden dauern, und der Describe-Refine-Loop sollte die 80 % der Bearbeitungen übernehmen, die semantisch sind („mach den Hero kompakter, füg eine Testimonial-Zeile hinzu“) anstatt räumlich.

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

3. Visueller Feinschliff on top. Klick auf das Element, ändere das Ding, sieh das Ergebnis – denn das Argument für Direct Manipulation stimmt. Der Canvas verschwindet nicht; er hört nur auf, die Rendering-Architektur zu sein, und wird das, was er immer hätte sein sollen: eine Bearbeitungsoberfläche über dem Code, der dir gehört.

Diese Kombination behält, was Drag-and-Drop richtig gemacht hat (visuelle Kontrolle, kein Code erforderlich), und verwirft, was falsch war (die Runtime, den Lock-in, das Limit der Block-Library). Genau da positioniert sich Fudge, genau da konvergiert das First-Party-Tooling von Shopify von unten, und wir würden wetten, dass auch die überlebenden Platzhirsche dort landen werden – wenn sie ihre Rendering-Architektur austauschen können, ohne ein Jahrzehnt an Kundenseiten zu zerstören, was eine viel härtere Migration ist, als eine Prompt-Box hinzuzufügen.

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

Bevor du etwas installierst, kannst du dir ansehen, was Prompt-Driven Design in deinem eigenen Shop tatsächlich bewirkt: Unser kostenloses Shopify Website Redesign Tool erstellt drei Homepage-Entwürfe aus deinen echten Produkten und Inhalten, ganz ohne App.

Du musst unsere These nicht teilen, um eine gute Wahl zu treffen. Egal, ob du dich für ein AI-first-Tool oder einen ausgereiften Drag-and-Drop-Builder entscheidest, die gleichen fünf Fragen decken die Kompromisse auf:

• Was ist der veröffentlichte Output? Nativer Theme-Code oder Markup, das über die Runtime der App gerendert wird? Diese eine Antwort lässt auf die meisten anderen schließen.
• Was passiert bei der Deinstallation? Frag den Anbieter direkt, schriftlich. „Seiten funktionieren weiterhin“ und „Seiten funktionieren weiterhin, solange unser Script-Tag in deinem Theme bleibt“ sind zwei völlig unterschiedliche Antworten.
• Was kostet es in Millisekunden? Führe Lighthouse auf einer Seite aus, die mit dem Tool erstellt wurde, und vergleiche sie mit deinem unveränderten Theme. Core Web Vitals sind ein Ranking- und User-Experience-Faktor unter mehreren,³ also ist das eine Umsatzfrage und keine Nerd-Frage.
• Wo liegt das Limit bei der Bearbeitung? Für Tools mit Block-Bibliothek: Was passiert, wenn der benötigte Block nicht existiert? Für KI-Tools: Was passiert, wenn der Prompt nicht das gewünschte Ergebnis liefert – gibt es eine visuelle Möglichkeit, das zu beheben, oder gibt es nur Re-Rolls?
• Kann natives Shopify das bereits? Nach Horizon und Sidekick ist ein großer Teil der Builder Use Cases zu kostenlosen Plattform-Features geworden.¹² Prüfe das, bevor du ein Abo dafür abschließt.

Für gerankte Empfehlungen nach Use Case wendet unser Guide für die besten Shopify Page Builder genau diesen Bewertungsmaßstab auf den gesamten Markt an – einschließlich der Tools, die uns in bestimmten Bereichen übertreffen.

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, absorbiert in das, was als Nächstes kommt. Die Widget-Runtime als Architektur tut das nicht, weil beide ihrer Rechtfertigungen gleichzeitig schwächer wurden: KI hat nativen Code für Händler dramatisch billiger gemacht, und Shopifys eigene KI hat viele der einfachen Jobs absorbiert, die früher die Installation einer App gerechtfertigt haben.

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

Wir sind voreingenommen (biased), weil wir genau für dieses Ergebnis gebaut haben. Aber wir zeigen dir lieber unsere Argumentation und unsere Quellen und lassen dich selbst nachrechnen, anstatt so zu tun, als wären wir neutral.

FAQ