Astro vs Next.js: Welches Framework für Unternehmenswebsites?

Die kurze Antwort

Nimm Astro, wenn deine Website Inhalte ausliefert: Startseite, Leistungen, Referenzen, Wissen-Artikel, Landingpages, Karriere. Nimm Next.js, sobald App-Logik dazukommt, also ein geschützter Login-Bereich, Daten die sich laufend ändern, oder Inhalte, die der Server für jeden Besucher pro Anfrage neu zusammensetzt. Zwischen diesen beiden Fällen liegt kein Graubereich, den du mit Geschmack füllen müsstest.

Unser Default für B2B-Websites ist Astro mit Sanity als Content-Datenbank, also einem Redaktionssystem ohne eigenes Frontend, das Inhalte über eine Schnittstelle ausliefert. Next.js setzen wir ein, sobald Login, Echtzeit-Daten oder serverseitige Daten pro Anfrage nötig sind. Wir arbeiten mit beidem im Tagesbetrieb: in-sync.io selbst läuft auf Next.js, leanwave.com auf Astro.

Beide Frameworks geben dir vollen Zugriff auf Rendering, strukturierte Daten, Sitemap und Caching. Für Google und für KI-Crawler ist genau das entscheidend, und darin unterscheiden sie sich nicht. Sie unterscheiden sich in dem, was der Browser herunterladen muss, und in dem, was der Server zur Laufzeit noch leisten kann.

Was Astro und Next.js sind

Beide sind JavaScript-Frameworks für Websites, beide erzeugen HTML, beide laufen auf Hosting-Plattformen wie Vercel. Ab da trennen sich die Wege, und zwar an der Frage, wann das HTML entsteht und wie viel Code danach noch im Browser arbeitet.

Astro: HTML beim Bauen, JavaScript nur für Inseln

Astro, oft als Astro JS geschrieben, erzeugt deine Seiten beim Bauen als fertiges HTML und legt sie als Dateien ab. Interaktive Elemente wie ein Suchfeld, ein Preisrechner oder ein Karussell werden als Islands ausgeliefert, also als einzelne interaktive Inseln in einer ansonsten statischen Seite, die ihr JavaScript selbst mitbringen und unabhängig voneinander starten. Alles andere bleibt reines HTML. Du kannst Komponenten aus React, Vue, Svelte oder Solid in derselben Seite mischen, weil Astro sie nur zum Rendern benutzt.

Next.js: React mit voller Laufzeitumgebung

Next.js ist ein React-Framework mit Server-Rendering (das HTML entsteht auf dem Server bei der Anfrage), statischem Build, React Server Components und einer vollen Laufzeitumgebung. Dahinter läuft ein Server-Prozess, der Sitzungen verwalten, Datenbanken abfragen, Formulare entgegennehmen und API-Routen bereitstellen kann, also eigene Schnittstellen für andere Systeme. Damit baust du keine Website mehr, sondern eine Anwendung, die auch als Website funktioniert.

Astro vs Next.js: zehn Kriterien im direkten Vergleich

Die folgende Tabelle vergleicht beide Frameworks entlang der Punkte, die in unseren Projekten tatsächlich den Ausschlag geben. Sie ersetzt keine Architektur-Entscheidung, aber sie zeigt, wo die Unterschiede liegen.

Ausgeliefertes JavaScript und Performance

Astro liefert für statische Inhalte standardmäßig 0 KB JavaScript aus. Skripte laden nur dort, wo du eine Insel platzierst. Next.js schickt die React-Laufzeit mit, auch wenn die Seite am Ende nur Text und Bilder zeigt. Das ist kein Fehler von Next.js, sondern der Preis für eine Umgebung, die im Browser weiterarbeitet.

Wie groß der Unterschied in der Praxis ausfällt, siehst du an unserer eigenen Messung vom 13.09.2026. leanwave.com, das wir statisch mit Astro bauen, lädt auf der Startseite rund 39 KB JavaScript in drei Dateien. Eine unserer Webflow-Kundenseiten lädt an derselben Stelle rund 740 KB in dreizehn Dateien. Wir nennen bewusst keine PageSpeed-Werte dazu, weil die vom Messzeitpunkt und vom Testgerät abhängen. Weniger JavaScript heißt weniger Arbeit für das Endgerät, und das schlägt direkt auf die Core Web Vitals durch, also auf Googles Messwerte für Ladeverhalten und Stabilität.

Ein sauber gebautes Next.js-Projekt kann ebenfalls sehr schnell sein. Es braucht dafür nur mehr Disziplin: Server Components statt Client-Komponenten, Bundles im Blick behalten, Bibliotheken sparsam einsetzen. Bei Astro ist der sparsame Zustand die Voreinstellung, bei Next.js ist er eine Entscheidung, die dein Team in jedem Sprint neu treffen muss.

Rendering-Modelle im Vergleich

Rendering heißt: Wann entsteht das HTML, das Browser und Crawler sehen. SSG steht für Static Site Generation, also fertiges HTML beim Bauen. SSR steht für Server Side Rendering, also HTML, das der Server bei jeder Anfrage erzeugt.

Astro kann beides und lässt dich pro Seite entscheiden. Eine Leistungsseite wird statisch, eine Suchergebnisseite serverseitig. Der Normalfall bleibt statisch, und statisch heißt: ausliefern ohne Rechenaufwand, überall im CDN, keine Abhängigkeit von einem laufenden Prozess. Der Preis ist der Rebuild. Ändert die Redaktion einen Text, läuft ein neuer Build, bei LeanWave ausgelöst per Webhook, also einem automatischen Aufruf, den Sanity bei jeder Änderung absetzt.

Next.js legt noch zwei Modelle obendrauf. ISR erneuert einzelne Seiten nach Ablauf einer Frist, ohne die ganze Website neu zu bauen. React Server Components rendern Komponenten auf dem Server und schicken nur das Ergebnis an den Browser. Beides ist stark, sobald du viele Seiten hast, die sich unabhängig voneinander ändern, oder Inhalte pro Nutzer unterschiedlich aussehen. Für eine Marketing-Website mit dreißig bis zweihundert Seiten brauchst du das selten.

Content und CMS-Anbindung

Beide Frameworks arbeiten mit einem Headless-CMS, also einem Redaktionssystem, das Inhalte nur als Daten ausliefert und kein eigenes Design vorgibt. Wir nutzen dafür Sanity. Das Content-Modell, die Abfragen und das Rendering liegen dabei im Code, nicht in einer Oberfläche, die dir Grenzen setzt.

Bei Astro holt der Build die Inhalte einmal ab und schreibt daraus Dateien. Bei Next.js kannst du zusätzlich pro Anfrage abfragen, was du brauchst, wenn ein Inhalt immer aktuell sein muss. In beiden Fällen steuerst du die ganze Kette programmatisch: Content-Modell, Templates, Rendering, Schema, Sitemap, interne Verlinkung und Deploy. KI-Agenten können über die API und über einen MCP-Server, also eine standardisierte Schnittstelle für KI-Werkzeuge, Inhalte anlegen und prüfen.

Das ist kein Alleinstellungsmerkmal gegenüber Baukästen: Webflow, Wix, Contentful und Storyblok haben ebenfalls offizielle MCP-Server und APIs. Der Unterschied liegt woanders, nämlich bei Item- und Collection-Limits, bei Template-Grenzen (ein Template hängt an einer Collection), bei API-Rate-Limits und beim fehlenden Zugriff auf Rendering, Caching, Schema-Logik und interne Verlinkung im Code. Wie sich das gegen Webflow und Wix Studio verhält, haben wir im großen Plattform-Vergleich aufgeschrieben. Wichtig bleibt in beiden Frameworks: Programmatisch erzeugte Seiten brauchen echte Substanz pro Seite, sonst wertet Google sie als Doorway-Pages ab, also als Seiten, die nur existieren, um ein Keyword abzudecken. Das haben wir auf unserer alten Website selbst erlebt.

Interaktivität und wo Astro an Grenzen stößt

Astro deckt jede Form von Interaktivität ab, die sich auf einer Seite abspielt. Formular mit Validierung, Filter über einer Liste, Animation beim Scrollen, ein 3D-Element: alles machbar, als Insel eingebunden, den Rest der Seite kostet es nichts. Unsere Animationsprojekte laufen genau so.

Die Grenze liegt beim geteilten Zustand über Seitenwechsel hinweg. Ein Warenkorb, der über fünf Seiten mitläuft. Ein Kundenportal mit Rechten und Rollen. Eine Oberfläche, in der Nutzer Daten anlegen und sofort gespiegelt sehen. Sobald du dafür anfängst, in Astro eine eigene Zustandsverwaltung und einen eigenen Server-Teil zu bauen, baust du Next.js nach, nur ohne dessen Werkzeuge. Das ist der Punkt, an dem wir wechseln.

Zweiter Grenzfall: personalisierte Inhalte pro Anfrage. Wenn jeder Besucher etwas anderes sieht, weil er eingeloggt ist oder aus einem bestimmten Land kommt, verliert der statische Build seinen Vorteil. Astro kann serverseitig rendern, aber dann vergleichst du es mit Next.js auf dessen Heimspielfeld, und dort hat Next.js die reifere Werkzeugkiste.

SEO- und GEO-Hebel: hier nehmen sich beide nichts

Rendering, strukturierte Daten, Sitemap, hreflang und Caching steuerst du in Astro und in Next.js gleichermaßen im Code. Beide liefern HTML aus, das Crawler ohne JavaScript-Ausführung lesen können. Kein Framework rankt von sich aus, beide geben dir jeden Hebel, den Google und KI-Crawler lesen.

Konkret heißt das: Schema-Auszeichnung wie FAQPage oder Organization erzeugst du aus denselben Daten, aus denen du die Seite baust. Die Sitemap entsteht automatisch aus deinen Routen. hreflang, also die Auszeichnung, welche Sprachversion für welches Land gilt, setzt du wechselseitig inklusive x-default. Eine llms.txt, also eine maschinenlesbare Übersicht deiner Inhalte für KI-Systeme, legst du in beiden Frameworks als Route an. Canonical-Angaben, die Google sagen, welche URL die maßgebliche ist, gehören in beiden ins Template. Mehr dazu im technischen SEO und in unserer Einordnung zu Generative Engine Optimization.

Der eine Unterschied mit SEO-Wirkung ist indirekt: Weniger ausgeliefertes JavaScript verbessert die Ladewerte auf schwachen Geräten, und Ladewerte sind ein Rankingfaktor unter vielen. Das ist ein Vorteil für Astro, aber kein Argument, das eine fehlende Portal-Funktion aufwiegt.

Team und Lernkurve

Astro ist für Entwickler zugänglich, die HTML, CSS und etwas JavaScript können. Die Komponenten-Syntax liegt nah an HTML, und du musst kein React lernen, um eine vollständige Website zu bauen. Wer React kann, nimmt es in Astro einfach mit, für die Inseln.

Next.js verlangt React-Kenntnisse, und seit React Server Components ein Verständnis dafür, welcher Code auf dem Server und welcher im Browser läuft. Das ist lernbar, aber es ist die steilere Kurve, und Fehler dabei kosten genau die Performance, wegen der du Next.js gewählt hast.

Für die Auswahl heißt das: Frag zuerst, wer die Website in zwei Jahren pflegt. Hat dein Unternehmen ein React-Team, ist Next.js auch für reine Inhaltsseiten vertretbar. Gibt es intern niemanden und übernimmt eine Agentur die Entwicklung, ist Astro das kleinere Risiko, weil die Einarbeitung für Nachfolger kürzer ist. Was beide Wege kosten, steht in unserer Übersicht zu Webentwicklungs-Kosten.

Kann man Astro und Next.js kombinieren?

Ja, und bei größeren Kunden ist das der Normalfall. Die Marketing-Website läuft auf Astro, das Produkt oder Kundenportal dahinter auf Next.js, beide auf derselben Domain, getrennt über Pfade wie /app oder eine Subdomain. Der Übergang ist für Besucher ein Klick, für Crawler eine normale Verlinkung.

Beide Teile ziehen ihre Inhalte aus derselben Sanity-Datenbank. Preise, Produktnamen, Rechtstexte, Übersetzungen: einmal gepflegt, an beiden Stellen aktuell. Die Marketing-Seite holt sie beim Bauen, die Anwendung pro Anfrage. Dass beide dasselbe Content-Modell lesen, spart genau die Doppelpflege, die in getrennten Systemen nach sechs Monaten auseinanderläuft.

Wenn du von einer bestehenden Plattform kommst, planst du diesen Schnitt schon im Relaunch-Projekt mit. Wie wir dabei Rankings absichern, steht im Artikel zum Relaunch ohne SEO-Verlust: Vorher-Crawl, Ranking-Snapshot, Redirect-Map 1:1 für jede alte URL, danach zwei Wochen Monitoring mit 404-Report.

Wann Astro, wann Next.js

Die Entscheidung fällt an der Frage, ob deine Website Inhalte ausliefert oder Logik ausführt. Die folgenden zwei Listen decken die Fälle ab, die uns in Projekten begegnen.

Wähle Astro, wenn

Deine Website ist im Kern ein Inhaltsprojekt, das schnell laden und gut gefunden werden soll.

Wähle Next.js, wenn

Deine Website ist Teil eines Produkts oder soll eines werden.

Unser Urteil

Astro ist unser Default für inhaltsgetriebene Unternehmenswebsites, Next.js unser Werkzeug, sobald App-Logik dazukommt. Diese Regel halten wir seit zwei Jahren durch, und sie hat sich in jedem Projekt gehalten, in dem wir sie angewendet haben.

LeanWave, die Website von Otto ID Solutions für RFID im Textilservice, bauen wir statisch mit Astro und Sanity auf Vercel: zweisprachig mit wechselseitigem hreflang inklusive x-default, übersetzten URL-Segmenten, 64 Dokumenten und 86 Bild-Assets, Rebuild per Webhook bei jeder Änderung. Bei Yarowa haben wir einen fünfsprachigen Webflow-Export 1:1 nach Astro portiert: 21 Seiten-Templates, 163 Sections, Design unverändert, der Umbau auf Sanity mit Presentation Mode ist in Planung. Ullsteinhaus (Astro, React, Three.js, Sanity) und Monteval (Astro, GSAP, Sanity) laufen ebenfalls auf Astro.

in-sync.io selbst steht auf Next.js, weil wir Server-Rendering und serverseitige Daten pro Anfrage nutzen: 49 Wissen-Artikel, 10 Service-Seiten und 17 Stadtseiten kommen aus einer Sanity-Datenbank, zweisprachig mit hreflang, dazu llms.txt, IndexNow und FAQPage-Schema. Ehrlich dazu: Die alte Wix-Website rankte für praktisch nichts, die neue ist seit Juni 2026 live und baut ihre Rankings gerade auf. Wenn du unsicher bist, welcher Weg zu deinem Projekt passt, schauen wir uns in der Beratung zu Webdesign und Entwicklung den konkreten Funktionsumfang an, bevor irgendein Framework feststeht.

Häufige Fragen

Nächster Schritt

Schick uns die Anforderungen deiner nächsten Website und wir sagen dir, ob Astro oder Next.js der kürzere Weg ist, bevor eine Zeile Code entsteht.