WordPress, Payload CMS oder Code mit KI — was lohnt sich 2026?

Vor zwei Jahren war die Frage einfach: WordPress oder Custom-Entwicklung. 2026 gibt es drei fundamental verschiedene Wege, eine Website zu bauen — und zum ersten Mal seit Jahren sinkt der WordPress-Marktanteil. Entwickler stimmen mit den Füßen ab.

Weg 1: WordPress oder ein Baukasten-System. Das kennt jeder. Weg 2: Payload CMS — ein Headless CMS mit TypeScript und eigenem Frontend. Weg 3: Rein statische Seiten, direkt im Code geschrieben, mit KI-Tools wie Claude Code als Entwicklungspartner. ZenML hat so 2.224 Seiten in einer Woche von Webflow zu Astro migriert. StackOne hat ihre Marketing-Website an ein paar Abenden neu aufgebaut.

Dieser Beitrag vergleicht alle drei Ansätze — mit konkreten Zahlen, Projekterfahrungen und einer ehrlichen Einordnung, welcher Weg für welches Projekt passt.

Der Überblick: Drei Ansätze, drei Philosophien

	WordPress / Baukasten	Payload CMS	Statisch mit KI
Prinzip	GUI-basiert, Plugin-Ökosystem	Code-first Headless CMS	Reine Code-Dateien, kein CMS
Sprache	PHP (WordPress) / proprietär	TypeScript	TypeScript / Astro / MDX
Content-Verwaltung	Admin-Panel im Browser	Admin-Panel (React)	MDX-Dateien in Git
Datenbank	MySQL	PostgreSQL / MongoDB	Keine
Hosting	Shared ab 3 €/Monat	Node.js ab 5 €/Monat	Cloudflare/Vercel: 0 €
Sicherheitsupdates	Monatlich (Pflicht)	npm update	Keine nötig
Angriffsfläche	Hoch (Plugins, Login, xmlrpc)	Mittel (Admin-Panel, API)	Null (statisches HTML)
Typische TTFB	400–800 ms	20–100 ms (SSG)	10–50 ms
Wer pflegt Inhalte?	Jeder mit Browser	Redakteure im Admin	Entwickler im Code
Laufende Kosten/Jahr	1.200–3.600 €	60–500 €	0–240 €

Die Zahlen verdienen Kontext. Darum geht es im Rest dieses Beitrags.

Weg 1: WordPress und Baukästen — das Bekannte

WordPress betreibt 43 % aller Websites weltweit. Dazu kommen Squarespace, Wix, Webflow und Jimdo. Die Stärke dieser Systeme: Jeder kann loslegen. Template auswählen, Texte eintippen, veröffentlichen.

Die Kosten kommen später.

Eine typische WordPress-Seite hat 20 bis 30 aktive Plugins. Jedes Plugin ist Code von einem Drittanbieter mit Zugriff auf Datenbank und Dateisystem. WordPress ist das meistangegriffene CMS der Welt — die überwiegende Mehrheit der Sicherheitslücken stammt aus Plugins und Themes, nicht aus dem Core.

Performance ist ein strukturelles Problem. WordPress muss bei jedem Seitenaufruf die PHP-Bootsequenz durchlaufen — inklusive aller Plugins. Typische TTFB ohne Cache: 400 bis 800 ms. Mit WP Rocket, Redis und CDN kommt man auf 100 bis 200 ms. Drei zusätzliche Plugins, um ein Problem zu lösen, das bei einer statischen Architektur gar nicht existiert.

Laufende Kosten eines typischen WordPress-Projekts:

• Managed Hosting: 20–50 €/Monat
• Premium-Plugins (ACF Pro, Yoast, WP Rocket): 200–500 €/Jahr
• Wartung (Updates, Backups, Monitoring): 50–150 €/Monat
• Summe: 1.200–3.600 €/Jahr — bevor eine einzige inhaltliche Änderung passiert

Wann WordPress Sinn macht: Wenn nicht-technische Redakteure täglich Inhalte pflegen müssen, das Budget unter 2.000 € liegt oder ein E-Commerce-Shop mit WooCommerce geplant ist. WordPress hat 20 Jahre Ökosystem-Vorsprung — das ist real.

Weg 2: Payload CMS — Headless, aber mit System

Payload CMS ist ein Open-Source Headless CMS in TypeScript, das Datenstrukturen als Code definiert, automatisch REST- und GraphQL-APIs generiert und ein React-basiertes Admin-Panel mitliefert — alles versionierbar in Git. Lizenz: MIT, keine versteckten Kosten.

Der fundamentale Unterschied zu WordPress: Die Content-Struktur lebt im Code, nicht in der Datenbank. Eine Collection sieht so aus:

const Projekte = {
  slug: 'projekte',
  fields: [
    { name: 'titel', type: 'text', required: true },
    { name: 'kunde', type: 'relationship', relationTo: 'kunden' },
    { name: 'status', type: 'select', options: ['Entwurf', 'In Arbeit', 'Live'] },
  ],
}

Drei Zeilen. Volle IDE-Unterstützung, Compile-Time-Checks, versioniert in Git. Wenn jemand ein Feld ändert, sehen Sie das im Pull Request — nicht erst, wenn die Produktionsseite Fehler wirft.

Seit Payload 3.0 läuft das CMS direkt innerhalb einer Next.js-App: Admin-Panel, API und Frontend in einem Projekt, ein Deployment. Die Angriffsfläche ist deutlich kleiner als bei WordPress — kein xmlrpc.php, kein öffentliches /wp-admin, kein Plugin-Code von unbekannten Drittanbietern. Access Control funktioniert bis auf Feld-Ebene.

Laufende Kosten:

• Hosting (Cloudflare/Vercel + Datenbank): 5–40 €/Monat
• Plugins: 0 € (alles Code)
• Wartung: minimal — automatisiertes Deployment via Git Push
• Summe: 60–500 €/Jahr

Wann Payload Sinn macht: Wenn das Projekt komplexe Datenstrukturen hat (Beziehungen zwischen Content-Typen, Mehrsprachigkeit, Workflows), wenn mehrere Redakteure ein Admin-Panel brauchen und wenn TypeScript-Entwickler im Team sind. Payload ist der richtige Schritt weg von WordPress — wenn man ein CMS braucht.

Die Frage ist: Braucht man überhaupt eins?

Weg 3: Statische Seiten mit KI — Code als CMS

Dieser dritte Weg existiert in dieser Form erst seit Mitte 2025 — seit KI-Coding-Tools wie Claude Code und Cursor leistungsfähig genug sind, um ganze Projekte zu verstehen. Die Idee: Keine Datenbank, kein Admin-Panel, kein CMS. Inhalte leben als MDX-Dateien und Astro-Komponenten direkt im Code-Repository. Änderungen passieren im Editor — oder per KI-Assistent im Terminal.

Das klingt nach einem Rückschritt. Die Zahlen sagen etwas anderes.

ZenML hat 2.224 Seiten, 20 CMS-Collections und 2.397 Bilder in einer Woche von Webflow zu Astro migriert — mit Claude Code. Der Entwickler nutzte Playwright, um die alte Webflow-Seite zu screenshotten, und ließ Claude Code die Layouts per visueller Analyse rekonstruieren. Komplexe Webflow-Animationen wurden als Video aufgenommen, in Frames zerlegt und als CSS-Animationen nachgebaut.

Ein Webentwickler aus dem UK dokumentiert: „4–6 Stunden Entwicklungszeit statt 4–6 Wochen.” Features, die früher 2–3 Stunden brauchten, waren in 12–18 Minuten fertig. Debugging-Zeit sank von 25 % des Tages auf 10 %. Astro hat inzwischen offizielle Dokumentation zum Thema „Building Astro sites with AI tools” veröffentlicht — so mainstream ist der Workflow geworden.

So sieht der Workflow aus: Ein Kunde schickt per E-Mail: „Bitte ändere die Telefonnummer auf der Kontaktseite und füge einen neuen Referenz-Eintrag hinzu.” In WordPress: Admin-Panel öffnen, navigieren, Felder finden, speichern, Cache leeren. Dauer: 10–15 Minuten. Mit Claude Code im Terminal: eine Anweisung, zwei Datei-Änderungen, git push, deployed in 30 Sekunden. Fertig.

Diese Website hier — paulmill.com — läuft genau so. Astro generiert statisches HTML aus .astro-Komponenten und MDX-Dateien. Blog-Beiträge wie dieser sind MDX-Dateien mit YAML-Frontmatter. Kein Admin-Panel, keine Datenbank, kein Server. Cloudflare Pages liefert die Dateien aus — kostenlos, weltweit, mit einer TTFB unter 30 ms.

Was KI-Tools am Workflow ändern

Claude Code, Cursor, GitHub Copilot — diese Tools haben den „Entwickler muss jede Zeile selbst schreiben”-Engpass beseitigt. Ein neuer Blog-Beitrag entsteht so:

1. Briefing: Ich beschreibe Thema, Zielgruppe und Ton in natürlicher Sprache
2. Entwurf: Claude Code generiert die MDX-Datei mit Frontmatter, Struktur und erstem Text
3. Review: Ich lese, korrigiere, ergänze eigene Erfahrungen und Daten
4. Bilder: KI generiert Bilder per API (Gemini, DALL-E) direkt in den public/-Ordner
5. Deploy: git push — Cloudflare baut und deployed automatisch

Gesamtdauer für einen 2.000-Wörter-Beitrag: 30 bis 60 Minuten statt einem halben Tag. Die KI übernimmt die Fleißarbeit — Struktur, Frontmatter, Schema-Markup, SEO-Grundgerüst. Ich bringe die Substanz: eigene Erfahrungen, konkrete Projektzahlen, eine Meinung.

Dasselbe gilt für Design-Änderungen. „Mache die Hero-Sektion responsive und füge eine Animations-Sequenz hinzu” — das ist ein Prompt, den Claude Code in 2 Minuten in funktionierenden Astro- und CSS-Code übersetzt. Inklusive Tailwind-Klassen, CSS Custom Properties und IntersectionObserver. Ohne ein einziges Plugin.

StackOne geht noch weiter: Dort macht inzwischen jeder im Team Änderungen an der Website per natürlicher Sprache — nicht nur Entwickler. Sie haben Claude-Code-Skills definiert (Design-Guidelines, Schreibstil), die automatisch konsistente Qualität sicherstellen. Das Marketing-Team ändert Texte und CTAs direkt im Terminal, ohne den Umweg über ein CMS-Admin-Panel.

Die Architektur dahinter

┌─────────────────────────────────────────────────┐
│  Content & Code (Git Repository)                │
│                                                 │
│  src/content/blog/*.mdx    ← Blog-Inhalte       │
│  src/components/*.astro    ← UI-Komponenten     │
│  src/pages/*.astro         ← Seitenstruktur     │
│  public/                   ← Bilder, Fonts      │
│                                                 │
│  Bearbeitung: Claude Code / Editor / IDE        │
├─────────────────────────────────────────────────┤
│  Build: Astro SSG (bun run build)               │
│  Output: statisches HTML + CSS + JS             │
├─────────────────────────────────────────────────┤
│  Hosting: Cloudflare Pages (0 €)                │
│  CDN: automatisch, weltweit                     │
│  SSL: automatisch                               │
│  Angriffsfläche: null (nur statische Dateien)   │
└─────────────────────────────────────────────────┘

Keine Datenbank, die gehackt werden kann. Kein PHP, das gepatcht werden muss. Kein Admin-Panel, das per Brute-Force angegriffen wird. Die gesamte „Anwendung” besteht aus HTML-Dateien auf einem CDN. Das ist die sicherste Website-Architektur, die existiert.

Laufende Kosten:

• Hosting: 0 € (Cloudflare Pages Free Tier)
• Domain: 10–15 €/Jahr
• KI-Tool (Claude Code / Cursor): 20–100 €/Monat (zahlt der Entwickler, nicht der Kunde)
• Wartung: 0 € — es gibt nichts zu warten
• Summe: 10–15 €/Jahr für den Kunden

Welcher Ansatz kostet wie viel?

Die Gesamtkosten über drei Jahre — die realistischere Perspektive als nur der Erstellungspreis:

Kostenstelle	WordPress	Payload CMS	Statisch + KI
Erstellung	1.500–5.000 €	4.000–12.000 €	3.000–10.000 €
Hosting (3 Jahre)	720–1.800 €	180–1.440 €	0–30 €
Plugins/Lizenzen (3 J.)	600–1.500 €	0 €	0 €
Wartung (3 Jahre)	1.800–5.400 €	360–1.200 €	0 €
Content-Änderungen	Kunde selbst (0 €)	Kunde selbst (0 €)	Entwickler (nach Aufwand)
3-Jahres-TCO	4.620–13.700 €	4.540–14.640 €	3.000–10.030 €

Die Überraschung: Der statische Ansatz mit KI-Unterstützung ist langfristig der günstigste — trotz höherer Erstellungskosten als WordPress. Der Grund: null laufende Kosten für Hosting, Plugins und Wartung. Die Einsparung gegenüber WordPress beträgt typisch 1.500 bis 4.000 € über drei Jahre.

Der Haken: Content-Änderungen erfordern einen Entwickler. Für eine Unternehmensseite, die 2–3 Mal im Monat aktualisiert wird, ist das kein Problem — 10 Minuten pro Änderung mit Claude Code. Für einen News-Blog mit täglichen Artikeln von wechselnden Redakteuren wäre es ein Flaschenhals.

Performance im direkten Vergleich

Dieselben Inhalte, unterschiedliche Architekturen — gemessen an einem realen 7-Seiten-Projekt (Dienstleister, keine Animationen, 6 Bilder):

Metrik	WordPress	Payload + Astro	Statisch (Astro)
TTFB	480 ms	45 ms	28 ms
LCP	2,8 s	0,9 s	0,7 s
Total JS	340 KB	12 KB	0 KB
Lighthouse Score	68	97	100
CWV bestanden	Nein (INP)	Ja	Ja

Die rein statische Variante liefert null JavaScript an den Browser — weil keins nötig ist. Keine jQuery-Altlast, kein React-Hydration, kein Analytics-SDK. Astro rendert auf dem Server und sendet reines HTML — 40 % schnellere Ladezeiten als vergleichbare Next.js-Seiten und 90 % weniger JavaScript. Schneller geht nicht.

Wenn Sie wissen möchten, was Ladezeit für Ihre Conversion Rate bedeutet: Performance-Rechner.

Sicherheit: Weniger Schichten, weniger Risiko

Die Angriffsfläche korreliert direkt mit der Anzahl laufender Prozesse:

WordPress: PHP-Interpreter, MySQL-Datenbank, 20+ Plugins, Login-Seite, xmlrpc.php, REST-API, Cron-Jobs. Die überwiegende Mehrheit aller WordPress-Schwachstellen stammt aus Plugins und Themes. Eine gehackte WordPress-Seite kostet im Schnitt 200–2.000 € zur Wiederherstellung.

Payload CMS: Node.js-Server, Datenbank, Admin-Panel hinter Auth. Deutlich kleiner als WordPress, aber noch eine laufende Anwendung mit Netzwerk-Endpunkten. Kein Plugin-Code von Drittanbietern — das eliminiert den größten Angriffsvektor.

Statisch: Keine laufende Anwendung. Keine Datenbank. Kein Login. Kein Server-Prozess. Nur HTML-Dateien auf einem CDN. Die einzige Angriffsfläche ist Cloudflare selbst — und die haben ein größeres Sicherheitsteam als jedes KMU. Ein DDoS-Angriff gegen statische Dateien auf einem CDN ist wie Wasser auf einen Fels werfen.

Wann welcher Ansatz?

Die Entscheidung ist kein Glaubenskrieg, sondern eine Frage der Anforderungen:

WordPress / Baukasten wählen, wenn:

• Nicht-technische Redakteure täglich Inhalte veröffentlichen
• E-Commerce mit WooCommerce geplant ist
• Budget unter 2.000 € für die gesamte Website
• Kein Entwickler langfristig verfügbar ist

Payload CMS wählen, wenn:

• Komplexe Datenstrukturen mit Beziehungen nötig sind (z. B. Produkte → Kategorien → Hersteller)
• Mehrere Redakteure ein Admin-Panel brauchen
• Multi-Channel-Ausgabe gewünscht ist (Website + App + API)
• Ein TypeScript-Team das Projekt betreut

Statisch mit KI wählen, wenn:

• Die Website 3–15 Seiten hat und selten geändert wird
• Performance und Sicherheit Priorität haben
• Null laufende Kosten gewünscht sind
• Ein Entwickler (oder eine Agentur) die Pflege übernimmt
• Der Content klar definiert ist (Unternehmensseite, Portfolio, Landing Pages)

In meinen Projekten landen etwa 60 % der Kunden beim statischen Ansatz. Der Grund: Die meisten KMU-Websites werden nach dem Launch selten geändert — vielleicht eine Telefonnummer, ein neues Projekt in der Referenzliste, ein Blog-Beitrag pro Monat. Dafür ein CMS mit Datenbank, Login und monatlichen Updates zu betreiben, ist wie einen LKW zu mieten, um einen Brief zur Post zu bringen.

Wie sieht der Workflow mit Claude Code konkret aus?

Ein Beispiel aus der Praxis — Kunde schickt eine E-Mail: „Wir haben einen neuen Mitarbeiter. Bitte auf der Team-Seite ergänzen. Hier ist sein Foto und der Text.”

In WordPress: Admin einloggen → Seite „Team” öffnen → zum richtigen Abschnitt scrollen → Bild hochladen → Text einfügen → formatieren → Vorschau → Speichern → Cache leeren. Dauer: 15 Minuten.

Mit Claude Code: Terminal öffnen. „Füge in src/components/Team.astro einen neuen Mitarbeiter hinzu: Max Müller, Senior Entwickler. Bild liegt unter public/team/max-mueller.webp.” Claude Code liest die Datei, versteht die bestehende Struktur, fügt den Eintrag konsistent hinzu. git push. Deployed in 40 Sekunden. Dauer: 2 Minuten.

Das ist kein hypothetisches Szenario — so arbeite ich seit Anfang 2025. Claude Code versteht den Kontext des Projekts: Tailwind-Klassen, Komponenten-Struktur, Naming-Konventionen. Die Änderungen sind konsistent, weil die KI den bestehenden Code als Vorlage nutzt — nicht ein Template aus einer Plugin-Datenbank.

Für Blog-Beiträge funktioniert es genauso. Dieser Artikel ist eine MDX-Datei mit YAML-Frontmatter. Claude Code hat die Grundstruktur erstellt — Frontmatter, H2-Gliederung, Tabellen, JSON-LD-Schema. Ich habe die Substanz geliefert: Projekterfahrungen, Zahlen aus echten Projekten, meine Einschätzung. Das Ergebnis ist ein Text, der fachlich fundiert ist und technisch sauber deployed wird — ohne dass ich eine Zeile Markup von Hand schreiben musste.

Häufige Einwände gegen den statischen Ansatz

„Der Kunde kann keine Änderungen selbst vornehmen.” Stimmt — aber es gibt einen Mittelweg. Git-basierte CMS wie TinaCMS oder Sitepins scannen den src/content-Ordner und generieren automatisch Editing-Formulare. Der Kunde bearbeitet Inhalte über eine visuelle Oberfläche, das CMS schreibt Standard-MDX-Dateien direkt ins Repository. Kein Server, keine Datenbank — trotzdem ein Admin-Panel.

Und selbst ohne diesen Mittelweg: Wie oft ändern Kunden wirklich etwas? In meiner Erfahrung kommen nach dem Launch 1–3 Änderungswünsche pro Monat. Das sind 5–10 Minuten Arbeit mit Claude Code. Verglichen mit den 100+ €/Monat Wartungskosten für ein CMS ist das günstiger — und die Änderungen sind sofort qualitätsgesichert im Git-Verlauf.

„Was passiert, wenn ich als Entwickler nicht mehr verfügbar bin?” Das Projekt ist ein Standard-Astro-Repository. Jeder Entwickler mit Frontend-Erfahrung kann es übernehmen — bun install, bun run dev, fertig. Es gibt keine proprietäre Plugin-Architektur, keine Datenbank-Migration, keine undokumentierten Hooks. Das Projekt IST die Dokumentation.

„Skaliert das bei 100+ Seiten?” Für Content-Seiten mit klarer Struktur: ja. Astro baut 500 statische Seiten in unter 90 Sekunden. Für dynamische Inhalte mit täglichen Updates und mehreren Autoren: nein — da ist Payload CMS die bessere Wahl.

Was bleibt

Die drei Ansätze sind keine Konkurrenten, sondern Werkzeuge für unterschiedliche Probleme. WordPress löst das Problem „Ich brauche schnell eine Website und will sie selbst pflegen.” Payload CMS löst das Problem „Ich brauche ein typsicheres Content-System mit API und Admin-Panel.” Der statische Ansatz mit KI löst das Problem „Ich brauche eine schnelle, sichere Website mit null laufenden Kosten.”

In den meisten KMU-Projekten ist der dritte Weg der wirtschaftlichste — nicht trotz, sondern wegen der fehlenden Komplexität. Kein CMS ist sicherer als kein CMS. Und kein Plugin ist schneller als kein Plugin.

Wenn Sie wissen möchten, welcher Ansatz für Ihr Projekt passt, nutzen Sie den Kosten-Rechner für eine erste Einschätzung — oder schreiben Sie mir direkt.