Code & Architektur · Leitfaden
Wie eine Website gebaut ist, entscheidet über alles andere.
Eine Kanzlei-Website ist kein Theme im Verzeichnis wp-content. Sie ist eine versionierte Codebasis mit Architektur, Werkzeugen und Qualitäts-Schranken. Diese Schichten entscheiden über Tempo, Wartbarkeit und Sicherheit — über Jahre, nicht über die ersten drei Monate nach dem Launch. Vier Bau-Schichten, die zusammen den Unterschied machen.
💼 Quick Wins
Drei Hebel, die Sie in unter 30 Minuten selbst prüfen können
- Im Browser-Quelltext (Strg+U) nach generator-Meta-Tag suchen — verrät das CMS.
- Eigene Site auf pagespeed.web.dev: Hat sie eine Datenbank-Last-Spitze unter Last?
- package.json oder Theme-Header öffnen: läuft hier ein modernes Framework oder ein 8 Jahre altes Theme?
Tipp: Wenn Sie keine 30 Minuten haben — unser kostenfreier URL-Audit prüft die offensichtlichsten Marker in 90 Sekunden, ohne Daten- Abfluss.
I. Die Bauweise: statisch oder dynamisch
Die fundamentalste Entscheidung ist, wann die Seite zusammengebaut wird. Bei klassischen CMS wie WordPress passiert das bei jeder Besucher-Anfrage live aus einer Datenbank — mit allen Folgen für Geschwindigkeit, Angriffsfläche und Wartungsaufwand. Bei statisch gerenderten Sites passiert es einmal vorab beim Build; die Besucher bekommen fertige Dateien aus dem CDN.
Für eine Kanzlei-Website mit überschaubarer Änderungs-Frequenz ist statisches Rendering die saubere Wahl — schneller, sicherer, einfacher zu betreiben. Die Frage, wo im Code-Repository was lebt, wird damit zur entscheidenden Architektur-Frage — nicht zur Theme-Frage.
II. Die Werkzeuge: Build-Pipeline und Typsicherheit
Eine moderne Kanzlei-Site bringt ihre Qualitäts-Mechaniken vor das Live-Gehen — nicht danach. `npm run build` durchläuft sechs Stufen, von TypeScript-Typprüfung über ESLint bis zur Asset-Optimierung. Jede Stufe kann den Build stoppen; was rot ist, geht nie live.
TypeScript im strict-Modus ist der vielleicht wichtigste einzelne Hebel: Statt Datenfeld-Tippfehler beim Mandanten als kaputtes Layout aufzufallen, wird der Build rot — eine Minute vor dem Push, nicht zwei Wochen nach dem Live-Gang. Telefon-Tickets sinken strukturell.
III. Die Qualitäts-Schranken: Linter und Hooks
Vor jedem Commit läuft eine Reihe automatischer Prüfungen: Voice-Linter gegen Marketing-Slop, ESLint inklusive Barrierefreiheits-Plugin, DSE-Konsistenz-Linter gegen Drift zwischen Datenschutzerklärung und Code. Was die Hooks fangen, landet gar nicht erst in der Historie — strukturell verhindert statt im Review entdeckt.
Dieser Workflow wird zusätzlich durch KI-Assistenz beschleunigt: VS Code mit Claude Code im Hintergrund schreibt Vorschläge, die durch dieselben Schranken laufen wie händische Edits. KI ist Hebel, kein Ersatz für Bau-Verantwortung — und genau diese Schranken machen den Unterschied.
IV. Die Inhalts-Kontrolle: Drittanbieter, Fonts, Pflege
Was eine Site lädt und an externe Server schickt, ist eine Architektur-Frage, nicht eine Inhalts-Frage. Self-hosted Fonts statt Google-CDN beseitigen den bekanntesten Datenschutz-Klassiker; ein bewusst geführtes Drittanbieter-Inventar verhindert, dass über Jahre stille Tracker und Widgets das System unterwandern.
Dass das Kontaktformular ohne klassischen Backend-Server läuft (Edge-Funktion + Server Action), ist konsequente Fortsetzung: keine Datenbank, kein WordPress-Plugin, keine eigene Server-Wartung. Und die operative Pflege — Saison-Banner, veraltete Hinweise — wird über Komponenten-Logik strukturell gelöst, nicht über Disziplin.
📥 Lead-Magnet
Architektur-Standortbestimmung
Sechs Fragen zu Stack, Deploy-Prozess, Updates und Code-Hoheit — wir mailen Ihnen eine PDF-Einschätzung mit konkreten Hebeln und Aufwand-Schätzung.
Eigenpraxis
Wie wir es bauen
fahoch2.de läuft als statisch gerenderte Next.js-Site mit strict-TypeScript, MDX-basierten Insight-Inhalten, drei eigenen Pre-Commit-Lintern (Voice, DSE-Konsistenz, Anti-Leak-Hash-Blocklist) und einer KI-gestützten Inhalts-Pipeline. Die Repo-Struktur ist im Ordner-Architektur-Insight 1:1 dokumentiert — was hier steht, ist im Repository belegbar.
Wenn Sie das in Ruhe besprechen möchten
Lassen Sie uns 30 Minuten zur Lage Ihrer Kanzlei sprechen.
Erst gratis-Vorprüfung über das URL-Tool — dann entscheiden Sie, ob ein 890-€-Hebel-Audit für Sie Sinn ergibt.
Alle Artikel der Rubrik Code & Architektur
12 Insights, nach Datum sortiert.
Glossar: Web-Tech und Web-Recht für Kanzleien
10. Juni 2026 · 12 Min
Pillar-Pages: Hub-and-Spoke-SEO im echten Kanzlei-Repo
08. Juni 2026 · 9 Min
Edge-Funktionen und Server Actions — ohne PHP-Server
05. Juni 2026 · 8 Min
Was passiert bei npm run build? Die Next.js-Pipeline
05. Juni 2026 · 8 Min
Tour durch das Repo einer modernen Kanzlei-Website
05. Juni 2026 · 9 Min
Pre-Commit-Hooks: die Schranke gegen schlechte Inhalte
05. Juni 2026 · 8 Min
TypeScript: strikte Typen gegen Telefon-Tickets
05. Juni 2026 · 8 Min
VS Code + Claude Code: KI-Coding-Workflow
05. Juni 2026 · 9 Min
Der Weihnachts-Banner im Juni — Pflege-Hygiene
31. Mai 2026 · 8 Min
Drittanbieter-Skripte — das versteckte Datenleck
29. Mai 2026 · 10 Min
Self-hosted Fonts mit next/font — der DSGVO-Fall gelöst
29. Mai 2026 · 10 Min
Statisches Rendering (SSG) vs. WordPress-Datenbank
29. Mai 2026 · 11 Min