Tour durch das Repo einer modernen Kanzlei-Website

Würdigung — eine Website ist ein Bauwerk, kein Theme#

Bei einer WordPress-Site lebt fast alles in einem einzigen Theme-Verzeichnis: Templates, Bilder, CSS, Plugin-Konfiguration. Das ist für schnelle Standard-Sites praktisch und für genau diesen Anwendungsfall auch sinnvoll. Sobald eine Site aber Architektur tragen muss — eigenes Design, eigene Komponenten, eigene Inhaltsfelder, eigene Build-Schritte —, wird der Theme-Ansatz schnell zur Engstelle: Alles wandert in immer größere Funktions-Dateien, eine Änderung an einer Stelle riskiert Nebenwirkungen an anderer.

Eine gebaute Kanzlei-Site geht den umgekehrten Weg. Jeder Top-Level-Ordner hat eine klare Verantwortung; Verantwortlichkeiten sind so geschnitten, dass eine Änderung an einem Ort möglichst genau dort bleibt. Das ist nicht akademisch — es ist der Grund, warum eine drei Jahre alte Site noch wartbar ist, ohne dass sich jemand erst „eindenken" muss.

Die Top-Level-Ordner einer Next.js-Kanzlei-Site#

Eine Tour durch das echte fahoch2.de-Repository (Next.jsNext.js · zum GlossarReact-Framework für SSG/SSR/ISR — der aktuelle Standard für moderne Kanzlei-Sites. 16 mit App Router, TypeScriptTypeScript · zum GlossarJavaScript mit statischer Typprüfung — fängt Tippfehler und Datenform-Bruch beim Build statt im Produktivbetrieb., Tailwind):

• src/ — der gesamte produktive Code: Routen, Komponenten, Inhalt-Daten, kleine Helper-Bibliotheken. Was hier liegt, wird vom Build verarbeitet und landet im finalen Bundle (oder als statisches HTML).
• public/ — statische Assets, die 1:1 an die URL ausgeliefert werden: Logo, Open-Graph-Bilder, Schriftarten, Roboter-Anweisungen für Suchmaschinen, eigene PDFs (z. B. Sales-Onepager). Was hier liegt, ist öffentlich abrufbar — Vorsicht mit allem, was nicht öffentlich werden soll.
• docs/ — interne Dokumentation: Strategie, Audits, technische Runbooks, SEO-Pipeline, Briefings. Wird vom Build NICHT angefasst, ist aber Bestandteil des Repos — damit ist die Doku der Site immer im selben Stand wie der Code (statt in einem separaten Tool, das schnell ausläuft).
• scripts/ — eigene kleine Werkzeuge: ein Voice-Linter, der Marketing-Phrasen abfängt, ein Legal-Linter, der die Konsistenz von Paragraphen-Verweisen prüft, ein Audit-PDF-Renderer. Diese Werkzeuge sind keine Abhängigkeit aus dem Netz, sondern projekt-eigene Skripte — sie laufen lokal und im Pre-Commit-Hook.
• .husky/ — Pre-Commit-/Pre-Push-Hooks, die vor jedem Commit prüfen, ob bestimmte Mindeststandards erfüllt sind (z. B. ob ein Insight-Slug auch im Cluster-Mapping eingetragen ist). Verhindert, dass schlechte Inhalte oder kaputter Code überhaupt erst in die Historie kommen — Details im Pre-Commit-Insight.
• .claude/ — Skill-Konfigurationen für unseren KI-Werkstatt-Workflow (z. B. ein projektleiter-Skill für das tägliche 6-Uhr-Briefing, ein fa2-lektor-Skill für die Insight-Qualitätsprüfung). Im Repo, weil die KI-Konfiguration zur Site gehört und sich mitversionieren lassen muss.
• tests/ — automatisierte Prüfungen (Vitest), die Funktion und Vertrags-Eigenschaften der Site sichern — von der CSP-Header-Konfiguration bis zur korrekten Markdown-Verarbeitung.
• Config-Dateien im Wurzel-Verzeichnis — next.config.ts (Build-Konfiguration, Sicherheits-Header), tsconfig.json (TypeScript-Strenge), eslint.config.mjs (Code-Standards), package.json (Abhängigkeiten + Scripts). Jede dieser Dateien hat einen klaren Zweck und gehört bewusst in den Wurzel-Pfad.
• node_modules/ und tsconfig.tsbuildinfo — Abhängigkeiten und Build-Caches. NICHT in der Versionskontrolle (über .gitignore ausgeschlossen), wird beim Build automatisch wiederhergestellt.

Was im src/-Verzeichnis lebt#

src/ ist die wichtigste Adresse. Die Sub-Struktur folgt der Next.js-App-Router-Konvention plus klare Trennung von Komponenten, Daten und Hilfsbibliotheken:

• src/app/ — jede Route der Site ist hier ein eigener Ordner (src/app/insights/[slug]/page.tsx rendert /insights/<slug>). Auch globale Stile, Layout-Wrapper und Schema.org-Markup leben hier. Der App Router ist ab Next.js 13.4 die kanonische Variante — der ältere Pages Router (src/pages/) gilt als Auslaufmodell für Neubau-Projekte.
• src/components/ — wiederverwendbare UI-Bausteine: Header, Footer, Buttons, Insight-Browser, Markdown-Renderer. Jede Komponente ist eigenständig testbar und einzeln änderbar — eine Änderung am Footer betrifft nicht versehentlich das Hero.
• src/data/ — strukturierte Inhalte: Insight-Artikel, Cluster-Mapping, Stadt-Landingpage-Konfiguration, rechtliche Quellen-Verzeichnisse. Was hier lebt, ist Daten für die Site — nicht zur Anzeige formuliert, sondern als TypeScript-Objekte, die Komponenten dann rendern.
• src/lib/ — kleinere Hilfsbibliotheken: Helper für die OG-Image-Generierung, PDF-Building-Funktionen, Hash-Utilities. Das ist die Werkzeug-Ecke des Codes.
• src/styles/ (bei uns leichtgewichtig, das meiste lebt in src/app/globals.css) — globale CSS-Variablen, Typografie-Defaults, Druckstil. Tailwind übernimmt den Rest auf Komponenten-Ebene.

Warum diese Trennung über Jahre wartbar bleibt#

Drei Effekte, die sich erst nach Monaten zeigen — aber dann sehr deutlich:

• Lokale Änderungen bleiben lokal. Eine Anpassung am Insight-Layout berührt nur src/app/insights/[slug]/page.tsx und einige Komponenten. Sie geht NICHT durch fünf zusammenhängende Theme-Funktionen, weil es solche Knoten in dieser Architektur nicht gibt.
• Inhalt und Logik sind getrennt. Inhalte (Insight-Artikel, Stadt-Landingpages, rechtliche Quellen) leben in src/data/ — sie können geändert werden, ohne Komponenten anzufassen. Umgekehrt kann eine Komponenten-Verbesserung die Inhalte unangetastet lassen. Das ist der strukturelle Grund, warum Pflege-Updates schnell und risikoarm bleiben.
• Neue Mitspieler finden sich zurecht. Eine zweite Entwicklerin, ein neuer KI-Assistent, eine Übergabe an einen anderen Dienstleister — alle profitieren davon, dass die Verantwortlichkeiten an den Ordnernamen ablesbar sind. „Wo gehört diese Änderung hin?" ist eine Frage mit klarer Antwort, nicht eine mit fünf möglichen.

Das ist der Mehrwert einer gebauten Site gegenüber einem zusammengeklickten Theme: Sie altert in Würde.

Was bei einer Kanzlei-Site besonders zu beachten ist#

Drei kanzlei-spezifische Punkte, die in der Architektur sichtbar werden:

• Sensibilitäts-Trennung sichtbar machen. In public/ darf nichts liegen, was nicht öffentlich werden soll — kein Vor-Vertrag, keine Mandanten-Liste, kein Audit-Entwurf. Wir prüfen das beim Bau mit einer Konvention (docs/sales-kit/ ist privat, public/sales-kit/ öffentlich) plus einem Vorlauf-Lint, der vor Push warnt, wenn etwas aus dem privaten Bereich öffentlich wandert. Berührt direkt § 203 StGB.
• Inhalt-Daten als eigene Schicht. Anders als bei Theme-Sites, wo der Text oft direkt im Template steht, leben unsere Texte in src/data/ — als TypeScript-Objekte mit klaren Feldern. Das macht spätere Korrekturen (Datenschutzerklärung aktualisieren, Stadt-Landingpage anpassen) zur reinen Inhalts-Arbeit, ohne Code-Risiko.
• KI-Konfiguration im Repo statt im Kopf. Wir versionieren unsere Skill-Definitionen für die KI-Werkstatt im .claude/-Ordner mit. So bleibt der KI-gestützte Arbeitsfluss reproduzierbar — wer das Repo klont, hat denselben Werkstatt-Stand wie wir, nicht bloß den Code.

Wie wir es bauen#

Bei jedem neuen Kanzlei-Projekt legen wir zuerst diese Top-Level-Ordner mit einer leeren README-Datei an, die den Zweck des Ordners auf zwei Sätzen festhält. Erst dann beginnt der eigentliche Code. Das wirkt überformell, ist aber der schnellste Weg, Konsistenz über Wochen Bau-Zeit zu sichern — auch wenn neue Personen oder ein neuer KI-Assistent dazukommen. Ergänzt wird das durch eine Pre-Commit-Hook-Schicht, die verhindert, dass Inhalte in den falschen Ordnern landen.

Für eine strukturierte Bewertung der Architektur einer bestehenden Site (Theme-Erkennung, Wartbarkeits-Marker, Sensibilitäts-Trennung) empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Eine moderne Kanzlei-Website ist nicht ein Theme, sondern ein strukturiertes Repository — mit klaren Verantwortlichkeiten je Ordner: src/ für produktiven Code, public/ für statische Assets, docs/ für interne Dokumentation, scripts/ für projekteigene Werkzeuge, .husky/ für Qualitätsschranken vor jedem Commit, .claude/ für KI-Konfiguration. Diese Trennung ist nicht akademisch, sondern macht die Site über Jahre wartbar: Inhalts-Änderungen bleiben Inhalt, Code-Änderungen bleiben lokal, neue Mitspieler finden sich zurecht. Kanzlei-spezifisch wichtig sind drei Punkte — Sensibilitäts-Trennung zwischen privatem und öffentlichem Bereich, Inhalt als eigene Daten-Schicht, KI-Konfiguration mit-versioniert. Das ist der konkrete strukturelle Mehrwert einer gebauten Site gegenüber einem zusammengeklickten Theme.

Quellen#

• Next.js — Project Structure (App Router) — abgerufen 2026-06-05
• Next.js — Routing Fundamentals — abgerufen 2026-06-05
• Vercel — Project Configuration — abgerufen 2026-06-05

Disclaimer: Beschreibung des tatsächlichen Bauprinzips von fahoch2.de zum Zeitpunkt der Veröffentlichung. Konkrete Strukturen sind framework-abhängig (hier Next.js mit App Router) und passen sich an gewählte Tooling-Entscheidungen an.