Was ist Astro?

Beides, und die Entscheidung fällt pro Route. Standard ist Prerendering: Die gesamte Website wird beim Build erzeugt und als statisches HTML ausgeliefert. Eine einzelne Route rendert über export const prerender = false zur Laufzeit; mit output: "server" dreht sich der Standard um und einzelne Seiten kommen über prerender = true zurück. Für dynamische Teile innerhalb einer ansonsten statischen Seite gibt es Server Islands, die über server:defer serverseitig nachgerendert werden – die Hülle bleibt cachebar, das personalisierte Element lädt nach.

Nicht zwingend. Standardmäßig wird die gesamte Website vorgerendert, und statische HTML-Seiten gehen an den Browser – das läuft auf jedem statischen Hosting oder CDN. Sollen einzelne Routen zur Laufzeit rendern, wird dort On-Demand-Rendering eingeschaltet und ein Adapter für die Ziellaufzeit ergänzt. Offiziell gepflegt sind unter anderem die Adapter für Node, Vercel und Cloudflare. Welches Modell für Ihr Projekt sinnvoll ist, steht unter Astro-Hosting.

Zum Bauen ja: Astro ist ein JavaScript-Framework und läuft beim Build in einer JavaScript-Umgebung. Im Browser sieht es anders aus. Standardmäßig entfernt Astro sämtliches clientseitige JavaScript aus Komponenten. Was im Browser laufen soll, fordern Sie pro Komponente ausdrücklich über eine client-Direktive an. Eine Seite ohne interaktive Inseln kommt ohne Framework-JavaScript beim Nutzer an.

Eine Insel ist eine aufgewertete UI-Komponente auf einer ansonsten statischen HTML-Seite – der Begriff stammt aus dem Astro-Projekt selbst. Es gibt zwei Arten: Client Islands sind interaktive Komponenten, die im Browser einzeln hydratisieren, gesteuert über client:load, client:idle oder client:visible. Server Islands werden über server:defer serverseitig unabhängig gerendert, sodass die Seitenhülle gecacht bleiben kann.

Ja. Astro ist UI-Framework-agnostisch; offizielle Integrationen gibt es für React, Preact, Svelte, Vue, SolidJS und Alpine.js. Mehrere Frameworks lassen sich in einem Projekt kombinieren, allerdings nur innerhalb einer .astro-Datei – laut Dokumentation können nur Astro-Komponenten Komponenten aus mehreren Frameworks enthalten. Ohne client-Direktive wird Ihre React-Komponente serverseitig gerendert und kommt als reines HTML an. Bestehende Komponenten lassen sich damit häufig übernehmen, statt sie neu zu schreiben.

Die technischen Voraussetzungen sind gut. Standardmäßig wird die Website vorgerendert und als statisches HTML ausgeliefert – Inhalte stehen also im ausgelieferten Dokument und nicht erst nach der Hydratisierung. Die eingebaute Bildoptimierung leitet Maße ab und vermeidet dadurch Layout-Shift. Rankings entstehen trotzdem aus Inhalt, Struktur und Verlinkung. Was eine bestehende Seite wirklich bremst, zeigt ein SEO Audit.

Der Unterschied ist architektonisch. Astro ist eine Multi-Page-Architektur mit Server-Rendering als Standard und entfernt clientseitiges JavaScript, solange keins angefordert wird. Next.js bringt das App-Modell mit, das eingeloggte Bereiche, Dashboards und viel Zustand im Browser voraussetzen. Faustregel: Je mehr Ihr Projekt eine Website ist, desto eher Astro; je mehr es eine Anwendung ist, desto eher Next.js. Ausführlich unter Astro vs. Next.js.

In der Voreinstellung sind sie sich nah: Alle drei erzeugen statisches HTML, das auf jedem CDN liegen kann. Der Unterschied liegt daneben. Astro bringt ein Komponentenmodell mit, in dem interaktive Inseln in React, Preact, Svelte, Vue, SolidJS oder Alpine.js geschrieben werden, ein typisiertes Inhaltsmodell über Content Collections mit Zod – und die Möglichkeit, einzelne Routen zur Laufzeit rendern zu lassen. Hugo und Jekyll sind dafür schlanker, haben keine JavaScript-Toolchain im Rücken und sind für rein statische Dokumentation oder Blogs weiterhin eine gute Wahl. Offizielle Migrations-Guides nach Astro existieren für beide.

Für vier Fälle, und wir nennen sie lieber vorher. Erstens eingeloggte Anwendungen mit Rollen, Echtzeitdaten und viel Zustand im Browser – da ist ein App-Framework die richtige Grundlage. Zweitens Seiten, auf denen fast jede Komponente interaktiv wäre; dann verliert die Islands Architecture ihren Sinn. Drittens Vorhaben, die vor allem auf ein Plugin-Ökosystem angewiesen sind, etwa Shop, Mitgliederbereich oder Buchung, ohne dass jemand Code anfassen möchte. Und viertens Teams, die Layouts visuell selbst bauen wollen: Dafür ist Webflow das passendere Werkzeug, und wir bauen das ebenfalls.

Astro ist seit 2021 öffentlich und folgt Semantic Versioning. Die aktuelle Major-Linie ist Astro 7. Der Rhythmus ist zügig: Astro 6.0 wurde im März 2026 stabil, Astro 7.0 folgte im Juni 2026 – zwei Major-Versionen innerhalb eines Jahres. Wichtig für die Planung: Extended Maintenance mit Sicherheits-Fixes gibt es für genau eine vorherige Major-Version. Daraus folgt kein Drama, aber eine Betriebsentscheidung: Major-Upgrades gehören als wiederkehrende kleine Aufgabe eingeplant, nicht alle drei Jahre als Großprojekt. Wie das aussieht, steht unter Astro-Upgrade.

Ein Stück weit schwerer als für WordPress oder React, und das sagen wir offen: Es gibt weniger Lebensläufe mit „Astro“ darin. Der Aufwand ist trotzdem kleiner, als es klingt, weil Astro-Komponenten HTML, CSS und TypeScript sind und interaktive Inseln in React, Preact, Svelte, Vue, SolidJS oder Alpine.js geschrieben werden. Sie stellen also aus dem allgemeinen JavaScript-Markt ein und nicht aus einem Astro-Markt. Zum Ökosystem gehört auch die ehrliche Seite: Es gibt keinen Plugin-Marktplatz wie bei WordPress, und die Dokumentation weist selbst darauf hin, dass manche Migrations-Guides noch Stubs sind.

Nicht automatisch. Wenn fünf Seiten dauerhaft fünf Seiten bleiben, sich selten ändern und niemand im Haus mit Git arbeiten will, ist ein visuelles Werkzeug schneller und günstiger am Ziel – dann schlagen wir Webflow vor. Astro rechnet sich, sobald sich Seitentypen wiederholen, ein Blog oder Wissensbereich dazukommt, Inhalte aus einer strukturierten Quelle stammen, Ladezeit und Auffindbarkeit geschäftlich zählen – oder Sie Repository, Hosting und Domain vollständig in eigener Hand behalten wollen.

In der Regel ja. Offizielle Migrations-Guides existieren unter anderem für WordPress, Next.js, Gatsby, Hugo, Jekyll, Eleventy, NuxtJS, SvelteKit und Docusaurus – die Dokumentation weist allerdings selbst darauf hin, dass viele davon noch Stubs sind. Für Webflow und Framer gibt es keinen offiziellen Guide; dort ist der Weg Export beziehungsweise Auslesen und Neuaufbau. Ablauf und Risiken: Migration zu Astro.

Ja, über drei kombinierbare Wege. Ein Headless CMS mit Oberfläche, Vorschau und Rechten für alle, die täglich redigieren. Content Collections mit Markdown im Repository, wenn Inhalte selten und strukturiert entstehen. Oder Pflege per Chat: Weil das Zod-Schema maschinell adressierbar ist, kann ein Agent nur Felder füllen, die es gibt, in Formaten, die validieren – Text ändern, Beitrag anlegen, Bild tauschen als Nachricht statt als CMS-Sitzung, mit Commit, Vorschau und Rollback. Dass Chat-Agenten bei uns Tagesgeschäft sind, belegt unser eigener WhatsApp-KI-Agent. Was der Weg nicht ersetzt: Freigabe-Workflows großer Redaktionen und strukturelle Layout-Änderungen.

Ja, und das ist einer der Gründe für diese Bauweise. Astro ist quelloffen unter der MIT-Lizenz; es gibt keine Lizenz, keinen proprietären Editor und keinen Baustein, der an einen Dienstleister gebunden wäre. Was Sie dafür brauchen: jemanden, der mit HTML, CSS, JavaScript und Git arbeitet, das Repository mit vollständiger Historie, dokumentierte Build- und Deployment-Schritte und eine überschaubare Komponentenbibliothek statt hundert Einzelseiten. Ein Wechsel bleibt unangenehm, aber er ist Einarbeitung und keine Neuentwicklung.

Wir – für das, was wir gebaut haben und was nicht so funktioniert, wie es vereinbart war. Das reparieren wir im Rahmen der gesetzlichen Gewährleistung ohne neue Rechnung. Davon zu trennen ist der Änderungswunsch: Eine neue Funktion oder ein neuer Seitentyp ist eine Beauftragung und kein Mangel. In welche der beiden Kategorien eine Meldung fällt, sagen wir, bevor wir anfangen, nicht hinterher. Feste Reaktions- und Wiederherstellungszeiten gehören schriftlich in eine Wartungsvereinbarung, wenn Ihr Einkauf sie braucht.

Dass die klassische Angriffsfläche einer Content-Website hier weitgehend entfällt. Eine vorgerenderte Astro-Seite hat im Auslieferungspfad keine Datenbank, kein Admin-Login und kein Plugin-Ökosystem – der übliche Weg über eine verwundbare Erweiterung existiert damit nicht. Was bleibt und wirklich geprüft gehört: Rechte auf Repository und Build-Pipeline, Herkunft der npm-Abhängigkeiten, Formular- und API-Endpunkte, jede Route mit On-Demand-Rendering samt ihrer Laufzeitumgebung, ein Headless CMS als eigenes System mit eigener Anmeldung sowie Domain- und Hosting-Konten. Wir arbeiten mit Zwei-Faktor-Pflicht, minimalen Rechten und regelmäßigen Abhängigkeits-Updates.

Astro ist ein Framework und verarbeitet selbst keine personenbezogenen Daten – die Frage entscheidet sich an Hosting, Formularen, Analytics und CMS. Ein statischer Build lässt sich bei einem Anbieter in der EU oder in Deutschland betreiben. Schriften binden wir selbst ein statt über fremde Server, für Analytics gibt es Varianten ohne Cookies, und der Formular-Endpunkt wird bewusst gewählt statt mitgeliefert. Wir benennen jeden eingesetzten Dienstleister, damit Ihr Datenschutzbeauftragter die Verträge zur Auftragsverarbeitung schließen kann. Rechtsberatung leisten wir nicht; die Freigabe bleibt bei Ihnen. Mehr dazu: DSGVO-konforme Website.

Weil wir das lieber so sagen, als eine zu erfinden. Ein öffentlich zeigbares Astro-Kundenprojekt haben wir bislang nicht. Was wir haben: eine gebaute und betreute Webflow-Referenz, eigene Produkte, die wir selbst entwickelt und veröffentlicht haben, und Jahre Software-Entwicklung mit Repository, Continuous Integration und Betrieb. Das Framework ist der kleinere Teil dieser Arbeit. Prüfen können Sie uns günstig: Die Ersteinschätzung kostet nichts, das Repository gehört Ihnen ab Tag eins, und gemessen wird vor und nach dem Launch in Ihrem eigenen Projekt.

Ja. Astro ist quelloffene Software unter der MIT-Lizenz; für das Framework selbst fällt keine Lizenzgebühr und kein Sitzplatzpreis an, auch kommerziell nicht. Kosten entstehen bei Entwicklung, Inhalten, Hosting und Betrieb – und, falls Sie eines einsetzen, beim Headless CMS.

Ein quelloffenes Projekt, das öffentlich im Repository withastro/astro entwickelt wird. Die MIT-Lizenz weist das Copyright von 2021 auf Fred K. Schott aus. Gepflegt und weiterentwickelt wird Astro von einem Kernteam und einer Community aus Beitragenden, aktuell in der Astro-7-Linie.

Offizielle Integrationen gibt es für React, Preact, Svelte, Vue, SolidJS und Alpine.js. Mehrere davon dürfen auf derselben Seite vorkommen, allerdings nur innerhalb einer .astro-Datei – laut Dokumentation können nur Astro-Komponenten Komponenten aus mehreren Frameworks enthalten.

Ja, das ist einer der Fälle, für die es gebaut wurde. Beiträge liegen als Markdown, MDX oder Markdoc in einer Content Collection mit Zod-Schema, Abfragen laufen typsicher über getCollection(), und das eingebaute Caching ist ausdrücklich für Sammlungen mit tausenden Einträgen gedacht.

Der offizielle Name ist schlicht Astro. Gesucht wird trotzdem oft nach „Astro JS“ oder „Astro.js“, weil es ein JavaScript-Framework ist und viele Frameworks diese Schreibweise tragen. Gemeint ist dasselbe Projekt – ein Zusatz wie „Framework“ in der Suche spart Zeit, weil „Astro“ online stark von Astrologie-Angeboten belegt ist.