So funktioniert der RevealTheme-Detektor

Wenn Sie eine URL in einen unserer Detektoren eingeben, passiert in den zwei Sekunden, bevor Sie die Ergebnisse sehen, eine ganze Menge. Hier ist der technische Rundgang für die Neugierigen, einschließlich der Grenzen, die wir nicht durch Engineering lösen können.

Schritt 1: Das öffentliche HTML abrufen

Wenn Sie eine URL absenden, ruft unser Server die öffentliche Webseite dieser URL mit einem Standard-Browser-User-Agent ab. Es ist dasselbe HTML, das Ihr Browser erhalten würde, wenn Sie die Website direkt besuchen. Wir umgehen keine Bezahlschranken, extrahieren keine durch Anmeldung geschützten Inhalte und verwenden keinerlei Authentifizierung.

Der Abruf verwendet ein Timeout von 20 Sekunden. Wir folgen bis zu 10 Weiterleitungen (was die Weiterleitungen HTTP → HTTPS, www → ohne-www und länderspezifische Weiterleitungen abdeckt). Gibt die Website eine 4xx- oder 5xx-Antwort zurück oder antwortet sie nicht innerhalb des Timeout-Fensters, geben wir einen klaren «nicht erreichbar»-Fehler zurück, statt zu raten.

Schritt 2: Die Plattform erkennen

Bevor wir versuchen, ein konkretes Theme zu identifizieren, prüfen wir, welches CMS die Website betreibt. Wir suchen nach Fingerabdrücken der 7 unterstützten Plattformen – WordPress, Shopify, Magento, Joomla, Drupal, Moodle und PrestaShop – und wählen die stärkste Übereinstimmung.

Wenn Sie eine Shopify-URL an unseren WordPress-Detektor senden (oder umgekehrt), weisen wir Sie darauf hin und verlinken auf den richtigen Detektor. Kein Raten, keine Fehlalarme.

Schritt 3: Theme-Erkennung

Speziell bei WordPress tauchen Theme-Verweise in der Regel im HTML der Seite in Pfaden wie wp-content/themes/THEME_NAME/style.css auf. Wir extrahieren jeden dieser Verweise aus jedem Teil des Dokuments: link-Tags, script-Tags, Inline-JavaScript, JSON-LD-Blöcke und sogar dem Textinhalt. So werden Themes erkannt, die stark optimierte Websites vor Standard-Erkennungstools verbergen.

Für jedes erkannte Theme versuchen wir, die Datei style.css des Themes abzurufen. Der Header dieser Datei enthält den offiziellen Theme-Namen, den Autor, die Version, die URI und die Beschreibung, direkt vom Theme-Entwickler. Das ist die Quelle der umfangreichen Theme-Informationen, die wir neben dem Erkennungsergebnis anzeigen.

Schritt 4: Plugin-Erkennung

Die Plugin-Erkennung verwendet zwei parallele Ansätze. Erstens extrahieren wir jeden Dateipfad, der zu wp-content/plugins/PLUGIN_NAME/ passt. Zweitens führen wir Dutzende signaturbasierter Prüfungen durch: Wir suchen nach bestimmten HTML-Strukturen, CSS-Klassennamen, Inline-JavaScript-Variablen und HTTP-Antwort-Headern, die beliebte Plugins wie Elementor, Yoast SEO, WPForms, WooCommerce, Wordfence und weitere eindeutig identifizieren.

Das Design mit doppeltem Ansatz erkennt Plugins, die ihre Dateipfade verbergen (durch Caching oder das Bündeln von Ressourcen), aber dennoch unverwechselbare Signaturen hinterlassen. Für jedes erkannte Plugin schlagen wir es im WordPress.org-Plugin-Verzeichnis nach, um das Ergebnis mit dem offiziellen Plugin-Namen, der Beschreibung, dem Autor und den Screenshots anzureichern.

Schritt 5: Hosting- + DNS-Abfragen

Um den Hosting-Anbieter zu identifizieren, führen wir eine DNS-Abfrage für die Domain durch und untersuchen die IP-Adresse, die ASN und den Reverse-DNS. Wir gleichen das mit einer Datenbank bekannter IP-Bereiche von Hosting-Anbietern ab, um den Anbieter zu identifizieren. Die Genauigkeit ist hoch für die großen Anbieter (AWS, Cloudflare, Hostinger, SiteGround usw.) und niedriger für Nischenanbieter.

Was wir nicht können

Einige Fälle, in denen die Erkennung nicht funktioniert, so gut unser Code auch ist:

Cloudflare-Bot-Challenge. Websites mit strikter Cloudflare-Bot-Abwehr (der Bildschirm «Sicherheitsüberprüfung läuft...») blockieren unseren Abrufer genauso, wie sie jede automatisierte Anfrage blockieren würden. Es gibt keinen sauberen Weg, das zu umgehen.
Stark angepasste Themes. Wurde ein Theme so weit verändert, dass jeder Verweis auf den ursprünglichen Theme-Namen aus dem HTML entfernt wurde, gibt es für uns nichts zu erkennen.
Aggressives Caching mit umgeschriebenen Ressourcenpfaden. Plugins wie LiteSpeed Cache, WP Rocket und der Rocket Loader von Cloudflare schreiben die URLs der Ressourcen manchmal um, um die Quelle zu verbergen. Unsere signaturbasierte Erkennung erfasst die meisten davon, aber nicht alle.
Statisch exportierte Websites. Eine WordPress-Website, die in statisches HTML exportiert wurde, verliert die meisten Laufzeit-Signaturen, die die Erkennung erst möglich machen.

Was wir nicht tun

Man hat uns danach gefragt. Die Antworten lauten nein:

Wir speichern die von Ihnen abgesendeten URLs nicht
Wir protokollieren keine IP-Adressen zu Marketingzwecken
Wir teilen keine Erkennungsdaten mit Anbietern
Wir umgehen keine Authentifizierung, keine robots.txt und keine sonstigen Zugangskontrollen
Wir führen den Detektor aus Sicherheitsgründen nicht auf internen/privaten IPs aus (127.0.0.1, 10.x.x.x usw.)

Die vollständigen Datenschutzdetails finden Sie in unserer Datenschutzerklärung.

API-Zugang

Derzeit bieten wir keine öffentliche API an, aber ein begrenzter programmatischer Zugang ist auf Anfrage für Agenturen und Forschende verfügbar. Schreiben Sie an hello@revealtheme.com mit Ihrem Anwendungsfall und dem erwarteten Anfragevolumen.

Warum ist es nicht Open Source?

Die Erkennungsregeln sind der Kern des Produkts, und wir aktualisieren sie häufig, während sich Themes und Plugins weiterentwickeln. Würden wir ihren Code offenlegen, würde das unsere Aktualisierungsfrequenz verlangsamen. Davon abgesehen veröffentlichen wir ausführliche Beiträge zu Erkennungstechniken in unserem Blog: Suchen Sie nach «Erkennung», um sie zu finden.

Bereit zum Ausprobieren?

Verwenden Sie den Detektor, der zur Website passt, die Sie untersuchen möchten: