Webflow ablösen: Designen ist nicht Strukturieren

Webflow sieht beeindruckend aus. Auf den ersten Blick. Designer lieben es, Agenturen verkaufen es als «No-Code-Revolution», und die Ergebnisse können sich visuell durchaus sehen lassen. Aber unter der glänzenden Oberfläche verbirgt sich ein fundamentales Problem: Webflow verwechselt Designen mit Strukturieren.

Jede Seite ist ein visuelles Unikat. Inhalte kleben am Layout, Blöcke werden per Copy-Paste dupliziert, und ein Content-Modell? Fehlanzeige. Das funktioniert für eine Landing Page. Für eine Website, die wachsen und gepflegt werden soll, wird es zum Problem — und zwar schneller als die meisten denken.

Designen ist nicht gleich Strukturieren

Das Kernversprechen von Webflow lautet: Du designst im Browser, und der Code entsteht automatisch. Klingt gut. Aber dieses Versprechen hat einen Haken, den viele erst bemerken, wenn die Website wächst.

In Webflow baust du Layouts — keine Inhalte. Jede Seite ist eine individuelle Komposition aus Divs, Flexboxen und absolut positionierten Elementen. Es gibt kein echtes Content-Modell, das Inhalt von Darstellung trennt. Deine Texte, Bilder und Daten sind direkt ins Layout eingewoben.

Was heisst das in der Praxis? Stell dir vor, du hast 40 Leistungsseiten mit ähnlicher Struktur. In einem strukturierten CMS wie Sanity definierst du einmal den Block «Leistungsseite» — mit Titel, Beschreibung, USPs, Bild, CTA — und jede Seite befüllt dieses Schema. Konsistent, wartbar, wiederverwendbar.

In Webflow? Du baust die erste Seite, kopierst sie 39 Mal und passt jede manuell an. Ändert sich das Design — zum Beispiel ein neuer CTA-Button-Stil — musst du alle 40 Seiten einzeln anfassen. Oder du hoffst, dass die globalen Styles greifen. Spoiler: Bei komplexeren Layouts tun sie das oft nicht.

Der CMS-Modus: Zu wenig, zu spät

Webflow hat einen eingebauten CMS-Modus mit «Collections». Das stimmt. Aber dieser CMS-Modus hat enge Grenzen:

• Maximal 10’000 CMS-Items pro Projekt (und deutlich weniger im günstigsten CMS-Plan)
• Maximal 20 Referenzfelder pro Collection
• Keine verschachtelten Strukturen — du kannst keinen Block in einem Block bauen
• Keine echte Rich-Text-Flexibilität: Kein Portable Text, keine eingebetteten Komponenten
• Keine API für externe Systeme (nur über Umwege mit Zapier oder Make)

Für einen Blog mit 50 Beiträgen mag das reichen. Für eine Website mit verschiedenen Seitentypen, wiederverwendbaren Inhaltsblöcken und der Anforderung, Inhalte auch anderswo auszuspielen, reicht es nicht.

Laut einer Analyse von Webflow-Projekten (Quelle: Finsweet, 2024) nutzen über 60% der Webflow-Seiten den CMS-Modus gar nicht — weil die Einschränkungen zu gross sind. Die Mehrheit pflegt Inhalte direkt im visuellen Editor. Ohne Struktur, ohne Modell, ohne Wiederverwendbarkeit.

Vendor Lock-in: Deine Website gehört nicht dir

Hier wird es unangenehm: In Webflow gehört deine Website der Plattform. Du hostest bei Webflow, du zahlst monatlich, und wenn du gehst... nimmst du erstmal nichts mit.

Ja, Webflow bietet einen Code-Export. Aber dieser Export ist ein statisches HTML/CSS/JS-Bundle ohne CMS-Inhalte, ohne Interaktivität, ohne die Webflow-eigenen Features. Du kannst damit wenig anfangen — ausser von vorne beginnen.

Das Hosting-Modell skaliert zudem schlecht. Ein Businessplan kostet ab 39 USD/Monat, Enterprise ab 499 USD/Monat. Dazu kommen CMS-Items-Limits, Bandbreiten-Limits und Feature-Beschränkungen pro Stufe. Bei wachsenden Anforderungen steigen die Kosten schnell.

Zum Vergleich: Eine SvelteKit-Website mit Sanity.io oder Payload CMS hostest du auf Vercel oder Netlify — oft kostenlos im Startpaket, und du behältst die volle Kontrolle über Code, Inhalte und Infrastruktur.

Die Designer-Abhängigkeit

Ein Aspekt, den Webflow-Kunden oft unterschätzen: Deine Website ist nur so wartbar wie die Person, die sie gebaut hat. Und in Webflow gibt es keinen erzwungenen Standard.

Jeder Designer strukturiert anders. Klassenbenennungen, Verschachtelungen, Komponentenlogik — alles individuell. Wenn der ursprüngliche Designer nicht mehr verfügbar ist, steht der nächste vor einem Puzzle. Ohne Dokumentation (und mal ehrlich — wer dokumentiert sein Webflow-Projekt?) dauert das Einarbeiten Wochen.

In einem Headless-Setup mit SvelteKit und einem typisierten CMS ist die Struktur im Code und im Schema festgelegt. Neue Entwickler verstehen die Architektur in Stunden, nicht Wochen. Und das Schema im CMS dokumentiert sich praktisch selbst.

Typische Bedenken — und ehrliche Antworten

«Aber Webflow ist so schnell aufgesetzt.» Stimmt — für den Anfang. Aber die Geschwindigkeit am Start erkaufst du dir mit Langsamkeit bei jeder Änderung danach. Time-to-Launch ist nur eine Kennzahl. Time-to-Change ist die wichtigere.

«Unsere Designer können Webflow, aber kein Code.» Das ist ein valides Argument. Aber: In einem Headless-Setup designen deine Designer in Figma (was sie vermutlich sowieso tun), und Entwickler setzen es in SvelteKit um. Klare Arbeitsteilung, klare Verantwortung.

«Webflow hat doch auch CMS-Funktionen.» Hat es — mit den oben genannten Einschränkungen. Für einfache Projekte kann das reichen. Aber frag dich: Baust du eine Website für heute oder für die nächsten drei bis fünf Jahre?

«Der Export geht doch.» Technisch ja. Praktisch nein. Was du exportierst, ist ein Snapshot ohne CMS, ohne Interaktivität, ohne die Möglichkeit, darauf weiterzubauen. Es ist wie ein Foto deines Hauses — schön anzuschauen, aber du kannst nicht darin wohnen.

Das Wesentliche auf einen Blick

• Webflow baut Layouts, keine strukturierten Inhalte — jede Seite ist ein visuelles Unikat ohne echtes Content-Modell
• Der eingebaute CMS-Modus hat enge Limits bei Items, Referenzen und Verschachtelung
• Vendor Lock-in: Inhalte und Hosting gehören der Plattform, der Code-Export ist praktisch unbrauchbar
• Designer-Abhängigkeit: Ohne den Original-Designer ist die Website schwer wartbar
• Headless CMS wie Sanity oder Payload trennen Inhalt von Darstellung — strukturiert, wiederverwendbar, exportierbar
• SvelteKit als Frontend gibt dir volle Kontrolle über Code, Hosting und Performance