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