Astro Framework: Was es ist und wann es die richtige Wahl ist

Die kurze Antwort

Astro ist ein Open-Source-Framework für inhaltsgetriebene Websites. Es rendert Komponenten zu HTML und CSS und schickt an den Browser standardmäßig null clientseitiges JavaScript. Der Besucher bekommt also ein fertiges Dokument statt eines Programms, das die Seite erst zusammensetzt. Interaktivität wird bewusst angefordert, Komponente für Komponente. Die aktuelle Hauptversion ist Astro 7.

Für eine B2B-Website hat das zwei Folgen. Die Seite ist sofort lesbar, für Menschen wie für Crawler, also die Programme, mit denen Google und KI-Systeme Inhalte einlesen. Und die Ladezeit hängt an deinen Entscheidungen, nicht daran, was eine Plattform ungefragt mitliefert. Unsere Messung vom 13.09.2026 zeigt den Abstand: Die Startseite von leanwave.com, die wir statisch mit Astro bauen, lädt rund 39 KB JavaScript in drei Dateien. Eine Webflow-Kundenseite aus unserem Bestand liegt an derselben Stelle bei rund 740 KB in dreizehn Dateien.

Die Grenze ist genauso deutlich. Wenn Login, Benutzerkonten oder Daten, die pro Anfrage frisch vom Server kommen, im Zentrum des Projekts stehen, nimmst du Next.js. Astro kann serverseitig rendern, aber es ist nicht dafür gebaut, eine Oberfläche zu tragen, die sich im Sekundentakt verändert.

Was ist Astro, und was macht es anders

Die meisten modernen Frameworks liefern eine Seite als JavaScript-Anwendung aus und bauen sie im Browser noch einmal auf. Astro dreht das um. Deine Komponenten werden gerendert, bevor ein Besucher sie sieht, und was ankommt, ist HTML mit CSS. JavaScript kommt nur dort dazu, wo du es anforderst. Das wirkt nach einem Detail, entscheidet aber darüber, wie schnell die erste Ansicht steht und wie viel ein Crawler ohne Umweg lesen kann. Für deine Werte in den Core Web Vitals ist der Zusammenhang direkt: weniger ausgelieferter Code, weniger Arbeit im Browser, bevor die Seite benutzbar ist.

Null clientseitiges JavaScript als Standard

Astro rendert Inhalte entweder im Voraus, also einmal beim Bauen der Website (SSG, statische Erzeugung), oder pro Aufruf auf dem Server (SSR, serverseitiges Rendern). In beiden Fällen verlässt die Seite den Server als fertiges HTML. Für statische Inhalte sind das 0 KB JavaScript. Du entfernst also keine Skripte, die ein Baukasten oder ein Theme ungefragt mitgebracht hat, sondern entscheidest bei jeder Komponente neu, ob sie überhaupt Code im Browser braucht.

Zwei Dinge verbessern sich dadurch messbar im Alltag. Erstens die Ladezeit auf schlechten Verbindungen und auf älteren Firmenrechnern, und genau darauf sitzen deine Einkäufer. Zweitens die Lesbarkeit für Systeme, die keine JavaScript-Ausführung abwarten. Wenn du willst, dass ChatGPT, Perplexity oder Google AI Overviews deine Inhalte sauber aufnehmen, ist fertiges HTML die verlässlichere Grundlage. Wie wir das systematisch angehen, steht in unserem Artikel zu Generative Engine Optimization.

Client Islands und Server Islands

Islands sind Astros Begriff für interaktive Inseln in einer sonst statischen Seite. Statt die komplette Seite mit JavaScript zu beleben, belebst du einzelne Bausteine. Zwei Formen brauchst du in der Praxis:

Praktisch heißt das: Ein Produktfilter bekommt sein JavaScript, eine Suche bekommt ihres, der Rest der Seite bekommt keines. Du zahlst Ladezeit nur für Funktionen, die du wirklich anbietest.

Astro im Vergleich zu Baukasten, Webflow und Next.js

Der Vergleich lohnt entlang der Fragen, die später im Betrieb wehtun: Wer kommt an Rendering und Caching, was kostet eine weitere Sprache, und was passiert, wenn du in drei Jahren umziehen willst. Die Tabelle ordnet die vier üblichen Wege ein, Preise mit Stand 13.09.2026. Das direkte Duell der beiden Frameworks ersetzt sie nicht, das kommt im nächsten Abschnitt.

Zwei Zeilen verdienen eine Erklärung. Der Webflow-Export liefert dir HTML, CSS und JS, aber weder die CMS-Inhalte noch die Interaktionen. Du nimmst also die Hülle mit und baust das Innenleben neu, was den Umzugsaufwand deutlich erhöht. Und die Lokalisierung läuft bei Webflow als Add-on, 9 $ pro Sprache und Monat im Essential-Tarif bis drei Sprachen, 29 $ pro Sprache im Advanced-Tarif bis zehn. Ob die Hauptsprache mitgezählt wird, sagt die Preisseite nicht. Bei fünf Sprachen summiert sich das jeden Monat, während eine Astro-Website die Sprachen im Content-Modell trägt.

Das heißt nicht, dass Webflow der falsche Weg ist. Bis etwa 30 Seiten, eine oder zwei Sprachen und ohne geplante programmatische Seiten reicht Webflow, und wir betreuen als zertifizierter Partner selbst Kunden darauf über unsere Webflow-Agentur. Oberhalb dieser Schwelle kippt die Rechnung, und die Alternativen haben wir in Webflow-Alternativen und in Webflow vs. Next.js einzeln durchgerechnet.

Wann Astro, wann Next.js

Beide Frameworks kommen aus demselben Werkzeugkasten, beide arbeiten bei uns mit Sanity, und beide liefern Seiten, an deren Technik du vollen Zugriff hast. Der Unterschied liegt darin, was im Zentrum steht: Inhalte oder Anwendung. in-sync.io selbst läuft auf Next.js, leanwave.com auf Astro. Die ausführliche Gegenüberstellung steht in Astro vs. Next.js, hier die Entscheidungsregel in Kurzform.

Wähle Astro, wenn

Deine Website erklärt, überzeugt und leitet weiter, statt Nutzer einzuloggen. Dann ist statisches Ausliefern der Normalfall, und du willst so wenig JavaScript wie möglich im Spiel haben.

Wähle Next.js, wenn

Ein Teil deines Produkts läuft in der Website, nicht daneben. Sobald Nutzer sich anmelden oder Daten pro Anfrage gezogen werden, gewinnst du mit Next.js mehr, als du an Einfachheit verlierst.

Wann Astro nicht passt

Es gibt Projekte, bei denen wir von Astro abraten, und das hat nichts mit dem Framework zu tun, sondern mit dem Zuschnitt. Astro ist stark, solange die Seite im Wesentlichen ein Dokument ist. Je mehr Zustand die Oberfläche hält, desto mehr arbeitest du gegen die Voreinstellungen.

In diesen Fällen nimmst du Next.js, und die Inhalte bleiben trotzdem, wo sie hingehören: in einem Headless CMS, also einem Redaktionssystem ohne eigenes Frontend. Der Wechsel des Frameworks ändert dann nichts an deinem Content-Modell. Gemischte Aufteilungen funktionieren ebenfalls, etwa die Marketing-Website in Astro und die Anwendung unter einer eigenen Adresse in Next.js. Das lohnt sich ab dem Punkt, an dem beide Teile von unterschiedlichen Leuten betreut werden.

Astro und Sanity: Inhalte als System statt als Seitensammlung

Astro allein ist ein Renderer. Interessant wird es mit einer strukturierten Content-Datenbank dahinter. Wir setzen dafür Sanity ein: Inhalte liegen als Dokumente mit klaren Feldern, nicht als fertige Seiten, und Astro holt sie beim Bauen ab. Ein Webhook, also ein automatischer Aufruf bei jeder Änderung, stößt den Neubau an, damit die Redaktion nicht auf einen Termin warten muss.

Der eigentliche Hebel liegt darin, dass die ganze Kette programmierbar ist: Content-Modell, Templates, Rendering, strukturierte Daten, Sitemap, interne Verlinkung und Deploy. KI-Agenten können über die API, also die Programmierschnittstelle, und über einen MCP-Server, eine standardisierte Schnittstelle für KI-Werkzeuge, Inhalte anlegen und prüfen. Ehrlich dazu: Webflow, Wix, Contentful und Storyblok bieten ebenfalls offizielle MCP-Server und APIs an. Der Unterschied liegt woanders, nämlich bei Item- und Collection-Limits, bei Template-Grenzen, weil ein Template an einer Collection hängt, bei API-Rate-Limits und beim fehlenden Zugriff auf Rendering, Caching, strukturierte Daten und Verlinkungslogik auf Code-Ebene.

Eine Warnung gehört dazu, weil wir sie selbst bezahlt haben. Programmatische Seiten funktionieren nur mit echter Substanz pro Seite. Andernfalls stuft Google sie als Doorway-Pages ein, also als Seiten ohne eigenen Zweck außer einem Keyword. Auf unserer alten Website haben wir genau diesen Fehler gemacht. Wenn du eine Seitengruppe nicht mit eigenen Daten, eigenen Beispielen und einem eigenen Grund füllen kannst, baue sie nicht. Wie wir Struktur, Indexierung und Auszeichnung aufsetzen, steht in technisches SEO.

So machen wir es: LeanWave, Yarowa und zwei Projekte daneben

Drei Projekte zeigen, was Astro im Betrieb leistet, und wo die Arbeit wirklich steckt. Alle drei laufen über unsere Webentwicklung, alle drei trennen Inhalte und Darstellung sauber.

LeanWave (Otto ID Solutions) verkauft RFID-Lösungen für Textilservice und Wäschereien. leanwave.com ist statisch mit Astro gebaut, mit Sanity, Tailwind und Vercel. Zweisprachig, Englisch auf der Wurzel, Deutsch unter /de, mit übersetzten URL-Segmenten: Aus /solutions wird /de/loesungen. hreflang, also die Auszeichnung, die jeder Sprachfassung ihre Gegenstücke zuweist, ist wechselseitig gesetzt inklusive x-default für die Standardfassung. Das Team pflegt 64 Dokumente und 86 Bild-Assets über den Sanity Presentation Mode im Tagesgeschäft, jede Änderung stößt per Webhook einen neuen Build an. Die Startseite landet bei rund 39 KB JavaScript in drei Dateien.

Bei Yarowa lag eine fünfsprachige B2B-Website vor, die ursprünglich in Webflow entstanden war. Den Webflow-Export haben wir unverändert nach Astro übertragen und auf Vercel gestellt: 5 Sprachen, 21 Seiten-Templates, 163 Sections, Design identisch. Das Design blieb unverändert, was den Fall interessant macht, denn der Nutzen lag komplett in Technik und Betrieb, nicht in einem neuen Look. Sanity mit Presentation Mode soll dort als Nächstes dazukommen. Wie ein solcher Umzug ohne Rankingverluste abläuft, steht in Website-Relaunch ohne SEO-Verlust, und das begleiten wir über unsere Relaunch-Agentur.

Zwei weitere Projekte zeigen die Bandbreite: Ullsteinhaus läuft mit Astro, React, Three.js und Sanity, Monteval mit Astro, GSAP und Sanity. GSAP ist eine JavaScript-Bibliothek für Animationen, und genau hier greifen Client Islands: Die Animation bekommt ihr Skript, der Rest der Seite bleibt statisch. Wie wir Bewegung einsetzen, ohne die Ladezeit zu ruinieren, steht in Website-Animationen.

Was eine Astro-Website kostet und was laufend anfällt

Die laufenden Kosten einer Astro-Website sind niedrig, weil du keine Plattformgebühr pro Website zahlst. Sanity Free kostet 0 $ und bringt 20 Plätze, 10.000 Dokumente, 100 GB Assets und 100 GB Bandbreite pro Monat mit, inklusive Presentation Mode und Visual Editing. Wird es größer, liegt Growth bei 15 $ pro Platz und Monat mit 25.000 Dokumenten. Vercel Pro kostet 20 $ pro Monat und Entwickler-Seat, inklusive 20 $ Nutzungsguthaben, ohne Grundgebühr pro Projekt. Unterm Strich läuft eine Astro-Website mit Sanity Free typischerweise mit 0-20 $ Hosting pro Monat, also nahezu ohne laufende Plattformgebühren. Eine weitere Sprache kostet bei uns keine zusätzliche Plattformgebühr.

Der Aufwand liegt im Aufbau, und dort gehört er auch hin. Eine Migration einer Marketing-Website mit 10-30 Seiten dauert typischerweise 3-6 Wochen bis Go-Live, plus Monitoring danach. Abgerechnet wird als Relaunch-Projekt, die Pakete dafür beginnen bei 8.000 € netto. Dazu gehören ein Vorher-Crawl mit Screaming Frog oder Ahrefs, ein Ranking-Snapshot, eine Redirect-Map 1:1 für jede alte URL, eine Launch-Checkliste, die Einreichung in Search Console und Bing sowie IndexNow. Anschließend zwei Wochen Beobachtung, mit 404-Report und Abgleich der Rankings.

Rechne den Vergleich über drei Jahre, nicht über den ersten Monat. Eine fünfsprachige Website auf einer Plattform mit Sprach-Add-on zahlt jeden Monat pro Sprache weiter, eine Astro-Website nicht. Was in eine solche Kalkulation gehört, haben wir in Webentwicklung Kosten aufgeschlüsselt.

Häufige Fragen

Nächster Schritt

Schick uns die Adresse deiner Website, und wir sagen dir in einem Gespräch, ob Astro der passende Weg ist und was der Umzug bei dir bedeutet.