NEXT.JS, ASTRO ODER WORDPRESS 2026

Next.js, Astro oder WordPress ist die Frage, die ich am häufigsten von Gründern und Agentur-Kunden gestellt bekomme. Die Antwort ist fast nie die, die sie erwarten. Die Entscheidung ist nicht Framework gegen Framework. Die Entscheidung ist Intent: Was baust du tatsächlich, wer wartet es nach dem Launch, und welcher Fehlermodus ist dir am wenigsten leisten können. Sobald diese drei ehrlich beantwortet sind, wählt sich die Framework-Entscheidung meist von selbst.

Was folgt, ist die Operatoren-Perspektive aus zwölf Jahren Einsatz aller drei. Wir fahren WordPress, Next.js und Astro jede Woche bei Seahawk Media, oft in demselben Kundenprojekt in verschiedenen Lebenszyklen. Jede ist echte gute Software. Jede ist die falsche Antwort für spezifische Situationen. Dieses Handbuch ist das Entscheidungsdiagramm, das ich tatsächlich nutze, nicht die Marketing-Page-Tour.

Next.js

Next.js ist ein React-Framework mit einer Server-Rendering-Schicht, dateibasiertem Routing und einem Build-System, das statisches HTML, serverseitiges HTML oder alles dazwischen erzeugt. Das App Router-Modell ist seit Version 15 stabil, React Server Components sind der Standard, und das Framework ist die dominierende Wahl für neue React-Projekte. Vercel entwickelt es, Netlify und Cloudflare betreiben es, und das Ökosystem ist riesig.

Astro

Astro ist ein Content-First-Framework, das standardmäßig null JavaScript ausliefert und dir ermöglicht, React-, Vue-, Svelte- oder Solid-Komponenten nur dort einzusetzen, wo du Interaktivität brauchst. Die Stärke liegt bei Content-Seiten: Marketing-Seiten, Blogs, Dokumentation, Prospekt-Seiten. Das mentale Modell ist „HTML by default, JS where needed", was die React-Annahme umkehrt, dass alles JavaScript ist, bis das Gegenteil bewiesen ist.

WordPress (klassisch und headless)

WordPress läuft auf PHP, lebt in einer MySQL-Datenbank und hat das größte Plugin-Ökosystem im Web. 2026 hat es zwei Betriebsmodi: klassisch (WordPress rendert Backend und Frontend) und headless (WordPress ist die API und das CMS, während Next.js, Astro oder Nuxt das Rendering übernehmen). Headless WordPress ist das, was die WordPress-mit-Editoren-Welt und die Next.js-mit-Ingenieuren-Welt verbindet.

Next.js gewinnt bei produktähnlichen Seiten. Konkret: das Team beherrscht React, das Produkt hat zustandsbehaftete Interaktivität jenseits einer typischen Marketing-Seite, das Datenmodell ist kundenspezifisch (nicht ein generischer Blog oder CMS), und das Engineering-Team wird die Codebasis Jahre lang betreuen.

Konkrete Beispiele aus Projekten, die ich umgesetzt habe: ein SaaS-Dashboard mit Marketing-Front-Door, ein Marketplace mit Login und personalisiertem Inhalt, eine Developer-Tools-Unternehmensseite mit tiefgreifend angepassten Demos, eine Multi-Tenant-Verzeichnisplattform wie HostList.io. Jedes dieser Projekte profitiert von React Server Components, den Next.js-Daten-Fetching-Primitiven und dem nahtlosen Übergang zwischen statischen Marketing-Seiten und authentifizierten App-Oberflächen unter demselben Framework.

Wo Next.js schnell teuer wird, sind inhaltsreiche Seiten mit nicht-technischen Editoren. Die CMS-Integration ist immer kundenspezifisch, der redaktionelle Workflow muss immer neu aufgebaut werden, und das Team, das es betreut, muss permanent mit Ingenieuren besetzt sein. Wenn dein redaktionelles Team drei Schreiber sind und du möchtest, dass sie ohne Engineering-Beteiligung veröffentlichen, kämpft Next.js den falschen Kampf.

Astro gewinnt bei inhaltsgesteuerten Websites mit starker Design-Sprache und Engineering-Kapazität zum Versand sauberer Komponenten. Konkret: eine Marketing-Website, ein Dokumentations-Hub, eine Broschüren-Website, ein Portfolio, eine Agency-Website, ein Blog, bei dem Performance Teil der Marke ist. Die Art von Website, bei der das Besuchererlebnis aus dem Lesen oder Scannen von Inhalten besteht, nicht aus der Interaktion mit zustandsbehafteten Flows.

Diese Website, gautamkhorana.com, ist auf Astro gebaut. Ebenso die Marketing-Website für viele Design-getriebene Agenturen und unabhängige Produkteinführungen 2026. Das Argument ist einfach: Null Standard-JavaScript bedeutet, dass Lighthouse-Scores mühelos 100 erreichen, das Content-Modell ist einfaches Markdown oder Sanity oder Supabase, und die Build-Pipeline produziert statisches HTML, das unbegrenzten Traffic auf jedem CDN übersteht. Die Websites, die ich auf Astro ausgeliefert habe, hatten zusammen seit dem Launch null Performance-Regressionem. Nicht wenige. Null.

Wo Astro die falsche Wahl ist: Alles mit erheblichem authentifizierten Benutzerzustand, alles, wo die Frontend-Komplexität die Content-Komplexität übersteigt, alles, wo das Team in React-Idiomen über die gesamte Codebase hinweg voranschreiten muss. Astro ist ausgezeichnet darin, leichtgewichtig zu sein; es ist das falsche Tool zum Bauen eines schweren Produkts.

WordPress gewinnt bei inhaltsgesteuerten Websites, wo das Editor-Erlebnis wichtiger ist als die Rendering-Performance, wo das Plugin-Ökosystem ein echtes Problem löst, und wo das Team keine laufende Engineering-Kapazität bereitstellen wird. Die /guides/wordpress/ Säule behandelt dies vollständig; die Kurzversion: Wenn Sie nicht-technische Editoren haben, Plugin-Leverage zählt, und die Gesamtbetriebskosten über drei Jahre das entscheidende Maßstab sind, bleibt WordPress die richtige Antwort für die Mehrheit der inhaltsgesteuerten Websites.

Konkret: Broschüren-Websites mit regelmäßigen redaktionellen Updates, E-Commerce-Websites, wo WooCommerce echte regionale Steuerkomplexität löst, Membership-Websites, wo MemberPress oder Restrict Content Pro den Workflow vorgeben, Immobilien- oder Job-Board-Websites, wo ein Nischen-Plugin neunzig Prozent des Modells handhabt, Websites, wo der Client explizit keinen Developer bereitstellen möchte für laufende Änderungen.

Headless WordPress ist die Bridge-Architektur: Behalte WordPress für das Editor-Erlebnis und Plugin-Ökosystem, aber rendere das Frontend mit Next.js oder Astro für Performance und Design-Kontrolle. Es zahlt sich in einem schmalen, aber echten Satz von Fällen aus.

Es zahlt sich aus, wenn: das Editorial-Team sich zu WordPress bekennt und nicht wechselt, aber die Marketing-Website ist performance-kritisch (hoher Traffic, teure Ads, Brand-sensitive Lighthouse-Scores). Es zahlt sich aus, wenn die Design-Sprache ungewöhnlich genug ist, dass die WordPress-Theme-Schicht nicht liefern kann, aber das Content-Modell ist wirklich WordPress-geformt (Posts, Pages, Custom Post Types, ACF-Felder). Es zahlt sich aus, wenn das Unternehmen sowohl redaktionelle als auch Engineering-Reife hat und es sich leisten kann, beide bereitzustellen.

Es zahlt sich nicht aus, wenn: das Team weder redaktionelle Reife noch Engineering-Kapazität hat (man zahlt zweimal), das Projekt wirklich eine Broschüren-Website ist, die monatlich bearbeitet wird, das Budget klein genug ist, dass Double-Stack-Wartung unerschwinglich ist. Die ehrlichen Kosten für das Betreiben von Headless WordPress 2026 betragen grob das 1,5- bis 2-Fache der Kosten für das Betreiben von klassischem WordPress über zwölf Monate. Stelle sicher, dass die Performance- und Design-Gewinne es rechtfertigen.

Speziell bei Next.js hat die Wahl der Rendering-Strategie größere Kostenauswirkungen als die Framework-Wahl selbst. Die vier Optionen:

Static Site Generation (SSG)

Alle Seiten werden zur Build-Zeit erstellt und als reines HTML vom CDN ausgeliefert. Am billigsten, am schnellsten, am sichersten. Die richtige Standardwahl für Marketing-Websites und Blogs. Die Einschränkung besteht darin, dass Inhaltsänderungen einen vollständigen Rebuild und ein erneutes Deployment erfordern. Bei Websites mit wenigen tausend Seiten ist das in Ordnung. Bei Websites mit zehntausenden Seiten werden Build-Zeiten zum Engpass.

Incremental Static Regeneration (ISR)

Seiten werden zur Build-Zeit statisch generiert, dann bei Bedarf oder nach Plan neu validiert. Der Mittelweg für Content-Websites im großen Maßstab. Das Problem, auf das die meisten Teams stoßen: ISR-Abrechnung bei Vercel erfolgt pro Invocation, und bei 91.000 Seiten mit häufiger Neuvalidierung haben wir Monate mit mehreren Millionen Events gesehen. Wir haben auf der Website Deluxe Astrology eine explizite Regel von „zwei Production-Merges pro Woche", genau weil jeder Merge ungefähr sechs Millionen ISR-Schreibereignisse auslöst. ISR ist hervorragende Technologie mit einer echten Kostenkurve im großen Maßstab.

Server-Side Rendering (SSR)

Seiten werden bei jeder Anfrage gerendert. Die richtige Antwort für authentifizierte Dashboards, personalisierte Inhalte und alles, wo der Seiteninhalt vom anfragenden Benutzer abhängt. Das Kostenmodell basiert auf CPU pro Anfrage, was bei hochfrequentierten öffentlichen Seiten schnell teuer wird. SSR für Marketing-Seiten vermeiden.

React Server Components (RSC)

Der Standard von Next.js 15, oft in Kombination mit den obigen Optionen verwendet. RSC verschiebt Datenabrufe auf den Server und sendet weniger JavaScript an den Client. Das mentale Modell erfordert etwas Umstellung, aber die Performance- und DX-Gewinne sind real. Die meiste neue Next.js-Arbeit 2026 sollte standardmäßig RSC verwenden.

Wenn du auf Next.js oder Astro headless gehst, ist die CMS-Layer-Entscheidung die zweitmächtigste Entscheidung nach dem Framework. Die fünf tragfähigen Optionen, die ich in jedem Projekt evaluiere:

Sanity

Meine Standardempfehlung für neue Headless-Projekte. Der Schema-as-Code-Ansatz ist das sauberste Content-Modell auf dem Markt, die Editor-Experience ist wirklich gut für nicht-technische Editoren, und die GROQ-Query-Language ist für die meisten Content-Formen flexibler als GraphQL. Die Preisgestaltung skaliert angemessen. Trade-off: kleineres Plugin-Ökosystem als WordPress, gelegentliche Reibungen bei maßgeschneiderten Editorial-Workflows.

Headless WordPress (via WPGraphQL oder REST)

Die richtige Antwort, wenn Vertrautheit der Editoren mit WordPress die primäre Einschränkung ist. WPGraphQL ist 2026 ausgereift und der Faust.js-Stack macht die Next.js-Integration unkompliziert. Kosten: du wartest WordPress UND das Frontend, was der inhärente Overhead ist, die zwei Welten zu verbinden.

Supabase

Meine Wahl, wenn das Content-Modell strukturierte Daten mehr als lange Prosa ist: Verzeichnisse, Listings, programmatic-SEO-Sites, alles tabellenförmige. HostList.io läuft auf Supabase. Kosten: Supabase ist eine Datenbank mit Content-Layer-Funktionalitäten, kein CMS im redaktionellen Sinne. Editoren lieben es nicht.

Contentful

Enterprise-Tier-Wahl mit starken Workflow-Features und Locale-Support. Die Preisgestaltung skaliert in den höheren Tiers schnell. Richtig, wenn das Team formale Content-Governance und Budget dafür hat.

Payload, Strapi

Self-hosted-Optionen, wenn Datenspeicherort oder Kostenkontrolle die primäre Sorge sind. Beide haben sich 2025 bedeutsam weiterentwickelt. Richtig für Teams mit Engineering-Kapazität, die die CMS-Schicht selbst kontrollieren wollen.

Wo du bereitstellst, ist die dritte Entscheidung, die sich mit der Zeit verstärkt. Die drei praktikablen Hosting-Optionen:

Vercel

First-Party-Host für Next.js, beste Developer Experience, höchste Preiskategorie. Bandwidth und ISR-Aufrufe sind die Kostenhebel, die die meisten Teams übersehen, bis die Rechnung kommt. Wir betreiben Sites auf Vercel wirklich wegen der DX-Vorteile, aber die Kostenkurve ist steiler als Leute erwarten. Plane für mindestens das Doppelte deiner initialen Schätzung bei jeder Skalierung, wo ISR stark genutzt wird.

Netlify

Exzellent für Astro und static-rendered Next.js, etwas weniger poliert für Next.js App Router mit vollständigem RSC. Pricing ist vorhersagbarer als Vercel. Das Build-Minuten-Preismodell ist der Hebel, auf den man achten muss. Diese Site läuft auf Netlify.

Cloudflare Pages and Workers

Beste Price-Performance 2026, materiell günstiger als die anderen beiden bei Skalierung, das zugrundeliegende Netzwerk ist unvergleichlich für globale Zustellung. Trade-off: das Deployment-Modell und die Next.js-Integration ist weniger poliert als Vercel. Es lohnt sich für kostensensible Projekte mit Engineering-Kapazität, um die rauen Kanten zu navigieren.

Wähle das Framework, das zum Team passt, das es später pflegt. Das klingt offensichtlich. Es ist die am häufigsten verletzte Regel bei Framework-Entscheidungen, die ich bei Seahawk sehe.

Ein Team von drei React-Ingenieuren sollte nicht auf WordPress bauen. Ein Team von einem PHP-Ingenieur plus drei Schreibern sollte nicht auf Next.js bauen. Ein Team von null Ingenieuren und einem freiberuflichen Designer sollte auf keinem davon bauen: Webflow, Framer oder gehostetes WordPress ist die richtige Antwort.

Die Kosten einer nicht angepassten Framework-Team-Kombination entstehen nicht am ersten Tag. Sie werden über Jahre hinweg bezahlt, während das Team gegen das Framework arbeitet statt mit ihm. Passe die Technologie an die operative Realität an.

Echte Zahlen von Websites, die ich 2026 gebaut oder audiert habe, alle gemessen bei 75. Perzentil der Felddaten:

Statisch gerenderte Astro

LCP unter 1,0 Sekunde durchgehend. Initial JavaScript unter 30KB auf den meisten Seiten. Lighthouse 100 über die ganze Breite ist das Standard-Ergebnis, nicht das Optimierungsziel. Die schwierigste Stufe für Content-Websites.

Statisch gerenderte Next.js (App Router, RSC)

LCP 1,0 bis 1,5 Sekunden auf optimierten Websites. Initial JavaScript 80 bis 150KB je nachdem, wie viele Client-Komponenten ausgeliefert werden. Lighthouse 90+ ist erreichbar, erfordert aber bewusste Optimierungsarbeit.

ISR oder SSR Next.js

LCP 1,5 bis 2,5 Sekunden je nach Cache-Hit-Rate und Origin-Response-Time. Die Performance bricht bei Cold-Cache-Misses dramatisch ein. Ausgezeichnete Technologie für den richtigen Use-Case, erfordert aber aktives Monitoring.

WordPress auf managed Hosting (Kinsta, WP Engine) plus Cloudflare

LCP typischerweise 1,8 bis 3,0 Sekunden. Lighthouse 70 bis 85 mit Aufwand. Akzeptabel für die meisten Content-Sites, aber merklich schlechter als die statischen Optionen. Die Performance-Obergrenze ist real.

WordPress auf Shared Hosting

LCP 3,5 Sekunden oder schlechter. Vermeiden für alle Sites, bei denen Performance Teil der Anforderungen ist.

Alle drei können auf höchstem Niveau ranken. Das SEO-Gespräch 2026 dreht sich nicht mehr darum, welches Framework „SEO-freundlicher" ist. Es geht um Implementierungsqualität.

Statisches Rendering auf Astro oder Next.js gibt dir das sauberste indexierbare HTML und die schnellsten Core Web Vitals – beide Ranking-Faktoren. WordPress mit Yoast oder Rank Math gibt dir das umfassendste In-Editor-SEO-Tooling, das Non-Technical-Editoren wesentlich dabei hilft, saubere Meta zu deployen. Headless WordPress gibt dir beides, zu den Kosten doppelter Stack-Wartung.

Wo ich SEO-Desaster sehe: JavaScript-lastige Next.js-Sites von Clients, die Core-Content im Browser statt auf dem Server rendern. Google kann JavaScript-gerenderte Inhalte technisch indexieren, aber Latenz, Vollständigkeit und Konsistenz sind alle schlechter als bei HTML-gerendertem Content. Wenn SEO wichtig ist, server-seitig oder statisch rendern. Immer.

Die meisten Kunden stellen die falsche Migrationsfrage. Die richtige Frage ist nicht „können wir von WordPress zu Next.js migrieren", sondern „was sind die Gesamtkosten über drei Jahre für jede Option, inklusive des Teams, das sie pflegen muss, und welche liefert die Metriken, die uns wirklich wichtig sind".

Eine typische WordPress-zu-Headless-Next.js-Migration, die wir bei Seahawk durchführen, kostet zwischen 25.000 und 90.000 USD je nach Umfang. Diese Migration amortisiert sich normalerweise innerhalb von zwölf Monaten bei Traffic, wo Lighthouse-Scores die Anzeigenkosten oder Conversion Rates beeinflussen. Sie amortisiert sich nicht auf einer Unternehmenswebseite, die zweitausend monatliche Besucher hat.

Die Migration, die häufiger sinnvoll ist, führt von WordPress auf Shared Hosting zu WordPress auf Kinsta, plus eine Cloudflare-Schicht, plus eine strengere Plugin-Diät. Gleiche Plattform, andere operative Realität, deutlich bessere Performance und Sicherheit zu einem Zehntel der Kosten einer Plattformumstellung. Die richtige Antwort für die meisten Kunden ist nicht „baue auf Next.js neu auf", sondern „repariere die WordPress-Installation, die du bereits hast".

Hier ist der tatsächliche Entscheidungsbaum, den ich in jedem neuen Kundengespräch 2026 durchlaufe:

Wenn das Team null Engineering-Kapazität hat und Editorial die einzige Funktion ist: Webflow oder gehostetes WordPress.

Wenn das Team Editorial-geführt ist mit leichter technischer Unterstützung, Content-schwer mit Plugin-Ökosystem-Anforderungen: klassisches WordPress auf verwaltetes Hosting. Standardantwort.

Wenn das Team Editorial-geführt ist, aber Performance und Design Teil des Briefs sind: Headless WordPress mit einem Astro- oder Next.js-Frontend.

Wenn das Team Engineering-geführt ist, das Produkt ist Content-schwer, die Design-Sprache ist ungewöhnlich und es gibt wenig Benutzerzustand: Astro mit Sanity oder Supabase.

Wenn das Team Engineering-getrieben ist, hat das Produkt authentifizierten Benutzerstatus und zustandsbehaftete Interaktivität: Next.js mit Sanity oder Supabase, deployed auf Vercel oder Cloudflare Pages je nach Kostenempfindlichkeit.

Wenn das Datenmodell in der Skalierung wirklich tabellenförmig ist (Verzeichnisse, Listings, programmatische SEO): Next.js oder Astro mit Supabase. HostList.io ist die Fallstudie hier.

Es gibt 2026 kein einziges „bestes" Framework. Es gibt ein bestes Framework für jede Kombination aus Team, Content-Form und operativer Realität. Die Teams, die gut ausliefern, sind diejenigen, die diese drei ehrlich aufeinander abstimmen. Die Teams, die kämpfen, sind diejenigen, die das Framework zuerst gewählt haben und versucht haben, ihre Realität daran anzupassen.

Drei ehrliche Zeichen, dass du dabei bist, das falsche Framework zu wählen: du wählst es, weil deine Freunde es nutzen, du wählst es, weil es diese Quartal auf der Trend-Liste ist, du wählst es, weil dich die Demo auf der Marketing-Seite gefühlt hat. Keine davon sind gute Gründe. Der richtige Grund ist: das passt zu meinem Team, das passt zu meinem Content, das passt zu meinem Budget über drei Jahre.

Wenn du eine zweite Meinung möchtest, welche richtig für das ist, was du baust, führen wir Konsultationen bei Seahawk Media durch. Das Gespräch ist kostenlos, die Empfehlung ist ehrlich, und wir werden dir manchmal sagen, dass die richtige Antwort ist, deine aktuelle WordPress-Site zu behalten und die Hosting-Schicht zu reparieren, weil das ist, was die Mathematik tatsächlich sagt.