Start
Astro Agentur
Astro vs. Next.js

Astro · Vergleich

Astro vs. Next.js: Es entscheidet die Form Ihrer Seite – keine Punktetabelle.

Viele Astro-vs-Next.js-Vergleiche stammen von einer Partei mit Interesse am Ergebnis: vom Hersteller eines der beiden Frameworks oder von einem Anbieter, der etwas daneben verkauft. Wir bauen Websites mit Astro und Anwendungen mit React. Beide Frameworks stehen unter MIT-Lizenz – wir verdienen an keinem von beiden, sondern an der Umsetzung. Deshalb steht hier keine Punktewertung, sondern die eine Unterscheidung, die in echten Projekten trägt: Astro ist auf inhaltsgetriebene Websites ausgelegt, Next.js auf React-Anwendungen. Dazwischen liegt der Fall, den die meisten Teams tatsächlich haben.

Technologie-Einschätzung anfragen Direkt zur Vergleichstabelle

Beide im eigenen Stack

Wir bauen Websites mit Astro und Anwendungen mit React – neben Webflow, Flutter, React Native und SwiftUI. Wir haben kein Framework zu verteidigen.

Keine Sterne, keine Sieger

Wir beschreiben, was die beiden Frameworks unterschiedlich machen, statt Punkte zu vergeben. Die Entscheidung fällt an Ihrem Seitenaufbau, nicht an einer Tabelle.

Messung statt Benchmark

Fremde Benchmark-Zahlen sagen wenig über Ihre Seite. Wir messen Ihre Core Web Vitals vorher und nachher – mit Ihren eigenen Felddaten.

Kurz gesagt

Die kurze Antwort: Inhaltsgetriebene Website – Astro. Anwendung mit Login, Sitzungszustand und durchgehend interaktiver Oberfläche – Next.js. Für alles dazwischen entscheidet eine einzige Frage: Wie viel Ihrer Seite ist wirklich interaktiv?
Der technische Kern: Astro entfernt standardmäßig sämtliches Client-seitige JavaScript aus Komponenten; Interaktivität wird pro Komponente über eine client:*-Direktive aktiviert. Next.js baut auf React – Server Components verlagern viel auf den Server, ein Client-Anteil gehört aber zum Modell.
Was für Next.js spricht: ein größeres React-Ökosystem, eine deutlich breitere Personaldecke und alles, was mit Zustand, Sitzungen und Personalisierung zu tun hat. Das sind echte Vorteile, keine Höflichkeitsfloskeln.
Was für Astro spricht: statisches HTML als Standard-Auslieferung, ein typisiertes Content-Modell über Content Collections mit Zod, freie Wahl der UI-Bibliothek und ein Build, der auf jedem CDN liegen kann.
Es ist kein Entweder-oder: Marketing-Auftritt in Astro, Produkt in Next.js – über Subdomain oder Pfad getrennt – ist eine gängige und meist die ehrlichste Aufteilung. Wenn Sie migrieren wollen: Next.js zu Astro.

01 — Die Unterschiede

Astro und Next.js im direkten Vergleich.

Acht Dimensionen, in denen sich die beiden Frameworks tatsächlich unterscheiden – beschrieben, nicht bewertet. Kein Feld ist per se besser; jedes ist besser für etwas Bestimmtes.

Stand: August 2026. Astro-Angaben nach der offiziellen Dokumentation, aktuelle Major-Linie Astro 7.
Dimension	Astro	Next.js
Bester Einsatzbereich	Astro beschreibt sich selbst als „a JavaScript web framework optimized for building fast, content-driven websites“. Marketing-Auftritte, Blogs, Dokumentation, Landingpages, Katalog- und Referenzseiten.	React-Framework für Anwendungen: Oberflächen mit Login, Rollen, Zustand und Personalisierung. Websites kann es ebenfalls, es ist dafür aber nicht der schmalste Weg.
JavaScript in der Standard-Auslieferung	Standardmäßig entfernt Astro sämtliches Client-seitige JavaScript aus Komponenten. Es kommt nur dort hinzu, wo eine Komponente es ausdrücklich anfordert.	React ist die Grundlage der Seite. Server Components verschieben viel Arbeit auf den Server – sobald eine Komponente interaktiv wird, gehört ein Client-Runtime-Anteil zum Modell.
Rendering-Modell	MPA-Architektur mit Server-Rendering als Standard. Vorgerendert ist die Voreinstellung; einzelne Routen rendern on demand über `export const prerender = false`. `output: 'server'` dreht den Standard um. Client-seitiges Routing ist opt-in über den eingebauten `<ClientRouter />`.	Statisch, serverseitig und inkrementell revalidiert je Route. Nach dem ersten Laden navigiert die Anwendung clientseitig im React-Router – Zustand bleibt über Seitenwechsel erhalten.
UI-Schicht	Framework-agnostisch. Offizielle Integrationen für React, Preact, Svelte, Vue, SolidJS und Alpine.js. Mehrere davon lassen sich auf einer Seite kombinieren – aber nur innerhalb einer `.astro`-Datei.	React, fest gesetzt. Das ist eine Festlegung und zugleich eine Stärke: ein Modell, ein Ökosystem, ein Einarbeitungsweg für neue Teammitglieder.
Wie Interaktivität dazukommt	Pro Komponente über eine Direktive: `client:load` lädt sofort, `client:idle` wenn der Browser Luft hat, `client:visible` erst im Viewport. Server Islands rendern über `server:defer` serverseitig nach.	Im App Router sind Komponenten standardmäßig Server Components; `'use client'` markiert die Grenze, ab der eine Komponente im Browser läuft. Die Granularität ist ähnlich – die Voreinstellung des Gesamtbaums ist eine andere.
Hosting & Adapter	Ein statischer Build ist reines HTML und liegt auf jedem Webserver oder CDN. On-Demand-Rendering braucht einen Adapter für die Ziel-Laufzeit; offizielle First-Party-Adapter im `@astrojs`-Scope gibt es für Node, Vercel und Cloudflare.	Selbst betreiben als Node-Server oder auf serverlosen Plattformen. Das Framework wird vom Hosting-Anbieter Vercel entwickelt; die dichteste Integration bietet entsprechend dessen Plattform, Self-Hosting ist ausdrücklich vorgesehen.
Content-Modell	Eingebaut. Content Collections seit Astro 2.0: Schema-Definition über Zod, automatische TypeScript-Typen, Abfrage über `getCollection()`, eingebautes Caching für tausende Einträge. CMS-agnostisch, mit dokumentierten Guides für Storyblok, Sanity, Contentful, Payload, Directus, Keystatic und WordPress im Headless-Betrieb.	Nicht eingebaut. Inhalte kommen aus der Datenquelle oder Bibliothek Ihrer Wahl – MDX-Setup, Headless CMS, eigene Datenbank. Mehr Freiheit, entsprechend mehr Eigenbau und mehr Entscheidungen im Team.
Portabilität	Open Source unter MIT-Lizenz. Ergebnis eines Standard-Builds ist HTML – das läuft überall und lässt sich notfalls ohne Framework weiterbetreiben.	Ebenfalls Open Source unter MIT-Lizenz. Der Betrieb ist an eine Laufzeit gebunden, nicht an einen Anbieter; einzelne Betriebsarten sind auf Plattformen mit passender Infrastruktur aber deutlich bequemer.

02 — Entscheidung

Wann welches Framework die richtige Wahl ist.

Wenn Sie sich in einer der beiden Spalten überwiegend wiederfinden, ist die Entscheidung gefallen. Finden Sie sich in beiden wieder, lesen Sie den Abschnitt darunter – das ist der Normalfall.

Astro wählen, wenn …

Ihre Seite ist im Kern ein Publikationsmedium.

Der Großteil Ihrer Seiten ist Inhalt: Startseite, Leistungen, Referenzen, Blog, Stellenanzeigen, Landingpages.
Ladezeit und Core Web Vitals sind ein Geschäftsziel, weil Sie Sichtbarkeit über Suche und bezahlte Anzeigen einkaufen.
Sie wollen den größten Teil der Seite als statisches HTML ausliefern und nur einzelne Komponenten interaktiv machen – Konfigurator, Suche, Filter, Formular.
Inhalte sollen ein typisiertes, validiertes Modell haben statt lose Dateien: ein Tippfehler im Frontmatter soll den Build brechen, nicht die Live-Seite.
Ihr Team ist nicht auf React festgelegt – oder soll es bewusst nicht werden, weil auf der Seite Svelte, Vue oder gar keine UI-Bibliothek sinnvoller ist.
Hosting soll frei wählbar bleiben: Ein statischer Build braucht keine Laufzeit und liegt auf jedem CDN.

Next.js wählen, wenn …

Ihr Produkt ist im Kern eine Anwendung.

Es gibt Login, Rollen und Berechtigungen, und ein großer Teil der Oberfläche existiert nur für angemeldete Nutzer.
Zustand soll über Seitenwechsel hinweg erhalten bleiben: mehrstufige Formularstrecken, Warenkörbe, Dashboards, Editoren.
Sie haben bereits ein React-Team und eine React-Komponentenbibliothek. Das ist ein realer Vorteil und kein Sunk-Cost-Argument – bestehende Kompetenz ist Projektgeschwindigkeit.
Sie brauchen das Ökosystem in der Tiefe: Auth, Payment, Datenlayer, Tabellen, Formular- und Validierungsbibliotheken sind rund um React am dichtesten.
Personaldecke zählt: React-Entwicklerinnen und -Entwickler sind auf dem Markt schlicht häufiger als Astro-Spezialisten. Für ein Produkt mit langer Lebensdauer und wachsendem Team ist das ein hartes Argument.
Nahezu jede Route ist personalisiert, und Server-Rendering pro Anfrage ist die Regel, nicht die Ausnahme.

03 — Die Mitte

Der Normalfall liegt in der Mitte – und dafür gibt es einen Test.

Die wenigsten Projekte sind eine reine Broschüre oder eine reine Anwendung. Die meisten sind eine Website mit ein paar interaktiven Stellen – und genau dort wird die Entscheidung tatsächlich getroffen.

Nehmen Sie Ihre Seitenliste und markieren Sie jede Fläche, die nur funktioniert, wenn im Browser JavaScript läuft: Suche mit Sofortergebnissen, Preiskonfigurator, Terminbuchung, Warenkorb, Filter, Kartenansicht, interaktives Diagramm. Nicht markiert werden Dinge, die auch ohne JavaScript gehen – ein Navigationsmenü, ein Akkordeon, ein Formular, das serverseitig verarbeitet wird.

Ist der markierte Anteil klein und liegt er in wenigen, klar abgegrenzten Flächen, ist Astro die schlankere Antwort. Genau dafür ist die Islands Architecture gebaut: Eine Insel ist in der Dokumentation „an enhanced UI component on an otherwise static page of HTML“. Der Rest der Seite bleibt statisches HTML, und die interaktive Komponente bekommt ihr JavaScript über eine Direktive – client:visible etwa lädt sie erst, wenn sie in den Viewport kommt. Der Textabschnitt darüber bekommt nichts.

Zieht sich der markierte Anteil dagegen durch fast jede Ansicht, hängt an einem gemeinsamen Zustand oder an einer Sitzung, ist Next.js die schlankere Antwort. Dann kämpfen Sie mit Astro gegen das Framework: Jede Insel ist eine eigene Wurzel, und Zustand über viele Inseln hinweg zu teilen wird zur Konstruktion. Ein Framework, das die ganze Seite als Anwendung denkt, ist an dieser Stelle einfach ehrlicher.

React-Kompetenz geht nicht verloren

Ein verbreitetes Missverständnis: Wer zu Astro geht, wirft sein React-Wissen weg. Das Gegenteil ist der Fall. Astro ist UI-Framework-agnostisch und hat eine offizielle React-Integration – Ihre bestehenden React-Komponenten laufen als Inseln weiter. Auf einer .astro-Seite dürfen sogar mehrere UI-Frameworks nebeneinander stehen. Was wegfällt, ist nicht React, sondern die Voreinstellung, dass alles React ist.

Die dritte Option, über die zu selten geredet wird

Marketing-Auftritt und Produkt müssen nicht im selben Projekt liegen. Eine sehr häufige und meist saubere Aufteilung: Die öffentliche Website – Startseite, Leistungen, Preise, Blog, Karriere – läuft in Astro und wird von Marketing gepflegt. Die Anwendung hinter dem Login läuft in Next.js und wird vom Produktteam entwickelt, unter app.ihre-domain.de oder einem eigenen Pfad. Beide Teams arbeiten dann in ihrem eigenen Tempo und blockieren einander nicht. Wenn die Marketing-Seite heute im selben Next.js-Repository liegt und jeder Textänderung ein Produkt-Deploy folgt, ist das oft der eigentliche Anlass für den Wechsel – und nicht die Ladezeit.

Zu Performance sagen wir bewusst keine Zahl

Im Netz kursieren griffige Prozentangaben zu beiden Frameworks. Wir veröffentlichen keine davon, weil sie sich mit jedem Release und jedem Messlauf verschieben und über Ihre Seite nichts aussagen. Qualitativ lässt sich belastbar sagen: Eine Seite, die kein Client-JavaScript ausliefert, hat weniger auszuführen als eine, die welches ausliefert. Was das für Ihre Kennzahlen bedeutet, messen wir an Ihrem Projekt – Lighthouse im Labor und Ihre eigenen Felddaten aus der Chrome-User-Experience-Erhebung, vor und nach dem Umbau. Mehr dazu unter Astro-Performance-Optimierung.

Und der Punkt, der bei beiden Frameworks fehlt: Wer pflegt das später?

Ein Framework-Vergleich endet meistens beim Build. Der Betrieb fängt danach erst an. Wir setzen deshalb auf einen modernen KI-Stack obendrauf: Unsere Kundinnen und Kunden können ihre Website im Chat bearbeiten – zum Beispiel über einen Telegram-Bot. Text ändern, einen Blogbeitrag anlegen, ein Bild tauschen, einen Preis korrigieren: als Nachricht, nicht als CMS-Sitzung.

Technisch funktioniert das, weil Astro-Inhalte in einem typisierten, schema-validierten Content-Modell liegen – Content Collections mit Zod – oder in einem Headless CMS mit API. Beides ist maschinell adressierbar: Das Schema definiert, welche Felder es gibt und was gültig ist, und wirkt damit als Leitplanke. Ein Agent kann nur Felder füllen, die existieren, in Formaten, die validieren; ein fehlerhafter Eingriff scheitert im Build und nicht auf der Live-Seite. Jede Änderung landet als nachvollziehbarer Commit mit Deploy – mit Historie, Review-Möglichkeit und Rollback. Das passt für Konzerne mit Redaktionsteam genauso wie für Einzelunternehmer und KMU, die nie ein CMS öffnen werden: Wer eine Sprachnachricht schicken kann, kann seine Website pflegen. Dass Chat-Agenten bei uns Tagesgeschäft sind und nicht Folienware, belegt unser eigener WhatsApp-KI-Agent.

Die Grenzen gehören dazu: Der Chat-Weg ersetzt kein Redaktionssystem für große Teams mit mehrstufigen Freigaben – er ergänzt es. Redaktionelle Verantwortung bleibt bei Ihnen; ein Agent schlägt vor und schreibt, er entscheidet nicht. Strukturelle Änderungen – neue Seitentypen, Layout, Navigation – bleiben Entwicklungsarbeit. Und der Umfang wird pro Projekt festgelegt: welche Collections, welche Felder, welche Freigabestufe. Ausführlich beschrieben unter Website per Chat pflegen.

Der Test in einem Satz

Markieren Sie jede Fläche, die ohne Browser-JavaScript nicht funktioniert. Wenige Flächen: Astro. Fast überall: Next.js.

Kein Framework-Wechsel nötig

React-Komponenten laufen in Astro als Inseln weiter. Es gibt eine offizielle React-Integration – Ihr Team muss nichts neu lernen, um loszulegen.

Beides ist erlaubt

Website in Astro, Anwendung in Next.js, getrennt über Subdomain. Zwei Teams, zwei Deploy-Rhythmen, keine gegenseitige Blockade.

Wenn es doch eine App ist

Bei echter Anwendungslogik bauen wir Ihnen lieber gleich eine individuelle Web-Anwendung – und sagen das vorher.

04 — Wechsel

Wenn Sie von Next.js zu Astro wechseln: die Realität.

Ein Frameworkwechsel ist ein Umbau, kein Knopfdruck. Was Sie erwartet, wenn eine bestehende Next.js-Seite nach Astro umzieht – inklusive der Punkte, die üblicherweise unterschätzt werden:

Es gibt einen offiziellen Migrations-Pfad – Die Astro-Dokumentation führt Next.js in ihrer Liste der Migrations-Guides. Das erspart Ihnen das Erfinden des Vorgehens – ersetzt aber keine Projektplanung. Die Docs weisen selbst darauf hin, dass ein Teil der Migrationsseiten knapp gehalten ist.
Routen und Layouts werden übersetzt, nicht kopiert – Datei-basiertes Routing gibt es in beiden Frameworks, die Konventionen unterscheiden sich aber. Jede Route bekommt eine Entscheidung: vorgerendert oder on demand. Genau diese Entscheidung ist der Kern des Umbaus.
React-Komponenten bleiben – die Frage ist, welche – Interaktive Komponenten ziehen als Inseln um. Alles, was nur Markup produziert, wird sinnvollerweise zu .astro-Komponenten umgeschrieben: Genau da entsteht die Einsparung an ausgeliefertem JavaScript. Diese Sortierung ist die eigentliche Handarbeit.
Datenzugriff wird neu verdrahtet – Server-seitiger Datenzugriff, Umgebungsvariablen, API-Routen und Bildpipeline müssen auf Astro-Äquivalente umgestellt werden. Für die Bilder bringt Astro eigene Komponenten mit, die alt, loading und decoding setzen und die Maße ableiten, damit kein Layout-Shift entsteht.
SEO ist der kritische Pfad, nicht die Optik – URLs, Redirects, kanonische Angaben, hreflang, strukturierte Daten und Sitemap gehören vor den Go-live geprüft. Ein Frameworkwechsel darf an den Adressen nichts ändern – und wenn doch, dann geplant und mit vollständiger Weiterleitungskarte.
Was es kostet, hängt an der Anzahl der Seitentypen – Nicht an der Anzahl der Seiten. Zwanzig Blogbeiträge derselben Vorlage sind ein Seitentyp; zwanzig individuell gebaute Landingpages sind zwanzig. Wir zählen im Erstgespräch die Seitentypen und die interaktiven Flächen – daraus wird der Rahmen, nicht aus einer Pauschale.
Wann Sie besser bleiben – Wenn Ihre Next.js-Seite technisch gesund ist, das Team damit produktiv arbeitet und die Ladezeit Ihre Ziele erfüllt, gibt es keinen Grund zu wechseln. Ein Umbau ohne Anlass ist verbranntes Budget. Wir sagen Ihnen das im Erstgespräch, bevor Sie ein Angebot bekommen.

Detailseite

Ablauf, Zeitrahmen und Prüfschritte im Detail: Next.js zu Astro migrieren.

Vorher messen

Wir nehmen Ihre Core Web Vitals und Ihre Rankings vor dem Umbau auf – sonst lässt sich hinterher nicht belegen, ob sich etwas verbessert hat.

Begleitung statt Übergabe

Größere Umbauten begleiten wir auf Wunsch als IT-Projektleitung, wenn Ihr internes Team einen Teil selbst umsetzt.

Andere Ausgangslage?

Auch Astro vs. Webflow und Astro vs. WordPress haben wir nach demselben Muster aufgeschrieben. Alles Weitere im Überblick: Astro Agentur.

05 — Zeitrahmen

Wie lange ein Wechsel realistisch dauert.

Preise stehen nicht auf dieser Seite – die bekommen Sie als nachvollziehbare Schätzung nach dem Erstgespräch. Über Zeit lässt sich dagegen vorher reden. Die folgenden Spannen sind unsere eigene Einschätzung für unsere Arbeitsweise, gerechnet von der Bestandsaufnahme bis zum Go-live – keine Branchenzahl und keine Zusage:

Nur die Entscheidung: wenige Tage bis eine Woche – Wenn Sie zunächst wissen wollen, welches Framework passt, brauchen wir Ihre Seitenliste, einen Blick in die bestehende Seite und ein Gespräch. Die schriftliche Einschätzung liegt in der Regel innerhalb einer Woche vor – mit Begründung und ausdrücklich auch mit der Option „bleiben Sie, wo Sie sind“.
Überschaubaren Marketing-Auftritt aus einem Next.js-Projekt lösen: 4 bis 7 Wochen – Bis zu etwa sechs eigenständige Seitentypen, Inhalte werden übernommen statt neu geschrieben, kein CMS, eine Sprache, gängige Integrationen wie Analytics, Consent und Formular. Enthalten sind Seitentyp-Inventar, Umbau, URL- und Weiterleitungskarte, Abnahme im Staging und der Go-live selbst.
Gewachsener Auftritt mit Archiv, CMS oder mehreren Sprachen: 8 bis 14 Wochen – Acht bis fünfzehn Seitentypen, angebundenes Headless CMS, zwei Sprachfassungen samt hreflang-Logik, mehrere Routen mit On-Demand-Rendering. Ein Blog-Archiv mit tausenden Beiträgen fällt hier hinein, ebenso ein Shop-, Buchungs- oder Suchsystem mit eigener Laufzeit. Alles darüber schneiden wir in Phasen, statt einen Termin zu behaupten.
Was die Spanne bewegt – und was nicht – Nicht die Anzahl der Seiten. Sondern: die Anzahl eigenständiger Seitentypen; ob Inhalte migriert oder redaktionell neu geschrieben werden; ob ein CMS dazukommt und wer es befüllt; die Anzahl der Sprachen; jede Integration mit eigener Laufzeit; und die Freigabezyklen auf Ihrer Seite. Zwei Abstimmungsrunden pro Vorlage sind Wochen, nicht Tage – das ist der am häufigsten unterschätzte Posten.
Der Umschaltmoment selbst ist kurz – Gebaut wird parallel: Ihre bestehende Next.js-Seite bleibt online, bis die neue Fassung im Staging abgenommen ist. Umgeschaltet wird über DNS beziehungsweise Hosting-Konfiguration, die Weiterleitungskarte geht zeitgleich live. Wir legen das Fenster außerhalb Ihrer Hauptlastzeiten und rechnen mit den üblichen DNS-Laufzeiten – nicht mit null Minuten.
Nach dem Go-live: 8 bis 12 Wochen Beobachtung – Suchmaschinen brauchen Zeit, bis sie eine umgezogene Seite vollständig neu erfasst haben. Wir prüfen deshalb Indexierung, Weiterleitungen, strukturierte Daten und Positionen in diesem Zeitraum fortlaufend und korrigieren, was auffällt. Ein Versprechen, dass sich keine einzige Position bewegt, geben wir nicht – Bewegung ist bei jedem Umzug normal.

Ablauf im Detail

Schritte, Prüfpunkte und Übergabe stehen auf der Migrationsseite: Next.js zu Astro migrieren.

Was den Preis treibt

Dieselben Variablen, die die Zeit bewegen, bewegen das Budget. Wie wir rechnen, steht unter Astro-Kosten.

Und danach?

Wer Updates, Monitoring und kleine Änderungen übernimmt, klären wir vor dem Go-live – siehe Astro-Support und Wartung.

06 — Auf einen Blick

Astro vs. Next.js auf einen Blick.

Die Kurzfassung dieser Seite in einer Tabelle – beschreibend, nicht bewertend. Die letzte Zeile ist unsere Meinung, klar als solche gekennzeichnet.

Kriterium	Kurzfassung
Worum es im Kern geht	Astro ist ein Framework für inhaltsgetriebene Websites, Next.js ein React-Framework für Anwendungen. Die Frage lautet nicht, welches besser ist, sondern welche Art von Seite Sie bauen.
Standard-Auslieferung	Astro: statisches HTML, Client-JavaScript nur dort, wo eine Komponente es über eine `client:*`-Direktive anfordert. Next.js: React als Grundlage der Seite; Server Components verlagern viel auf den Server, ein Client-Anteil gehört zum Modell.
UI-Bibliothek	Astro ist framework-agnostisch – offizielle Integrationen für React, Preact, Svelte, Vue, SolidJS und Alpine.js. Next.js ist auf React festgelegt; das ist zugleich seine Stärke: ein Modell, ein Ökosystem, ein Einarbeitungsweg.
Inhalte	Astro bringt Content Collections mit Zod-Schema, TypeScript-Typen und eingebautem Caching mit. Next.js bringt kein Content-Modell mit – Sie wählen Bibliothek, CMS oder Datenbank selbst und bauen die Anbindung.
Betrieb und Hosting	Ein statischer Astro-Build liegt auf jedem Webserver oder CDN; On-Demand-Rendering braucht einen Adapter (Node, Vercel, Cloudflare). Next.js läuft als Node-Server oder serverlos; entwickelt wird es vom Hosting-Anbieter Vercel, Self-Hosting ist ausdrücklich vorgesehen.
Lizenz	Beide sind quelloffen unter MIT-Lizenz. Für keines der beiden Frameworks zahlen Sie Lizenzgebühren – Kosten entstehen durch Entwicklung, Hosting und Betrieb.
Personalmarkt	React-Entwicklerinnen und -Entwickler sind auf dem Markt deutlich häufiger als Astro-Spezialisten. Wer React kann, arbeitet sich in Astro schnell ein – der größere Markt bleibt trotzdem ein echtes Argument für Next.js.
Aufwand für einen Wechsel	Überschaubarer Marketing-Auftritt: 4 bis 7 Wochen. Gewachsener Auftritt mit Archiv, CMS oder mehreren Sprachen: 8 bis 14 Wochen. Ablauf, Prüfschritte und Kostenlogik stehen unter Next.js zu Astro migrieren.
Unsere Einschätzung	Für alles, was in erster Linie gelesen wird, würden wir heute Astro nehmen – wegen der Voreinstellung, nicht wegen fremder Benchmarks: Was nicht ausgeliefert wird, muss auch nicht ausgeführt werden. Für alles hinter einem Login würden wir Next.js nehmen und darüber nicht lange diskutieren. Und im häufigsten Fall – Website plus Produkt – würden wir beides nehmen und sauber trennen. Wer Ihnen ohne Blick auf Ihre Seitenliste einen Sieger nennt, verkauft Ihnen sein Standardvorgehen.

07 — FAQ

Häufige Fragen zu Astro vs. Next.js.

Ist Astro schneller als Next.js?

Bei einer inhaltsgetriebenen Seite in der Regel ja – aber nicht, weil das eine Framework besser programmiert wäre, sondern wegen einer Voreinstellung: Astro entfernt standardmäßig sämtliches Client-seitige JavaScript aus Komponenten, Next.js liefert React als Grundlage der Seite mit. Weniger auszuführendes JavaScript heißt tendenziell bessere Werte. Bei einer interaktiven Anwendung verschwindet dieser Vorteil, weil die Interaktivität ohnehin gebraucht wird. Belastbar ist nur die Messung an Ihrer Seite.

Können wir unsere React-Komponenten in Astro weiterverwenden?

Ja. Astro ist UI-Framework-agnostisch und hat eine offizielle React-Integration; bestehende Komponenten laufen als Inseln weiter und bekommen ihr JavaScript über eine Direktive. Innerhalb einer .astro-Datei dürfen sogar Komponenten mehrerer Frameworks nebeneinander stehen. Sinnvoll ist trotzdem, rein darstellende Komponenten in .astro-Komponenten zu überführen – genau dort entsteht die Einsparung an ausgeliefertem JavaScript.

Kann Astro auch Server-Rendering und dynamische Routen, oder nur statische Seiten?

Beides. Vorgerendert ist die Voreinstellung: Standardmäßig wird die gesamte Seite vorgerendert und als statisches HTML ausgeliefert. Einzelne Routen rendern on demand über export const prerender = false; mit output: server dreht sich der Standard um und einzelne Seiten kommen mit prerender = true zurück. On-Demand-Rendering braucht einen Adapter für die Ziel-Laufzeit – offizielle gibt es für Node, Vercel und Cloudflare.

Astro oder Next.js für SEO – gibt es einen Unterschied?

Bei der Indexierbarkeit kaum: Beide liefern serverseitig gerendertes HTML aus, Crawler sehen in beiden Fällen fertigen Inhalt. Der Unterschied liegt bei den Core Web Vitals, weil die ausgelieferte JavaScript-Menge auf Interaktivitäts- und Ladezeitwerte durchschlägt. Größer als der Framework-Unterschied ist allerdings fast immer der Unterschied in Informationsarchitektur, interner Verlinkung und Inhalt. Ein Frameworkwechsel ersetzt keine SEO-Arbeit.

Lohnt sich der Wechsel von Next.js zu Astro?

Nur mit Anlass. Gute Anlässe: Die Marketing-Seite liegt im Produkt-Repository und jede Textänderung braucht einen Produkt-Deploy; die Seite ist fast ausschließlich Inhalt, liefert aber die volle Anwendungs-Laufzeit aus; die Betriebskosten für serverseitiges Rendern stehen in keinem Verhältnis zum Inhalt. Kein guter Anlass: Ein Framework ist gerade populär. Läuft Ihre Seite gut, bleiben Sie. Details unter „Next.js zu Astro migrieren“.

Finden wir langfristig Entwickler und Wartung für Astro?

Der React-Arbeitsmarkt ist deutlich größer – das ist ein realer Vorteil von Next.js und sollte in die Entscheidung eingehen. Auf der anderen Seite: Astro steht unter MIT-Lizenz, folgt Semantic Versioning und pflegt jeweils eine vorherige Major-Version mit Sicherheits-Fixes weiter; die aktuelle Linie ist Astro 7. Und wer React kann, kommt in Astro schnell zurecht, weil die React-Komponenten dieselben bleiben.

Können wir die Website später wirklich per Chat pflegen?

Ja, in einem definierten Rahmen. Weil Astro-Inhalte in einem typisierten, Zod-validierten Content-Modell oder in einem Headless CMS mit API liegen, kann ein Agent sie strukturiert schreiben: Text ändern, Beitrag anlegen, Bild tauschen, Preis korrigieren – als Nachricht, etwa über einen Telegram-Bot. Jede Änderung wird ein nachvollziehbarer Commit mit Deploy. Strukturelle Änderungen bleiben Entwicklungsarbeit, und welche Felder freigegeben sind, legen wir pro Projekt fest.

„Unser Produktteam arbeitet seit Jahren mit React. Müssen wir das aufgeben, wenn die Website auf Astro läuft?“

Nein. Astro ist UI-Framework-agnostisch und hat eine offizielle React-Integration – Ihre Komponenten laufen dort als Inseln weiter, und die Anwendung hinter dem Login bleibt ohnehin, wo sie ist. Was sich ändert, ist die Voreinstellung: Nicht mehr alles ist React, sondern nur noch das, was Interaktivität braucht. Für ein React-Team ist das eine Umgewöhnung von Tagen, kein Umlernen. Die eigentliche Arbeit ist die Sortierung, welche Komponente Insel bleibt und welche zur .astro-Komponente wird.

„Wir haben 4.000 Blogbeiträge. Wie lange dauert die Umstellung, und gibt es dabei eine Downtime?“

Die Anzahl der Beiträge ist selten das Problem: Vier Vorlagen für 4.000 Beiträge sind vier Seitentypen, und Content Collections sind ausdrücklich mit eingebautem Caching für tausende Einträge dokumentiert. Aufwand macht der Zustand der Inhalte – uneinheitliches Markup, eingebettete Komponenten, alte Bildpfade. Für einen Auftritt dieser Größe planen wir eher 8 bis 14 Wochen. Gebaut wird parallel, die alte Seite bleibt bis zur Abnahme online, umgeschaltet wird in einem geplanten Fenster mit fertiger Weiterleitungskarte.

„Wir sind mit unserem Hosting zufrieden. Zwingt uns Astro zu einem Wechsel?“

Nein. Ein statischer Astro-Build ist reines HTML und liegt auf jedem Webserver oder CDN – auch auf dem, den Sie heute nutzen. Nur On-Demand-Rendering braucht einen Adapter für die Ziel-Laufzeit; offizielle First-Party-Adapter gibt es für Node, Vercel und Cloudflare. Wenn Ihre Next.js-Anwendung heute auf Vercel läuft und das gut funktioniert, kann die Astro-Seite dort ebenfalls bleiben. Das ist eine Betriebsentscheidung, keine Framework-Entscheidung.

„Unser Marketing will publizieren, ohne auf Entwickler zu warten. Reicht Astro dafür?“

Nur mit einem Aufsatz. Astro selbst bringt kein Redaktions-Frontend mit; Inhalte liegen in Content Collections oder in einem angebundenen Headless CMS. Praktikabel sind drei Wege: ein Headless CMS mit Redaktionsoberfläche, ein Git-basiertes CMS oder unser Chat-Weg über einen Telegram-Bot. Wenn redaktionelle Autonomie Ihr wichtigstes Kriterium ist und niemand im Haus mit Deployments zu tun haben will, ist Webflow oft die ehrlichere Antwort – das bauen wir ebenfalls.

„Wir brauchen personalisierte Inhalte für angemeldete Nutzer. Schließt das Astro aus?“

Nicht automatisch. Astro kennt Server Islands: dynamische Komponenten, die über server:defer serverseitig unabhängig gerendert werden. Seitenhülle und Hauptinhalt lassen sich dadurch aggressiv cachen, während das personalisierte Element nachlädt, ohne das erste Rendering zu blockieren. Für Begrüßungsname, Warenkorbzähler oder Empfehlungsblock reicht das gut. Wenn dagegen nahezu jede Route personalisiert ist und alles an einer Sitzung hängt, ist Next.js der schlankere Weg.

„Können wir schrittweise wechseln, statt alles auf einmal umzustellen?“

Ja, bei größeren Auftritten ist das oft der ruhigere Weg. Üblich ist eine Trennung nach Pfad oder Subdomain: Blog oder Landingpages ziehen zuerst nach Astro, der Rest bleibt vorerst in Next.js, und ein Reverse Proxy oder die Hosting-Konfiguration verteilt die Anfragen. Das kostet für die Übergangszeit etwas Betriebskomplexität und verlangt eine saubere Weiterleitungsplanung – senkt aber das Risiko deutlich gegenüber einer Umstellung in einer Nacht.

„Was passiert, wenn Sie ausfallen oder wir uns trennen? Können wir intern weiterarbeiten?“

Ja. Repository, Hosting-Konten und Domains laufen von Anfang an auf Sie – wir arbeiten darin, wir besitzen es nicht. Was entsteht, ist ein Standard-Astro-Projekt unter MIT-Lizenz ohne proprietäre Zwischenschicht: übliche Konventionen, dokumentierte Struktur, keine Blackbox. Wer React kennt, liest sich darin an einem Tag ein. Zur Übergabe gehören ein Setup-Dokument und auf Wunsch eine gemeinsame Sitzung mit Ihrem Team.

„Wer haftet, wenn nach dem Launch etwas nicht funktioniert?“

Was wir liefern, verantworten wir. Vor dem Go-live halten wir schriftlich fest, was als Fehler gilt und in welcher Frist wir reagieren; die vertraglichen Regelungen dazu stehen im Angebot, nicht in einer FAQ. Technisch arbeiten wir so, dass Fehler früh auffallen: Abnahme im Staging, Prüfliste für URLs, Weiterleitungen, Meta-Daten und strukturierte Daten – und jede Änderung als eigener Commit mit Deploy-Historie, sodass ein Rollback Minuten dauert.

„Was kostet die Entscheidung, und was kostet der Wechsel?“

Die Ersteinschätzung stellen wir nicht in Rechnung. Für den Umbau nennen wir hier bewusst keine Pauschale, weil sie ohne Ihre Seitenliste geraten wäre. Die Kostentreiber sind dieselben wie die Zeittreiber: Anzahl eigenständiger Seitentypen, Anzahl interaktiver Flächen, ob Inhalte migriert oder neu geschrieben werden, CMS ja oder nein, Sprachen und Integrationen. Nach dem Erstgespräch bekommen Sie eine Schätzung, in der jede Position einzeln benannt ist.

Ist Astro kostenlos?

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz. Lizenzgebühren fallen nicht an – auch nicht für Next.js, das ebenfalls unter MIT-Lizenz steht. Kosten entstehen durch Entwicklung, Hosting und Betrieb, nicht durch das Framework selbst.

Braucht Astro einen Server?

Für eine vorgerenderte Seite nicht: Standardmäßig wird die gesamte Seite vorgerendert und als statisches HTML ausgeliefert, das auf jedem Webserver oder CDN liegen kann. Erst On-Demand-Rendering braucht eine Laufzeit und einen passenden Adapter – offizielle gibt es für Node, Vercel und Cloudflare.

Was ist die Islands Architecture?

Astro hat den Begriff geprägt: eine komponentenbasierte Web-Architektur für inhaltsgetriebene Websites. Eine Insel ist laut Dokumentation „an enhanced UI component on an otherwise static page of HTML“ – der Großteil der Seite bleibt statisches HTML, interaktive Komponenten kommen nur dort hinzu, wo sie gebraucht werden.

Welche Astro-Version ist aktuell?

Die aktuelle Major-Linie ist Astro 7. Astro folgt Semantic Versioning, und Extended Maintenance mit Sicherheits-Fixes gibt es für genau eine vorherige Major-Version. Für Sie heißt das: Upgrades sind planbar, gehören aber eingeplant – Astro veröffentlicht Major-Versionen in kurzer Folge.

Wer entwickelt Next.js?

Next.js wird vom Hosting-Anbieter Vercel entwickelt und steht unter MIT-Lizenz. Entsprechend bietet dessen Plattform die dichteste Integration, Self-Hosting als Node-Server ist ausdrücklich vorgesehen. Astro ist ebenfalls quelloffen unter MIT-Lizenz und wird öffentlich im withastro-Repository auf GitHub entwickelt.

Kann man Astro und Next.js zusammen betreiben?

Ja, und das ist häufiger als gedacht: Website in Astro, Anwendung in Next.js, getrennt über Subdomain oder Pfad. Zwei Repositories, zwei Deploy-Rhythmen, keine gegenseitige Blockade. Nötig sind dafür eine einheitliche Navigation, ein gemeinsames Design-System und saubere kanonische Angaben.

Unsicher, welche Seite Sie eigentlich haben?

Schicken Sie uns Ihre Seitenliste oder die URL Ihres bestehenden Auftritts. Sie bekommen eine begründete Einschätzung, ob Astro, Next.js oder eine Aufteilung passt – und was uns zu dieser Einschätzung bringt. Auch wenn die Antwort „bleiben Sie, wo Sie sind“ lautet.

Einschätzung anfordern

Eine Framework-Entscheidung ohne Verkaufsinteresse.

Beschreiben Sie Ihr Vorhaben in drei Sätzen – Sie bekommen eine begründete Empfehlung für Astro, Next.js oder eine saubere Aufteilung. In der Regel innerhalb von 24 Stunden.

Technologie-Einschätzung anfragen

08 — Vertiefen