WordPress vs. Kirby CMS: Warum wir Kirby statt WordPress einsetzen

WordPress dominiert den Web-Markt: 59,1 % aller Websites, deren CMS bekannt ist, nutzen WordPress (41,2 % aller Websites). Doch die Mehrheit dieser Seiten sind statische Unternehmensseiten, die kein CMS brauchen, und gerade dafür zahlt man mit Performance-Kosten, Sicherheitslücken und Plugin-Dependency-Hölle.

Wir setzen stattdessen auf Kirby CMS: ein dateibasiertes, plugin-freies CMS, das genau das tut, was es soll, und nicht mehr.

Warum Kirby?

Keine Datenbank, keine Plugins

Kirby speichert Inhalte als Markdown-Dateien im Dateisystem. Keine MySQL-Instanz, keine 37 aktivierten Plugins, keine monatlichen Sicherheitsupdates für eine Plugin-Bibliothek, die niemand mehr gepflegt hat.

• Performance: Ein Kirby-Request liest eine Datei, rendert sie und fertig. Kein Datenbank-Join, kein Plugin-Hook, kein Cache-Warmup.
• Sicherheit: 90 % der WordPress-Sicherheitslücken kommen von Plugins. Kirby hat keine Plugin-Architektur im klassischen Sinne, Erweiterungen sind PHP-Klassen, die du selbst kontrollierst.
• Wartung: Ein Kirby-Update ist ein git pull. Keine Kompatibilitätsprüfung für 15 Plugins, keine "your site broke" Meldung am nächsten Morgen.

Dateibasiert statt Admin-Interface

In Kirby bearbeitest du Inhalte direkt als Markdown-Dateien; entweder lokal in deinem Editor oder über das optionale Kirby-Panel. Das hat drei Vorteile:

1. Versionierung: Dein gesamter Inhalt ist in Git. Jeder Edit ist nachvollziehbar, reversibel, branchbar.
2. Editor-Flexibilität: Nutze VS Code, Vim, Emacs; dein bevorzugter Editor mit Syntax-Highlighting, Linting und Autocomplete.
3. Deployment: git push auf den Server. Kein Datenbank-Export, kein Media-Sync, keine Migration.

Kirby vs. WordPress: Die Zahlen

Die CVE-Differenz ist dramatisch: WordPress Core hat 18.978 Sicherheitslücken im NVD, und Plugins kommen mit weiteren 17.623 hinzu. Kirby hat 59 CVEs insgesamt, ein 321-facher Unterschied.

Kirbys eingebauter Seiten-Cache und dateibasierte Architektur eliminieren den Datenbank-Engpass vollständig. Für Seiten mit hunderten Unterseiten empfiehlt Kirby eine verschachtelte Verzeichnisstruktur, um die Performance zu erhalten.

Warum nicht WordPress?

WordPress ist kein schlechtes Produkt, aber es ist das falsche Werkzeug für statische und semi-statische Websites.

Die Plugin-Falle

Ein Kunde wollte ein Kontaktformular. In WordPress: Contact Form 7 + Flamingo + SMTP-Plugin + Anti-Spam-Plugin + Custom CSS für das Formular-Layout. Fünf Plugins für eine E-Mail.

In Kirby: Ein 20-Zeilen-PHP-Skript, das mail() oder SMTP nutzt. Keine Abhängigkeit, keine Update-Pflicht, keine Sicherheitslücke.

Performance-Kosten

Ein WordPress-Request lädt den Core, initialisiert die Datenbank-Verbindung, durchläuft 15–30 aktivierte Plugins, führt Datenbank-Joins für Menüs, Sidebars und Widgets aus, rendert das Theme und gibt das Ergebnis aus. Das Ergebnis: 200–800 ms.

Kirby: Datei lesen, Markdown parsen, Template rendern. 10–30 ms. Der Unterschied ist messbar, und für SEO und Conversion entscheidend.

Angriffsfläche

WordPress ist ein Angriffsziel, weil:

• 41,2 % aller Websites nutzen es → hoher ROI für Angreifer
• WordPress Core hat 18.978 CVEs; Plugins kommen mit 17.623 hinzu
• Jedes Plugin erweitert die Angriffsfläche
• Viele Plugins sind verwaist (keine Updates seit Jahren)
• Update-Zyklen sind unregelmäßig bei 59.000+ Plugins

Kirby hat insgesamt nur 59 CVEs, eine 321-mal kleinere Angriffsfläche. Kirby hat keine klassische Plugin-Architektur: Erweiterungen sind PHP-Klassen, die du selbst schreibst oder einbindest. Das Update-System kann auf Sicherheits-Updates beschränkt werden, und es gibt keine verwaisten Dritt-Plugins.

Kirby in der Praxis

Wir betreiben mehrere Kirby-Sites, von Unternehmensseiten über Blogs bis zu Dokumentationen. Der Workflow:

1. Lokal entwickeln: git checkout -b feature/neue-seite
2. Inhalt schreiben: Markdown-Datei erstellen, Kirby-Blueprint zuweisen
3. Testen: php -S localhost:8000 lokal testen
4. Deployen: git push origin main → Server pullt, Caddy serviert

Kein Admin-Login, keine Datenbank-Session, keine Plugin-Konfiguration.

Migration von WordPress nach Kirby

Der typische Migrationspfad:

1. Inhalte exportieren: WP All Export oder native XML-Export-Funktion
2. Markdown konvertieren: Skript, das HTML-Blocks in Markdown umwandelt
3. Templates erstellen: Kirby-Blueprints für jede Inhaltstyp
4. Media migrieren: Bilder in content/-Ordner, Pfade anpassen
5. Deploy: Git-Repository initialisieren, Server konfigurieren

Für 50–200 Seiten sind 2–5 Entwicklungstage realistisch. Danach hast du ein System, das wartungsfrei läuft.

Fazit

WordPress ist die richtige Wahl, wenn du:

• Ein Blog mit 10.000 Artikeln brauchst
• Komplexe E-Commerce-Funktionalität brauchst
• Ein Team von 50 Redakteuren hast, die ein Admin-Interface brauchen

Kirby ist die richtige Wahl, wenn du:

• Eine Unternehmensseite mit 10–50 Seiten hast
• Selbstständig bist und deine Website wartungsfrei betreiben willst
• Performance und Sicherheit priorisierst
• In Git arbeiten willst

Wir haben den Wechsel mehrfach gemacht, und nie wieder WordPress für ein Kundenprojekt eingesetzt.

Weiterführende Quellen

• Kirby CMS: offizielle Projektseite
• Kirby Dokumentation
• WordPress-Marktanteil: W3Techs
• Kirby vs. WordPress: Community-Vergleich