Grenzen der WordPress-Erkennung: Wann es nicht klappt

WordPress-Erkennung funktioniert in der überwältigenden Mehrheit der Fälle zuverlässig. Es gibt jedoch Installationen, bei denen die gängigen Methoden versagen. Das liegt nicht an Fehlern in der Analyse, sondern an aktiven Maßnahmen der Betreiber, die den technischen Fingerabdruck gezielt minimieren. Wer diese Grenzen kennt, kann Erkenntnisse besser einordnen und bei Bedarf alternative Wege gehen.

Die häufigsten Härtungsmaßnahmen

Erfahrene WordPress-Administratoren und Sicherheits-Plugins verbergen die auffälligsten Erkennungsmerkmale. Die Maßnahmen reichen von einfach bis aufwendig.

Generator-Meta-Tag entfernen

Das Generator-Meta-Tag im HTML-Kopfbereich nennt standardmäßig die WordPress-Version:

<meta name="generator" content="WordPress 6.5" />

Diesen Tag zu entfernen ist eine der ersten Empfehlungen in jedem WordPress-Sicherheitsratgeber und lässt sich mit wenigen Zeilen in der functions.php umsetzen. Die Maßnahme ist so verbreitet, dass das Fehlen des Tags kein zuverlässiges Gegenindiz für WordPress ist.

Login-URL umbenennen

Die Standard-Login-URL /wp-login.php ist ein eindeutiges Erkennungsmerkmal, das aber problemlos umbenannt werden kann. Plugins wie WPS Hide Login leiten Anfragen an /wp-login.php auf eine 404-Seite um und aktivieren die echte Anmeldeseite nur unter einem konfigurierbaren Pfad.

Ist die Standard-Login-URL gesperrt, fehlt dieses Erkennungssignal vollständig.

REST-API einschränken

Die REST-API unter /wp-json/ gibt bei aktivem WordPress eine strukturierte JSON-Antwort zurück und ist ein starkes Erkennungsmerkmal. Betreiber können den Zugriff auf die API einschränken:

• Vollständige Deaktivierung der öffentlich zugänglichen Endpunkte
• Authentifizierungspflicht für alle API-Anfragen
• Umleitung aller Anfragen an /wp-json/ auf eine Fehlerseite

Ohne API-Antwort fehlt dieses Signal.

Pfade und URLs verschleiern

Die Verzeichnisstruktur mit /wp-content/, /wp-includes/ und /wp-admin/ ist charakteristisch für WordPress. Mit Konfigurationsänderungen auf Webserver-Ebene lässt sich die öffentlich sichtbare Pfadstruktur umschreiben:

• wp-content kann in ein beliebiges Verzeichnis verschoben werden
• Mit Rewrite-Regeln in der Webserver-Konfiguration erscheinen Plugin- und Theme-Ressourcen unter anderen Pfaden
• Plugin-URLs können über Proxying verschleiert werden

Diese Maßnahmen sind technisch aufwendig und können Plugin-Kompatibilität beeinträchtigen. Sie sind deshalb selten, aber sie existieren.

HTTP-Header bereinigen

Standard-WordPress-Installationen setzen den Link-Header mit dem Verweis auf api.w.org. Dieser Header gilt als besonders verlässliches Signal, weil er von WordPress core automatisch erzeugt wird. Er lässt sich jedoch deaktivieren:

remove_action('template_redirect', 'rest_output_link_header', 11);

Nach dieser Änderung fehlt das stärkste HTTP-Header-Signal.

Fälle, in denen auch automatische Tools versagen

Automatische Analyse-Tools wie der Analyzer prüfen viele Signale gleichzeitig. Dennoch gibt es Szenarien, in denen keines der Signale auslösbar ist:

• Stark gehärtete Installationen mit deaktivierter REST-API, entferntem Generator-Tag und umbenannten Pfaden
• Reverse-Proxy-Setups, bei denen WordPress hinter einem vorgeschalteten System läuft, das alle Antworten filtert
• Headless-WordPress-Konfigurationen, bei denen WordPress nur als Backend-API dient und das Frontend komplett auf einer anderen Technologie basiert
• Websites, bei denen Cloudflare oder ein ähnliches CDN alle Anfragen zwischenspeichert und die Ursprungsserver-Signale vollständig überlagert

Was ein negatives Ergebnis bedeutet

Findet der Analyzer keine WordPress-Signale, sind zwei Interpretationen möglich:

1. Die Site nutzt tatsächlich kein WordPress
2. Die Site nutzt WordPress, hat aber alle erkennbaren Merkmale aktiv entfernt

Diese Unterscheidung ist von außen nicht immer trennscharf möglich. Ein negatives Ergebnis ist kein Beweis für das Fehlen von WordPress, sondern der Befund, dass die Analyse keine ausreichenden Hinweise gefunden hat.

Alternative Ansätze bei unklaren Ergebnissen

Wenn die direkten Methoden versagen, gibt es ergänzende Wege:

• Web-Archive (archive.org) zeigen oft ältere Versionen der Site, bevor Härtungsmaßnahmen greifen
• DNS-Lookups können CDN-Anbieter und damit indirekte Hinweise auf den Stack liefern
• Job-Ausschreibungen des Unternehmens nennen häufig die genutzten Technologien
• Pressemitteilungen zu Website-Relaunches geben manchmal die Plattform preis
• Code-Repositories auf GitHub oder GitLab sind manchmal öffentlich zugänglich

Diese Methoden erfordern mehr Aufwand und sind weniger systematisch, liefern aber in hartnäckigen Fällen nützliche Hinweise.