Der Baukasten war die richtige Entscheidung
Vorab, damit wir uns richtig verstehen: Wenn du deine SaaS-Website mit Webflow oder WordPress gestartet hast, hast du nichts falsch gemacht. Ein Baukasten bringt dich in zwei Wochen live, kostet einen zweistelligen Betrag im Monat und braucht keinen Entwickler. In der Seed-Phase zählt genau das: Geschwindigkeit vor Architektur. Ich empfehle Gründern diesen Weg regelmäßig selbst.
Aber jedes Werkzeug hat ein Einsatzgebiet. Was mit fünf Seiten und einem Blog gut funktioniert hat, wird ab einer gewissen Größe zur Bremse: für dein Marketing, deine Rankings und dein Team. Ich zeige dir fünf Signale, an denen ich erkenne, dass eine SaaS-Website ihrem Werkzeug entwachsen ist — und genauso ehrlich, wann du besser bleibst, wo du bist.
Falls du zuerst das große Bild willst: In der Anatomie einer B2B-SaaS-Website beschreibe ich, welche Seitentypen ein SaaS überhaupt braucht. Dieser Artikel hier setzt später an: bei der Frage, wann das Fundament darunter nicht mehr trägt.
Fünf Signale, dass dein SaaS dem Werkzeug entwachsen ist
Die fünf Signale stammen aus Migrationsanfragen, die bei uns landen. Sie treten selten einzeln auf: Wer zwei davon bei sich erkennt, sieht die übrigen meist schon am Horizont. Geh sie der Reihe nach durch und zähl mit.
Signal 1: Dein Content-Modell passt nicht mehr in Collections
Webflow organisiert Inhalte in CMS Collections, und deren Grenzen stehen schwarz auf weiß in der Preisliste: je nach Tarif 2.000, 10.000 oder 20.000 Items und 20, 40 oder 100 Collections. Selbst in den größten Tarifen erlaubt Webflow pro Collection höchstens 100 Felder, davon maximal 20 Referenzfelder (Stand: September 2026).
Für ein SaaS ist das schneller eng, als es klingt. Features, Integrationen, Use Cases, Branchen und Vergleichsseiten verweisen kreuzweise aufeinander: genau dafür brauchst du Referenzfelder. Sobald du programmatische Seiten wie «Integration mit X» oder «Lösung für Branche Y» in Serie ausrollen willst, stößt du an diese Decke.
WordPress hat das umgekehrte Problem: kaum harte Limits, aber auch kein Content-Modell. Custom Post Types und strukturierte Felder kommen erst über Plugins wie ACF ins System. Dein Modell lebt dann in Plugin-Konfigurationen, die bei jedem Major-Update zur Zitterpartie werden. Ob Headless-WordPress ein Ausweg ist, habe ich im Vergleich WordPress: Headless oder Baukasten beantwortet.
Signal 2: Mehrsprachigkeit wird teuer oder bleibt liegen
Sobald dein SaaS neben DACH einen englischsprachigen Markt bedient, brauchst du mindestens zwei Sprachversionen mit sauberen hreflang-Angaben. Genau hier trennen sich Baukasten und Code-Stack am deutlichsten.
Webflow löst Mehrsprachigkeit über das kostenpflichtige Localize-Add-on: ab 9 US-Dollar pro Monat und Locale, höchstens drei zusätzliche Sprachen im Basispaket, bis zu zehn im Advanced-Paket ab 29 US-Dollar pro Locale. Die eingebaute KI-Übersetzung ist zudem gedeckelt: 10.000 Wörter pro Sprache und Monat, im Advanced-Paket 50.000 (Stand: September 2026).
WordPress sagt es in der eigenen Dokumentation erfreulich ehrlich: «WordPress currently does not support a bilingual or multilingual blog out-of-the-box.» Du brauchst Plugins wie WPML oder Polylang — und die verweben sich tief in Datenbank und Theme.
In einem Code-Stack ist Mehrsprachigkeit dagegen ein Routing-Thema plus ein Sprachfeld im CMS: Sanity hält Sprachvarianten als eigene Dokumente, Next.js routet /de/ und /en/. Unsere eigene Website läuft genau so: zweisprachig, ohne Aufpreis pro Sprache.
Signal 3: Docs, Changelog und Blog leben in drei Systemen
Eine SaaS-Website besteht nicht nur aus Marketing-Seiten. Dokumentation, Changelog und Blog gehören dazu, und ein Baukasten deckt davon genau einen Teil ab. Das typische Bild bei Anfragen: Marketing-Seiten in Webflow, Docs bei GitBook oder ReadMe, der Changelog in einem dritten Tool.
Drei Systeme heißen drei Logins, drei Designs und drei Subdomains. SEO-seitig ist das der teuerste Teil: Deine Docs sammeln Autorität auf docs.deinprodukt.de, statt sie unter /docs auf deine Hauptdomain einzuzahlen. Für Suchanfragen wie «X einrichten» rankt dann das Template der Docs-Plattform statt deiner Website.
Der Merksatz dazu: ein Produkt, eine Domain, ein Content-System. Ein strukturiertes CMS wie Sanity hält Marketing-Seiten, Docs und Changelog als unterschiedliche Dokumenttypen im selben Backend, mit einem Design und einer Suche darüber.
Signal 4: Dein Team wächst, deine Workflows nicht
Mit drei Leuten im Marketing brauchst du plötzlich, was Entwickler seit Jahren haben: Entwürfe, Freigaben, Vorschau, Versionierung. Bei Webflow gibt es Page Branching erst ab der Team-Stufe für 2.500 US-Dollar im Monat, granulare Rollenrechte erst im Enterprise-Tarif. Darunter teilt sich dein Team eine gemeinsame Arbeitsfläche, auf der ein versehentlicher Publish die ganze Site treffen kann.
WordPress kann Redaktions-Workflows nur über weitere Plugins, Staging hängt am Hoster. Im Code-Stack bekommst du all das ab Werk: Jede Änderung erzeugt bei Vercel ein eigenes Preview-Deployment mit teilbarer URL, Freigaben laufen als Review, und Git protokolliert jede Zeile. Sanity ergänzt Entwurfs- und Publish-Zustände pro Dokument.
Signal 5: Lighthouse stagniert, egal was du optimierst
Das fünfte Signal misst du in Zahlen: Wenn deine Lighthouse-Werte trotz Optimierungs-Plugins nicht mehr steigen, kämpfst du gegen das Werkzeug statt an der Website. In unseren Audits sehe ich gewachsene WordPress-Sites regelmäßig bei mobilen Performance-Werten zwischen 40 und 60 — das ist Projekterfahrung, keine Statistik.
Die Ursache ist strukturell. WordPress schleppt mit jedem Plugin zusätzliches CSS und JavaScript in jede Seite, Page-Builder erzeugen tief verschachteltes Markup. Webflow liefert deutlich saubereren Code, lässt dich aber weder Code-Splitting noch das Nachladen von Skripten im Detail steuern.
Next.js dreht das Verhältnis um: Seiten werden statisch vorgerendert, Bilder automatisch verkleinert, JavaScript nur dort geladen, wo es gebraucht wird. Gute Core-Web-Vitals-Werte sind dann der Normalzustand, nicht das Ergebnis einer Plugin-Sammlung.
Was die Migration kostet und wie lange sie dauert
Vorab zur Einordnung: Die folgenden Spannen sind unsere Projekterfahrung bei happycoding aus Migrationen auf Next.js und Sanity, keine Marktstudie. Dein Fall kann darüber oder darunter liegen, vor allem bei Sonderfällen wie Produkt-Integrationen oder großen Docs-Beständen.
| Umfang | Typischer Fall | Dauer | Budget |
|---|---|---|---|
| Kompakt | 10–20 Seiten, Blog, eine Sprache | 4–6 Wochen | 12.000–20.000 € |
| Standard | 30–60 Seiten, Blog und Docs, zwei Sprachen | 8–12 Wochen | 20.000–40.000 € |
| Groß | über 100 Seiten, programmatische Templates, Integrationen | 3–4 Monate | ab 40.000 € |
In den Spannen steckt mehr als Design und Entwicklung: Content-Modellierung, Datenübernahme, Redirect-Konzept und Tracking-Umzug gehören dazu. Die Datenübernahme unterschätzen viele: Webflow exportiert dynamische Inhalte nicht mit dem Code, Collections bekommst du nur einzeln als CSV heraus. Ab ein paar hundert Items schreiben wir deshalb Import-Skripte gegen die Sanity-API.
Eine detaillierte Aufschlüsselung nach Projektgrößen findest du im Artikel Was kostet eine SaaS-Website?. Als Faustregel für Mehrsprachigkeit: Rechne mit 30 bis 50 Prozent Aufschlag auf den Grundumfang.
SEO-sicher migrieren: deine Rankings sind das Kapital
Die größte Angst vor jeder Migration ist berechtigt: der Verlust organischer Rankings. Dazu ein Fall aus unserer Praxis: Ein Interessent kam zu uns, nachdem beim vorherigen Relaunch die URL-Struktur ohne Redirect-Konzept geändert worden war. Rund 30 Prozent des organischen Traffics waren binnen weniger Wochen weg, die Erholung zog sich über Monate.
Dabei ist die Absicherung kein Hexenwerk, Google beschreibt sie in der eigenen Dokumentation zu Site-Moves: permanente 301-Redirects verwenden, Weiterleitungsketten auf höchstens drei Sprünge begrenzen und die Redirects mindestens ein Jahr stehen lassen. Ranking-Schwankungen während der Umstellung sind laut Google normal; bei mittelgroßen Sites dauert die Neuindexierung einige Wochen.
Unsere Reihenfolge in Migrationsprojekten:
- URLs erhalten: Die beste Weiterleitung ist die, die du nicht brauchst. Wo die alte Struktur tragfähig ist, übernehmen wir sie eins zu eins.
- Redirect-Map vor dem Go-live: Jede alte URL bekommt ein Ziel, auf Basis eines vollständigen Crawls plus der Search-Console-Daten.
- Messung ab Tag eins: Sitemap einreichen, Search Console und 404-Monitoring beobachten, bei mehrsprachigen Sites die hreflang-Angaben prüfen.
Eine Migration verliert Rankings nicht durch den Stack-Wechsel, sondern durch fehlende Redirects.
Wie wir Relaunches technisch absichern, beschreibe ich auf unserer Seite zum Website-Relaunch. Der Stack-Wechsel selbst zahlt sogar ein: Bessere Ladezeiten und saubere interne Verlinkung sind zwei der Hebel, die nach der Migration greifen.
Wann du nicht migrieren solltest
Radikale Ehrlichkeit gehört dazu: Eine Migration ist ein Projekt mit fünfstelligem Budget, und in manchen Situationen rate ich aktiv ab. Vier davon begegnen mir immer wieder:
- Deine Website hat unter 15 Seiten und wächst kaum: Dann spielt der Baukasten seine Stärken aus, und die Limits aus diesem Artikel treffen dich schlicht nicht.
- Dein Problem ist die Botschaft, nicht die Technik: Wenn Positionierung und Texte nicht sitzen, ändert der beste Stack nichts an deiner Conversion.
- Niemand betreut die Inhalte: Das schönste Content-Modell bleibt leer, wenn im Team niemand schreibt. Erst die Redaktion klären, dann das Werkzeug.
- Das Budget liegt unter 12.000 Euro: Dann holst du im bestehenden System meist mehr pro Euro heraus als mit einer halben Migration.
Stehst du dagegen noch ganz am Anfang und wählst gerade dein erstes Werkzeug, hilft dir mein Vergleich Webflow, Framer oder Squarespace weiter. Für alle anderen gilt: Migriere wegen konkreter Grenzen, die du benennen kannst — nicht wegen eines Bauchgefühls.
Nächste Schritte
Zähl die fünf Signale ehrlich durch: Triffst du zwei oder mehr, lohnt sich der Blick auf eine Migration. Der erste Schritt kostet dich nur eine Stunde: Zieh ein Content-Inventar, exportiere deine URLs aus der Search Console und notiere die drei Stellen, an denen dich dein heutiges System am meisten bremst. Mit dieser Liste wird aus dem Bauchgefühl eine Entscheidungsgrundlage.
Als Agentur für B2B-Websites begleiten wir genau diesen Weg: Content-Modellierung, Datenübernahme, Redirect-Konzept und Go-live, auf demselben Next.js-und-Sanity-Stack, auf dem auch unsere eigene Website läuft. Wenn du wissen willst, ob sich der Wechsel für dein SaaS rechnet, dann buch dir ein unverbindliches Erstgespräch: Wir schauen gemeinsam auf deine Website, zählen die Signale und du bekommst eine ehrliche Einschätzung — auch wenn sie «bleib im Baukasten» lautet.
