Next.js SSG für SEO: Warum Build-time Static 2026 gewinnt

SEO-Vorteile: Crawlability, TTFB und Core Web Vitals

Suchmaschinen und generative Systeme brauchen denselben Text, den Menschen lesen. Bei SSG liegt dieser Text im HTML. Es gibt kein Warten auf Client-Hydration, bevor H1, Absätze und interne Links sichtbar sind. Canonical, Meta-Description und strukturierte Daten stehen im ersten Dokument — nicht in einem nachgeladenen JSON.

Time to First Byte (TTFB) sinkt typischerweise, weil die Antwort von einem CDN-Edge kommt statt von einer PHP- oder Node-Instanz mit Datenbank. Das ist kein Garant für Rankings, aber eine Voraussetzung dafür, dass Largest Contentful Paint und Interaction to Next Paint überhaupt erreichbar bleiben. Shared Hosting mit langsamer Origin-Antwort macht Frontend-Optimierung oft zunichte; statische Auslieferung umgeht diesen Flaschenhals.

Core Web Vitals messen das Nutzererlebnis in Felddaten. Google definiert auf web.dev Schwellenwerte für „gut“: Largest Contentful Paint (LCP) unter 2,5 Sekunden, Interaction to Next Paint (INP) unter 200 Millisekunden, Cumulative Layout Shift (CLS) unter 0,1. SSG hilft vor allem bei LCP und TTFB, weil der kritische HTML-Pfad kurz ist. INP bleibt eine Frage des JavaScript-Budgets — Page-Builder mit großen Bundles reißen diesen Wert auch auf schnellem Hosting.

Wann SSG nicht passt

Nicht jedes Produkt ist eine Marketing-Site. Sobald der sichtbare Inhalt vom eingeloggten Nutzer, von Session-Cookies oder von Echtzeitdaten abhängt, liefert Build-time Static die falsche Antwort. Ein Kundenportal, das Auftragsstatus aus dem ERP zeigt, kann nicht sinnvoll als hunderttausend statische HTML-Dateien gebaut werden — und soll es auch nicht.

Stark personalisierte Preislisten, A/B-Tests mit serverseitiger Variantenwahl, Warenkörbe mit Bestandsabfrage und Dashboards mit Berechtigungen gehören in SSR, Server Components oder eine separate Web-App. Next.js erlaubt genau diese Mischform: die öffentliche Firmenwebsite bleibt SSG, der Login-Bereich wird dynamisch gerendert.

Auch redaktionelle Systeme mit stündlichen News-Updates können SSG belasten, wenn jeder Artikel einen Voll-Rebuild der gesamten Site auslöst. Dann helfen gezielte Revalidation, partielle Builds oder ein Headless-CMS mit On-Demand-Rebuild einzelner Pfade — nicht der Rückfall auf CSR. Die Faustregel bleibt: Ändert sich der Inhalt selten und ist er für alle Besucher gleich, gewinnt SSG. Ändert er sich pro Request und pro Nutzer, gewinnen Server oder Client.

Next.js App Router: generateStaticParams und Metadata

Im App Router (Next.js 16) beschreiben Dateien unter app/ die Routen. Für dynamische Segmente wie app/ratgeber/[slug]/page.tsx exportieren Sie generateStaticParams: Die Funktion liefert zur Build-Zeit die Liste aller Slugs, für die HTML entstehen soll. Fehlt der Eintrag, existiert die Seite nicht als statisches Artefakt — ein bewusstes Gate gegen Thin Content und tote URLs.

generateMetadata (oder das statische metadata-Objekt) erzeugt Title, Description, Open-Graph-Tags und Canonical pro Seite. Bei Hirnworx kommen diese Felder aus typisierten Content-Modulen: dieselbe Post-Struktur, die den sichtbaren Text speist, füllt auch die Metadaten. So können Länge und Inhalt nicht auseinanderlaufen, weil Redaktion und SEO-Felder keine getrennten CMS-Formulare sind.

Praktisch bedeutet das für ein Ratgeber-System: posts ist ein Array typisierter Objekte; generateStaticParams mappt jeden slug; die Page-Komponente lädt den Post und rendert Abschnitte, FAQ und Quellen. Beim Deploy entstehen hunderte HTML-Dateien — jede mit eigenem Title und eigener Description — ohne dass jemand 250 CMS-Einträge von Hand pflegt. Dasselbe Muster trägt Stadt- und Leistungsseiten.

Schema.org aus dem Code statt aus Plugin-Raten

Strukturierte Daten entscheiden mit darüber, ob Suchmaschinen und AI-Systeme eine Seite als zitierbare Quelle behandeln. Bei WordPress hängen FAQ-, LocalBusiness- oder Article-Markups oft an Plugins, die Felder doppelt pflegen oder veraltete Typen ausspielen. Im code-basierten Ansatz erzeugt dieselbe Funktion, die den FAQ-Block rendert, auch das FAQPage-JSON-LD — Drift ist architektonisch ausgeschlossen.

Für Hirnworx-Seiten typisieren wir Seitentypen: BlogPosting und WebPage für Ratgeber, Service und BreadcrumbList für Leistungshubs, FAQPage wo Fragen existieren. Die Generatoren leben in lib/seo und werden von der Page-Komponente eingebunden. Jede Änderung am sichtbaren FAQ aktualisiert das Markup beim nächsten Build automatisch.

Das ist kein Selbstzweck. Generative Suche und klassische Rich Results belohnen konsistente, vollständige Daten. Ein Schema, das einen anderen Text behauptet als die Seite, ist schädlicher als keines. Deshalb gehört Schema in den Build, nicht in ein nachträglich aktiviertes SEO-Plugin mit Default-Texten.

Sitemap und robots aus der Build-Pipeline

Eine Sitemap ist nur so gut wie die Regel, die URLs aufnimmt. Bei SSG kennen Sie zur Build-Zeit jede erzeugte Route. Daraus folgt eine Sitemap, die exakt die indexierbaren Seiten listet — ohne tote CMS-Entwürfe und ohne Parameter-URLs, die nie gerendert wurden.

robots.txt und robots-Meta-Tags steuern, was angeboten wird. Auf Landingpage-Systemen entscheidet bei uns eine Indexierbarkeits-Prüfung im Code: Seiten ohne ausreichend eigenen Inhalt bleiben erreichbar, landen aber nicht in der Sitemap und tragen noindex, wo nötig. Das ist der Unterschied zwischen einem Hub-and-Spoke-System und einer Seitenschleuder.

Nach dem Deploy melden wir Änderungen zusätzlich über IndexNow und prüfen die Abdeckung in der Google Search Console. Die technische Kette lautet: typisierte Daten → statische HTML-Dateien → Sitemap und robots → Push und Monitoring. Kein Schritt hängt an einem manuellen „Sitemap neu erzeugen“-Klick im Backend.

Vergleich: Baukasten, WordPress und Next.js SSG

Alle drei Wege sind legitim. Die Frage ist Seitenanzahl, Änderungsfrequenz und Anspruch an Sichtbarkeit — nicht, welches Tool gerade hip ist. Unter zehn Seiten ohne SEO-Ziel ist ein Baukasten oft die ehrlichere Wahl. Zwischen zehn und fünfzig Seiten mit Redaktionsbetrieb funktioniert WordPress, wenn Updates und Plugins diszipliniert laufen. Ab echtem Sichtbarkeitsziel, eigener Logik oder dreistelliger Seitenanzahl rechnet sich code-basiertes SSG.

Die folgende Tabelle verdichtet die Kriterien, die in Angebotsvergleichen sonst untergehen. Einstiegskosten allein sagen wenig: Wer später 200 Stadtseiten braucht, zahlt bei Baukasten und Builder die Skalierung in Redaktionszeit und Thin-Content-Risiko.

Core Web Vitals: LCP 2,5 s und INP 200 ms als Planungsgröße

Google veröffentlicht die Schwellenwerte für Core Web Vitals auf web.dev. Ein „gutes“ Largest Contentful Paint liegt unter 2,5 Sekunden; Interaction to Next Paint unter 200 Millisekunden gilt als gut (INP hat im März 2024 First Input Delay abgelöst). Diese Zahlen sind Planungsgrößen für Architektur und Budget — keine Marketing-Claims über „X-mal schneller“.

SSG adressiert den HTML- und TTFB-Anteil des LCP. Der Rest ist Handwerk: Bildformate und Größen, Priorität des LCP-Elements, Schriftladen ohne Layoutsprung, Vermeidung blockierender Third-Party-Skripte. INP leidet vor allem unter großen JavaScript-Bundles und teuren Event-Handlern — typisch für visuelle Page-Builder mit Dutzend Plugins.

Messgrundlage sollten Felddaten sein (Chrome UX Report / Search Console), nicht nur ein einmaliger Lighthouse-Lauf auf einem schnellen Rechner. Wir planen Performance-Budgets im Projekt und prüfen nach dem Go-Live im Monitoring-Fenster. Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz (BFSG) zudem für viele Verbraucherangebote barrierefreie digitale Angebote — semantisches HTML aus dem SSG-Build ist dafür die bessere Ausgangslage als nachträglich geflickte Builder-Markups.

Hosting: CDN-Plattformen wie Vercel und qualitative Alternativen

Statische Sites brauchen kein klassisches Shared Hosting mit PHP und MySQL. Sie brauchen ein CDN, das HTML und Assets am Edge ausliefert, Preview-Deployments für Reviews und eine Pipeline, die bei jedem Git-Push einen Build startet. Vercel ist dafür der natürliche Partner von Next.js: Preview-URLs, Edge-Netzwerk, Analytics und Speed Insights ohne Extra-Stack.

Qualitativ vergleichbar sind andere CDN- und Static-Hosts mit Build-Hooks — entscheidend ist nicht das Logo, sondern: HTTPS und HTTP/2 bzw. HTTP/3, globale Edge-Präsenz, atomare Deployments, Rollback und Logs. Shared Hosting mit Time to First Byte über einer Sekunde bleibt der Flaschenhals, egal wie schlank das Frontend ist.

Betriebskosten für Hosting und kleines Änderungsbudget beginnen bei Hirnworx-Projekten ab etwa 150 € im Monat (Abhängigkeits-Updates, Monitoring, CDN). Das ist der günstigste Teil des Lebenszyklus und der, an dem am häufigsten gespart wird — mit dem Risiko, dass der Stack nach zwei bis drei Jahren nicht mehr wirtschaftlich aktualisierbar ist.

Migration von WordPress oder Baukasten ohne Ranking-Verlust

Der häufigste vermeidbare Schaden beim Umstieg auf Next.js SSG ist ein Relaunch ohne Weiterleitungskonzept. Neue URLs, kein Mapping der alten Adressen, Sammelweiterleitung auf die Startseite — danach Fehlerseiten in der Search Console und Monate Erholungszeit für organischen Traffic.

Vor dem Umbau exportieren wir indexierte URLs aus der Search Console und aus einem Crawl sowie die organischen Einstiegsseiten der letzten zwölf Monate. Daraus entsteht eine 301-Matrix auf inhaltliche Gegenstücke. Seiten ohne Pendant bekommen eines oder werden bewusst mit 410 abgeschaltet. Nach dem Go-Live läuft ein Monitoring-Fenster von sechs bis acht Wochen: Abdeckung, Fehler, Rankings und Core Web Vitals.

Inhaltlich lohnt der Umstieg, Inhalte nicht 1:1 zu klonen, wenn sie Thin Content waren. Programmatische Stadtseiten brauchen eigenen Textkörper — sonst reproduzieren Sie das Indexierungsproblem nur in einem schnelleren Stack. Migration als Kostentreiber liegt bei uns typisch bei 1.500–5.000 € zusätzlich, weil Redirect-Map und Abgleich Arbeit sind, keine Checkbox.

Checkliste: Wann Sie Next.js SSG beauftragen sollten

Nutzen Sie die folgende Liste als Entscheidungs- und Briefing-Hilfe. Wenn die meisten Punkte zutreffen, ist Build-time Static die passende Architektur — unabhängig davon, ob Sie Hirnworx oder ein anderes Team beauftragen.