Next.js-Entwickler

Was ich liefere

Next.js 15 mit App Router und React 19 Server Components im Frontend. WordPress 6.7+ als redaktionelles Back-End, das über REST oder GraphQL kommuniziert. Cloudflare Workers und Pages als Runtime und Edge-Cache. TypeScript über den ganzen Stack. Tailwind CSS als Design-System. Anthropic Claude und Model Context Protocol, sobald sich KI-Funktionen tatsächlich rechnen.

Das ist keine Technologieliste aus einer Stellenanzeige, sondern der Stack, den ich in eigener Produktion betreibe. Jedes Element hat einen Grund: Der App Router ermöglicht Rendering pro Route, RSC reduziert das JavaScript zum Client, Workers eliminieren Kaltstarts und halten Daten in Reichweite europäischer Regulierung. Fällt ein Element in der Praxis durch, fliegt es aus dem Stack, was ich vierteljährlich im Tech Radar dokumentiere.

Wann Next.js die richtige Wahl ist

Personalisierte Seiten, sitzungsgetriebene Flows, A/B-getestete Erlebnisse, transaktionaler Checkout, Echtzeit-Dashboards und authentifizierte Arbeitsbereiche profitieren vom Streaming-SSR- und RSC-Modell. Das mentale Modell lautet: "nahe an den Daten rendern, streamen, was bereit ist, hydrieren, was interaktiv ist". Für passende Seiten liefert Next.js ein UX, das klassisches SSR oder Statik nicht erreicht.

Für Seiten, die nicht passen, sage ich das offen. Inhaltsschwere Marketing-Sites, Blogs und Dokumentationen gewinnen meist auf Astro mit statisch + ISR und niedrigeren Kosten. Die Framework-Entscheidung ist Teil der Umfangsklärung, nicht der Default. Zeigt das Discovery, dass Ihre Website Next.js nicht braucht, hören Sie das direkt, zusammen mit einer günstigeren Empfehlung.

Architektur: WordPress als Back-End, Next.js als Frontend

Im Headless-Setup rendert WordPress keine Seiten mehr und bleibt das, worin es wirklich gut ist: ein redaktionelles System. Das Content-Team arbeitet im vertrauten Panel, mit denselben Rollen, Workflows und redaktionellen Plugins. Next.js holt die Inhalte über REST oder WPGraphQL und rendert sie mit der Strategie, die zur Route passt: Startseite und Landingpages statisch mit Revalidierung, Produktkatalog als ISR mit Webhook-Invalidierung, Checkout und Kundenkonto als SSR mit voller Session.

Drei Elemente entscheiden darüber, ob diese Architektur in der Praxis funktioniert, und alle drei gehören zur Umsetzung. Redaktionelle Vorschau: Redakteure müssen den Entwurf vor der Veröffentlichung sehen, also konfiguriere ich einen Draft Mode mit WordPress-Anbindung, statt dem Team zu erklären, dass "das jetzt nicht mehr geht". Cache-Invalidierung: Eine Veröffentlichung in WordPress löst einen Webhook aus, der genau die betroffenen Routen revalidiert, statt den gesamten Cache zu leeren. Medien-Pipeline: Bilder laufen durch die Next.js-Pipeline mit automatischem AVIF und responsiven Größen, unabhängig davon, was die Redaktion hochgeladen hat.

Performance und Core Web Vitals

Performance in Next.js kommt nicht aus dem Framework, sondern aus Architekturentscheidungen, die das Framework ermöglicht. Streaming-SSR sendet das erste Byte, bevor der Server das Rendern abgeschlossen hat, was TTFB und LCP direkt senkt. Server Components halten die Datenabruflogik auf dem Server, der Client bekommt weniger JavaScript, und INP leidet nicht mehr unter der Hydratation von allem auf einmal. Der Cache am Cloudflare-Edge antwortet vom nächstgelegenen Netzwerkpunkt statt von einem einzelnen Origin-Server.

Jedes Projekt beginnt mit einer Baseline: TTFB, LCP, INP und CLS werden vor der Änderung an echten Nutzern gemessen, nicht im Labor. Nach dem Go-live erhebt RUM dieselben Metriken, verglichen im Side-by-Side-Messfenster. Das Projektergebnis ist die Differenz in den Felddaten, kein Lighthouse-Screenshot. Ein öffentliches Messprotokoll Astro vs Next.js auf WooCommerce, mit offengelegter Methodik, gehört zur Proof-Schicht dieser Website.

WooCommerce headless auf Next.js

Ein Shop ist die anspruchsvollste Headless-Variante, weil er statischen Inhalt mit Live-Transaktionen kombiniert. Produktseiten und Kategorien rendere ich als ISR: schnell wie Statik, per Webhook aktualisiert bei jeder Preis- oder Bestandsänderung. Warenkorb, Checkout und Kundenkonto laufen als SSR mit Session, angebunden an die WooCommerce Store API. Kundenspezifische Preise, B2B-Rabattstaffeln und Kataloge hinter Login, typische Anforderungen im Großhandel, erzwingen keinen Cache-Verzicht für den gesamten Shop mehr, weil die Rendering-Entscheidung auf Routenebene fällt.

Dazu kommt eine Schicht, nach der Shops immer öfter fragen: Bereitschaft für KI-Einkaufsagenten. Sauberes, serverseitig gerendertes HTML mit korrektem Product- und Offer-Schema ist die Eintrittsbedingung dafür, dass ein Agent den Katalog überhaupt sieht. Es ist dieselbe Architektur, die Menschen schnelle Seiten liefert, Sie zahlen also nicht doppelt dafür.

SEO, GEO und AEO in Next.js

Serverseitiges Rendering ist das Sichtbarkeitsfundament, das clientseitiges React nie liefern wird: KI-Crawler wie GPTBot, ClaudeBot oder PerplexityBot führen kein JavaScript aus, und Googlebot tut es verzögert und mit begrenztem Budget. Next.js mit SSR und RSC liefert den vollständigen Inhalt in der ersten HTML-Antwort, was der Nutzer sieht, sieht also auch der Bot.

Auf diesem Fundament baue ich die technische Schicht: Metadata-API pro Route, Canonical und hreflang über metadata.alternates, Sitemap über generateSitemaps, strukturierte Daten als JSON-LD passend zum Seitentyp (Product, Article, FAQPage, HowTo), Open Graph mit pro Seite generierten Bildern. Für Sichtbarkeit in generativen Suchmaschinen ergänze ich GEO-Elemente: Abschnitte mit direkten Antworten, FAQ mit strukturierten Daten, llms.txt und Content Negotiation für Agenten. Jedes Projekt durchläuft vor dem DNS-Cutover eine 30-Punkte-SEO-Checkliste.

Sicherheit und EU-Jurisdiktion

Headless verkleinert die Angriffsfläche auf eine Weise, die sich der Geschäftsführung in einem Satz erklären lässt: WordPress verschwindet aus dem öffentlichen Internet. Login-Panel, XML-RPC und Plugin-Dateien sind für Scanner nicht mehr erreichbar, weil Next.js das Frontend ausliefert und der Origin ausschließlich für dieses erreichbar ist. Dazu kommen zentral konfigurierte Security-Header, serverseitige Validierung aller Eingaben und Secrets außerhalb des Repositorys.

Für Unternehmen im Geltungsbereich von DSGVO, NIS2 oder DORA zählt auch die Datengeografie: Runtime auf Cloudflare mit Verarbeitung in der EU, Auftragsverarbeitungsverträge in englischer oder polnischer Sprache, dokumentierte Datenflüsse für das Verzeichnis von Verarbeitungstätigkeiten. Ein B2B-Vertrag in europäischer Jurisdiktion, keine Plattform-AGB von außerhalb.

Für wen das gedacht ist

• WooCommerce-Stores mit individuellem Checkout oder nutzerspezifischer Preislogik
• SaaS-Dashboards und authentifizierte Arbeitsbereiche mit WordPress als Inhaltsschicht
• Multiregionale Marken, die ISR mit Webhook-getriebener Invalidierung benötigen
• Redaktionelle Publisher mit Live-Datenfeeds, Kommentaren oder Echtzeit-Analytics-Oberflächen
• B2B-Großhändler mit Katalogen hinter Login und pro Kunde verhandelten Preislisten

Zusammenarbeitsmodell

Senior-B2B-Verträge in EU-Jurisdiktion. Vier Phasen: Discovery mit Content-Audit und Performance-Baseline, Umfangsklärung mit Rendering-Entscheidungen pro Route, iterativer Build mit wöchentlichen Demos und Side-by-Side-Messfenster, schließlich Tuning und Retainer mit Observability und vierteljährlichen Stack-Reviews. Festpreis- oder Time-and-Materials-Engagement. Preisgestaltung individuell, Zeitplan pro Etappe mit Entscheidungspunkten.