Von Framer zu Astro – wenn die Seite aus dem Werkzeug herauswächst.

Nein – jedenfalls nicht so, dass am Ende ein wartbares Projekt steht. Astro dokumentiert Migrationsleitfäden für eine Reihe von Frameworks wie Next.js, Gatsby, Hugo, Jekyll oder WordPress; Framer gehört nicht dazu. Der Weg ist deshalb Neuaufbau: Das Design wird in Astro als Komponenten- und Token-System nachgebaut, während Inhalte, Sammlungen, Metadaten und URL-Struktur übernommen werden. Was Sie nicht verlieren, ist Ihr Design – nur die Datei bleibt zurück.

Nicht, wenn der Umzug geplant wird. Vor dem Wechsel ziehen wir alle indexierten URLs und bauen daraus eine vollständige 301-Liste, halten Titel- und Überschriftenstruktur der tragenden Seiten stabil und testen jede Weiterleitung auf Staging. Nach dem Go-live beobachten wir Indexierung und Positionen mehrere Wochen und korrigieren nach. Rankings gehen bei Relaunches selten durch die Technik verloren, sondern durch vergessene URLs.

Die wichtigen ja, aber neu implementiert – und wir versprechen keine pixelgleiche Reproduktion. Seitenübergänge löst Astro mit den eingebauten View Transitions, Hover- und Zustandsbewegung läuft in CSS, aufwendige Effekte werden zu Inseln mit eigenem Ladezeitpunkt. Vor dem Angebot bekommen Sie ein Inventar aller Bewegungen mit einer Empfehlung pro Effekt. Wenn Ihre Marke im Kern aus Motion besteht, sagen wir Ihnen, dass Framer die bessere Wahl bleibt.

Ja, wenn wir es so aufsetzen – und das tun wir. Entweder über ein Headless CMS mit Masken, in dem ein Speichern den Deploy auslöst, oder direkt über Markdown-Dateien im Repository, wo das Zod-Schema fehlende Felder meldet, bevor etwas live geht. Für Teams ohne Lust auf ein weiteres System richten wir zusätzlich den Chat-Weg ein: Text ändern, Bild tauschen, Beitrag anlegen als Nachricht. Strukturelle Änderungen bleiben Entwicklungsarbeit.

Den Rahmen bestimmen drei Größen: die Anzahl unterschiedlicher Seitenvorlagen (nicht der Seiten), der Umfang der zu übernehmenden Inhalte samt CMS-Entscheidung und die Menge an Motion, die tatsächlich nachgebaut werden soll. Dazu kommen Integrationen und – bei mehreren Sprachen – die Lokalisierungsstruktur. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit Annahmen. Die Kostentreiber im Detail stehen unter Astro Kosten.

Wenn die Seite jung ist und sich noch häufig ändert, wenn Motion Design zur Markenwirkung gehört, wenn niemand im Team entwickelt und der Inhaltsumfang klein bleibt. In diesen Fällen ist Framer genau das richtige Werkzeug, und ein Umzug kostet Geld, ohne ein Problem zu lösen. Wir sagen Ihnen das im Erstgespräch – wir bauen auch mit anderen Werkzeugen und müssen Ihnen Astro deshalb nicht verkaufen.

Das hängt daran, wer die Seite nach dem Launch pflegt und wie viel Inhalt dazukommt. Framer ist stark, wenn Design und Bewegung im Vordergrund stehen. Webflow passt, wenn Marketing ohne Deploy publizieren soll – wir bauen beides. Astro passt, wenn Inhalte, Integrationen und Kontrolle über die Auslieferung wichtiger werden. Für den Weg von der anderen Plattform gibt es eine eigene Seite: Webflow zu Astro. Was Astro überhaupt ist, erklären wir unter Was ist Astro?.

Zuverlässig nachbaubar sind Scroll-Reveals, gestaffelte Einblendungen, Sticky-Sektionen, Parallax im Hero, Hover- und Zustandswechsel sowie Seitenübergänge mit fortbestehenden Elementen – Letzteres über die eingebauten View Transitions. Aufwendiger, aber machbar: verschachtelte Timelines, federnde Bewegungskurven, cursor-gebundene Szenen. Die entstehen als Insel mit eigenem Ladezeitpunkt und mit eigenem Budget. Was wir nicht zusagen, ist pixel- und millisekundengleiche Übereinstimmung mit der Framer-Fassung.

Nein, und genau dafür gibt es das Motion-Inventar. Effekte, die nur beim allerersten Besuch auffallen, aber bei jedem Seitenaufruf Code kosten – Preloader, Zähler, Text-Scrambling, Cursor-Follower – streichen wir in der Regel. Bewusst anders bauen wir alles, was den Hauptinhalt beim Einstieg blockiert oder Layout-Sprünge erzeugt: Inhalt zuerst, Bewegung danach. Jede Bewegung bekommt außerdem einen Reduced-Motion-Fallback. Die Streichliste entscheiden Sie mit; wir schlagen vor.

Ja, als Struktur – nicht als Datei. Aus jeder Sammlung wird eine Content Collection mit Zod-Schema oder ein Modell im Headless CMS. Verweise zwischen Sammlungen, etwa Beitrag auf Autor oder Projekt auf Kategorie, werden zu Referenzfeldern und beim Build geprüft. Der Gewinn danach: Ein kaputter Verweis oder ein fehlendes Pflichtfeld bricht den Build, statt auf der Live-Seite als leere Karte zu erscheinen. Feldnamen und Slugs halten wir dabei stabil.

Die Einträge werden strukturiert abgezogen: Felder, Slugs, Datumsangaben, Bilder und Verweise. Bilder laufen dabei einmal durch die Astro-Bildpipeline. Danach vergleichen wir Eintrag für Eintrag gegen die alte Seite – Anzahl, Slugs, Pflichtfelder. Downtime entsteht nicht: Bis zum Umschalten der Domain laufen beide Systeme parallel, die neue Seite steht auf Staging. Vor dem Wechsel senken wir die DNS-Laufzeit und frieren die Redaktion kurz ein, damit kein Beitrag nur in einem System landet.

Das Formular selbst wird neu angeschlossen: entweder an eine serverseitig gerenderte Route mit Adapter für Ihre Laufzeit oder an einen externen Dienst. Spam-Schutz, Double-Opt-in, Weiterleitung ins CRM und die Auftragsverarbeitung werden dabei neu festgelegt. Der Punkt, an den fast niemand denkt: Bereits eingegangene Einsendungen liegen in der Plattform und müssen vor der Kündigung exportiert werden. Das steht bei uns auf der Abnahme-Checkliste, nicht in einer Fußnote.

Teilweise, und das ist die gute Nachricht: Diese Komponenten sind React. Die eigentliche Logik lässt sich häufig übernehmen und als React-Insel in Astro einbinden – für React gibt es eine offizielle Integration, die Komponente wird über eine client:*-Direktive hydratisiert. Nicht mit übernommen werden plattformeigene APIs und Property-Controls; daraus werden Props beziehungsweise Felder im Content-Modell. Aufwand pro Komponente: wenige Stunden bis mehrere Tage, je nach Verankerung in der Plattform.

Erst ein Inventar, dann eine Entscheidung pro Skript. Chat-Widget, Analytics, Buchungstool: Vieles ist auch in Astro ein Skript-Tag – der Unterschied ist, dass Sie Ladezeitpunkt und Reihenfolge selbst bestimmen und einzelne Skripte erst nach einer Einwilligung laden können. Manches ersetzen wir serverseitig, etwa den direkten Weg vom Formular ins CRM, und sparen das Skript ganz. Was bleibt, bekommt eine Ladestrategie und einen Eintrag in Ihrer Datenschutzerklärung.

Nein – es wird nur explizit statt still. Sitemap und robots.txt entstehen im Build, Canonical und hreflang kommen aus dem Layout, Title, Description und OG-Bild werden zu Feldern im Schema, deren Länge geprüft wird. Konfiguriert wird das einmal, nicht pro Seite. Ihre bestehenden Weiterleitungsregeln ziehen wir aus der Plattform ab und übernehmen sie in die 301-Liste, damit ältere Umzüge nicht ein zweites Mal verloren gehen. Ketten lösen wir dabei auf ein Ziel auf.

In der Praxis eher umgekehrt. Astro ist die Präsentationsschicht und ausdrücklich UI-Framework-agnostisch: Komponenten sind HTML und CSS, Interaktives kommt aus React, Vue, Svelte, Preact, SolidJS oder Alpine. Wer eines davon kann, ist in einem Astro-Projekt innerhalb weniger Tage produktiv. Das Ergebnis ist ein gewöhnliches Git-Repository mit npm-Abhängigkeiten. In einem Baukasten hängt Wissen dagegen an einer bestimmten Oberfläche und lässt sich schlechter übertragen.

Repository, Domain und Hosting-Account laufen von Anfang an auf Ihren Namen – wir arbeiten darin, wir besitzen es nicht. Der Stack ist bewusst Standard: Astro unter MIT-Lizenz, Git, Markdown oder ein CMS Ihrer Wahl. Zur Übergabe gehören README, Deploy-Beschreibung und die Content-Schemata. Damit kann jedes Team weitermachen, das Astro oder React kennt. Wenn Sie intern weiterentwickeln wollen, arbeiten wir die letzten Wochen im Pairing, damit Ihr Team die erste eigene Änderung noch mit uns deployt.

Fehler an dem, was wir gebaut haben, beheben wir im Rahmen der vereinbarten Gewährleistung, ohne neue Rechnung. Damit klar ist, worüber wir reden, gibt es vor dem Go-live eine Abnahme mit Prüfliste: Weiterleitungen, Formulare, Metadaten, Analytics, Rechtstexte, Sprachversionen. Was danach kommt – Updates, Monitoring, kleine Änderungen, neue Seiten – ist Betrieb und läuft über eine eigene Vereinbarung. Die Möglichkeiten stehen unter Astro Support und Wartung.

Für einen kompakten Auftritt bis etwa zehn Seiten rechnen wir mit drei bis fünf Wochen ab freigegebenem Inventar. Für einen gewachsenen Auftritt mit Archiv, Headless CMS und zwei Sprachen mit sechs bis zehn Wochen. Ab drei Märkten, serverseitigen Anbindungen und viel markentragender Bewegung planen wir in Ausbaustufen. Davor liegen ein bis zwei Wochen Inventar und Messung, danach acht bis zwölf Wochen Beobachtung. Die Variablen stehen im Abschnitt Zeitrahmen.

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz, auch für kommerzielle Projekte. Für das Framework selbst fällt keine Lizenzgebühr an. Kosten entstehen für Entwicklung, Hosting und – falls gewünscht – ein CMS. Eine Plattformgebühr je Website wie bei einem Baukasten gibt es nicht.

Nicht zwingend. Standardmäßig wird die gesamte Seite vorgerendert und als statisches HTML ausgeliefert; das läuft auf nahezu jedem Webspace oder CDN. Erst wenn einzelne Routen zur Laufzeit rendern sollen – Formularverarbeitung, geschützte Bereiche, Live-Daten – kommt ein Adapter für Node, Vercel oder Cloudflare dazu.

Ja, das ist der Kernfall. Beiträge liegen als Markdown in einer Content Collection mit Zod-Schema. Astro liefert dafür typisierte Abfragen wie getCollection() und ein Caching, das ausdrücklich für tausende Einträge gedacht ist. Kategorien, Autorenseiten, Feeds und Paginierung entstehen daraus als Routen.

Astro liefert standardmäßig fertiges HTML aus, das Crawler ohne JavaScript-Ausführung lesen können, und lässt Ihnen die Kontrolle über Metadaten, strukturierte Daten und Sitemap. Rankings entstehen dadurch nicht von selbst – aber eine ganze Klasse technischer Hürden fällt weg. Den Rest macht der Inhalt.

Astro ist ein Open-Source-Projekt unter MIT-Lizenz, Copyright 2021 Fred K. Schott, entwickelt im withastro-Repository auf GitHub von einem Kernteam und der Community. Die aktuelle Major-Linie ist Astro 7. Das Projekt folgt Semantic Versioning; erweiterte Wartung gibt es für genau eine Vorgänger-Major.