Letzte Woche haben wir wp-rankings.com live geschaltet.
Sie verfolgt jedes Plugin im WordPress.org-Repository: Wachstum, Installationsschätzungen, Rankings, Momentum, Keyword-Positionen und Wettbewerbervergleiche.
Das läuft darauf:
- 60.000+ Einträge
- 40 benutzerdefinierte Felder bei jedem einzelnen davon
- 16,2 Millionen Zeilen historischer Daten im Hintergrund
- 3.000 echte Besucher am Launchtag, die meisten davon innerhalb weniger Stunden
- 10.000+ Unique Visitors in den ersten 5 Tagen, noch in der Beta
- Google PageSpeed-Score von 92, ohne jegliche Optimierungsarbeit unsererseits
Alles davon auf GeoDirectory.
Die Suche läuft über unsere eigene Elasticsearch-Erweiterung, ein GeoDirectory-Add-on, das wir für Websites in dieser Größenordnung entwickelt haben. Warum wir es brauchten, erklären wir später.
Die Leute fragen uns ständig, wie weit GeoDirectory skaliert. Die Antwort lautete früher: „Weiter, als Sie denken – und hier sind einige Kundenseiten.
Dieser Beitrag beschreibt, wie es aufgebaut wurde.
Warum es diese Seite gibt
WordPress.org zeigte früher auf jeder Plugin-Seite ein Diagramm zum Wachstum der aktiven Installationen. Irgendwann wurde es entfernt. Das Trac-Ticket, das die Wiederherstellung fordert, #6511, ist noch offen.
Dieses Diagramm war die einzige Möglichkeit zu sehen, ob ein Plugin tatsächlich wächst.
Ohne es bekommt man nur eine Zahl in einem Bereich, „10.000+ aktive Installationen,
Also haben wir vor 4 Jahren begonnen, die WordPress.org-Plugin-API täglich abzurufen, die Ergebnisse zu speichern, und haben wp-rankings V1 entwickelt.
Seitdem haben wir keinen einzigen Tag ausgelassen.
4 Jahre tägliche Snapshots des gesamten Repositorys. Das ist das Einzige, was man im Nachhinein nicht mehr erstellen kann.
V2 ist die Weiterentwicklung davon, mit deutlich mehr Statistiken – und das Ergebnis davon, endlich ein erstklassiges Frontend für die Daten zu bauen.
Die Listing-Struktur
Jedes Plugin im Repository ist ein GeoDirectory-Listing. A gd_place Beitrag, mit seinen Daten in GeoDirectorys Detailtabelle, wp_geodir_gd_place_detail.
40 benutzerdefinierte Felder auf jedem einzelnen. Aktive Installationen, Downloads, Bewertung, Anzahl der Bewertungen, Support-Threads, gelöste Threads, Version, getestet bis, WordPress.org-Rang – plus die Werte, die wir selbst berechnen und zurückschreiben.
Das ist der Teil, den die Leute unterschätzen.
GeoDirectory-Benutzerdefinierte Felder sind ein echtes Schema, in einer echten Tabelle, mit echten Spaltentypen. Unsere berechneten Wachstumsraten leben in FLOAT-Spalten.
Sie werden indiziert, sortiert, gefiltert. Sie verhalten sich wie Datenbankspalten – weil sie genau das sind.
Wer jemals versucht hat, ein WordPress-Archiv auf einer halbwegs großen Website nach einem Post-Meta-Wert zu sortieren, weiß, warum das wichtig ist.
Post-Meta ist ein Schlüssel-Wert-Speicher im Schema-Kostüm – und er fällt genau dann auseinander, wenn man anfängt, interessante Fragen zu stellen.
Alles andere in diesem Beitrag hängt von dieser einen Entscheidung ab. Bringt man seine Daten korrekt in benutzerdefinierte Felder, wird der Rest möglich.
Suche und Sortierung – und der Fehler, den wir gemacht haben
Wenn Sie nur einen Abschnitt dieses Beitrags lesen, dann diesen.
Wir brauchten eine Trending-Sortierung. Das Archiv nach 7-Tage-Wachstum sortieren, um zu sehen, was gerade im Trend liegt.
Claude Code übernimmt den Großteil der Implementierung in diesem Projekt, und seine erste Antwort war individuelles SQL. Benutzerdefinierte JOINs und ein benutzerdefinierter Order-by-Hook, der an GeoDirectorys Abfrage angehängt wurde.
Es sah vernünftig aus. Lokal lief es einwandfrei.
Auf der Live-Website brach die Performance ein. Eine Suche, die zuvor schnell war, dauerte plötzlich zehnerlei Sekunden.
Wir erkannten das sofort und ließen die KI das Ganze verwerfen und es stattdessen auf GeoDirectory-typische Weise umsetzen.
Die richtige Lösung war simpel. Füge growth_7d als benutzerdefiniertes GeoDirectory-Feld hinzu, das eine FLOAT-Spalte in der Detailtabelle erzeugt. Den Wert in einem Hintergrundjob berechnen. Ihn in das Feld schreiben.
Dann die Sortierung im eigenen Sortiersystem von GeoDirectory registrieren und GeoDirectory die Sortierung übernehmen lassen – genau wie bei allen anderen Sortierungen. growth_7d_desc. Fertig.
Wieder schnell. Bei 60.000 Einträgen.
Hier ist die Lektion – und sie geht weit über dieses Projekt hinaus.
KI-Programmierwerkzeuge bauen standardmäßig deine Infrastruktur neu auf. Gib einer ein Sortierproblem, und sie greift auf SQL zurück, weil sie es im Training eine Million Mal gesehen hat.
Sie weiß nicht, dass Stiofan jahrelang damit verbracht hat, die Query-Schicht von GeoDirectory für große Datensätze zu optimieren.
Sie weiß nicht, dass alles, was sie gleich bauen will, bereits gebaut, in der Produktion getestet und über ein Jahrzehnt hinweg verfeinert wurde.
Sie liefert selbstsicher eine schlechtere Version eines bereits gelösten Problems – und ist dabei mächtig stolz auf sich.
Wenn du also Claude oder ChatGPT auf einer GeoDirectory-Website verwendest, ist die mit Abstand wertvollste Anweisung, die du ihr geben kannst, diese:
Umgehe nicht die native Such-, Sortier- und Filterinfrastruktur von GeoDirectory. Erweitere sie mit benutzerdefinierten Feldern.
Genau dafür sind benutzerdefinierte Felder da. Das ist der ganze Trick.
Wo GeoDirectory endet und unser Code beginnt
Wir haben 2 eigene Plugins.
Das erste ist der Scraper. Stiofan hat ihn vor 4 Jahren entwickelt, und er hat eine einzige Aufgabe: täglich die WordPress.org-Plugin-API abrufen und die gefundenen Daten in die Einträge schreiben. Er ist der Grund, warum der Datensatz überhaupt existiert, und er läuft seitdem still und zuverlässig.
Das zweite ist das Analytics-Plugin, neu in V2. Es verwaltet die Snapshot-Tabelle mit 16,2 Millionen Zeilen. Eine Zeile pro Plugin pro Tag: Rangposition, Installationsbereich, geschätzte Installationen, Wachstumsrate, Momentum-Status.
Zeitreihen sind keine Aufgabe eines Verzeichnisses, und wir würden das nie von GeoDirectory verlangen. Diese Tabelle hat ihr eigenes Schema, eigene Indizes und eigene Hintergrundjobs und liegt vollständig außerhalb von GeoDirectory.
Aber die Ergebnisse fließen zurück.
Das Analytics-Plugin erledigt die schwere Arbeit mit seinen eigenen Daten und schreibt die Ausgabe dann in benutzerdefinierte GeoDirectory-Felder. Eine 7-Tage-Wachstumsrate wird aus Millionen von Zeilen historischer Daten berechnet und erscheint als einzelner FLOAT im Eintrag.
Aus GeoDirectory's Perspektive ist es einfach ein weiteres Feld. Es wird sortiert, gefiltert und wie jedes andere angezeigt.
Außen berechnen. Innen speichern. GeoDirectory abfragen lassen.
Das ist die Architektur in 3 Zeilen – und der Grund, warum die Website trotz eines sehr großen Datensatzes schnell ist. Die Archiv-Abfrage berührt die 16 Millionen Zeilen nie. Sie liest eine einzige Zahl, die vor Stunden berechnet wurde.
Die einzelne Eintragsseite
Die Plugin-Seite ist ein Dashboard. Metrikkarte, geschätzte aktive Installationen mit Vertrauensbewertung, Wachstumsdiagramme über 30 Tage, 90 Tage, 1 Jahr und gesamten Zeitraum, ein Momentum-Klassifikator, eine Prognose für den nächsten Meilenstein, Bewertungs- und Support-Statistiken, WordPress.org-Keyword-Rankings sowie eine Vergleichskarte mit bis zu 3 Wettbewerbern.
Im Hintergrund steckt eine standardmäßige GeoDirectory-Einzeleintragsseite im Stock-Blockstrap. Kein individuelles Theme.
Das Dashboard selbst ist unser Code. Chart.js, gespeist aus den benutzerdefinierten Feldern. Ein normaler Blockstrap-Nutzer könnte das nicht von Hand bauen – und es hat keinen Sinn, so zu tun, als ob.
Aber hier ist, was es wert ist, laut gesagt zu werden: Sie müssen es nicht mehr von Hand bauen.
Vor 2 Jahren bedeutete eine solche Seite, wochenlang einen Entwickler zu engagieren.
Heute beschreibst du, was du willst, und eine KI baut es. Diagramme, Karten, Vergleichstabellen und bedingte Badges.
Das ist heute fast trivial, weil das Schwierige bereits erledigt war. Die Daten lagen in GeoDirectory-benutzerdefinierten Feldern – strukturiert, typisiert und abfragbar.
KI ist sehr gut darin, auf einer sauberen Datenschicht aufzubauen. Sie ist sehr schlecht darin, eine zu erfinden.
Gib ihr ein gut strukturiertes benutzerdefiniertes Feld und bitte um ein Wachstumsdiagramm – du wirst es vor dem Mittagessen haben. Lass sie deine Query-Schicht entwerfen, und sie wird fröhlich deine Website zum Absturz bringen, wie wir herausgefunden haben.
Die Aufteilung ist also einfach. GeoDirectory besitzt die Daten und die Abfragen. KI baut alles, was du obendrauf haben willst.
Mach es in dieser Reihenfolge, und diese Art von Website liegt im Bereich einer einzelnen Person.
Die Archive
Hier zahlt sich alles Obige aus.
Die Trending-Seite zeigt Plugins mit mindestens 10.000 aktiven Installationen, geordnet nach ihrer Wachstumsgeschwindigkeit über 7 Tage. Rang, Plugin, 24-Stunden-Bewegung, 7-Tage-Bewegung, Wachstumsprozentsatz und geschätzte aktive Installationen.
Das Ganze ist ein GeoDirectory-Listings-Block.
GeoDirectory's eigener Listings-Block, sortiert nach einer GeoDirectory-Sortieroption, liest benutzerdefinierte GeoDirectory-Felder. Die Trending-Sortierung sitzt im Sortiersystem von GeoDirectory neben allen anderen Sortierungen – sie funktioniert also überall, wo Listings funktionieren.
Es steckt kein benutzerdefiniertes SQL darin.
Die Statistikseite verlinkt direkt dorthin.
Jeder Installations-Bucket auf dieser Seite ist ein Link in den Trending-Bereich mit bereits angewendetem Filter, sodass „Zeig mir die Plugins mit über 100.000 Installationen, die sich gerade bewegen
Die Daten in benutzerdefinierte Felder übertragen, die Sortierung korrekt registrieren, und die Archive bauen sich aus Komponenten zusammen, die GeoDirectory bereits mitliefert.
Der Claim-Prozess
Plugin-Inhaber können ihr Listing beanspruchen. Das ist GeoDirectorys native Claim-Funktion, ergänzt um unsere Verifizierungslogik.
Wir prüfen den Plugin URI: Header, den in der PHP-Hauptdatei, und verifizieren, dass der Antragsteller die Kontrolle über diese Domain hat.
E-Mail-Verifizierung, automatische Genehmigung per Klick.
Etwa 100 Plugins wurden in der ersten Woche beansprucht.
Dasselbe Muster wie überall sonst auf dieser Website.
GeoDirectory liefert die Funktion. Ihre Geschäftsregeln setzen darauf auf.
Traffic, Geschwindigkeit und die Elasticsearch-Frage
Der Launch wurde fast ausschließlich durch X angetrieben.
Der Beitrag verbreitete sich weitläufig, einige bekannte Persönlichkeiten im WordPress-Bereich griffen ihn auf, und der Traffic kam schlagartig.
3.000 echte Menschen am Launch-Tag. Nicht gleichmäßig über 24 Stunden verteilt, sondern auf wenige davon konzentriert.
Ein Wort zur Messung, denn das bringt viele ins Stolpern. Cloudflare meldete 72.000 Unique Visitors für diesen Zeitraum. Die Server-Logs zeigten rund 3.000 Menschen. Der Rest waren Bots.
Wenn Sie einen Kunden über den Verzeichnis-Traffic informieren, prüfen Sie zuerst die Server-Logs, bevor Sie jubeln.
Der Stack hielt stand. GeoDirectory Cloud, Cloudflare davor, LiteSpeed-Caching.
Nichts Ausgefallenes.
Google PageSpeed bewertet es mit 92, und wir haben noch nicht einmal mit der Optimierung begonnen (das passiert, sobald die Beta endet).
Jetzt der ehrliche Teil.
Die Suche auf dieser Website läuft über unsere eigene Elasticsearch-Erweiterung für GeoDirectory.
Bei 60.000 Einträgen mit 40 benutzerdefinierten Feldern und der Sortierung nach berechneten Werten wurde die Suche mit benutzerdefinierter Sortierung langsamer, als wir es uns gewünscht hätten.
MySQL leistete mehr Arbeit, als es hätte sein sollen.
Die meisten Verzeichnisse werden dem niemals nahekommen.
GeoDirectorys native Suche ist schnell, und wenn Sie einige Tausend Einträge betreiben, ist sie bereits die richtige Wahl. Das würden wir Ihnen so sagen.
wp-rankings befindet sich wirklich am äußersten Ende der Kurve, und die Elasticsearch-Erweiterung ist etwas, das wir bei maßgeschneiderten Projekten für Websites installieren und konfigurieren, die MySQL entwachsen sind.
Das Wichtige daran ist, dass sie sich in GeoDirectorys Suchebene einklinkt.
Es tauscht die Engine darunter aus, alles darüber bleibt nativ. GeoDirectory behält die Kontrolle über Suche, Sortierung und Filterung.
Dasselbe Prinzip wie zuvor, nur aus der anderen Richtung.
Arbeite mit der Infrastruktur von GeoDirectory, nie daran vorbei. Das eine skaliert die Website. Das andere bringt sie zum Absturz.
Der Rest des Stacks
UsersWP für Konten, Login, Registrierung und Profile.
Blockstrap, plus das Blockstrap Page-Builder-Plugin, für die Templates und alles Visuelle.
Turnstile bei Login und Registrierung, über AyeCode Connect.
GetPaid und UsersWP Membership für die Premium-Stufe, wenn sich die Nachfrage als real erweist. Wir haben sie noch nicht gebaut.
Die Nachfrage, die wir nicht erwartet haben, ist Werbung.
Ein halbes Dutzend Leute haben bereits angefragt, die Website zu sponsern, also kommt das GeoDirectory Advertising Add-on als Nächstes – als Self-Service, sodass Sponsoren ihre eigenen Werbeplätze kaufen können, ohne dass wir eingreifen müssen.
Der gesamte AyeCode-Stack – macht genau das, wofür er gebaut wurde. Hier ist nichts ein Workaround.
Was das beweist
„Wie weit skaliert GeoDirectory?
Now there’s a public one you can go and break.
60.000 Einträge. 40 benutzerdefinierte Felder bei jedem. 16 Millionen Zeilen Verlauf dahinter.
Ein Traffic-Spike, der die meisten Verzeichnis-Websites in die Knie zwingen würde – problemlos absorbiert.
Wir zwei haben es gebaut.
Der Großteil der Umsetzung wurde KI-gestützt durchgeführt, und die einzigen echten Probleme entstanden, als wir die KI die Architektur von GeoDirectory neu gestalten ließen, anstatt sie einfach zu nutzen.
Schau es dir an: wp-rankings.com
Wenn du etwas Ähnliches bauen möchtest, weißt du bereits, womit es läuft.