Migration zu Astro ist ein Neuaufbau, keine Konvertierung.

Nicht, wenn die Migration geplant ist. Sichtbarkeit geht bei Plattformwechseln fast immer aus vier Gründen verloren: fehlende oder pauschale Weiterleitungen, gekürzte Inhalte, verlorene Metadaten und ein Launch, den danach niemand beobachtet. Wir legen eine vollständige Redirect-Karte an, übernehmen Titel, Descriptions, Canonicals und hreflang unverändert, markieren vorher die Textpassagen, die Positionen tragen, und prüfen in den Wochen nach dem Umschalten die Search Console. Eine Garantie gibt niemand seriös – ein nachvollziehbares Verfahren schon.

Nein. Es gibt Werkzeuge, die Inhalte exportieren und nach Markdown konvertieren, und Astro veröffentlicht offizielle Migrations-Guides – unter anderem für WordPress, Next.js, Gatsby, Hugo, Jekyll, Eleventy, NuxtJS, SvelteKit, Create React App, Docusaurus und VuePress. Die decken Inhalte und Projektstruktur ab, nicht Ihr Design. Die Präsentationsschicht wird in jedem Fall neu gebaut. Wer einen Ein-Klick-Umzug verspricht, meint entweder nur den Inhaltsexport oder rechnet den Neubau später nach.

Nach unserer Erfahrung: 3–5 Wochen für eine kleine Marketing-Website mit wenigen Vorlagen, 6–9 Wochen für eine klassische Unternehmensseite mit CMS, 8–14 Wochen für eine Content-Seite mit Magazin oder Blog und ab 14 Wochen für mehrsprachige oder stark gewachsene Bestände. Ein Headless-Umstieg, bei dem das Redaktionssystem bleibt, liegt bei 4–8 Wochen. Gemessen wird von der Freigabe des Inhaltsinventars bis zum Umschalttag. Die Variablen dahinter stehen in der Dauer-Tabelle.

Den Rahmen bestimmen die Vorlagen-Konsolidierung, Menge und Zustand der zu übernehmenden Inhalte, die Integrationen und der Umfang des Redirect-Plans. Der Inhaltsumzug ist dabei selten der teure Teil – der Neubau der Oberfläche ist es. Deshalb weisen wir beides getrennt aus, damit Sie sehen, wofür Sie zahlen. Welche Faktoren wie stark durchschlagen, haben wir unter Astro-Kosten offengelegt.

Ja, und oft ist das der beste Weg. Astro ist CMS-agnostisch und bleibt die Präsentationsschicht. Wenn Ihr Redaktionsteam eingespielt ist, behalten Sie das Backend und tauschen nur die Auslieferung – bei WordPress heißt das Headless-Betrieb. Alternativ ziehen die Inhalte in ein Headless CMS oder direkt als Content Collections ins Repository. Welcher Weg passt, entscheidet Ihr Redaktionsalltag, nicht die Technik.

Sie stehen auf derselben Liste wie die Seiten. Bilder werden übernommen und in die Bildpipeline von Astro überführt, die Maße ableitet und damit Layout-Verschiebungen vermeidet. PDFs behalten in der Regel ihre Pfade, weil sie verlinkt und indexiert sind. Alte Kampagnen-URLs mit Query-String, Paginierungsseiten, Kategorie- und Tag-Archive sowie Feed-Adressen bekommen ebenfalls Weiterleitungsziele. Genau diese vergessenen Adressen sind der häufigste Grund für 404-Wellen nach einem Relaunch.

Ja. Bei größeren Websites ist das oft der ruhigere Weg: Ein Bereich läuft zuerst auf Astro – häufig der Blog oder ein Sprachzweig –, der Rest bleibt vorerst im alten System. Ausgeliefert wird pfadweise über einen vorgelagerten Proxy, sodass für Besucher und Suchmaschinen genau eine Domain bestehen bleibt. Das kostet etwas mehr Aufsetzarbeit und senkt das Risiko deutlich. Ob es sich lohnt, hängt an Größe und Umsatzrelevanz der Seite.

Wenn die Beschwerde fehlt. Ist Ihre Seite schnell genug, arbeitet Ihr Team zufrieden und stimmen die Pflegekosten, dann ist ein Wechsel verbranntes Budget. Ebenso, wenn Ihr Marketing selbst visuell Seiten baut und das gut läuft – dann bleiben Sie bei Webflow, das bauen wir genauso gern. Und wenn das eigentliche Problem Inhalte oder Struktur sind, bringt ein SEO-Audit mehr als jeder Technologiewechsel.

Ihre alte Seite bleibt online, bis die neue freigegeben ist – der Neubau entsteht parallel auf einer Vorschau-Umgebung mit Ihren echten Inhalten. Der Umschalttag ist danach eine DNS- oder Proxy-Änderung, keine Abschaltung. Wir senken vorher die DNS-Laufzeit, legen den Wechsel in eine verkehrsarme Stunde und halten die alte Umgebung noch eine Weile erreichbar. Der Rollback-Plan steht schriftlich fest, bevor jemand etwas anfasst. Eine Null-Downtime-Garantie gibt Ihnen niemand seriös; eine Umgebung, die bis zur Freigabe weiterläuft, schon.

Rechnen Sie in Wochen, nicht in Tagen. Suchmaschinen müssen die neuen Adressen crawlen, die Weiterleitungen auswerten und die Seiten neu bewerten – bei großen Beständen dauert allein das Nachcrawlen eine Weile. Schwankungen in den ersten Wochen sind normal und kein Alarmsignal, ein anhaltender Rückgang schon. Deshalb setzen wir das Beobachtungsfenster auf sechs bis acht Wochen nach dem Umschalten an und melden Sitemap sowie geänderte URLs zusätzlich über IndexNow, damit der Neuabgleich nicht auf den nächsten Crawl wartet.

Weniger, als es klingt. Eine Astro-Seite besteht aus HTML, CSS, TypeScript und Komponenten-Dateien; für die interaktiven Teile gibt es offizielle Integrationen für React, Preact, Svelte, Vue, SolidJS und Alpine.js. Wer eine dieser Bibliotheken kann, arbeitet nach kurzer Einarbeitung produktiv – anders als bei einem gewachsenen Theme mit eigener Template-Sprache und Plugin-Logik. Dazu kommt: Der Code liegt in Ihrem Repository unter MIT-Lizenz. Sie sind an keinen Anbieter gebunden, sondern an eine gängige Werkzeugkette.

Dann geht die Arbeit weiter, ohne uns. Das Repository gehört Ihnen ab dem ersten Commit, Hosting-Konten und Domain laufen auf Ihren Namen, und wir bauen keinen proprietären Zwischenschritt ein, den nur wir bedienen können. Zur Übergabe gehören eine Dokumentation der Inhaltsstruktur, der Deployment-Weg und eine Einweisung. Astro selbst steht unter MIT-Lizenz. Wir sind ein kleines Team und sagen das offen – deshalb legen wir Projekte so an, dass jede andere Agentur sie übernehmen kann.

Wir. Was wir gebaut haben, bringen wir in Ordnung – im Rahmen der vertraglich vereinbarten Gewährleistung und ohne Diskussion über Zuständigkeiten. Die Abnahme läuft gegen eine konkrete Liste: die Redirect-Karte, Seite für Seite geprüft, plus Metadaten und Formularwege. Was danach an neuen Wünschen kommt, ist Weiterentwicklung und wird als solche beauftragt. Der laufende Betrieb – Updates, Monitoring, kleine Änderungen – ist ein eigener Punkt: Support und Wartung.

Ja, und das ist ausdrücklich vorgesehen. Ihr Team bekommt das Repository, eine Standard-Werkzeugkette ohne Sonderwege und eine Einführung in das Inhaltsmodell. Weil die Felder über ein Zod-Schema typisiert sind, ist die Struktur selbsterklärend und Fehler fallen schon im Build auf, nicht erst auf der Live-Seite. Ihre Entwickler übernehmen also nicht ein gewachsenes Rätsel, sondern ein dokumentiertes Modell. Wir bleiben für Wartung oder größere Ausbauten verfügbar – aber als Wahl, nicht als Zwang.

Nicht wegen uns. Frisch investiertes Budget ist ein guter Grund, mindestens einen Zyklus zu warten – vorausgesetzt, das System liefert. Was wir stattdessen vorschlagen: erst messen, was genau stört. Oft ist es nicht die Plattform, sondern eine überladene Startseite, ein Consent-Layer oder eine Struktur, die niemand mehr pflegt. Ein SEO-Audit oder eine Performance-Analyse kostet einen Bruchteil einer Migration und beantwortet die Frage, ob sich der Wechsel überhaupt lohnt.

Mehrsprachigkeit vervielfacht nicht die Vorlagen, aber alles andere: eigene URLs je Sprache, hreflang-Paare in beide Richtungen, eine Redirect-Karte pro Sprachzweig, Sprachumschalter mit korrekten Zielen und Übersetzungen, deren Stand oft auseinanderläuft. Dazu kommen mehr Freigabewege, weil selten eine Person alle Sprachen verantwortet. Realistisch liegen solche Projekte bei 14 Wochen aufwärts. Der ruhigere Weg ist häufig, einen Sprachzweig zuerst umzuziehen und die übrigen in Wellen nachzuziehen.

Es kommt darauf an, wo der Schwerpunkt liegt. Astro ist die Präsentationsschicht – Kategorie-, Produkt- und Inhaltsseiten lassen sich damit sehr gut ausliefern, während Warenkorb, Checkout, Zahlungen und Warenwirtschaft in einem spezialisierten System bleiben oder headless angebunden werden. Wenn Ihr Geschäft aber im Wesentlichen aus Checkout, Lager und Kundenkonten besteht und die Inhalte nur Beiwerk sind, spricht das eher gegen eine Migration. Diesen Fall sagen wir Ihnen im Erstgespräch, bevor Aufwand entsteht.

Ehrlicherweise mehr, als die meisten erwarten: ein bis drei Stunden pro Woche für Rückfragen und Freigaben, dazu zwei größere Blöcke – die Entscheidung über die Abschaltliste und die Abnahme gegen die Redirect-Karte. Außerdem brauchen wir Zugänge zu Hosting, Domain, Analytics und Search Console. Der häufigste Grund für Verzug ist nicht die Technik, sondern eine offene Freigabe. Deshalb benennen wir zu Beginn genau eine Person auf Ihrer Seite, die entscheiden darf – ein Gremium reicht nicht.

Bei Seiten ohne Rankings gern – da ist die Migration der beste Moment dafür. Bei Seiten, die Positionen tragen, raten wir davon ab, beides im selben Schritt zu tun. Wenn Umzug und Textarbeit gleichzeitig passieren und die Sichtbarkeit danach fällt, weiß niemand, woran es lag: an der Weiterleitung, am neuen Text oder am Layout. Wir ziehen deshalb erst eins zu eins um, messen sechs bis acht Wochen und machen die inhaltliche Überarbeitung als eigene Welle danach.

Berechtigte Frage – und Astro allein beantwortet sie nicht. Was hilft: Statisch ausgelieferte Seiten brauchen kein öffentlich erreichbares Backend und kein Plugin-Ökosystem, das unbemerkt Drittanbieter nachlädt. Das Hosting können Sie in der EU wählen, das Repository liegt bei Ihnen. Was Arbeit bleibt: Formulare, Analytics, Schriftarten, eingebettete Videos und Consent-Verwaltung. Wir dokumentieren die Datenflüsse der neuen Seite, damit Ihr Datenschutzbeauftragter etwas Prüfbares in der Hand hat statt einer Vermutung.

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz, es fallen keine Lizenzgebühren an – auch nicht pro Seite, Nutzer oder Umsatz. Kosten entstehen für Entwicklung, Hosting und, falls Sie eines nutzen, für Ihr CMS. Genau das ist einer der Gründe, aus denen Teams die laufenden Kosten senken.

Astro ist ein Open-Source-Projekt, das öffentlich auf GitHub im withastro-Repository entwickelt wird. Die Lizenzdatei nennt MIT-Lizenz und Copyright (c) 2021 Fred K. Schott. Der Code ist einsehbar, forkbar und nicht an eine Plattform gebunden – anders als bei einer geschlossenen Website-Plattform.

Standardmäßig nicht: Astro rendert Ihre Seiten beim Build vor und liefert statisches HTML aus, das jedes Static-Hosting oder CDN ausliefern kann. Erst wenn einzelne Routen zur Laufzeit gerendert werden sollen, braucht es einen Adapter für die Ziel-Laufzeit – offiziell etwa für Node, Vercel und Cloudflare.

Ja, das ist der Standardfall. Beiträge liegen als Markdown oder MDX in Content Collections mit einem Zod-Schema, das jedes Feld validiert. Übersichts-, Kategorie- und Autorenseiten entstehen daraus automatisch, ebenso Feeds und Sitemap. Alternativ kommen die Beiträge aus einem Headless CMS.

Die Voraussetzungen sind gut: Server-gerendertes HTML als Standard, volle Kontrolle über Titel, Descriptions, Canonicals und strukturierte Daten, kein Client-JavaScript, solange keins angefordert wird. Ranking macht das aber nicht die Technik, sondern Inhalt, Struktur und interne Verlinkung. Astro nimmt Ihnen nur die technischen Ausreden.

Wir bauen auf der aktuellen Astro-7-Linie. Astro folgt Semantic Versioning, und für genau eine vorherige Major-Version gibt es erweiterte Wartung mit Sicherheits-Fixes. Deshalb gehört ein geplanter Upgrade-Pfad bei uns zum Projekt und nicht in die Kategorie „irgendwann mal“.