Jamstack erklärt: was hinter dem Begriff steckt und was 2026 gilt

Die kurze Antwort

Jamstack beschreibt Websites, die vorab zu HTML gerendert, über ein CDN ausgeliefert und über APIs mit Inhalten und Funktionen versorgt werden. CDN steht für Content Delivery Network, ein Netz aus Servern, das fertige Dateien nah am Besucher bereithält. API steht für Schnittstelle, über die ein anderes System Daten liefert. Der Name selbst setzt sich aus JavaScript, APIs und Markup zusammen.

Der Begriff ist gealtert, das Prinzip nicht. Frameworks mischen heute statisches Rendern, serverseitiges Rendern und die nachträgliche Erneuerung einzelner Seiten in einem einzigen Projekt. Damit fällt die saubere Trennung zwischen statisch und dynamisch weg, die den Begriff getragen hat. Wer 2026 von Jamstack spricht, meint in der Regel drei Dinge: Auslieferung über ein CDN statt Rendering bei jeder Anfrage, Inhalte aus einem Content-System per Schnittstelle statt aus einer Datenbank hinter dem Webserver, und eine Build- und Deploy-Kette statt Live-Bearbeitung am Server.

Genau so bauen wir. Astro für Inhalte, die sich vorab rendern lassen, Next.js sobald Login, App-Logik oder Daten pro Anfrage dazukommen, Sanity als Content-Quelle, Vercel für Build und Auslieferung. Das ist keine Glaubensfrage. Es ist eine Entscheidung darüber, wer die Kontrolle über Rendering, Auslieferung und Wartungsaufwand hat.

Was Jamstack ursprünglich meinte

Der Begriff entstand, als statische Generatoren wieder populär wurden. Ein statischer Generator, kurz SSG, baut alle Seiten einmal vorab zu HTML und legt das Ergebnis auf ein Auslieferungsnetz. Beim Aufruf passiert dann nichts mehr außer der Übertragung fertiger Dateien. Kein PHP-Prozess, keine Datenbankabfrage, kein Warten auf den Webserver.

Die drei Buchstaben beschreiben die Arbeitsteilung. Markup ist das vorgerenderte HTML. APIs liefern alles, was dynamisch sein muss: Formularversand, Suche, Produktdaten, Inhalte aus dem Redaktionssystem. JavaScript verbindet beides im Browser, dort wo es gebraucht wird. Das war die Gegenbewegung zum klassischen Modell, in dem ein Server jede Seite bei jeder Anfrage aus einer Datenbank zusammensetzt und Redakteure direkt an diesem laufenden System arbeiten.

Der praktische Gewinn lag nicht im Namen, sondern in vier Punkten: gleichbleibende Ladezeit unabhängig von der Last, weil nur Dateien ausgeliefert werden. Eine kleine Angriffsfläche, weil kein Redaktionssystem öffentlich erreichbar ist. Klare Trennung von Inhalt und Darstellung, weil das Content-System nur Daten liefert. Und Nachvollziehbarkeit, weil jede Änderung durch einen Build läuft. Diese vier Punkte gelten unverändert, egal wie das Konzept gerade heißt.

Wichtig für die Einordnung: Jamstack war nie ein Produkt und nie ein Anbieter. Du kannst es nicht lizenzieren und nicht buchen. Es ist eine Beschreibung dafür, wie die Teile zusammengesteckt sind, und deshalb passt es auf sehr unterschiedliche Umsetzungen. Zwei Websites können beide dem Prinzip folgen und trotzdem völlig verschieden gebaut sein, mit unterschiedlichen Frameworks, unterschiedlichen Content-Systemen und unterschiedlichen Hosting-Anbietern. Wenn ein Angebot dir Jamstack als Leistung verkauft, frag nach den konkreten Bestandteilen.

Warum der Begriff heute seltener fällt

Die Grenze zwischen statisch und serverseitig ist verschwommen. Dasselbe Projekt rendert heute den Blog vorab, die Preisseite bei jeder Anfrage neu und ein personalisiertes Element erst, nachdem die Seite schon beim Besucher ist. Ein Etikett, das nur zwei Zustände kennt, beschreibt das nicht mehr.

Astro zeigt das gut. Standardmäßig liefert es null clientseitiges JavaScript aus und rendert Komponenten zu HTML und CSS. Interaktivität wird bewusst angefordert. Client Islands sind Komponenten mit einer client:*-Direktive: Sie laden ihr JavaScript separat, nur dieser Teil wird im Browser aktiviert, der Rest bleibt statisches HTML. Server Islands sind Komponenten mit server:defer: Sie rendern dynamische oder personalisierte Teile unabhängig nach, während die Hauptseite sofort ausgeliefert wird. Was davon in deinem Projekt sinnvoll ist, erklärt der Artikel zum Astro-Framework im Detail.

Next.js macht dasselbe aus der anderen Richtung. Es kommt vom serverseitigen Rendern, kurz SSR, also dem Zusammenbauen der Seite auf dem Server bei jeder Anfrage, und kann einzelne Seiten trotzdem vorab bauen und später erneuern. Beide Wege treffen sich in der Mitte. Welcher für dein Projekt passt, hängt weniger am Etikett als an der Frage, wie viel pro Anfrage entschieden werden muss. Die Gegenüberstellung steht in Astro vs. Next.js.

Für dich als Entscheider heißt das: Frag nicht, ob ein Angebot Jamstack ist. Frag, was beim Seitenaufruf tatsächlich passiert und wer es ändern kann.

Was von der Idee trägt

Vier Bausteine sind geblieben, und sie sind der Grund, warum wir so bauen. Erstens die Auslieferung über ein CDN statt Rendering pro Anfrage. Der Besucher bekommt eine fertige Datei aus einem nahen Rechenzentrum, nicht das Ergebnis einer Datenbankabfrage. Das wirkt direkt auf die Ladezeit und damit auf die Werte, die Google unter Core Web Vitals misst.

Zweitens die Inhalte aus einer Schnittstelle statt aus einer Datenbank hinter dem Webserver. Ein headless CMS, also ein Redaktionssystem ohne eigene Ausgabeschicht, liefert Inhalte als strukturierte Daten an beliebige Frontends. Was das im Alltag bedeutet, steht in unserer Einführung zu headless CMS, die Produktdetails im Artikel zu Sanity.

Drittens die Build- und Deploy-Kette statt Live-Bearbeitung am Server. Bei LeanWave löst jede Änderung in Sanity einen Webhook aus, also einen automatischen Aufruf, der den Neubau der Website anstößt. Niemand arbeitet an einem laufenden Produktivsystem, jede Version ist reproduzierbar.

Viertens die kleine Angriffsfläche. Es gibt keine öffentlich erreichbare Anmeldemaske am eigenen Webserver, keine Plugin-Kette, die aktuell gehalten werden muss, und keine Datenbank, die man absichern müsste. Dazu kommt ein Punkt, der beim Aufkommen des Begriffs noch keine Rolle spielte: Wenn du Rendering, Schema-Auszeichnung, Sitemap und interne Verlinkung im Code kontrollierst, hast du jeden Hebel in der Hand, den Google und KI-Crawler lesen. Der technische SEO-Artikel zeigt, welche das sind.

Rendering pro Anfrage gegen Jamstack-Prinzip

Die folgende Tabelle stellt das klassische Modell, bei dem ein Server jede Seite aus einer Datenbank zusammensetzt, dem vorgerenderten Modell gegenüber. Sie bewertet nicht, sie beschreibt, wo der Unterschied im Alltag spürbar wird.

Die letzte Zeile ist die ehrliche. Sie führt direkt zum nächsten Abschnitt.

Zur Gebührenzeile noch ein Wort, weil sie in Angeboten oft untergeht. Bei Webflow kostet Premium 25 $ pro Monat mit 20.000 CMS-Items und 40 Collections, Lokalisierung kommt als Add-on mit 9 $ pro Sprache und Monat obendrauf. Wix rechnet pro Website ab, von 17 $ für Light bis 159 $ für Business Elite. Eine Astro- oder Next.js-Website mit Sanity Free läuft dagegen typischerweise mit 0-20 $ Hosting im Monat, also nahezu ohne laufende Plattformgebühren. Dafür trägst du die Entwicklung selbst, und ohne Entwicklerteam im Haus oder an deiner Seite funktioniert dieser Weg nicht.

Wo die reine Lehre nicht trägt

Vier Fälle sprengen das vorgerenderte Modell, und du solltest sie kennen, bevor jemand dir eine rein statische Website verkauft.

Login und geschützte Bereiche. Sobald ein Besucher sich anmeldet und je nach Konto andere Inhalte sieht, kann die Seite nicht vorab für alle gebaut sein. Das ist der Punkt, an dem wir von Astro auf Next.js wechseln, weil dort serverseitige Logik und Sitzungsverwaltung zum Standardumfang gehören.

Warenkorb und Bestellprozess. Preise, Verfügbarkeit und Zahlung entscheiden sich zum Zeitpunkt der Anfrage. Der Produktkatalog kann vorgerendert bleiben, Warenkorb und Kasse laufen serverseitig oder über Dienste per Schnittstelle.

Personalisierte Inhalte. Wenn jeder Besucher eine andere Startseite sehen soll, ist eine vorgerenderte Seite die falsche Grundlage. Server Islands sind hier der mittlere Weg: Die Seite geht sofort raus, der personalisierte Block rendert unabhängig nach.

Sehr große Seitenzahlen mit häufigen Änderungen. Wenn Zehntausende Seiten mehrmals täglich wechseln, wird ein kompletter Neubau bei jeder Änderung unpraktisch. Dann rendert man die betroffenen Seiten bei Anfrage neu oder erneuert sie gezielt. Und unabhängig von der Technik gilt: Programmatisch erzeugte Seiten brauchen echte Substanz pro Seite, sonst stuft Google sie als Doorway-Pages ein, also als Seiten, die nur existieren, um ein Suchwort abzudecken. Auf unserer eigenen alten Website haben wir genau das erlebt.

Keiner dieser Fälle führt zurück zum Baukasten. Wer hier landet, braucht mehr Kontrolle über das Rendering, nicht weniger. Zum Vergleich der beiden Welten im Detail gibt es Webflow vs. Next.js.

Wann Webflow reicht, wann du ein eigenes Frontend baust

Die Entscheidung hängt an Umfang, Sprachen und daran, wie viele Seiten aus Daten entstehen sollen. Wir sind zertifizierter Webflow-Partner und betreuen Bestandskunden darauf, deshalb ist die Grenze hier nüchtern gezogen und nicht verkaufsgetrieben.

Wähle Webflow, wenn

Webflow ist stark bei Design, Editor und Tempo bis zur ersten Version. In diesen Fällen ist es die richtige Wahl, und unsere Webflow-Agentur baut genau das:

Wähle Astro oder Next.js mit Sanity, wenn

Sobald Inhalte zum System werden, verschiebt sich die Rechnung. Dann baut unsere Webentwicklungs-Agentur ein eigenes Frontend:

So machen wir es

LeanWave zeigt das Modell im Reinzustand. Die Website von Otto ID Solutions für RFID im Textilservice läuft statisch mit Astro, Sanity, Tailwind und Vercel. Zweisprachig, Englisch auf der Wurzel, Deutsch unter /de, mit übersetzten URL-Segmenten, aus /solutions wird /de/loesungen. Die hreflang-Auszeichnung, also der Hinweis an Google, welche Sprachfassung zu welcher Seite gehört, ist wechselseitig gesetzt und enthält x-default. 64 Dokumente, 86 Bild-Assets, Neubau per Webhook bei jeder Änderung, Redaktion im Presentation Mode von Sanity mit Vorschau im Kontext. Auf der Startseite laden rund 39 KB JavaScript in drei Dateien, gemessen am 13.09.2026.

Yarowa zeigt den Zwischenschritt. Der fünfsprachige B2B-Auftritt war in Webflow gebaut. Wir haben den Export eins zu eins nach Astro portiert und auf Vercel gehostet: 5 Sprachen, 21 Seiten-Templates, 163 Sections, Design unverändert. Sanity mit Presentation Mode kommt dort als nächster Schritt dazu. Der Schritt löst zuerst das Auslieferungs- und Gebührenproblem, die Redaktion folgt danach.

Unsere eigene Website ist 2026 von Wix auf Next.js, Sanity und Vercel umgezogen: 49 Wissen-Artikel, 10 Service-Seiten, 17 Stadtseiten, alle aus einer Sanity-Datenbank, zweisprachig mit hreflang, Server-Rendering, llms.txt, IndexNow und FAQPage-Schema. Dazu gehört die unbequeme Hälfte: Die alte Wix-Website war in der Suche praktisch unsichtbar, die neue steht seit Juni 2026 und arbeitet sich gerade hoch.

Wenn du von einem bestehenden System kommst, ist der Wechsel ein Relaunch-Projekt mit Vorher-Crawl, Ranking-Snapshot und einer Redirect-Map 1:1 für jede alte URL. Typischerweise 3-6 Wochen bis Go-Live bei 10-30 Seiten, danach zwei Wochen Monitoring mit 404-Report. Relaunch-Pakete beginnen bei uns bei 8.000 € netto. Der Ablauf steht in der CMS-Migration, die Statuscodes im Detail in der 301-Weiterleitung, und wenn du heute noch auf einem Baukasten sitzt, hilft der Vergleich der Squarespace-Alternativen bei der Einordnung. Den Umzug selbst begleitet unsere Relaunch-Agentur.

Nächster Schritt

Wenn du wissen willst, ob dein Projekt vorgerendert oder serverseitig laufen sollte, schauen wir uns deine Inhalte und deine Roadmap gemeinsam an.