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

SSG liefert HTML zur Build-Zeit — kein Runtime-DB-Overhead, LCP unter 2s, perfekt crawlbar. Hirnworx setzt auf Next.js App Router ohne CMS für SEO-Content.

Metadata, Canonicals und Sitemap werden aus dem Code generiert — eine Quelle der Wahrheit. Über 250 statische Seiten auf hirnworx.de (Stand Juli 2026).

Warum nicht WordPress?

Page-Builder und Plugin-Stacks verschlechtern CWV. Für programmatische Stadtseiten (250+ URLs) ist Code-basiertes SSG wartbarer als 250 CMS-Einträge.

Hinzu kommt die Angriffsfläche: Jedes WordPress-Plugin ist ein potenzielles Sicherheitsrisiko und ein Wartungsvertrag mehr. Eine statisch ausgelieferte Next.js-Site hat keine Datenbank im Frontend, die kompromittiert werden könnte — das reduziert Betriebsaufwand und Risiko spürbar.

Schema.org & strukturierte Daten aus dem Code

Rich Results und AI-Zitierbarkeit hängen an sauberen strukturierten Daten. Bei einem code-basierten Ansatz werden Breadcrumb-, Service-, FAQPage- und Organization-Schema aus denselben Datenquellen generiert wie der sichtbare Inhalt — sie können also nicht auseinanderlaufen.

Für generative Suche (Google AI Overviews, ChatGPT, Perplexity) ergänzen wir eine llms.txt und Answer-first-Absätze. So wird jede Seite sowohl für klassische Rankings als auch für AI-Antworten optimal aufbereitet.

Wann SSR oder ISR sinnvoll ist

SSG ist ideal für Inhalte, die sich selten ändern — Marketing-Seiten, Ratgeber, Stadtseiten. Für hochdynamische Bereiche (Login, personalisierte Dashboards, Live-Preise) setzt Next.js Server Components und Server-side Rendering ein.

Incremental Static Regeneration (ISR) verbindet beide Welten: statisch ausgeliefert, aber im Hintergrund periodisch neu gebaut. So bleiben große Shops mit tausenden Produkten schnell, ohne bei jedem Build komplett neu generiert zu werden.