Website bauen mit Claude Code, Hostinger und WordPress – ein Praxisbericht

Du hast bestimmt schon mal ChatGPT oder Claude ausprobiert und dir einen netten Text generieren lassen. Vielleicht sogar ein paar Zeilen Code. Cool. Aber hast du schon mal eine komplette Unternehmenswebsite damit gebaut? Nicht irgendein Spielzeug mit bunten Farben – eine echte, professionelle Website mit Security Headers, DSGVO-Compliance und einem Deploy-Script, das deine Änderungen in 30 Sekunden live bringt?

Genau das haben wir gemacht. Und zwar mit einem Stack, der überraschend gut funktioniert: Claude Code als KI-Entwicklungspartner direkt in VS Code, Hostinger als Hosting-Plattform und WordPress als CMS. Dazu kommen Git für die Versionskontrolle, ein selbstgeschriebenes Deploy-Script und eine Datei namens CLAUDE.md, die das Ganze erst richtig zum Fliegen bringt.

Alles, was du in diesem Artikel liest, stammt aus einem echten Projekt – trail1.de. Keine Theorie, keine Fantasie-Beispiele. Jedes Code-Snippet kommt direkt aus der Codebasis.

Was du brauchst (und was nicht)

Vergiss erstmal alles, was du über Website-Baukästen denkst. Wir brauchen genau fünf Dinge:

• VS Code – der Code-Editor, den ohnehin die halbe Welt benutzt
• Claude Code – die KI-Extension für VS Code, die wirklich mitdenkt
• Git – für Versionskontrolle (falls etwas schiefgeht – irgendetwas geht immer schief)
• Einen SSH-Key – damit du sicher auf deinen Server kommst
• Einen Hostinger-Account – mit SSH-Zugang und WordPress vorinstalliert

Warum Hostinger? Weil die Server in Frankfurt stehen (EU, gut für DSGVO), LiteSpeed Cache eingebaut ist, PHP 8.2+ läuft und du echten SSH-Zugang bekommst. Das ist kein Shared-Hosting-Keller aus den 2000ern.

Nach der Einrichtung legst du dir einen SSH-Alias an, damit du nicht jedes Mal die halbe Server-Konfiguration tippen musst:

# ~/.ssh/config
Host mein-server
  HostName <deine-server-ip>
  User <dein-username>
  Port <dein-custom-port>
  IdentityFile ~/.ssh/id_ed25519

Dann initialisierst du dein Git-Repository im Projektordner und kannst loslegen. Damit kommen wir zum eigentlichen Geheimnis dieses Setups.

Die geheime Zutat: CLAUDE.md

Hier wird es spannend. Die meisten Leute öffnen Claude Code und tippen drauflos: „Mach mir eine Website.“ Das Ergebnis ist dann auch dementsprechend – funktioniert irgendwie, aber professionell ist es nicht.

Der Unterschied zwischen „KI spuckt irgendwas aus“ und „KI arbeitet wie ein Entwickler, der deine Projektregeln kennt“ heißt CLAUDE.md. Diese Datei liegt im Projekt-Root und ist im Grunde ein Lastenheft für deine KI. Claude Code liest sie bei jedem Start und weiß danach: Welche Coding-Standards gelten, was erlaubt ist, was verboten ist und welche Werkzeuge zur Verfügung stehen.

So sieht ein Auszug aus unserer echten CLAUDE.md aus:

## Code-Stil
- PHP: WPCS, immer Escaping (esc_html(), esc_attr(), esc_url(), wp_kses_post())
- SQL: $wpdb->prepare() bei jeder Query, keine Ausnahmen
- JS: ES Modules, kein jQuery außer WP-Core erfordert es
- CSS: BEM-Klassen, Tokens via CSS Custom Properties, kein !important
- functions.php nur require_once -- Logik in inc/<feature>.php

Damit weiß Claude: Jede PHP-Ausgabe wird escaped. Keine Ausnahme. Kein „ich mach das später“. Und es funktioniert – Claude hält sich tatsächlich daran.

Aber es geht noch weiter. In der CLAUDE.md definierst du auch Skills und Slash Commands:

## Skills
| Skill          | Beschreibung                                              |
|----------------|-----------------------------------------------------------|
| wp-block       | Custom Block: block.json + render.php + style.css + edit.js |
| wp-security    | Security-Audit: Headers, Escaping, Nonces, Permissions    |
| wp-performance | Lighthouse-Audit, Query-Analyse, Asset-Optimierung        |

## Slash Commands
| Command            | Zweck                                              |
|--------------------|-----------------------------------------------------|
| /wp-commit         | Git-Diff analysieren, Conventional Commit erstellen |
| /wp-audit          | Security + DSGVO + Performance in einem Durchlauf   |
| /wp-deploy-staging | Build, Validate, Backup, Deploy auf Staging         |

Skills sind spezialisierte Wissenspakete – Claude weiß bei wp-security genau, was es prüfen muss. Commands sind Einzeiler-Workflows: /wp-commit analysiert den Git-Diff und erstellt automatisch einen sauberen Commit auf Deutsch. Investiere Zeit in eine gute CLAUDE.md. Es ist die beste Investition in deinem gesamten Projekt.

So arbeitet man wirklich mit Claude Code

Jetzt, wo Claude deine Regeln kennt, ändert sich die Arbeitsweise komplett. Statt stundenlang selbst zu coden, beschreibst du, was du willst. Claude liefert. Aber nicht blind, sondern nach einem festen Ablauf:

Erst planen, dann bauen. Claude Code hat einen Plan-Modus. Du aktivierst ihn, beschreibst dein Feature. Claude erstellt einen detaillierten Umsetzungsplan. Erst wenn der Plan steht, wird Code geschrieben. Das klingt nach Overhead, spart aber Stunden, weil du nicht dreimal von vorne anfangen musst.

Inkrementell arbeiten. Ein Feature nach dem anderen. Kontaktformular fertig? Testen. Funktioniert? Committen. Nächstes Feature. Nie drei Dinge gleichzeitig anfassen.

Ein Praxisbeispiel: Unser Kontaktformular. Claude hat auf Basis der CLAUDE.md-Regeln ein Formular mit sieben Sicherheitsebenen gebaut – in einem Durchgang:

// 1. Nonce-Check (CSRF-Schutz)
if ( ! wp_verify_nonce( $_POST['_wpnonce'], 'my_contact_nonce' ) ) {
    my_form_redirect( 'error', 'Sicherheitsprüfung fehlgeschlagen.' );
    return;
}

// 2. Honeypot (unsichtbares Feld -- Bots füllen es aus, Menschen nicht)
if ( ! empty( $_POST['website_url'] ) ) {
    my_form_redirect( 'success' ); // Bot bekommt Fake-Erfolg
    return;
}

// 3. Timing-Check (< 3 Sekunden = Bot, kein Mensch tippt so schnell)
if ( ( time() - (int) $_POST['_ts'] ) < 3 ) { /* Zu schnell */ }

// 4. Rate Limiting (max 3 pro Stunde pro IP)
// 5. Input-Sanitization (sanitize_text_field, sanitize_email)
// 6. Pflichtfeld-Validierung + Datenschutz-Checkbox
// 7. E-Mail-Domain MX-Check (existiert die Domain überhaupt?)

Sieben Sicherheitsebenen. Kein reCAPTCHA, kein externer Dienst, keine Datenübermittlung an Google. Alles serverseitig. Claude hat das gebaut, weil die CLAUDE.md klar vorgibt: „Nonce-Validierung bei allen Formularen. Keine Ausnahmen.“

Nach jedem Feature kommt die Verifikation: Kompiliert es? Sind die Coding-Standards eingehalten? Funktioniert es im Browser – Desktop und Mobil? Liegt die Lighthouse-Performance über 90? Erst dann geht es weiter.

In 30 Sekunden live – aber sicher

Irgendwann muss dein Code vom lokalen Rechner auf den Server. Hier machen viele den Fehler, Dateien per FTP hochzuladen oder – noch schlimmer – direkt auf dem Server zu editieren. Bitte nicht.

Unser Ansatz: Ein einziges Bash-Script namens deploy.sh, das alles automatisiert:

#!/bin/bash
set -e  # Bei jedem Fehler sofort abbrechen

REMOTE="mein-server"
REMOTE_PATH="~/domains/example.de/public_html"
THEME_PATH="wp-content/themes/mein-theme"

# [1/4] Theme-Dateien hochladen via SCP
echo "[1/4] Theme-Dateien hochladen..."
scp -r "$THEME_PATH"/* "$REMOTE:$REMOTE_PATH/$THEME_PATH/"

# [2/4] .htaccess hochladen (Security Headers!)
echo "[2/4] .htaccess hochladen..."
scp .htaccess "$REMOTE:$REMOTE_PATH/.htaccess"

# [3/4] OPcache zurücksetzen (WICHTIG!)
echo "[3/4] OPcache zurücksetzen..."
ssh "$REMOTE" "php -r 'opcache_reset();' || curl -s localhost/opcache-endpoint"

# [4/4] LiteSpeed Cache leeren
echo "[4/4] Cache leeren..."
ssh "$REMOTE" "wp litespeed-purge all 2>/dev/null || wp cache flush"

Vier Schritte, vollautomatisch. SCP überträgt die Dateien verschlüsselt über SSH. Die .htaccess wird mitdeployt, weil dort die Security Headers leben. Dann kommen die zwei Schritte, die wir auf die harte Tour gelernt haben: OPcache zurücksetzen und Cache leeren.

Ohne OPcache-Reset zeigt dein Server nach dem Deploy fröhlich die alte PHP-Version an. Du starrst auf den Bildschirm, fragst dich, warum sich nichts geändert hat. Du zweifelst an deinem Verstand. Spoiler: Es lag nicht an dir. PHP cached den Bytecode. Ohne explizites Reset bleibt der alte Stand im Speicher.

Warum SCP statt rsync? Weil rsync unter Windows nicht nativ läuft. SCP funktioniert überall, ist einfach und sicher. Pragmatismus schlägt Perfektion.

Der Whitelist-Trick: Nur tracken, was du selbst geschrieben hast

WordPress-Projekte und Git sind keine natürliche Freundschaft. WordPress bringt tausende Core-Dateien mit, dazu Plugins, Uploads, Cache-Ordner – das willst du nicht alles im Repository haben. Die klassische Lösung ist eine .gitignore, die bestimmte Ordner ausschließt. Unser Ansatz geht andersherum: Wir ignorieren alles und whitelisten nur das, was wir selbst geschrieben haben.

# ALLES IGNORIEREN, NUR AUSNAHMEN TRACKEN
/*

# Diese Dateien tracken
!.gitignore
!.htaccess
!CLAUDE.md
!content/
!.claude/
!deploy.sh

# Nur unser Theme tracken
!wp-content/
wp-content/*
!wp-content/themes/
wp-content/themes/*
!wp-content/themes/mein-theme/

# NIEMALS tracken
wp-config.php
wp-content/uploads/
wp-content/plugins/

Das Ergebnis: Ein Repository mit unter 100 Dateien statt tausenden. Sauber, übersichtlich und vor allem sicher, denn wp-config.php und Credentials können gar nicht versehentlich committed werden.

Für Commits nutzen wir Conventional Commits auf Deutsch. Claude generiert die automatisch per /wp-commit:

feat: Kontaktformular mit 7-Schichten-Sicherheit implementiert
fix: .gitignore auf Whitelist-Ansatz umgestellt
style: Mobile Navigation Breakpoint auf 768px angepasst

Ein Feature, ein Commit. Klar, nachvollziehbar, rückverfolgbar.

DSGVO ist kein Hindernis, wenn du es von Anfang an richtig machst

Jetzt wird es ernst. Die meisten WordPress-Tutorials handeln DSGVO ab mit „installier halt ein Cookie-Plugin“. Das ist ungefähr so, als würdest du ein Pflaster auf einen Rohrbruch kleben. DSGVO ist kein nachträglicher Gedanke – es ist ein Qualitätsstandard, der von Anfang an in die Architektur gehört.

Hier sind fünf konkrete Maßnahmen aus unserem Projekt:

1. Lokale Fonts statt Google Fonts CDN

Jeder Aufruf von Google Fonts überträgt die IP-Adresse deiner Besucher an Google – in die USA. Das ist ohne explizite Einwilligung ein DSGVO-Verstoß. Die Lösung ist simpel: Fonts herunterladen und lokal hosten.

/* DSGVO-konform: Kein Google Fonts CDN */
@font-face {
  font-family: 'Source Sans 3';
  src: url('./assets/fonts/SourceSans3-Latin.woff2') format('woff2');
  font-weight: 400 900;
  font-style: normal;
  font-display: swap;
}

Die WOFF2-Dateien liegen im Theme-Ordner. Kein externer Request, keine Datenübermittlung, kein Problem. font-display: swap sorgt dafür, dass der Text sofort sichtbar ist, auch wenn die Schrift noch lädt.

2. Security Headers in der .htaccess

Professionelle Websites setzen Security Headers. Die schützen vor Clickjacking, erzwingen HTTPS und kontrollieren, welche externen Ressourcen geladen werden dürfen:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set Content-Security-Policy "default-src 'self'; font-src 'self'; ..."
</IfModule>

Die Content-Security-Policy (CSP) ist besonders wichtig: Sie erlaubt nur Ressourcen von der eigenen Domain. Keine versteckten Tracker, keine eingeschleusten Scripts. Die Permissions-Policy deaktiviert Kamera, Mikrofon und Geolocation. Funktionen, die eine Unternehmenswebsite nicht braucht.

3. Kein Tracking, keine Marketing-Cookies

Auf unserer Website gibt es kein Google Analytics, kein Facebook Pixel, kein Hotjar. Nur technisch notwendige Cookies für die WordPress-Session und den LiteSpeed Cache. Das bedeutet: Kein Cookie-Banner nötig. Technisch notwendige Cookies fallen nicht unter die Einwilligungspflicht. Weniger Banner, bessere User Experience, volle Compliance.

4. Kontaktformular ohne reCAPTCHA

Google reCAPTCHA sendet Nutzerdaten an Google. Das ist ein DSGVO-Problem. Unsere Alternative: Sieben serverseitige Sicherheitsebenen (Nonce, Honeypot, Timing, Rate Limiting, Sanitization, Validierung, MX-Check). Kein externer Dienst, keine Datenübermittlung. Funktioniert mindestens genauso zuverlässig gegen Bots.

5. Datenschutz-Checkbox als Pflichtfeld

Jedes Formular braucht eine explizite Einwilligung mit Link zur Datenschutzerklärung. Keine vorausgefüllte Checkbox, kein versteckter Hinweis. Der Nutzer muss aktiv zustimmen, bevor das Formular abgeschickt werden kann.

Zusammen ergeben diese Maßnahmen eine Website, die DSGVO-konform ist, ohne ein einziges Privacy-Plugin zu installieren. Der Trick: Man baut es von Anfang an richtig, statt nachher zu flicken.

Dein nächster Schritt

Fassen wir zusammen, was du jetzt weißt:

• CLAUDE.md ist das Fundament – investiere Zeit in gute Regeln. Claude Code liefert dann Code auf professionellem Niveau
• Inkrementell bauen – ein Feature, ein Commit, validieren, weiter
• deploy.sh automatisiert den langweiligsten Teil deines Workflows und verhindert Fehler
• Git mit Whitelist-Ansatz hält dein Repository sauber und sicher
• DSGVO von Anfang an einplanen, nicht nachträglich draufkleben – das spart Zeit, Geld und Nerven

Das Schöne an diesem Setup: Es skaliert. Ob du eine einzelne Landingpage baust oder ein komplexes Unternehmensportal – die Werkzeuge und Workflows bleiben dieselben. Claude Code wird mit jeder Iteration besser, weil die CLAUDE.md das Projektwissen konserviert. Dein Deploy-Script funktioniert heute genauso wie in sechs Monaten. Deine Git-Historie erzählt eine saubere Geschichte deines Projekts.

Die Website trail1.de wurde mit genau diesem Stack gebaut. Jede Zeile Code, jeder Security Header, jede Font-Datei – alles, was du in diesem Artikel gelesen hast, läuft dort in Produktion. Kein Prototyp, kein Demo-Projekt. Das echte Ding.

Du willst deine eigene Website nach diesen Standards aufbauen, brauchst aber Unterstützung bei der Umsetzung? Vereinbare ein kostenloses Erstgespräch – 30 Minuten, unverbindlich, vertraulich. Wir schauen gemeinsam, welcher Ansatz für dein Projekt der richtige ist.