Website von Webflow zu Custom migrieren

Wie man eine Website von Webflow zu einer Custom-Entwicklung migriert

Ein in Webflow erstellter Auftritt kann fertig wirken und trotzdem noch erstaunlich viel Technik unter der Oberfläche verbergen. Die visuelle Ebene ist meist der einfache Teil; schwierig wird alles, was an Webflows Muster, Standardwerte und Abkürzungen gebunden ist. Wenn du planst, eine Website von Webflow auf eine Custom-Entwicklung zu migrieren oder eine Webflow zu Custom Website migrieren willst, ist der erste Schritt nicht das Programmieren. Es ist die Analyse.

Beginne mit den Dingen, die oft vergessen werden zu dokumentieren. Klassennamen, Interaktionsauslöser, CMS-Struktur, Formularlogik, Einbettungen und jedes Element, das nur funktioniert, weil Webflow es richtig interpretieren kann. Eine Website kann 40 Seiten und nur 6 echte Templates haben – oder 6 Seiten und 40 kleine Sonderfälle. Dieser Unterschied ist entscheidend.

Betrachte den Aufbau so, als müsstest du ihn jemandem erklären, der das Designer-Panel nie gesehen hat. Das heißt: prüfen, was global ist, was nur auf einer Seite gilt und was versehentlich entstanden ist. Ein kleiner Einschub: „versehentlich“ bedeutet oft „jemand hat es in der Oberfläche schnell gefixt und nie dokumentiert“.

1. Den Webflow-Aufbau auf versteckte Einschränkungen prüfen

Webflow-Seiten verstecken Einschränkungen oft hinter aufgeräumten Oberflächen. Ein Klassensystem kann nach außen konsistent wirken und sich in Wahrheit auf einmalige Überschreibungen, verschachtelte Kombinationsklassen oder doppelte Stilentscheidungen stützen, die nur ein einzelnes Seitenproblem lösen sollten. Bei der Migration werden solche Details zu echten technischen Entscheidungen – nicht zu visuellen Nebensächlichkeiten.

Untersuche zuerst die CMS-Collections. Zähle die Collection-Typen, notiere die Referenzfelder und dokumentiere, welche Seiten davon abhängen. Wenn ein Blog-Index, eine Autorenseite und eine Case-Study-Seite alle aus derselben Collection gespeist werden, ist das nicht nur Content-Organisation. Das ist Datenkopplung. Wer das unsauber auflöst, erhält zwar eine optisch richtige, aber funktional falsche Website.

Prüfe anschließend die Interaktionen. Webflow-Interaktionen basieren oft auf Page Load, Scroll-Position, Hover-Zuständen und zeitgesteuerten Abläufen. Manche davon lassen sich direkt in Code nachbauen. Andere sollte man nicht kopieren. Eine 0,5-Sekunden-Verzögerung, die in Webflow gut wirkte, kann in einem Custom-Build merkwürdig erscheinen – besonders auf Mobilgeräten mit anderer Darstellung. Teste sie auch bei langsamer Verbindung.

Ignoriere Formulare nicht. Webflow-Formulare können Routing-Regeln, versteckte Felder, Spamfilter, Datei-Uploads und Übergaben an Drittanbieter enthalten, die man leicht übersieht, bis der erste Lead verschwindet. Ein Formular, das in Webflow „einfach funktioniert“ hat, kann von Plattformverhalten abhängen, auf das du dich nie bewusst verlassen wolltest. Genau so entstehen Launch-Wochenenden mit Problemen.

2. Designentscheidungen von der Webflow-Implementierung trennen

Gute Migrationsarbeit beginnt mit einer klaren Frage: Was an diesem Design ist eine Markenentscheidung, und was ist bloß Webflow-Komfort? Die Antwort ist selten offensichtlich. Ein gestapeltes Kartenlayout kann die Markenstimme widerspiegeln – oder nur deshalb existieren, weil der Designer ein Collection-List-Item wiederverwenden wollte. Das ist nicht dasselbe.

Trenne Design und Implementierung Zeile für Zeile. Typografie-Skala, Abstands-Rhythmus, Button-Hierarchie, Bildausschnitte und Bewegungsstil sind meist die eigentlichen Designentscheidungen. Dagegen verraten feste Wrapper-Breiten, ungeschickte Verschachtelungen und wiederholte Div-Blöcke oft eher die Grenzen der Plattform als die Absicht der Marke. Bewahre die Absicht. Verliere den Zufall.

Hier werden Teams oft sentimental. Sie wollen „das Gefühl“ der Website erhalten – verständlich, aber Gefühl ist keine technische Spezifikation. Übersetze das Gefühl in Regeln: 24px Abschnittsabstand, ein primärer Call-to-Action pro Seite, 3 Ebenen der Hierarchie oder ein bestimmtes Bildseitenverhältnis. Mit Regeln kann das Code-Team arbeiten. Mit Nostalgie nicht.

Als nützlichen Vergleichspunkt kannst du lesen, wie man Website-Monitoring verbindet, wenn deine Migration auch die Suchperformance oder das Traffic-Tracking beeinflusst. Ein Neuaufbau verändert oft sowohl den Code als auch die Signale, die du beobachtest – und beides sollte nicht getrennt betrachtet werden.

3. Das aktuelle Content-Modell auf eine Custom-Datenstruktur abbilden

Webflow-Inhalte beginnen oft als Seiten und Collections, aber Custom Development braucht ein saubereres Modell. Bevor irgendein Code geschrieben wird, ordne jeden Seitentyp einem Datentyp zu. Eine Service-Seite kann zu einem strukturierten Datensatz werden mit Feldern für Überschrift, Kurzbeschreibung, Leistungsübersicht, FAQ-Einträge und SEO-Metadaten. Eine Case Study braucht vielleicht ein eigenes Modell mit Kundename, Herausforderung, Ergebnis, Galerie und verwandten Leistungen. Genau hier lässt sich die Webflow CMS in eigene Datenstruktur übertragen besonders sauber planen.

Mach diese Zuordnung zuerst auf Papier oder in einer Tabelle. Liste jede Webflow-Collection, jedes Referenzfeld, jedes verschachtelte Element und jede wiederverwendbare Komponente auf. Entscheide dann, ob die neue Website einen Typ, zwei Typen oder fünf Typen braucht. Du kopierst nicht die Webflow-Struktur. Du übersetzt sie.

Beobachte Seiten, die einzigartig wirken, aber eigentlich Varianten derselben Struktur sind. Wenn drei Landingpages dieselbe Hero-Sektion, denselben Testimonial-Block und denselben CTA teilen, ist das wahrscheinlich ein Template mit drei Datensätzen. Sie als getrennte Seiten zu behandeln, erzeugt später nur zusätzlichen Pflegeaufwand. Das CMS soll Arbeit reduzieren, nicht vervielfachen.

Wiederverwendbare Komponenten brauchen besondere Sorgfalt. In Webflow kann eine Komponente wie ein einzelner Block wirken, während der eigentliche Inhalt gesperrt, gespiegelt oder manuell überschrieben sein kann. In einem Custom-Build musst du entscheiden, was wirklich wiederverwendbar ist und was editierbar bleiben muss. Ein Content-Editor sollte nicht raten müssen, ob sich eine Überschrift auf Seite 1 auch auf Seite 9 auswirkt.

4. Abhängigkeiten von Drittanbietern und Embeds identifizieren

Webflow-Seiten sammeln oft unbemerkt externe Tools an. Analytics-Tags, Heatmaps, Chat-Widgets, Buchungssysteme, Zahlungstools, Consent-Banner, Social Embeds und Tracking-Skripte können jahrelang im Projekt bleiben. Manche sind in der UI sichtbar. Andere leben in Custom-Code-Snippets und erinnern sich kaum noch daran, warum sie hinzugefügt wurden.

Erstelle eine Abhängigkeitsliste mit vier Spalten: Toolname, Funktion, Einsatzort und ob es bleiben muss. Die letzte Spalte ist wichtig. Ein Tool kann nützlich, aber nicht notwendig sein. Wenn ein Chat-Widget nur einmal pro Quartal einen Lead bringt, ist die Migration ein guter Zeitpunkt, um zu fragen, ob es überhaupt auf die neue Website gehört. Verschwendung versteckt sich gern hinter „falls doch mal“.

Eingebettete Medien verdienen eine eigene Prüfung. Videoplayer, Karten, Formulare, PDFs und Inhalte von externen Plattformen können sich anders verhalten, sobald die Seite nicht mehr innerhalb von Webflows Rahmen gehostet wird. Ein Embed kann in Staging problemlos laden und in Production wegen einer Domain-Whitelist oder der Skript-Reihenfolge fehlschlagen. Das kann bei einer Migration passieren. Es ist technisch, weil es technisch ist.

Für Fragen zu Vertrauen und Angriffsfläche solltest du Website-Sicherheit während der Prüfung der Abhängigkeiten mit berücksichtigen. Eine Migration ist ein praktischer Moment, um alte Skripte zu entfernen, Zugriffe zu reduzieren und alles zu ersetzen, was keinen klaren Owner mehr hat.

5. Formulare, Interaktionen und dynamisches Verhalten neu aufbauen

Bei Migrationen werden Formulare oft zum entscheidenden Punkt. Ein Kontaktformular braucht vielleicht Validierungsregeln, bedingte Felder, Datei-Handling, Routing nach Abteilung und eine Fallback-Meldung, falls das Absenden fehlschlägt. In Webflow lassen sich mehrere dieser Aufgaben hinter der Oberfläche verbergen. In der Custom-Entwicklung brauchen sie klare Entscheidungen und Tests.

Schreibe die Regeln, bevor du den Code schreibst. Wenn jemand „Partnerschaft“ auswählt, zeigt das Formular dann ein Feld für das Budget? Wenn eine Person ein Portfolio hochlädt, gilt ein Limit von 10 MB? Wenn eine Einsendung fehlschlägt, was passiert dann? Die Antworten sollten vor der Entwicklungsarbeit feststehen. Sonst erfindet der Entwickler sie für dich – und das ist meist schlechter.

Bewegung und Interaktion brauchen dieselbe Behandlung. Ein Hover-Effekt kann dekorativ sein oder die Hierarchie erklären. Ein Scroll-Reveal kann angenehm sein oder Inhalte für Nutzer verbergen, die sich schnell durch die Seite bewegen. Teste die Interaktion mit Tastatur, Maus, Touch und auf kleinen Bildschirmen. Eine Animation, die auf dem Desktop elegant wirkt, kann bei 375px Breite nerven.

Kopiere Webflow-Interaktionslogik nicht aus Gewohnheit. Baue das Verhalten neu, nicht den Mechanismus. Wenn das Ziel lautet „nach 2 Sekunden Aufmerksamkeit auf den Preisblock lenken“, kann die Umsetzung einfacher sein als im Original. Die Custom-Website soll denselben Nutzerbedarf erfüllen – nicht die exakte Abfolge der Klicks hinter den Kulissen bewahren. Genau deshalb ist es sinnvoll, die Webflow Website in Custom Development umziehen nicht als bloße 1:1-Kopie zu verstehen.

6. Die Übergabe zwischen alten Webflow-URLs und der neuen Website planen

Die URL-Planung sollte vor der Launch-Woche beginnen. Alte Webflow-URLs, neue URL-Muster, interne Links und Redirect-Maps müssen zusammenpassen. Wenn ein Nutzer /about/team als Lesezeichen gespeichert hat und der neue Auftritt den Inhalt nach /company/team verschiebt, muss die Weiterleitung am ersten Tag bereit sein. Kaputte Pfade erzeugen schnell Supportaufwand.

Erstelle eine Zuordnungstabelle von Seite zu Seite. Setze die aktuelle URL in eine Spalte, die neue URL in eine andere und eine Notiz für Sonderfälle in die dritte. Diese Sonderfälle sind wichtig: eine komplett entfernte Seite, eine zusammengeführte Seite, ein umbenannter Slug oder ein Inhalt, der auf zwei Ziele aufgeteilt wird. Ohne diese Tabelle sind Redirects reine Vermutung.

Auch interne Links brauchen eine Prüfung. Viele Webflow-Seiten enthalten fest eingebaute Links in Fließtexten, Karten, Buttons und Footer-Blöcken. Wenn diese exportiert oder manuell neu erstellt werden, bleiben manche alten Pfade an Stellen erhalten, die niemand kontrolliert. Deshalb lohnt sich ein Link-Crawl. Er fängt die langweiligen Probleme ab, bevor Nutzer es tun.

Wenn du einen verwandten Prozess als Referenz möchtest, lies wie man von manueller Website-Migration umsteigt. Die Parallele ist einfach: In beiden Fällen ist der Wechsel sicherer, wenn die Übergabe geplant und nicht nur angenommen wird.

7. Inhalte, Assets und Komponenten für Entwickler sauber übergeben

Entwickler brauchen mehr als eine Design-Datei. Sie brauchen das Copy-Dokument, exportierte Assets, Hinweise zu Komponenten, SEO-Metadaten und eine Liste von Sonderfällen. Eine ausgefeilte Figma-Datei ohne inhaltlichen Kontext ist nur die halbe Arbeit. Das Code-Team muss trotzdem raten, welche Überschrift final ist, welches Bild freigegeben wurde und welcher CTA noch geprüft wird.

Paketiere Assets mit sinnvollen Namen. „hero-final-v7.jpg“ ist kein Benennungssystem. Verwende Namen, die dem Entwickler sagen, wohin die Datei gehört und wofür sie da ist. Bewahre auch die Originalgrößen auf, denn ein Bild mit 2400 px verhält sich anders als ein Crop mit 1200 px. Solche Kleinigkeiten sparen Überarbeitungszyklen.

Dokumentiere alles, was aus dem Design nicht unmittelbar ersichtlich ist. Wechselt ein Testimonial manuell oder automatisch? Soll sich ein FAQ-Akkordeon nur einzeln öffnen oder mehrere offene Panels erlauben? Zeigt der Footer alle Links oder nur die der obersten Ebene? Konkrete Hinweise verhindern eine lange Kette von Rückfragen während der Entwicklung.

Das ist auch der Moment zu prüfen, ob das Content-Paket etwas sicherheitsrelevantes enthält. API-Keys, Admin-Zugangsdaten, unveröffentlichte Entwürfe und temporäre Zugriffslinks sollten nicht in normalen E-Mail-Verläufen landen. Wenn dein Team eine Checkliste braucht, deckt die Seite zu Website-Sicherheit die Art von Routinearbeit ab, die oft liegenbleibt, wenn alle nur auf die Optik schauen.

8. Die neu aufgebaute Website gegen Webflow-spezifische Funktionen validieren

Der letzte Durchgang ist ein Vergleich, keine Feierstunde. Gehe die Custom-Website Seite für Seite gegen die alte Webflow-Website durch und prüfe das Verhalten, nicht nur das Aussehen. Öffne Menüs, Formularübermittlungen, Filter, Akkordeons, Anker, Animationsauslöser und mobile Breakpoints. Wenn etwas von Webflow-Standards gesteuert wurde, bestätige, dass die Custom-Version weiterhin dasselbe Ergebnis liefert.

Achte auf die kleinen Unterschiede, die Nutzer zuerst bemerken. Verdeckt der Sticky Header Ankerziele? Verhält sich die Bildergalerie in Safari anders? Erscheint ein dynamisch geladener Block eine Sekunde später als in Webflow? Das sind keine kosmetischen Fehler. Sie beeinflussen, ob die Seite fertig wirkt.

Führe auch auf der neu aufgebauten Website einen Content-Audit durch. Fehlender Alt-Text, defekte Links, leere Karten, doppelte Meta-Titel und fehlerhaftes Structured Data lassen sich nach dem Funktionstest leichter entdecken. Ein sauberer Neuaufbau kann trotzdem mit einem übersehenen Feld live gehen. Und genau dieses Feld kann wichtiger sein als die optische Verfeinerung.

Wenn Analytics oder Monitoring Teil deiner Launch-Kriterien sind, behalte das neue Verhalten auch nach dem Go-Live im Blick. Die Custom-Website kann korrekt sein und trotzdem andere Event-Zahlen, Formularbestätigungen oder Engagement-Muster erzeugen. Das ist normal. Die Aufgabe besteht darin, die Veränderung zu prüfen – nicht so zu tun, als hätte sie keine Folgen.