Das WordPress-Plugin-Verzeichnis, einmal komplett gezählt.
Wir haben nicht gestichprobt. Wir haben am 28. August 2026 jede gelistete Erweiterung abgerufen und gegen jede jemals vergebene Kennung gehalten. Methode, Rohdaten und Skript stehen weiter unten, damit jeder nachrechnen kann.
Stichtag 28.08.2026 · 70.909 gelistete Plugins · 284 Abrufe in 190 Sekunden · Skript und Daten offen
Dieselbe Frage, zwei Antworten
Anteil der Erweiterungen ohne veröffentlichte Aktualisierung seit über einem Jahr.
5,4 %. Der Balken ist so kurz, dass die Zahl nicht hineinpasst. Genau das ist der Befund: Das Verzeichnis sieht nach Stückzahl aus wie ein Friedhof und nach Nutzung wie ein gesundes Ökosystem. Beides stimmt.
In absoluten Zahlen: 41.395 der 70.909 gelisteten Plugins hatten am Stichtag seit über 365 Tagen keine Veröffentlichung. 35.602 Plugins (50,2 Prozent) seit über 730 Tagen, 32.920 Plugins (46,4 Prozent) seit über 1.095 Tagen. Nach Installationen gewichtet sind das 5,4 Prozent, 3 Prozent und 2 Prozent.
Zwei von fünf Kennungen sind Grabsteine
Ein Feld für je 200 vergebene Plugin-Kennungen. Grau bedeutet: heute nicht mehr im Verzeichnis. Warum sie verschwunden sind, sagt diese Ausgabe nicht, das misst Ausgabe 02.
620 Kacheln, davon 265 grau. Maßstab 1 zu 200.
Die Punktwolke, mit sichtbarer Unschärfe
Jeder Punkt ist ein Plugin ab 1.000 Installationen. Waagerecht die Tage seit der letzten Veröffentlichung, senkrecht die Installationen. Und jetzt der Teil, den sonst niemand zeigt: der Hof um jeden Punkt ist die Messunsicherheit.
Das Verzeichnis liefert Installationszahlen mit genau einer signifikanten Stelle. Ein Plugin mit dem Wert 10.000 hat real irgendetwas zwischen 10.000 und 19.999. Der innere Kreis zeigt die Untergrenze, der äußere die Obergrenze. Wer hier eine exakte Fläche zeichnet, behauptet eine Genauigkeit, die die Quelle nicht hergibt.
Prüfe deine eigenen Plugins
Trag die Verzeichnis-Kennungen ein, die auf deiner Seite laufen, eine pro Zeile. Du findest sie in der Adresse der Verzeichnisseite oder als Ordnername unter wp-content/plugins/. Die Abfrage passiert in deinem Browser, es geht nichts an uns.
Die Fallen der WordPress.org-API
Beim Erheben sind wir in jede einzelne davon getreten. Wer schon einmal Zahlen aus dieser Schnittstelle gezogen hat, kennt vermutlich mindestens eine und hielt sie für den eigenen Fehler. Alle Befunde sind mit den folgenden Aufrufen reproduzierbar.
1. Das Verzeichnis kann seine eigene Größe nicht angeben
Zum selben Zeitpunkt, dreimal reproduziert: Über browse=updated meldet die Schnittstelle 70.826 Ergebnisse, über browse=popular 66.709. Differenz rund 4.100. Wer nach Beliebtheit blättert, verliert einen Teil des Bestands, ohne es zu merken.
curl -s 'https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request[browse]=updated&request[per_page]=250' | head -c 200 curl -s 'https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request[browse]=popular&request[per_page]=250' | head -c 200
2. Die gemeldete Seitenzahl stimmt nicht
Bei einer Suche meldet Seite 1 den Wert pages: 11. Ruft man Seite 11 ab, meldet dieselbe Antwort plötzlich 27. Wer info.pages als Abbruchbedingung nimmt, verliert rund 60 Prozent der Treffer. Wir brechen deshalb an der ersten leeren Seite ab, nicht an der gemeldeten Zahl.
3. Die Seitenzahl wird still bei 999 geklemmt
Die Abfrage von Seite 1000, 1001, 2000 und 3001 liefert jeweils den Inhalt von Seite 999, und info.page meldet dann ebenfalls 999. Ein Crawler, der seinem eigenen Zähler traut, nimmt dieselben Datensätze mehrfach auf und merkt nichts.
4. „Gib mir alles" liefert am wenigsten
Die Download-Historie akzeptiert limit bis 730 und gibt dann 729 Tage zurück. Ab 731 fällt sie kommentarlos auf 179 Tage. Geprüft mit 731, 800, 850, 900, 999, 1000 und 2000, immer dasselbe.
curl -s 'https://api.wordpress.org/stats/plugin/1.0/downloads.php?slug=akismet&limit=730' | tr ',' '\n' | wc -l curl -s 'https://api.wordpress.org/stats/plugin/1.0/downloads.php?slug=akismet&limit=731' | tr ',' '\n' | wc -l
5. Versionsfelder sind manchmal ein Boolean
Bei 44,5 Prozent der gelisteten Plugins ist requires_php nicht etwa leer, sondern false. Dasselbe kommt bei tested und requires vor. Wer auf einen Versionsstring parst, stürzt ab oder zählt still falsch. Das ist der wahrscheinlichste Grund, warum kursierende Kompatibilitätszahlen auseinandergehen.
6. Die wichtigste Kennzahl der Branche hat eine signifikante Stelle
In der Vollerhebung kommen bei active_installs nur 52 verschiedene Werte vor: 0, 10, 20 bis 90, 100, 200 bis 900, 1000 und so weiter. Es gibt keine 12.500 und keine 47.000. Der Wert ist außerdem die Untergrenze eines Bereichs, nicht dessen Mitte. Summiert man über den ganzen Bestand, liegt die Summe der Untergrenzen bei 324,8 Millionen und die der Obergrenzen bei 482,3 Millionen. Das sind 48,5 Prozent Spannweite, die durch keine größere Stichprobe kleiner wird.
Die Konsequenz für alle Zahlen, die man liest: Jede Aussage der Bauart „X Millionen Websites nutzen Y" aus dieser Quelle trägt diese Spannweite in sich, ob sie das dazusagt oder nicht.
Methode, und was diese Zahlen nicht hergeben
Erhoben wurde am 28.08.2026 über api.wordpress.org/plugins/info/1.2 mit action=query_plugins und browse=updated, 284 Seiten zu je 250 Einträgen, ein Abruf pro 250 Millisekunden. Der Nenner, also alle je vergebenen Kennungen, stammt aus der Verzeichnisliste von plugins.svn.wordpress.org: 123.921 Einträge. Sechs Datensätze tauchten während des Laufs auf zwei Seiten auf, weil sich der nach Aktualität sortierte Bestand währenddessen bewegt, sie sind über den Slug entdoppelt.
Was wir nicht sagen können. Installationen sind keine Websites und keine Kunden, sie zählen Installationen, die sich beim Update-Check melden. Downloads und Installationen sind nicht ineinander umrechenbar, jedes automatische Update zählt als Download. Warum eine Kennung nicht mehr gelistet ist, sagt diese Ausgabe nicht. Und die Angaben zu getesteter Version und PHP-Mindestversion sind Selbstauskunft der Autoren, niemand prüft sie nach.
Warum hier keine Plugin-Namen stehen. Die Daten würden eine Rangliste der stillsten Erweiterungen hergeben, und die wäre der meistgeteilte Teil dieser Seite. Wir bauen sie nicht. Eine solche Liste macht aus einer Messung eine Anklage gegen namentlich genannte Einzelne, oft ehrenamtliche Entwickler. Wer einen bestimmten Fall wissen will, kann ihn oben abfragen, und bekommt genau die Auskunft, die auch die offizielle Schnittstelle gibt.
Was uns selbst betrifft. Von unseren drei Einträgen im Verzeichnis meldet Leadlotse „getestet bis 7.0.4", während der Kern bei 7.1 steht, liegt also selbst im Rückstand. Leadlotse und Wellenbrecher stehen beide im untersten Installationsbereich. Das gehört in dieselbe Tabelle wie alles andere.
Nachrechnen
Wer uns nicht glaubt, soll es besser machen können. Beides steht unter CC BY 4.0.
- census-01-2026.json mit allen Aggregaten und der Punktwolke, 75 KB
- census-slugs.tsv mit allen 70.909 Kennungen, Installationsbereich, Tagen seit dem letzten Release, getesteter Version und PHP-Mindestversion, 2,4 MB. Kopfzeile:
slug,installationsbereich(Untergrenze des API-Eimers),tage_seit_release,getestet_bis,php_min - Die Erhebungs- und Auswertungsskripte liegen im Projekt unter
bin/seekarte-bestand.mjsundbin/seekarte-auswerten.mjs
Zitierform: hafenstudios, Plugin Directory Census 01/2026, Stichtag 28.08.2026, hafenstudios.com/census/01-2026/, SHA-256 der Aggregatdatei census-01-2026.json: b893363ff71d48b64016c9eaaca8576c81d61d9fc3f950023370b156d5ad1244
Prüfwert der Kennungsdatei census-slugs.tsv: 63f30cdaa41f292120746cf1d3f6e9bf34b082d0a7d75a12c75954fffa58fe79