Zwei Workflows, ein System — wie wir Sites bauen und migrieren

Jedes Web-Projekt begann bei mir zu lange mit einem leeren Bildschirm. Andere Schrift, andere Plugin-Wahl, andere CSS-Strategie, andere Reihenfolge — und am Ende dieselben Mühen am selben Detail, nur eine Site später. Dass das nicht mein Können hochhebt, sondern es jedes Mal aufs Neue verbraucht, war irgendwann offensichtlich.

Was sich geändert hat: ein gemeinsames Fundament — Stack, Design-System, BEM-CSS — und darauf zwei klar getrennte Workflows. Einer für Neubauten, einer für Migrationen bestehender Sites. Beide folgen denselben fünf Phasen, beide enden mit derselben sauberen Site, beide sind als Markdown-Bundle dokumentiert, das sich nachbauen lässt. Wer sich für die Mechanik interessiert: am Ende des Beitrags liegen drei ZIPs zum Download.

Warum ein gemeinsames Fundament

Eine Site für eine Heilpraktikerin in Hamburg und eine Migration für ein Stress-Programm in Berlin haben mehr gemeinsam, als es zunächst aussieht. Beide brauchen eine Theme-Architektur, die nicht beim ersten WordPress-Update bricht. Beide brauchen ein Design-System, das sich nicht in einer fremden Tailwind-Compiler-Macke verfängt. Beide brauchen Sektionen, die ein Kunde später ohne mich pflegen kann — und die nicht in einem Page-Builder eingesperrt sind, der sich nicht mehr deinstallieren lässt.

Der Unterschied liegt nicht im Werkzeug, sondern in der Ausgangslage. Beim Neubau ist die DNA noch zu erfinden. Bei der Migration ist sie da — und muss respektiert, nicht ersetzt werden. Genau dafür sind die zwei Workflows getrennt.

Der Stack: bewusst klein, bewusst altmodisch

Drei Bausteine, nicht mehr.

WP Draft als Parent-Theme. Ein Blank-Theme von rund sechs Kilobyte, ohne eigene Templates, ohne eigene Styles. Es liefert die Block-Editor-Infrastruktur und lässt alles andere offen. Genau das, was ein Child-Theme zum Atmen braucht.

somatic-base als Child-Theme. Es bringt die fehlenden Templates mit (Page, Single, Index, Archive, Search, 404), die Template-Parts für Header und Footer — und vor allem eine einzige große style.css mit rund 870 Zeilen BEM-CSS. Mobile-first, drei Breakpoints, alle Brand-Tokens als CSS Custom Properties am Anfang der Datei. Pro Kunde wird das Theme geforked und im :root-Block angepasst — keine Komponenten-CSS-Edits.

BEM-Klassen als einzige Stilsprache. Kein Tailwind, kein Page-Builder, keine Utility-Soße im Markup. Jede Sektion ist ein <section class="section"> mit einem Container darin, jeder Button ein <a class="btn btn--primary">, jede Card ein <article class="card card--bordered">. Wenn ein Pattern fehlt, kommt es am Ende der style.css dazu — nie mittendrin.

Das ist bewusst altmodisch. Es bedeutet: keine Build-Pipeline. Keine Compiler-Fehler beim Cache-Generieren. Keine Plugin-Eigenarten, die mit dem nächsten Update kaputtgehen. Wenn die style.css im Browser lädt, läuft die Site. Wenn sie nicht lädt, ist der Fehler in einer Datei und in zwei Minuten zu finden.

Das Design-System als verbindlicher Vertrag

Ein Stack alleine baut keine Marke. Der zweite Baustein ist ein Design-System — entstanden mit einem Claude-Design-Agenten, dessen Methode ich an anderer Stelle beschrieben habe. Was er ausgibt, ist kein PDF-Styleguide, sondern ein strukturiertes Verzeichnis aus drei Schichten:

Die Logik dahinter ist einfach. Schicht 1 sagt, was nicht erlaubt ist. Schicht 2 sagt, welche Werte gelten. Schicht 3 sagt, wie es aussehen soll. Vor jeder Sektion, die ich baue, geht ein Blick in alle drei — eine erzwungene Pflicht-Lesereihenfolge, die verhindert, dass ich aus der Spur rutsche.

Die Pflicht-Lesereihenfolge

Das klingt umständlich, ist aber der entscheidende Trick gegen den schleichenden Brand-Drift. Wer eine Site mit zwanzig Sektionen baut, kann sich bei Sektion drei noch an jede Brand-Regel erinnern — bei Sektion siebzehn nicht mehr. Also wird die Reihenfolge eingehalten, jedes Mal: erst SKILL.md, dann der passende Abschnitt der README.md, dann die JSX-Komponente, die dem Sektionstyp am nächsten kommt, dann die bem-bridge.md für die konkreten Klassen.

Das Ergebnis ist eine Sektion, die visuell der JSX-Vorlage folgt, strukturell nur BEM-Klassen aus der style.css verwendet und inhaltlich die Brand-Verbote respektiert — kein Schatten, wo keiner sein darf, kein Wort, das die Brand nicht spricht.

Die fünf Phasen — gleiche Struktur, andere Fragen

Beide Workflows arbeiten in fünf Phasen. Jede Phase hat eine eigene Markdown-Datei mit Anleitung, Checkliste und einem Status-Update am Ende. Was sich pro Phase unterscheidet, hängt davon ab, ob etwas Neues entsteht oder etwas Bestehendes übersetzt wird.

Variante 1: Neubau

Hier ist die DNA noch zu erfinden. Die fünf Phasen:

1. Analyse. Wer ist die Marke, wer die Zielgruppe, welche drei Eigenschaften soll sie tragen? Welche Seiten braucht die Site, welche Funktionalitäten? Was kommt aus dem Briefing, was muss noch geklärt werden? Am Ende steht ein präziser Projekt-Scope und eine Sitemap.

2. Setup. WP Draft installieren, das Child-Theme forken zu somatic-[kunde], den :root-Block mit den Brand-Tokens aus dem Design-System (falls vorhanden) füllen, Schriften enqueuen, Validierungs-Test durchführen. Wenn der Test besteht — eine kurze HTML-Sektion mit Headline, Eyebrow und Button erscheint korrekt im Brand-Look — ist das technische Fundament gelegt.

3. Seitenbau. Pro Seite werden die Sektionen einzeln gebaut. Pflicht-Lesereihenfolge bei jeder. Output ist eine HTML-Datei im Projektordner und ein Draft in WordPress, angelegt via MCP, mit Rank-Math-Metadaten von Anfang an. Header und Footer leben im Theme — nicht in einzelnen Seiten.

4. Feinschliff. Sichtprüfung pro Seite, Brand-Compliance-Check, Performance-Tuning, Bilder optimieren, Forms testen, Cookie-Consent konfigurieren, SEO-Meta finalisieren.

5. Übergabe. Site live schalten, Backups einrichten, Kundenschulung, Übergabe-Dokumentation. Was am Ende übergeben wird, kann der Kunde pflegen — ohne mich.

Variante 2: Migration

Hier ist die DNA schon da. Sie steckt in der bestehenden Site, hat sich über Jahre verfestigt und trägt das Vertrauen, das der Kunde aufgebaut hat. Eine Migration, die diese DNA wegwirft und durch etwas Neues ersetzt, ist keine Migration — sie ist ein Rebranding mit Datenmigration als Nebeneffekt. Beides hat seinen Platz; sie sollten nur nicht verwechselt werden.

Mein Migrations-Workflow folgt deshalb der Haltung Refresh statt Reskin. Die visuelle DNA bleibt erhalten — gleiche Farbpalette, gleiche Typografie-Anmutung, gleiche Bildsprache. Was sich verbessert: Strukturierung, Konsistenz, Whitespace, Responsive-Verhalten, Performance, Barrierefreiheit. Die fünf Phasen:

1. Bestandsaufnahme. Vollständige Inventur der Altsite — jede URL, jede Funktion, jedes Drittanbieter-Tool, jede SEO-Position. Was bleibt, was geht, was wird redirected? Ohne diese Liste keine Migration.

2. Design-System. Der Claude-Design-Agent bekommt die Altsite als Input und destilliert die DNA in ein verbindliches Design-System — bewusste Verbesserungen werden dabei in einer design-decisions.md dokumentiert, damit der Kunde weiß, was sich ändert und warum.

3. Content-Plan. Welche Inhalte werden 1:1 übernommen, welche überarbeitet, welche neu geschrieben? Welche Bilder bleiben, welche werden ersetzt, welche optimiert? Hier wird auch entschieden, welche Blog-Posts manuell migriert werden und welche per Redirect auf neue Themen-Bündel zeigen.

4. Aufbau auf Staging. Die neue Site entsteht auf einer Subdomain — niemals direkt auf Live. Theme aktivieren, Header und Footer anpassen, alle Seiten via MCP als Drafts anlegen mit der Pflicht-Lesereihenfolge, Forms aufsetzen, Cookie-Consent konfigurieren, Brand-Compliance-Check durchführen.

5. Cutover. Backup der Altsite. Domain umziehen oder DNS umstellen. 301-Redirects aktivieren. SEO-Position überwachen. Rollback-Plan in der Schublade — der hoffentlich nie gebraucht wird.

Was die Pflicht-Lesereihenfolge in der Praxis bedeutet

Ein Beispiel. Wenn ich eine Hero-Sektion für ein Espresso-Magazin baue, läuft das so ab:

Was nicht passiert: dass ich aus dem Bauch heraus einen Tailwind-artigen Klassen-Salat tippe, der zwar visuell hinkommt, aber bei der nächsten Brand-Iteration unwartbar ist. Was passiert: eine Sektion, deren Klassen-Namen ich auf dem nächsten Projekt wiedersehe, weil sie aus demselben Komponentensatz kommen.

Anti-Konvergenz, eine Ebene tiefer

Der Grund, warum ich diese Disziplin überhaupt aufschreibe — und mit ihr arbeite —, ist derselbe, der im Markendesign-Beitrag die Methode aus Anker und Designer-Linse rechtfertigt. KI-Werkzeuge tendieren zum Durchschnitt. Beim Logo ist der Durchschnitt eine bestimmte Schrift und eine bestimmte Farbe. Beim Sektions-HTML ist der Durchschnitt eine bestimmte Tailwind-Kombination und ein bestimmtes Hero-Layout.

Wer KI gegen den Durchschnitt einsetzen will, muss ihr Leitplanken geben — präzise genug, dass sie greifen, locker genug, dass sie nicht ersticken. Die Pflicht-Lesereihenfolge ist eine Leitplanke. Die bem-bridge.md ist eine. Die Trennung in Phasen ist eine. Zusammen erzeugen sie eine Site, die nach dem Kunden aussieht, nicht nach KI-Default — auch wenn KI an jedem Schritt beteiligt war.

Die drei Bundles zum Download

Ich halte das Verfahren offen. Wer mag, baut es nach oder passt es für die eigene Arbeit an. Drei ZIPs:

Warum das für Ihre Site zählt

Wenn Sie coachen, therapieren oder behandeln, ist Ihre Site kein Marketing-Trichter — sie ist eine Vertrauens-Vorbereitung. Sie soll vermitteln, was Sie tun und wie Sie arbeiten, bevor jemand bei Ihnen klingelt. Das gelingt einer Site umso besser, je weniger sie sich anfühlt wie aus einer Maschine — und je mehr sie sich anfühlt wie aus einer bewussten Haltung.

Die Workflows hier sind nicht das Geheimnis dieser Haltung. Sie sind die Buchhaltung dazu — sie sorgen dafür, dass eine bewusste Entscheidung am Anfang nicht in der dritten Sektion einer Über-uns-Seite verloren geht. Die Entscheidung selbst treffen wir gemeinsam, in einem Gespräch. Was Sie hier bekommen, ist der Apparat, der sie konsequent durchhält.