Statisches Rendering (SSG) vs. WordPress-Datenbank

Würdigung — was „statisch" wirklich heißt#

„Statisch" klingt nach „unflexibel" — ist aber das Gegenteil eines Nachteils. Es beschreibt nur den Zeitpunkt, zu dem die Seite gebaut wird. Bei Static Site Generation (SSG) entsteht die fertige HTML-Seite einmal zur Build-Zeit, beim Veröffentlichen. Was der Besucher abruft, ist eine bereits fertige Datei. Bei einem klassischen WordPress-Setup entsteht die Seite dagegen erst im Moment des Aufrufs: WordPress fragt die Datenbank ab, führt PHP-Code aus, setzt das HTML zusammen — bei jedem einzelnen Besuch erneut.

Die Inhalte sind dabei keineswegs eingefroren. Wenn sich etwas ändert, wird neu gebaut und neu veröffentlicht — bei uns automatisch bei jedem Git-Push. Der Unterschied ist nicht „änderbar vs. nicht änderbar", sondern „einmal vorgebaut vs. bei jeder Anfrage neu gerechnet".

Für eine Steuerkanzlei sind die Folgen dieses Unterschieds handfest — in den zwei Dimensionen, die zählen: Sicherheit und Tempo.

Keine Datenbank, keine SQL-Injection — die Sicherheits-Seite#

Die häufigste Angriffsklasse gegen datenbankgestützte Websites ist die SQL-Injection: Ein Angreifer schleust über ein Eingabefeld Datenbank-Befehle ein und liest oder verändert Daten. Eine statisch gerenderte Seite ohne Datenbank im Anfrage-Pfad bietet dieser Angriffsklasse schlicht kein Ziel — es gibt keine Live-Datenbank, die man manipulieren könnte, und keinen serverseitigen Interpreter, der eingeschleusten Code ausführt.

Das Gleiche gilt für die Plugin-Angriffsfläche: Wo kein Plugin-Park mit Datenbank-Zugriff läuft, kann auch keine Plugin-Lücke zur Einfallstür werden. Die Angriffsfläche schrumpft nicht durch zusätzliche Schutz-Werkzeuge, sondern dadurch, dass die verwundbaren Teile gar nicht erst existieren. Das ist Sicherheit durch Architektur statt durch Nachrüstung — und für eine Kanzlei, die hinter dem Kontaktformular Mandanten-Daten unter § 203 StGB verantwortet, der ruhigere Weg.

Wichtig zur Ehrlichkeit: „keine Angriffsfläche" gibt es nie absolut. Auch eine statische Seite braucht saubere Schutz-Header und einen sicheren Pfad für das Kontaktformular. Aber die größten und meistgenutzten Angriffsklassen fallen strukturell weg.

Vorgerendert = schnell — die Performance-Seite#

Eine fertige HTML-Datei kann ohne Datenbank-Abfrage und ohne PHP-Ausführung ausgeliefert werden — und sie lässt sich ideal im CDN-Cache am Netz-Rand vorhalten. Das senkt die Antwortzeit (Time to First Byte) deutlich und stabilisiert sie auch unter Last: Ein Besucher-Ansturm, der einen WordPress-Server mit Datenbank in die Knie zwingt, lässt eine statische Seite vom CDNCDN · zum GlossarContent Delivery Network — globales Netzwerk an Edge-Servern, das statische Inhalte ortsnah ausliefert. kalt.

Das wirkt direkt auf die Core Web Vitals und damit auf das Google-Ranking. Eine schnell und gleichmäßig ausgelieferte Seite hat den Performance-Vorsprung nicht durch Optimierungs-Tricks, sondern durch die Bauweise.

Wann SSR/ISR trotzdem nötig sind — die ehrliche Abgrenzung#

SSG ist nicht für alles richtig. Es gibt Fälle, in denen Inhalte erst im Moment der Anfrage entstehen müssen:

• Server-Side Rendering (SSR): für Seiten, die pro Anfrage individuell sind — etwa ein eingeloggter Bereich oder ein personalisiertes Mandanten-Portal.
• Incremental Static Regeneration (ISR): für Seiten, die meist statisch sein können, sich aber regelmäßig ändern, ohne dass man bei jeder Änderung komplett neu baut.

Eine Kanzlei-Marketing-Website mit Leistungen, Profil, Insights und Kontakt ist der klassische SSG-Fall: Die Inhalte ändern sich überschaubar oft, und jede Änderung kann einen sauberen Neubau auslösen. Erst wenn echte Interaktivität dazukommt — ein Login, ein Dokumenten-Upload, ein personalisiertes Dashboard — wird SSR sinnvoll. Diese Teile lassen sich dann gezielt dynamisch bauen, während der Rest der Seite statisch bleibt. Architektur heißt, pro Seite die richtige Render-Strategie zu wählen, nicht dogmatisch alles statisch oder alles dynamisch zu machen.

Wie wir fahoch2.de bauen#

Unsere Seite ist überwiegend statisch vorgerendert. Die Insight-Artikel etwa werden über generateStaticParams zur Build-Zeit als fertige HTML-Seiten erzeugt — beim letzten Build siebzehn Stück, jede als eigene statische Seite. Im Build-Report sind sie mit dem SSG-Marker ausgewiesen. Nur dort, wo es wirklich Dynamik braucht — das URL-Audit-Tool, der Onboarding-Pfad, OG-Bilder — läuft serverseitiger Code. Das ist die bewusste Mischung: statisch, wo möglich; dynamisch, wo nötig. Wie sich diese Mischung in einer modernen Repo-Architektur niederschlägt und was beim Build daraus entsteht, beschreiben eigene Insights.

Für eine vollständige Bewertung des Tech-Stacks — Architektur, Angriffsfläche, Performance — empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Statisches Rendering baut die Seite einmal vor, statt sie bei jeder Anfrage aus einer Datenbank zusammenzusetzen. Das hat zwei konkrete Folgen: Die größten Angriffsklassen — SQL-Injection, Plugin-Lücken — fallen mangels Datenbank und Plugin-Park strukturell weg, und die vorgebaute Seite lädt schnell und gleichmäßig, weil sie sich ideal im CDN cachen lässt. SSG ist nicht für alles richtig: Login-Bereiche und personalisierte Inhalte brauchen SSR. Die Kunst ist, pro Seite die richtige Strategie zu wählen. Eine Kanzlei-Marketing-Website ist der klassische SSG-Fall — Sicherheit und Tempo kommen hier nicht aus Nachrüstung, sondern aus der Bauweise.

Quellen#

• Next.js — generateStaticParams (statisches Rendering) — abgerufen 2026-05-29
• Next.js — Static Exports — abgerufen 2026-05-29
• OWASP Top 10 — A03:2021 Injection — abgerufen 2026-05-29
• Google web.dev — Core Web Vitals — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung. Die richtige Render-Strategie hängt vom konkreten Funktionsumfang einer Seite ab; dies ist keine pauschale Technik-Empfehlung für jeden Einzelfall.