Die Hälfte des Plugin-Verzeichnisses ist verwaist

#Einleitung

Wir haben das WordPress.org-Plugin-Verzeichnis am 10. August 2026 vermessen. Von 69.286 Plugins hatten 35.696 seit mindestens zwei Jahren kein Update erhalten, also 51,5 Prozent. Diese Zahl ist nicht aus einem fremden Bericht übernommen, denn einen solchen Bericht gibt es nicht. Es folgen die Methode, die Ergebnisse bei vier Schwellen und was daraus für jemanden folgt, der fremde Websites betreut.

#Kurz gefasst

• 35.696 von 69.286 Plugins ohne Update seit zwei Jahren, 51,5 Prozent des Verzeichnisses.
• 28.146, also 40,6 Prozent, ohne Update seit fünf Jahren.
• 20.242, also 29,2 Prozent, ohne Update seit acht Jahren.
• In einer Stichprobe von 5.250 verwaisten Plugins haben 5,9 Prozent tausend oder mehr aktive Installationen, hochgerechnet rund 2.100 im gesamten Schwanz.
• Die kursierenden 43,8 Prozent und 59 Prozent haben keine Primärquelle. Ich habe beide geprüft. Die Wahrheit liegt dazwischen.
• Die Methode ist dokumentiert und mit einem Befehl wiederholbar, denn eine Zahl, die man nicht nachprüfen kann, ist genau so viel wert wie jene beiden.

#Warum ich überhaupt gemessen habe

Ich wollte einen Text auf der Zahl von 43,8 Prozent verwaister Plugins aufbauen. Bevor ich sie benutzte, suchte ich die Quelle. Es gibt keine.

Ich suchte nach einer Alternative und fand 59 Prozent, vielfach wiederholt neben einer Zahl von rund 34.000 Plugins. Das wirkt solider, weil eine absolute Zahl dabeisteht. Ich habe den Text gelesen, der sie einführt, und auch dort steht keine Zuordnung. Der Autor zitiert WordPress.org und WPExperts, aber für die Gesamtzahl der Plugins, und für den Anteil der verwaisten gar nichts.

Das ist der übliche Lebenslauf einer Statistik in dieser Branche. Jemand veröffentlicht eine Zahl ohne Quelle, der Nächste zitiert den Ersten mit Link, ein Dritter zitiert den Zweiten, und ein Jahr später liest sich das wie Allgemeinwissen. Bei uns gilt seit dem 31. Juli 2026 eine Regel, nachdem wir jede nicht belegbare Zahl von der eigenen Website entfernt hatten. Diese Zahl zu veröffentlichen hätte sie unmittelbar gebrochen.

Blieb ein ehrlicher Weg: zählen.

#Die Methode, damit sie wiederholbar ist

WordPress.org stellt unter api.wordpress.org/plugins/info/1.2/ eine öffentliche Verzeichnis-API bereit. Der Modus browse=updated liefert Plugins absteigend nach dem Datum der letzten Aktualisierung.

Da die Liste sortiert ist, lautet die Antwort auf die Frage, wie viele Plugins älter als zwei Jahre sind, schlicht: der Rang des ersten Plugins jenseits der Schwelle. Um ihn zu finden, muss man nicht das ganze Verzeichnis herunterladen, eine binäre Suche über die Seiten genügt. Neun Anfragen statt siebenhundert.

Die gesamte Messung liegt in unserem Repository als npm run measure:plugin-abandonment, eine Wiederholung dauert unter einer Minute. Wenn du das in einem halben Jahr liest und die Zahlen anders aussehen, liegt das nicht daran, dass eine Seite irrt. Es liegt daran, dass das Verzeichnis lebt.

#Ergebnisse bei vier Schwellen

Das Verzeichnis umfasste zum Messzeitpunkt 69.286 Plugins, und die jüngste Aktualisierung war Minuten alt.

Interessant ist die Form dieser Verteilung, nicht eine einzelne Zahl. Zwischen der Zwei- und der Achtjahresschwelle fallen nur rund 15.000 Plugins weg, also wurden die meisten verwaisten Plugins nicht kürzlich aufgegeben. Knapp drei Zehntel des gesamten Verzeichnisses sind Code, den seit acht Jahren niemand angefasst hat: vor Gutenberg, vor PHP 7.2, vor Blöcken.

#Die Zahl mit praktischer Bedeutung

Der Anteil verwaister Plugins ist für sich genommen eine Kuriosität. Das Verzeichnis darf beliebig viel toten Code enthalten, ohne dass jemand Schaden nimmt, solange ihn niemand einsetzt.

Deshalb habe ich eine zweite Sache gemessen: wie viele dieser verwaisten Plugins noch auf Websites laufen. Ich nahm eine systematische Stichprobe aus dem Schwanz des Verzeichnisses, jede siebte Ergebnisseite, 5.250 Plugins, und zählte die aktiven Installationen.

Überträgt man die 5,9 Prozent auf den gesamten Schwanz, ergeben sich rund 2.100 Plugins, die seit zwei Jahren kein Update erhalten haben und dennoch auf je tausend Websites oder mehr laufen.

Das ist die Zahl, die man sich statt des Prozentsatzes merken sollte. Zweitausend Stück Code, jedes auf mindestens tausend Websites, jedes seit zwei Jahren ohne Betreuer.

Ausdrücklich: Das ist eine Stichprobe, keine Vollerhebung. Sie wurde systematisch statt zufällig gezogen, wenn sich aktive Installationen im Schwanz also in einem regelmäßigen Muster mit einer Periode von sieben Seiten anordnen würden, wäre das Ergebnis verzerrt. Ich sehe keinen Grund dafür, halte es aber fest, statt so zu tun, als hätte ich alle 35.696 gezählt.

#Was diese Messung nicht sieht

Drei Dinge, die die Methode konstruktionsbedingt ausschließt. Ich nenne sie, weil 51,5 Prozent sonst genauer wirkten, als es ist.

Sie sieht keine Plugins außerhalb des Verzeichnisses. Jedes Premium-Plugin, direkt beim Autor oder auf einem Marktplatz gekauft, liegt außerhalb dieser API und taucht in keiner der obigen Zahlen auf. Ein typischer WooCommerce-Shop betreibt mehrere davon, meist die heikelsten, denn sie berühren Zahlungen, Versand und Kundendaten. Ihr Zustand muss von Hand geprüft werden, eines nach dem anderen, und diese Arbeit ersetzt keine einzelne Abfrage.

Sie sieht keine geschlossenen Plugins. Wird ein Plugin aus dem Verzeichnis genommen, verschwindet es aus der API und landet weder im Zähler noch im Nenner. Paradoxerweise heißt das, dass aus Sicherheitsgründen geschlossene Plugins die Statistik verbessern, weil sie aus der Menge fallen. Die 51,5 Prozent sind ein Anteil unter den weiterhin gelisteten Plugins.

Aktive Installationen werden von WordPress.org in Stufen angegeben, nicht exakt. Deshalb enthält die Tabelle Bereiche statt Summen. Ein Plugin mit dem Etikett tausend Installationen kann zwölfhundert oder neunzehnhundert haben, das Verzeichnis unterscheidet das nicht. Für die Schlussfolgerung reicht diese Auflösung, für alles Feinere nicht.

#Was acht Jahre ohne Update konkret bedeuten

Die Zahl von 20.242 seit acht Jahren unberührten Plugins bleibt abstrakt, bis man sich erinnert, wie WordPress damals aussah.

August 2018 ist WordPress 4.9. Gutenberg war noch nicht im Kern, es kam erst im Dezember mit 5.0. Der Block-Editor, mit dem heute praktisch jeder Inhalt entsteht, ist für diesen Code eine Zukunft, die nie eintrat. Ein Plugin aus jener Zeit weiß nichts von Blöcken, von register_block_type, von theme.json, von Full Site Editing.

Bei PHP dasselbe Bild. PHP 7.0 und 7.1 waren verbreitet, viele Hoster liefen noch auf 5.6. Seither kamen typisierte Eigenschaften, benannte Argumente, match-Ausdrücke, Attribute und vor allem PHP 8, das viele Warnungen in fatale Fehler verwandelte. Code, der 2018 eine Notice ins Log schrieb, kann eine Website heute lahmlegen.

Nichts davon heißt, dass jedes solche Plugin kaputt ist. Es heißt, dass niemand nachgesehen hat, und der Abstand zwischen seinen Annahmen und der heutigen Umgebung acht Jahre beträgt.

#Was die Zahl nicht bedeutet

Ein verwaistes Plugin ist nicht automatisch verwundbar, und dieser Text soll nicht als Schreckensmeldung gelesen werden.

Ein Plugin, das einen Shortcode hinzufügt und keine externen Eingaben annimmt, kann ein Jahrzehnt ohne Update laufen und völlig sicher sein. Ausbleibende Updates können auch heißen, dass der Code fertig ist, was in einer Welt wöchentlicher Releases fremd klingt, bei wirklich kleinen Werkzeugen aber zutrifft.

Risiko entsteht nicht aus Alter, sondern aus Angriffsfläche. Es steigt dort, wo ein Plugin Nutzereingaben annimmt, REST-Endpunkte registriert, Uploads verarbeitet, Datenbankabfragen aus Parametern baut oder Zahlungen und personenbezogene Daten berührt. Alter ist dann ein Multiplikator, keine Ursache: alter Datei-Code ist nicht gefährlich, weil er alt ist, sondern weil sich PHP und die Angriffstechniken weiterentwickelt haben und er nicht.

Es gibt eine Kehrseite. Auch ein wöchentlich aktualisiertes Plugin kann verwundbar sein, und zwar frisch. Das Datum der letzten Aktualisierung ist ein Signal über Betreuung, nicht über Codequalität.

#Wie du deine eigenen Websites in fünfzehn Minuten prüfst

Drei Schritte in dieser Reihenfolge, keiner braucht ein kostenpflichtiges Werkzeug.

Erstelle die Liste. Zieh die Slugs aller Plugins aus jeder betreuten Installation. Bei einer Website reicht das Backend, bei Dutzenden braucht es WP-CLI und eine Schleife. Ergebnis soll eine Liste sein, nicht zwanzig Browser-Tabs.

Frage das Verzeichnis ab. Hol dir für jeden Slug das Datum der letzten Aktualisierung und die Zahl aktiver Installationen aus der API. Das ist eine Anfrage pro Plugin und lässt sich in der Menge erledigen. Plugins außerhalb des Verzeichnisses, also Premium und Eigenbau, liefern nichts zurück, und diese Leerstelle ist selbst ein Ergebnis: sie tauchen in keiner solchen Aufstellung je auf, und meist sind es genau sie, die Zahlungen berühren.

Sortiere nach Risiko, nicht nach Datum. Eine Datumsspalte allein sagt nichts. Interessant ist der Schnitt aus drei Dingen: lange unbetreut, berührt Daten oder Zahlungen, schwer abzuschalten ohne Schaden für den Kunden. Ein Plugin, das alle drei erfüllt, ist Arbeit für diese Woche, nicht für irgendwann.

Wenn die Liste ohnehin offen ist, ergänze gleich eine Spalte dafür, welches Plugin sich eine Stunde folgenlos abschalten lässt. Diese Information ist am Tag eines Vorfalls unbezahlbar, und sie dann zu erheben ist der denkbar schlechteste Zeitpunkt.

#Was tun, wenn ein Plugin wirklich verwaist ist

Von billig nach teuer, denn die erste Option löst mehr Fälle, als man erwartet.

Prüfe, ob es noch gebraucht wird. Ein großer Teil verwaister Plugins auf Kundenwebsites tut etwas, das niemand mehr nutzt: ein Formular aus einer Kampagne von vor drei Jahren, eine Anbindung an einen eingestellten Dienst, ein Widget in einem längst umgebauten Footer. Löschen ist dann die vollständige Lösung und dauert eine Minute.

Prüfe, ob der Kern das inzwischen kann. WordPress hat in den letzten Jahren einiges aufgenommen, was früher ein Plugin brauchte: Lazy Loading, WebP, Teile der Blockarbeit, XML-Sitemaps. Ein Plugin von 2017 ist oft schlicht überflüssig.

Suche einen gepflegten Ersatz. Beurteile ihn nach Release-Takt und danach, ob der Autor im Supportforum antwortet, nicht nach Installationszahl. Ein Plugin mit einer Million Installationen und letztem Release vor einem Jahr ist die schlechtere Wahl als eines mit fünftausend und einem Release im letzten Monat.

Schreib es selbst, wenn die Funktion klein ist. Ein Plugin, das eine Sache in fünfzig Zeilen erledigt, gehört häufiger als fünfzig Zeilen in das eigene Funktions-Plugin als in eine Abhängigkeit von jemandem, der verschwunden ist. Das ist echte Arbeit, beendet das Problem aber, statt es an den nächsten Betreuer weiterzureichen.

Behalte und beobachte es, bewusst. Manchmal gibt es keinen Ersatz und ein Neuschreiben ist zu teuer. Das ist eine legitime Entscheidung, sofern sie aufgeschrieben ist: wer sie getroffen hat, wann, und was bei einem CVE passiert. Der Unterschied zwischen technischer Schuld und Chaos besteht darin, dass Schuld dokumentiert ist.

#Drei Fälle aus der Praxis, je einer pro Entscheidung

Damit es nicht bei Grundsätzen bleibt, drei typische Situationen mit drei verschiedenen Schlüssen.

Ein Galerie-Plugin, letztes Update vor fünf Jahren, rund tausend Installationen, auf einer Unterseite im Einsatz. Die Prüfung dauert eine Minute: kann der Kern das schon. Block-Galerien beherrschen heute Layouts, Lightbox und responsive Bilder, die Antwort lautet also meist ja. Der billigste Weg, entfernen und den Inhalt in einen Block überführen, beendet die Sache ohne Ersatzsuche.

Ein Formular-Plugin, letztes Update vor drei Jahren, Zehntausende Installationen, betreibt Kontaktformular und Newsletter-Anmeldung. Hier zählt das Alter, denn ein Formular nimmt externe Eingaben an und schreibt sie in die Datenbank, also genau die Fläche, die am schlechtesten altert. Die hohe Installationszahl beruhigt nicht, im Gegenteil, sie macht das Plugin zum lohnenden Ziel. Das ist ein Kandidat für den Wechsel auf ein gepflegtes Pendant, samt Migration gespeicherter Einsendungen, und das ist ein halber Tag Arbeit, keine Minute.

Eine Anbindung an einen Versanddienstleister, letztes Update vor zwei Jahren, wenige hundert Installationen, kein Ersatz, im Checkout verdrahtet. Der härteste Fall, weil sich weder abschalten noch ersetzen lässt. Die einzige ehrliche Entscheidung ist behalten und aufschreiben: wer entschieden hat, wann, was bei einem CVE geschieht und wer quartalsweise prüft, ob der Autor zurück ist. Ohne diesen Eintrag erinnert sich in einem Jahr niemand, dass es eine Entscheidung war und kein Versehen.

Der gemeinsame Nenner ist, dass das Datum der letzten Aktualisierung nie für sich ein Schluss ist. Es ist ein Eingang in eine Abwägung, in der auch Angriffsfläche, Abschaltkosten und die Existenz eines Ersatzes zählen.

#Warum sich das nicht von selbst regelt

Das Verzeichnis kennt keinen Mechanismus, der ein Plugin allein wegen ausbleibender Updates entfernt, und das ist richtig, denn ein solcher Mechanismus würde auch fertigen, funktionierenden Code löschen. Es kennt einen Mechanismus, Plugins aus Sicherheitsgründen zu schließen, und der funktioniert.

Das Problem ist, dass beides zusammen eine Landschaft ergibt, in der der Normalzustand eines Plugins das Fortbestehen ist. Der Autor antwortet nicht mehr, das Plugin bleibt. Die Installationen sinken langsam, denn Websites entfernen selten etwas. Acht Jahre später stehen zwanzigtausend Plugins im Verzeichnis und niemand auf der anderen Seite.

Dazu kommt die Zahl, die Patchstack in State of WordPress Security in 2026 nennt: 46 Prozent der Schwachstellen hatten zum Zeitpunkt der Veröffentlichung keinen Patch. Bei einem betreuten Plugin ist ein fehlender Patch eine Frage von Stunden oder Tagen. Bei einem verwaisten wird es nie einen geben, weil niemand da ist, der ihn schreibt.

Ich schließe nicht mit einem Appell an das Verzeichnis, denn das Verzeichnis ist hier nicht der Hauptakteur. Die einzige Partei, die an einem verwaisten Plugin auf einer konkreten Website etwas ändern kann, ist die Person, die diese Website betreut.

#Wie sich das zur Sechs-Stunden-Wartezeit verhält

Vor wenigen Tagen habe ich über die Initiative Protect the Shire geschrieben, die jedes neue Plugin-Release bis zu sechs Stunden zurückhält, damit ein automatischer Prüfer ansehen kann, was gleich in die Auto-Updates geht. Diesen Text neben die vorliegende Messung zu legen ergibt einen Schluss, den keiner von beiden allein hergibt.

Die Wartezeit schützt vor einem bösartigen Release. Damit sie überhaupt wirkt, muss es ein Release geben. Ihr ganzer Wert betrifft also Plugins, die jemand noch veröffentlicht, und das ist die Hälfte des Verzeichnisses mit Betreuer.

Die andere Hälfte, die hier vermessene, liegt vollständig außerhalb dieses Mechanismus. Ein seit acht Jahren unberührtes Plugin wird kein bösartiges Release ausliefern, aber auch keinen Patch. Es gibt nichts zurückzuhalten, weil nichts kommt. Das Risiko verschiebt sich von dem, was ankommt, zu dem, was bereits installiert ist.

Das sind zwei verschiedene Probleme mit einem gemeinsamen Wort im Namen, und man sollte sie nicht verwechseln. Das erste löst das Verzeichnis, und es löst es zunehmend gut. Das zweite kann das Verzeichnis nicht lösen, denn die Lösung besteht darin, dass jemand auf eine konkrete Website schaut und über ein konkretes Plugin entscheidet.

#Wiederhole die Messung selbst

Das Skript ist in unserem Repository öffentlich und läuft mit einem Befehl. Es fragt ausschließlich die öffentliche WordPress.org-API ab, braucht keinen Schlüssel und stellt für die gesamte Messung weniger als fünfzig Anfragen.

Wenn bei dir etwas anderes herauskommt als bei mir, schreib. Lieber mit einer Zahl korrigiert werden als ungeprüft zitiert, denn genau aus fehlender Prüfung sind die 43,8 und die 59 Prozent entstanden, mit denen ich angefangen habe.

#Quellen

• API des WordPress.org-Plugin-Verzeichnisses, Modus browse=updated, Messung vom 10. August 2026
• Patchstack, State of WordPress Security in 2026, 25. Februar 2026

Zuletzt geprüft: 10. August 2026.