Was umfasst eine Migration von Webflow zu Astro wirklich?

Wir haben bshdo.co im Oktober 2026 von seinem Webflow-Export umgezogen. Die Website hatte vier Marketing-Seiten und elf Fallstudien, alles statisches HTML aus einem bereinigten Webflow-Export, ausgeliefert über Cloudflare Pages. Das hier hat der Umzug umfasst, mit den Zahlen, denn dasselbe Muster gilt für die meisten Marketing-Websites, deren Migration man bei uns anfragt.

Was eine Migration ist und was nicht

Eine Migration ist kein Redesign. Die Seiten, die Texte, die URLs und die strukturierten Daten bleiben; es ändert sich, wo sie liegen und wie sie gebaut werden. Wir haben jede Seite eins zu eins portiert und dann alle siebzehn gebauten Seiten (die fünfzehn Seiten der Website, die 404 und die 401) mit den Originalen verglichen, nachdem Leerraum und Attributreihenfolge normalisiert waren. Die einzigen Unterschiede waren vier bewusste Korrekturen. Das JSON-LD wurde als Daten verglichen und war auf allen fünfzehn Seiten, die es tragen, identisch.

Dieser Gleichheitstest ist der Kern der Arbeit. Ohne ihn verliert eine Migration unbemerkt hier eine Meta-Beschreibung, dort eine Breadcrumb, und der Ranking-Verlust zeigt sich einen Monat später ohne erkennbare Ursache.

Die URL-Regeln

Jede indexierte URL der alten Website hatte keinen abschließenden Schrägstrich und keine Dateiendung: /services, nicht /services/ oder /services.html. Astro schreibt standardmäßig ein Verzeichnis pro Route, was jede URL geändert hätte. Eine einzige Konfigurationsentscheidung, build.format: 'file', behält eine Datei pro Route und die URLs genau so, wie sie waren.

Alte URLs, die es nicht mehr gibt, bekommen eine Weiterleitung, nie eine 404. Unsere Tabelle hatte 33 Einträge: einunddreißig Bilder, umbenannt von den Upload-Namen in Webflow, und zwei Seitenpfade, die noch Traffic bekamen. Ein Build-Schritt prüft jetzt jede URL, die je live war, gegen die Build-Ausgabe und die Weiterleitungsdatei und lässt den Build fehlschlagen, wenn eine davon nichts zurückgeben würde.

Assets

Webflow exportiert von Hand erzeugte Bildgrößen: -p-500, -p-800, -p-1080 als Kopien jedes Fotos. Astro erzeugt die Größen beim Build aus einer einzigen Quelle, also sind die Kopien weg. Das Stylesheet schrumpfte nach dem Bundling von 86 KB auf 85 KB, die Skripte wanderten in Bundles mit Hash im Namen, und jede erzeugte Datei wird ein Jahr lang gecacht, weil sich ihr Name ändert, wenn sich ihr Inhalt ändert. Die einzige Ausnahme ist alles mit einem festen Namen, etwa Open-Graph-Bilder, die einen Tag bekommen.

Die animierten Collagen der Website, einunddreißig Megabyte Video-Loops, blieben genau, wo sie waren. Astro verarbeitet kein Video; es kopiert die Loops unverändert in jeden Build, und einunddreißig Megabyte pro Deploy waren es nicht wert, wegoptimiert zu werden.

Strukturierte Daten

Auf der alten Website war ein fünf Kilobyte großer Organization-Knoten in alle fünfzehn Seiten eingefügt. Jetzt liegt er in einer einzigen Datendatei und wird beim Build in jede Seite übernommen, also passiert eine Änderung an der Adresse des Unternehmens nur einmal. Jede Seite behält ihre eigenen Knoten: WebPage, BreadcrumbList, ein CreativeWork pro Fallstudie, eine ItemList auf der Referenzen-Seite.

Was wir wieder so machen würden

Den Gleichheitstest zuerst bauen. Das URL-Format beibehalten. Jede alte URL in eine Liste schreiben, die der Build prüft. Bilder in die Build-Pipeline holen und Video in Ruhe lassen. Die Sitemap am Tag des Livegangs neu einreichen und für die wichtigsten Seiten die Indexierung beantragen.

Was wir nicht wieder tun würden: die Inhalte als Teil der Migration behandeln. Die Neupositionierung dieser Website kam nach dem Umzug, als eigenes Stück Arbeit, und deshalb ließ sich der Umzug Zeile für Zeile prüfen.