Was WordPress so beliebt macht
WordPress ist kostenlos, hat tausende Themes und Plugins, eine massive Community und einen visuellen Editor. Ein Junior-Webdesigner kann in 2 Tagen eine Standard-Site live haben. Plugins wie WooCommerce, Yoast SEO oder Contact Form 7 erschlagen 80 % aller Anforderungen out-of-the-box.
Für viele KMU-Websites ist das die richtige Wahl. Aber: Was als Stärke verkauft wird, ist oft auch die größte Schwachstelle.
Die drei großen WordPress-Probleme
1. Sicherheit
WordPress-Core ist gut abgesichert. Plugins und Themes meist nicht. Eine durchschnittliche WordPress-Site hat 5–20 Plugins — jedes ein potenzielles Einfallstor. Sicherheits-Tracker wie Wordfence und Patchstack melden jedes Jahr tausende neue Schwachstellen in WordPress-Plugins.
Wer WordPress betreibt und nicht regelmäßig patcht, riskiert, dass die Site gehackt wird. Typische Symptome bei vernachlässigten Installationen: Spam-Injektionen, Defacements oder Malware-Skripte, die unbemerkt auf andere Server umleiten und das Google-Ranking versenken.
Pikant: Selbst Security-Plugins sind nicht immun. Wordfence — das meistinstallierte Sicherheits-Plugin für WordPress — hat in den letzten Jahren mehrere eigene CVEs in der NVD-Datenbank kassiert (zuletzt CVE-2022-3144, eine Stored-XSS-Lücke im Wordfence Security – Firewall & Malware Scan-Plugin). Das ist die ehrliche Lehre: Mehr Plugins = mehr Angriffsfläche, auch wenn das Plugin „Schutz" verspricht. Jedes zusätzliche Plugin will gepatcht und auditiert werden.
WordPress ohne Wartung ist eine Zeitbombe. Wer das System produktiv betreibt, braucht entweder einen festen Wartungs-Rhythmus (Backups + Updates mindestens monatlich) oder einen Wartungsvertrag mit jemandem, der das übernimmt.
2. Performance
WordPress lädt bei jedem Seitenaufruf eine PHP-Engine, Datenbank-Abfragen und Plugins — eine typische Site rendert dadurch spürbar langsamer als eine statische HTML/CSS-Site, die direkt vom Webserver ausgeliefert wird. Caching-Plugins (W3 Total Cache, WP Rocket) helfen — sind aber wieder ein Plugin mehr und müssen konfiguriert werden. Eine statische HTML/CSS/JS-Site braucht das alles nicht.
Mit aktivem Page-Cache (Cloudflare, WP Rocket, W3 Total Cache) wird die linke Pipeline für nicht eingeloggte Besucher größtenteils übersprungen — der Cache liefert vorgeneriertes HTML aus, fast wie bei Static. Mehr dazu im nächsten Abschnitt zu CDN.
3. Lock-in
Wer einen WordPress-Site mit Page-Builder (Elementor, Divi, WPBakery) baut, ist drin. Der Inhalt ist in proprietäre Datenstrukturen verstrickt — eine Migration ist Wochen-Arbeit. Bei einer HTML-Site: einfach den Ordner kopieren, fertig.
Wann HTML/CSS/JS die bessere Wahl ist
- Brochure-Sites mit ca. 5–15 Unterseiten und festem Inhalt (Profil, Leistungen, Cases, Kontakt) — kein dynamischer Content nötig.
- Hohe Performance-Anforderungen — Lighthouse-Score 100, Core Web Vitals top.
- Wartungsfaule Kunden — wer nicht jeden Monat Updates fahren will, ist mit statisch glücklicher.
- Lange Lebensdauer — eine HTML-Site läuft auch in 10 Jahren noch ohne Update.
- Premium-Optik — eigene Animationen, Custom-Layouts, Editorial-Vibes lassen sich freier gestalten.
Wann WordPress die bessere Wahl ist
- Blog-fokussierte Sites — wenn du regelmäßig Artikel veröffentlichst und eine UI dafür willst.
- E-Commerce — WooCommerce ist solide, hat alle Schnittstellen.
- Kunden-Eigenpflege — wenn der Kunde Inhalte selbst ändern will.
- Membership / User-Login — wenn dynamische Funktionen nötig sind.
CDN als Equalizer — wie Cloudflare den Gap schließt
Das Performance-Diagramm oben ist nur die halbe Wahrheit. In der Praxis sitzt vor fast jeder gut gepflegten WordPress-Site ein CDN — meistens Cloudflare. Und das verändert das Spiel grundlegend.
Cloudflare macht drei Sachen, die direkt auf das obige Diagramm einwirken:
- Edge-Caching: Gecachte HTML-Versionen liegen auf weltweit verteilten Servern. Ein Besucher in Köln bekommt die Seite vom Cloudflare-Knoten in Frankfurt — der eigentliche WordPress-Server (z. B. in Hetzner Falkenstein) wird gar nicht erst angesprochen. Die ganze PHP/DB/Plugin-Pipeline aus dem Diagramm wird übersprungen.
- WAF + Bot-Schutz: Bevor ein Request den Webserver erreicht, filtert Cloudflare Bot-Traffic, Brute-Force-Versuche und Exploit-Pattern raus. Das ist insbesondere für WordPress wertvoll, weil 0-Day-Lücken in Plugins so geblockt werden können, bevor du überhaupt von der CVE erfährst.
- Asset-Auslieferung: CSS, JS, Bilder, Fonts — Cloudflare cached und liefert sie aus, mit Brotli-Kompression und HTTP/3. Das gilt sowohl für WordPress als auch für statische Sites. Beide profitieren, aber WP profitiert mehr (weil die Ausgangslage langsamer ist).
Mit Page-Cache + CDN ist eine WordPress-Site für anonyme Besucher fast so schnell wie eine statische Site. Der Unterschied wird messbar nur noch beim ersten Request (Cache-Miss) und für eingeloggte Nutzer (z. B. WooCommerce-Warenkorb, Member-Bereich) — dort läuft die volle PHP/DB-Pipeline weiter.
Heißt für die Entscheidung: Wenn du WordPress mit ordentlichem Caching und Cloudflare betreibst, ist Performance kein zwingendes Argument für Static. Sicherheit und Wartungsaufwand bleiben aber: ein Plugin-Update vergessen kannst du jeden Monat neu, ein Static-File altert nicht.
WordPress ohne CDN ist heute fahrlässig. Cloudflare Free reicht für 90 % der KMU-Sites — DNS umstellen, Page-Rules setzen, Brotli + HTTP/3 aktivieren. Eine eigene tiefere Anleitung dazu folgt als separater Beitrag.
Der Hybrid-Weg: Static + Headless CMS
Wenn dir Static gefällt, der Kunde aber doch Inhalte selbst pflegen können soll, gibt es eine moderne Alternative: Static + Headless CMS. Das funktioniert so:
- Die Website ist und bleibt eine Sammlung statischer HTML-Dateien — schnell, sicher, ohne PHP.
- Daneben läuft ein Headless-CMS (z. B. Strapi, Sanity, Decap-CMS), das ein schickes Editier-UI bereitstellt — entweder selbst-gehostet oder als SaaS.
- Wenn der Kunde im CMS einen Artikel anlegt oder ein Bild austauscht, läuft im Hintergrund ein Build-Schritt (Static-Site-Generator wie 11ty, Astro, Next.js Static Export, Hugo) und regeneriert die HTML-Dateien aus den CMS-Daten. Anschließend werden sie auf den Server bzw. den CDN-Edge deployed.
Der Kunde sieht: ein normales Redaktions-UI, fast wie WordPress. Der Server sieht: nur statische Dateien, keine Datenbank, keine PHP-Engine, keine Wartung. Das Beste aus beiden Welten — mit etwas mehr Setup-Aufwand am Anfang, aber praktisch null Wartung danach.
Für wen passt das? Klassische KMU-Sites mit gelegentlichem Blog, Foto-Portfolio das wachsen soll, Vereins-Sites mit News-Stream. Ungeeignet für E-Commerce mit Live-Inventory, Member-Bereiche oder echte Web-Apps — dort brauchst du wirklich dynamisches Backend.
WordPress ist kein „falsches" Tool. Aber es ist auch nicht das „richtige" für jede Aufgabe. Wer ehrlich beraten will, fragt zuerst nach dem Use-Case — nicht nach der Plattform.
Was ich Kunden in Aachen empfehle
Wenn ich gefragt werde: WordPress nur dann, wenn der Kunde wirklich selbst pflegen will — und auch nur mit Wartungsvertrag, klar geregelten Update-Zyklen und Backup-Strategie. Sonst lieber eine handgeschriebene HTML-Site mit dem Vorteil: läuft, läuft, läuft. Und in 5 Jahren ist sie immer noch sicher.
Fazit
WordPress hat seinen Platz — vor allem für Blogs, Shops und Kunden mit eigener Pflege-Disziplin. Für reine Marken-Websites ist eine handgeschriebene HTML/CSS/JS-Site oft die ehrlichere Wahl: schneller, sicherer, billiger im Betrieb.