Worum es geht
Es gibt eine Zahl, die in kaum einem Gespräch über Content-Management-Systeme fehlt: Rund vier von zehn Websites laufen mit WordPress. Sie wird gern vorgetragen, als wäre Verbreitung bereits ein Qualitätsurteil. Dabei beschreibt sie zunächst einen Markt. Ob ein System zu einer Organisation passt, zu ihrer Redaktion, ihren Schnittstellen und dem Aufwand, den sie in die Pflege investieren kann, verrät die Zahl nicht.
Die Frage, ob WordPress gut ist, lässt sich mit dem Marktanteil also nicht beantworten. Wohl aber mit der Frage, woher dieser Marktanteil kommt. Denn die Gründe für den Erfolg des Systems sind zugleich seine Stärken, und einige von ihnen erweisen sich bei näherem Hinsehen als seine Schwachstellen.
WordPress entstand 2003 als Fork einer kleinen Blogsoftware namens b2/cafelog, initiiert von Matt Mullenweg und Mike Little. Technische Eleganz war nie sein stärkstes Argument. Gewonnen hat es durch Zugänglichkeit: eine Installation, die in wenigen Minuten erledigt war, eine Oberfläche, die auch Menschen ohne Programmierkenntnisse verstanden, und eine Lizenz, die jedem erlaubt, den Code zu nutzen, zu verändern und weiterzugeben. Aus dem Blog-Werkzeug wurde im Lauf der Jahre ein vollwertiges Content-Management-System.
Der eigentliche Motor ist ein Netzwerkeffekt. Je mehr Websites mit WordPress laufen, desto mehr Entwicklerinnen schreiben Plugins und Themes, desto mehr Hoster bieten die Installation per Klick an, desto mehr Tutorials, Schulungen und Fachkräfte gibt es. All das zieht wiederum neue Nutzer an. Ökonomen sprechen bei solchen Konstellationen von zweiseitigen Märkten: Jede Seite macht das Angebot für die andere wertvoller, bis der Vorsprung kaum noch einzuholen ist.
Für Betreiber liegt der greifbarste Nutzen dieser Größe allerdings woanders, als man vermuten würde. Er heißt Wechselfreiheit, und es lohnt, genau hinzusehen, welche gemeint ist. Den Hoster zu wechseln, ist bei WordPress meist überschaubar, weil nahezu jeder Anbieter das System beherrscht. Auch ein neuer Dienstleister findet sich leicht. Der Wechsel des Systems selbst ist eine andere Sache: Wie gut sich Inhalte und Strukturen aus WordPress heraustragen lassen, entscheidet die konkrete Umsetzung. Eine Internetpräsenz, die nur eine einzige Agentur versteht, macht abhängig, ganz gleich, mit welchem CMS sie läuft.
Gerade dieser Vorsprung gerät 2026 in Bewegung. Laut W3Techs lag der Anteil von WordPress an allen erfassten Websites am 1. Januar 2025 bei 43,6 Prozent, am 1. Oktober 2026 noch bei 40,2 Prozent; unter den Websites mit erkennbarem CMS waren es 58,7 Prozent (1). Kleinere Dellen gab es auch früher, neu ist das Tempo: Search Engine Journal berichtete bereits im Frühjahr von sechs Monaten Rückgang in Folge (2).
Die Ursachen lassen sich aus den Zahlen allein nicht ablesen. Shopify hat seit Jahresbeginn zugelegt, manche Beobachter sehen außerdem einen Zusammenhang mit dem Rechtsstreit, der die WordPress-Welt seit 2024 beschäftigt. Ein sinkender Anteil heißt zudem nicht, dass es weniger WordPress-Websites oder weniger Dienstleister gibt; das Netz wächst, und andere Systeme wachsen schneller. Mit gut fünf Prozent für Shopify als Nummer zwei bleibt das Ökosystem von WordPress um ein Vielfaches größer als jedes andere. Veraltet ist das System auch nicht: Seit Mai 2026 sind mit WordPress 7.0 und 7.1 zwei große Versionen erschienen, die unter anderem einen KI-Client und eine Erweiterung der mit 6.9 eingeführten Abilities API in den Core bringen. Die Kurve zeigt aber, dass auch ein Netzwerkeffekt keine Naturkonstante ist.
Das stärkste Argument für WordPress ist seine Lizenz. Die GPL erlaubt, WordPress zu nutzen, zu untersuchen, zu verändern und weiterzugeben, und einmal veröffentlichter Code lässt sich seinen Nutzern nicht wieder entziehen. Angeboten wird WordPress selbst kostenlos; Geld kosten Hosting, Premium-Plugins, Entwicklung und Pflege. Damit ist eine wichtige Voraussetzung für Datensouveränität geschaffen, allerdings nur eine. Ob eine Organisation ihre Website tatsächlich selbstbestimmt betreibt, hängt ebenso an Daten, Zugängen, eingebundenen Diensten und Verträgen. Und der praktische Betrieb stützt sich auf eine Infrastruktur, die keine Lizenz erfasst: das Plugin-Verzeichnis, das Theme-Verzeichnis und den Update-Dienst auf wordpress.org. Über diese Plattform verfügt de facto eine einzelne Person, Matt Mullenweg, der zugleich das Unternehmen Automattic führt.
Was das bedeuten kann, zeigte sich im Herbst 2024. Nach einem öffentlich ausgetragenen Konflikt mit dem Hoster WP Engine sperrte wordpress.org dessen Zugriff auf die eigenen Ressourcen. Kunden des Hosters erhielten Plugin-Updates vorübergehend nicht mehr auf dem gewohnten Weg, und der Verzeichniseintrag des verbreiteten Plugins Advanced Custom Fields wurde durch eine Abspaltung ersetzt. Erst eine einstweilige Verfügung im Dezember 2024 stellte den Zugang und die Kontrolle über den Plugin-Eintrag wieder her. Der Rechtsstreit dauert an.
Eine Antwort aus der Community kam im Juni 2025: Unter dem Dach der Linux Foundation startete der FAIR Package Manager, ein föderiertes, herstellerneutrales Verteilsystem für Plugins und Themes, das die Abhängigkeit von einer einzigen Quelle auflösen soll (3). Für Betreiber folgt daraus eine nüchterne Einsicht: Die Lizenz schützt den Code, nicht die Lieferkette. Der bessere Prüfstein für Souveränität ist eine schlichte Frage: Könnte eine andere qualifizierte Stelle die Website morgen übernehmen und weiterbetreiben? Dazu gehören gesicherte Zugänge und Herausgaberechte, verfügbare Daten und Medien, dokumentierte Abhängigkeiten und ein Umzug, der nicht nur auf dem Papier möglich ist.
Kaum ein Ruf hält sich so hartnäckig wie der vom unsicheren WordPress. Die Zahlen sind genauer als der Ruf. Patchstack zählte für 2025 insgesamt 11.334 neu entdeckte Sicherheitslücken im WordPress-Ökosystem, 42 Prozent mehr als im Vorjahr. 91 Prozent davon steckten in Plugins, der Rest in Themes; auf den Core entfielen ganze sechs, allesamt mit geringem Risiko (4). Brisanter sind zwei andere Befunde. Für fast die Hälfte der Lücken gab es zum Zeitpunkt der Veröffentlichung noch keinen Patch des Herstellers. Und bei besonders stark angegriffenen Schwachstellen beobachtete Patchstack erste Ausnutzungsversuche oft binnen weniger Stunden; der nach Angriffsaktivität gewichtete Median lag bei fünf Stunden.
Selten heißt allerdings nicht nie, und die Zahl gemeldeter Lücken misst nicht das Risiko einer konkreten Website. Ein einziger weitreichender Fehler im Core kann schwerer wiegen als Dutzende kaum ausnutzbarer Plugin-Lücken. Im Juli 2026 wurde unter dem Namen wp2shell eine Kette aus zwei Schwachstellen im Core bekannt, über die Angreifer ohne Anmeldung Code auf einer völlig unveränderten Installation ausführen konnten; WordPress reagierte mit Notfall-Releases und erzwungenen automatischen Updates (5). Im Oktober folgten mit PHP2Shell zwei kritische PHP-Sicherheitslücken eine Ebene tiefer, in der Programmiersprache selbst. Abhilfe schafft nur die Aktualisierung der eingesetzten PHP-Laufzeit, ein WordPress-Update ändert daran nichts.
Sicherheit ist bei WordPress deshalb weniger eine Eigenschaft des Systems als eine des Betriebs. Sie ergibt sich aus der Auswahl der Erweiterungen, der Pflege von Server und PHP und der Zeit zwischen dem Bekanntwerden einer Lücke und der Reaktion darauf. Wer Updates einmal im Quartal einspielt, verlässt sich bei einem Zeitfenster von wenigen Stunden im Grunde auf Glück. Und weil es oft zunächst keinen Patch gibt, besteht eine gute Wartung aus mehr als Updates: aus der Entscheidung, ein Plugin vorübergehend abzuschalten oder zu ersetzen, aus Schutzregeln, Backups und abgesicherten Zugängen. Gegen Zero-Day-Lücken bleibt auch dann ein Restrisiko.
Zwei Websites mit WordPress teilen mitunter kaum mehr als die Anmeldemaske. Auf rund einem Drittel aller WordPress-Installationen erkennt W3Techs den Page Builder Elementor, der den Editor durch eine eigene Gestaltungsebene mit eigener Datenstruktur ersetzt. Das liefert schnelle Ergebnisse und schafft eine Abhängigkeit mitten im offenen System: Wer den Builder irgendwann loswerden will, muss Seitenaufbau, Gestaltung und manche Funktion oft neu aufsetzen, auch wenn Texte und Medien erhalten bleiben. Dazu kommen Installationen mit Dutzenden Plugins, von denen jedes eine eigene Update-Politik, eine eigene Qualität und ein eigenes Sicherheitsrisiko mitbringt.
Der andere Weg führt über den Block-Editor, der seit 2018 zum Core gehört. Eigene Gutenberg-Blöcke, ein in der theme.json definiertes Designsystem, zugelassene Blöcke, Vorlagen und gesperrte Bereiche geben der Redaktion Leitplanken statt einer leeren Leinwand: Sie kann Seiten frei zusammenstellen, ohne das Corporate Design versehentlich zu zerlegen. Auch eigene Blöcke schaffen allerdings Abhängigkeiten, vor allem dynamische, die ihren Code für die Ausgabe brauchen. Dokumentation und eine saubere Übergabe gehören zum Handwerk.
Wer eine WordPress-Agentur auswählt, sollte nach der Machart fragen; Referenzen mit WordPress hat fast jede. Welche Aufgaben übernehmen die Plugins, wer pflegt sie, und was geschieht, wenn eines davon eingestellt wird? Werden Page Builder eingesetzt? Wer betreut die eigenen Blöcke nach Projektende, und liegt alles so dokumentiert vor, dass ein anderer Dienstleister übernehmen könnte?
In Verbänden entstehen Inhalte selten an einem einzigen Schreibtisch. Die Geschäftsstelle pflegt Termine, die Pressestelle Mitteilungen, Fachausschüsse liefern Stellungnahmen zu, Ehrenamtliche betreuen Regionalseiten, und alle paar Jahre wechselt ein Teil des Personals. Hier zahlt sich die Verbreitung von WordPress praktisch aus: Viele neue Mitarbeitende haben schon mit dem Backend gearbeitet, und wer es nicht kennt, findet WordPress selten schwer zu lernen. Wie kurz die Einarbeitung ausfällt, hängt trotzdem von der jeweiligen Umsetzung ab. Mit eigenen Inhaltstypen und Taxonomienlassen sich Veranstaltungen, Positionspapiere oder Fachgebiete sauber strukturieren.
Genauer hinsehen sollten Verbände beim Rechtekonzept. WordPress bringt brauchbare Standardrollen mit, doch die Rolle „Redakteur“ darf auch fremde Inhalte bearbeiten. Dass eine Person ausschließlich die Seiten ihres Landesverbands pflegt oder ein Positionspapier erst nach Freigabe durch den Vorstand erscheint, ergibt sich daraus nicht von selbst. Ein organisationsspezifisches Berechtigungskonzept braucht zusätzliche Konfiguration, Erweiterungen oder Entwicklung, und es gehört ins Lastenheft, bevor das erste Template entsteht.
Die eigentliche Grenze verläuft dort, wo eine Website zur Fachanwendung wird. Mitgliederverwaltung, Beitragsabrechnung oder die Organisation eines Kongresses lassen sich mit Plugins zwar nachbilden, das Ergebnis gerät aber schnell zum Flickenteppich, weil jedes Plugin sein eigenes Datenmodell mitbringt. Tragfähiger ist es meist, solche Prozesse einem spezialisierten System zu überlassen und es über Schnittstellen wie die REST-API und ein gemeinsames Single-Sign-on mit der öffentlichen Website zu verbinden. Wir entwickeln mit WordPress, TYPO3 und eigener Plattform; deshalb richtet sich die Empfehlung allein nach dem Bedarf des jeweiligen Verbands.
Agenturen, die Konzept und Gestaltung verantworten, brauchen für die Umsetzung häufig einen technischen Partner. WordPress hat für diese Konstellation einen Vorzug, der selten ausgesprochen wird: Es ist eine gemeinsame Sprache. Die Agentur versteht das Backend, die Kundin kann ihre Inhalte selbst pflegen, und der Entwicklungspartner bleibt ersetzbar. Für alle drei sinkt damit das Risiko, an einer einzigen Stelle zu hängen.
Entscheidend ist, was nach dem Launch geschieht. Eine dokumentierte Übergabe und ein Aufbau ohne builderspezifische Gestaltungsebenen sorgen dafür, dass ein späterer Dienstleister nichts erst entwirren muss. So bleibt die Kundenbeziehung bei der Agentur, während die technische Betreuung durch einen Partner im Hintergrund laufen kann.
WordPress ist kein Universalwerkzeug, auch wenn sein Marktanteil das nahelegt. Für viele Onlineshops ist WooCommerce dennoch eine naheliegende Wahl; W3Techs findet das Shop-Plugin auf rund jeder fünften WordPress-Website. Je komplexer allerdings Preislogik, Varianten, Warenwirtschaft, Logistik und internationaler Vertrieb werden, desto genauer muss geprüft werden, ob WooCommerce noch die wirtschaftlich sinnvollste Grundlage ist oder eine Plattform wie Shopify oder Shopware besser passt. Hochindividuelle Anwendungen wie Portale mit eigener Geschäftslogik lassen sich mit einem Framework oder einer individuellen Programmierung meist direkter umsetzen. Und eine kleine Website, deren Inhalte sich alle zwei Jahre ändern, braucht mitunter gar kein CMS.
Bleibt die organisatorische Frage, die vor jeder technischen kommt: Wer kümmert sich? Eine schnell zusammengesteckte WordPress-Website verschiebt Integrations- und Pflegearbeit gern in die Zukunft, und dort wird sie selten kleiner. Ein WordPress, das niemand aktualisiert, ist das teuerste aller günstigen Systeme. Die Popularität sorgt dafür, dass sich immer jemand finden lässt, der diese Aufgabe übernehmen kann. Ob sich tatsächlich jemand kümmert, entscheidet jede Organisation selbst.