Eine der häufigsten Fragen, die wir bekommen, ist „Plugin X ist installiert, aber im Report wird es nicht aufgelistet.“ Das ist fast immer erwartetes Verhalten und kein Fehler. InspectWP führt einen einzelnen anonymen Besuch deiner Seite durch, wie jeder andere Besucher auch, und arbeitet ausschließlich mit dem, was öffentlich sichtbar ist. Dieser Artikel erklärt, was das in der Praxis bedeutet.
1. So funktioniert die Erkennung im Prinzip
InspectWP lädt die angegebene URL genau einmal mit einem echten Headless-Browser. Wir schauen uns dann an:
- Das gerenderte HTML und Inline-Skripte.
- Alle CSS- und JavaScript-Dateien, die die Seite lädt.
- Bild- und Font-URLs, insbesondere deren Pfade.
- HTTP-Antwort-Header und Cookies.
- Meta-Tags und Strukturdaten.
Aus diesen Signalen leiten wir ab, welche Plugins oder Themes im Einsatz sind. Wir loggen uns nicht in deine Seite ein, greifen nicht auf wp-admin zu und lesen dein wp-content-Verzeichnis nicht direkt aus. Wir sehen nur das, was jeder anonyme Besucher sehen würde.
2. Warum ein Plugin unsichtbar bleiben kann
Es gibt mehrere legitime Gründe, warum ein Plugin nicht auftaucht:
- Es ist ein reines Backend-Plugin. Viele Plugins (Admin-Tools, Backup-Plugins, Staging-Werkzeuge, interne SEO-Checker, Rollenmanager) geben gar nichts ans Frontend aus. Es gibt nichts zu erkennen.
- Es lädt nur auf bestimmten Seiten. Ein Buchungs-Plugin lädt seine Assets vielleicht nur auf der Buchungsseite. Wenn du deine Startseite crawlst, taucht es dort nicht auf. Crawle stattdessen die Seite, auf der das Plugin tatsächlich eingesetzt wird.
- Es lädt nur für eingeloggte Nutzer. Ein Mitgliederbereich-Plugin lädt für anonyme Besucher unter Umständen gar nichts. Gleicher Effekt wie oben.
- Aggressive Optimierung versteckt es. Caching- und Optimierungs-Plugins können Assets so weit kombinieren, minifizieren oder umbenennen, dass der ursprüngliche Plugin-Name nicht mehr erkennbar ist. Siehe Abschnitt 4.
- Es ist ein sehr neues oder sehr nischiges Plugin. Erkennung funktioniert am besten bei Plugins mit stabilem, wiedererkennbarem Footprint. Brandneue Releases oder selbstgebaute Plugins sind möglicherweise noch nicht in unseren Erkennungsregeln hinterlegt.
- Das Plugin ist deaktiviert. Ein deaktiviertes Plugin lädt im Frontend nichts. Lohnt sich, in Plugins → Installierte Plugins nachzusehen.
3. Warum ein Theme falsch identifiziert werden kann
Theme-Erkennung ist normalerweise ziemlich zuverlässig, weil Themes typischerweise klare Spuren in den Asset-Pfaden hinterlassen (/wp-content/themes/dein-theme/...). Trotzdem kann es schiefgehen:
- Child-Themes: Wenn du ein Child-Theme verwendest, siehst du eventuell beide aufgelistet, Parent und Child. Das ist korrekt: WordPress lädt beide.
- Umbenannte Themes: Manche Agenturen benennen einen Parent-Theme-Ordner aus Branding-Gründen um. Wenn der neue Ordnername nicht in unseren Erkennungsregeln steht, erscheint das Theme als „unbekannt“ oder unter dem umbenannten Slug.
- Page-Builder mit eigenem Theme: Manche Page-Builder ersetzen das Theme effektiv. Das erkannte Theme ist dann das Basis-Theme des Builders, nicht das, was du erwarten würdest.
- Multisite mit Theme-Overrides: In einer Multisite kann das aktive Theme pro Subsite unterschiedlich sein. Stelle sicher, dass du die richtige URL gecrawlt hast.
4. Die Asset-Optimierungs-Falle
Das ist mit Abstand der häufigste Grund für fehlende Plugins auf ansonsten normalen Seiten. Plugins wie WP Rocket, LiteSpeed Cache, Autoptimize, W3 Total Cache, Perfmatters oder eingebaute CDN-Optimierer können all das machen:
- Viele CSS-Dateien zu einer großen Datei mit generischem Namen wie
combined-abc123.csskombinieren. - Viele JavaScript-Dateien analog zusammenfassen.
- Dateiinhalte minifizieren und verschleiern.
- Asset-Pfade auf ein CDN umschreiben und dabei das
/wp-content/plugins/...-Präfix verlieren. - Critical CSS inline einbetten, sodass das ursprüngliche Stylesheet nicht mehr angefordert wird.
Wenn das alles gleichzeitig passiert, verschwinden die Signaturen einzelner Plugins. Das Plugin läuft auf deiner Seite weiterhin einwandfrei, wir können es nur von außen nicht mehr erkennen.
5. CDN, Reverse-Proxy und Edge-Caches
Wenn deine Seite hinter Cloudflare, BunnyCDN, KeyCDN oder einem Edge-Cache deines Hosters läuft, kann die Antwort, die wir sehen, schon stark transformiert sein. Manche CDN-Funktionen (Rocket Loader, automatische Minifizierung, Mirage, Polish) verändern HTML und Assets zusätzlich. Die Plugins sind weiterhin da, der öffentliche Fingerprint hat sich nur verändert.
6. Server-seitiges Rendering und JavaScript-Apps
Seiten, die mit Headless-WordPress gebaut sind (ein JavaScript-Frontend, das per REST oder GraphQL mit WordPress spricht), zeigen meistens fast keine klassischen WordPress-Signale. Das Frontend ist im Grunde eine eigene App. In solchen Fällen ist die Erkennung von WordPress selbst, geschweige denn einzelner Plugins, von außen nur eingeschränkt oder gar nicht möglich.
7. Was tun, wenn etwas fehlt
- Crawle die Seite, auf der das Plugin tatsächlich verwendet wird, nicht nur die Startseite.
- Crawle als ausgeloggter Besucher in einem privaten Browser-Tab, um dieselbe Sicht wie InspectWP zu sehen.
- Schalte die Datei-Kombination in deinem Caching-Plugin kurzzeitig aus und crawle erneut.
- Prüfe per „Quelltext anzeigen“, ob das Plugin tatsächlich etwas im Frontend ausgibt.
- Wenn du sicher bist, dass das Plugin Frontend-Output erzeugt und trotzdem fehlt, schreibe uns an hello@inspectwp.com mit der Report-URL und dem Plugin-Namen. Wir bauen unsere Erkennungsregeln laufend aus.