WordPress Security für Website-Verantwortliche: Was Sie ohne Admin-Zugang prüfen können

WordPress ist nicht „unsicher“, nur weil es WordPress ist. Das größere Risiko entsteht durch Sichtbarkeit, Verbreitung und Komplexität: sehr viele Installationen, sehr viele Plugins, sehr viele Themes, sehr unterschiedliche Wartungsprozesse.

Genau deshalb ist WordPress Security kein reines Entwickler- oder Hosting-Thema. Auch Website-Verantwortliche, Marketing-Teams und Agenturen sollten regelmäßig prüfen können, ob eine Website grundlegende Sicherheitsrisiken zeigt — selbst wenn sie keinen Admin-Zugang zur WordPress-Installation haben.

Dieser Artikel erklärt, was sich öffentlich oder remote prüfen lässt, wo die Grenzen liegen und wie sich aus einzelnen Sicherheitschecks ein wiederholbarer Prozess machen lässt.

Kurzfassung

• WordPress ist das dominierende CMS. Laut W3Techs wird WordPress am 2. Mai 2026 von 59,6 % aller Websites mit bekanntem CMS und von 42,2 % aller Websites genutzt.
• Die häufigsten operativen Risiken liegen nicht nur im WordPress-Core, sondern in Plugins, Themes, veralteten Komponenten, exponierten Endpunkten und fehlender Wartungsroutine.
• OWASP nennt „Vulnerable and Outdated Components“ als Top-10-Risiko. Besonders riskant ist, wenn Teams nicht wissen, welche Komponenten und Versionen im Einsatz sind.
• Ein Remote-Check ohne Admin-Zugang kann keine vollständige Sicherheitsprüfung ersetzen, aber er kann viele öffentlich sichtbare Risikosignale identifizieren.
• +Analytics Pro macht WordPress-Security-Prüfungen wiederholbar: automatische Erkennung, Abgleich mit der Wordfence Vulnerability Database, Konfigurationsprüfung, Executive Summary und teilbare Ergebnislinks.

Warum WordPress Security so oft unterschätzt wird

Viele Website-Betreiber behandeln WordPress wie ein Publishing-Tool: Inhalte einpflegen, Landingpages bauen, Formulare ergänzen, Plugins installieren. Aus Marketingsicht ist das verständlich. Aus Sicherheitssicht entsteht dadurch aber schnell ein Problem: Die Website wird zu einem produktiven Softwaresystem, ohne wie ein produktives Softwaresystem gemanagt zu werden.

Das Risiko liegt selten in einer einzelnen Entscheidung. Es entsteht kumulativ:

• ein Plugin bleibt installiert, obwohl es nicht mehr genutzt wird
• ein Theme wird nicht mehr aktiv gepflegt
• eine alte Plugin-Version enthält eine bekannte Schwachstelle
• XML-RPC ist erreichbar, obwohl es nicht benötigt wird
• wp-admin ist öffentlich erreichbar und nicht zusätzlich abgesichert
• Security Headers fehlen
• niemand prüft regelmäßig, ob neue Schwachstellen für installierte Komponenten bekannt geworden sind

WordPress.org selbst beschreibt Sicherheit als Risikoreduktion, nicht als absolut sicheren Zustand. Die offizielle Hardening-Dokumentation empfiehlt unter anderem aktuelle Versionen, vertrauenswürdige Plugin- und Theme-Quellen, Backups, Monitoring, Logging und die Begrenzung unnötiger Angriffsflächen.

Das eigentliche Problem: fehlendes Komponenten-Inventar

Viele Teams wissen ungefähr, dass ihre Website „auf WordPress läuft“. Sie wissen aber nicht zuverlässig:

• welche WordPress-Version aktiv ist
• welche Plugins installiert sind
• welche Plugin-Versionen aktiv oder öffentlich erkennbar sind
• welches Theme eingesetzt wird
• ob die Komponenten noch gepflegt werden
• ob bekannte CVEs oder Wordfence-Einträge existieren
• wann der letzte Security-Check durchgeführt wurde
• wer bei kritischen Findings zuständig ist

Genau dieses Problem beschreibt OWASP in der Kategorie „Vulnerable and Outdated Components“: Verwundbar ist man unter anderem dann, wenn man die Versionen eingesetzter Komponenten nicht kennt, wenn Software veraltet ist oder wenn nicht regelmäßig auf bekannte Schwachstellen geprüft wird.

Für WordPress ist das besonders relevant, weil das System sehr häufig durch Erweiterungen individualisiert wird. Plugins und Themes sind praktisch, aber jedes zusätzliche Modul vergrößert die Angriffsfläche.

Warum ein WordPress Security Check auch ohne Admin-Zugang sinnvoll ist

Ein nicht-authentifizierter Remote-Check sieht nicht alles. Er kann keine vollständige Code-Analyse, kein internes Patchmanagement und keinen Penetrationstest ersetzen.

Trotzdem ist er wertvoll, weil viele Risikosignale öffentlich oder indirekt erkennbar sind. Für Website-Verantwortliche ist das ein wichtiger Vorteil: Sie können eine erste Sicherheitsbewertung starten, ohne Zugangsdaten anzufordern, ohne ein Plugin zu installieren und ohne in den produktiven Betrieb einzugreifen.

Das ist besonders hilfreich für:

• Agenturen, die viele Kundenseiten betreuen
• Geschäftsführer, die eine Website von einem Dienstleister übernehmen
• Marketing-Teams, die technische Risiken sichtbar machen müssen
• Compliance- oder IT-nahe Stakeholder, die einen ersten Status brauchen
• Website-Betreiber, die vor einem Relaunch oder einer Migration prüfen wollen, wo sie stehen

Ein Remote-Check ist damit kein Ersatz für Security Engineering, sondern ein Einstieg in bessere Sichtbarkeit.

Was Sie ohne Admin-Zugang prüfen können

1. Ob eine Website WordPress nutzt

Viele WordPress-Installationen lassen sich über öffentlich sichtbare Signale erkennen, zum Beispiel über Generator-Meta-Tags, typische Pfade, REST-API-Endpunkte, Asset-Strukturen oder WordPress-spezifische Dateien.

Problem: Wenn niemand sicher weiß, welches System im Einsatz ist, kann auch niemand passende Wartungsprozesse definieren.

Risiko: Die Website wird wie ein statischer Webauftritt behandelt, obwohl sie ein CMS mit Plugins, Themes, Logins und Updatepflichten ist.

Prüfung: Remote-Erkennung über WordPress-typische technische Signale.

Maßnahme: Zuständigkeiten klären, Wartungsrhythmus definieren, Security-Check in den Betriebsprozess aufnehmen.

2. Sichtbare Core-, Plugin- und Theme-Versionen

Nicht jede Version ist öffentlich erkennbar. Viele Installationen verstecken Versionsinformationen oder liefern sie nur indirekt über Assets aus. Wenn Versionen aber sichtbar sind, können sie mit bekannten Vulnerability-Datenbanken abgeglichen werden.

Problem: Veraltete Komponenten sind ein klassisches Einfallstor.

Risiko: Eine bekannte Schwachstelle ist öffentlich dokumentiert, aber auf der Website noch nicht gepatcht.

Prüfung: Soweit erkennbar: Abgleich von WordPress-Core, Plugins und Themes mit bekannten Schwachstellenquellen.

Maßnahme: Kritische und hoch bewertete Findings zuerst beheben, anschließend ungenutzte Plugins und Themes entfernen.

3. Bekannte Plugin- und Theme-Schwachstellen

Wordfence veröffentlicht laufend neue Schwachstelleninformationen. In der Woche vom 20. bis 26. April 2026 wurden laut Wordfence 157 Vulnerabilities in 122 WordPress-Plugins und 27 Themes zur Datenbank hinzugefügt. Davon waren 42 zum Zeitpunkt des Reports ungepatcht; 6 wurden als kritisch und 47 als hoch eingestuft.

Diese Zahlen zeigen nicht, dass jede WordPress-Site akut kompromittiert ist. Sie zeigen aber, dass WordPress-Sicherheit ein laufender Prozess ist. Wer nur einmal jährlich prüft, verpasst potenziell viele neue Risiken.

Problem: Plugin- und Theme-Risiken ändern sich laufend.

Risiko: Eine Website war beim letzten Audit unauffällig, ist aber durch eine später veröffentlichte Schwachstelle inzwischen betroffen.

Prüfung: Regelmäßiger Abgleich sichtbarer Komponenten mit einer aktuellen WordPress-Vulnerability-Datenbank.

Maßnahme: Wiederkehrende Checks einrichten, Findings priorisieren und Verantwortliche benennen.

4. Exponierte WordPress-Endpunkte

Einige WordPress-Endpunkte sind funktional legitim, aber nicht für jede Website nötig. Dazu gehören insbesondere:

• /wp-admin/
• /wp-login.php
• /xmlrpc.php
• REST-API-Endpunkte
• Upload- und Theme-/Plugin-Pfade

Diese Endpunkte sind nicht automatisch gefährlich. Entscheidend ist, ob sie benötigt, abgesichert und überwacht werden.

Problem: Öffentliche Endpunkte können automatisierte Angriffe erleichtern.

Risiko: Brute-Force-Versuche, User Enumeration, Missbrauch alter XML-RPC-Funktionen oder unnötige Offenlegung technischer Informationen.

Prüfung: Erreichbarkeit und Verhalten typischer WordPress-Endpunkte prüfen.

Maßnahme: Nicht benötigte Funktionen deaktivieren oder einschränken, Login-Bereiche zusätzlich schützen, Rate Limiting und WAF-Regeln prüfen.

5. Sicherheitskonfiguration und Hardening-Signale

Ein Remote-Check kann bestimmte Konfigurationssignale erkennen oder validieren, zum Beispiel:

• ob HTTPS korrekt eingesetzt wird
• ob HSTS aktiv ist
• ob Security Headers fehlen
• ob Mixed Content ausgeliefert wird
• ob Server- oder Technologieinformationen unnötig offengelegt werden
• ob typische WordPress-Hardening-Punkte sichtbar problematisch sind

WordPress-Hardening ist kein einzelner Schalter. Es geht um Verteidigung in mehreren Schichten: Hosting, Updates, Zugriffsschutz, Backups, Monitoring, Konfiguration, Plugin-Hygiene und Wiederherstellungsfähigkeit.

Problem: Einzelmaßnahmen wie „Version verstecken“ erzeugen oft ein falsches Sicherheitsgefühl.

Risiko: Sichtbare Symptome werden kaschiert, während echte Schwachstellen bestehen bleiben.

Prüfung: Security Headers, HTTPS, exponierte Pfade und WordPress-spezifische Konfiguration gemeinsam prüfen.

Maßnahme: Hardening nach Risiko priorisieren: erst bekannte Schwachstellen und offene Angriffsflächen, dann zusätzliche Schutzmaßnahmen.

Was ein Remote-Check nicht leisten kann

Ein seriöser WordPress Security Check sollte seine Grenzen klar benennen. Ohne Admin-Zugang kann ein Tool in der Regel nicht zuverlässig sehen:

• alle installierten Plugins
• alle deaktivierten, aber noch vorhandenen Komponenten
• private Theme-Anpassungen
• Serverkonfiguration im Detail
• Dateirechte und wp-config.php-Konfiguration vollständig
• Benutzerrollen und schwache Passwörter
• kompromittierte Admin-Konten
• Backups und Restore-Fähigkeit
• individuelle Code-Schwachstellen in Custom Plugins

Das bedeutet nicht, dass ein Remote-Check nutzlos ist. Es bedeutet nur, dass er als Frühwarnsystem, Triage-Werkzeug und wiederholbarer Baseline-Check verstanden werden sollte.

Eine praktische Checkliste für Website-Verantwortliche

Sofort prüfen

• Läuft die Website auf WordPress?
• Ist die WordPress-Version öffentlich sichtbar?
• Sind Plugin- oder Theme-Versionen öffentlich erkennbar?
• Gibt es bekannte Schwachstellen für sichtbare Komponenten?
• Ist /xmlrpc.php erreichbar?
• Ist /wp-admin/ öffentlich erreichbar?
• Funktioniert HTTPS sauber?
• Sind HSTS und zentrale Security Headers gesetzt?
• Gibt es Mixed Content?
• Gibt es offensichtliche Server- oder Technologie-Leaks?

Monatlich prüfen

• Gibt es neue Schwachstellen für bekannte Plugins oder Themes?
• Sind ungenutzte Plugins und Themes entfernt?
• Wurden Updates getestet und eingespielt?
• Sind Backups aktuell und wiederherstellbar?
• Gibt es neue kritische Findings im Security-Check?
• Sind Verantwortlichkeiten dokumentiert?

Vor Relaunch, Kampagnen oder größeren Releases prüfen

• Wurden neue Plugins hinzugefügt?
• Hat sich das Theme geändert?
• Sind neue Formulare, Logins oder Upload-Funktionen live gegangen?
• Wurden Security Headers durch Deployments verändert?
• Sind Tracking-, Consent- oder Tag-Manager-Skripte neu eingebunden?
• Gibt es neue öffentlich erreichbare Endpunkte?

Wie +Analytics Pro hier hilft

Der WordPress Security Checker von +Analytics Pro ist für genau diese Situation gebaut: Website-Verantwortliche sollen WordPress-Risiken prüfen können, ohne zuerst ein Plugin zu installieren oder Admin-Zugang zu beschaffen.

Der Checker bietet:

• automatische WordPress-Erkennung über öffentlich sichtbare technische Signale
• Abgleich von WordPress-Core, Plugins und Themes mit der Wordfence Vulnerability Database
• Prüfung relevanter Sicherheitskonfigurationen, darunter wp-admin-Erreichbarkeit und XML-RPC-Exposition
• AI-powered Executive Summaries für nicht-technische Stakeholder
• Developer Assistance für technische Maßnahmen
• gespeicherte Ergebnisse mit dedizierten Permalinks zum Teilen mit Admins, Agenturen oder Security-Teams

Der Mehrwert liegt nicht nur im einzelnen Scan. Der eigentliche Vorteil entsteht, wenn solche Prüfungen Teil eines kontinuierlichen Website-Monitorings werden: wiederkehrende Checks, priorisierte Findings, teilbare Nachweise und klare nächste Schritte.

Warum WordPress-Sicherheit auch für Vertrauen und Auffindbarkeit relevant ist

Security ist zunächst ein Risikothema. Für SEO und AI Visibility hat es aber indirekte Relevanz:

• Kompromittierte Websites können Malware, Spam-Seiten oder Weiterleitungen ausliefern.
• Sicherheitswarnungen im Browser zerstören Vertrauen.
• Schadcode kann Performance, Indexierbarkeit und User Experience beeinträchtigen.
• Unsichere oder instabile Websites sind schlechte Quellen für Suchmaschinen und KI-Systeme.
• Ein sauber dokumentierter Audit-Prozess schafft Vertrauen bei Kunden, Partnern und Stakeholdern.

Für LLM-Sichtbarkeit ist außerdem wichtig, dass Inhalte klar, überprüfbar und vertrauenswürdig wirken. Ein Unternehmen, das Website-Qualität, Sicherheit, Datenschutz, Barrierefreiheit und Nachhaltigkeit nachvollziehbar dokumentiert, liefert bessere Signale als ein Unternehmen, das nur Marketingclaims veröffentlicht.

Fazit

WordPress Security beginnt nicht erst beim Incident. Sie beginnt bei Sichtbarkeit: Welche Komponenten sind im Einsatz? Welche davon sind öffentlich erkennbar? Welche haben bekannte Schwachstellen? Welche Endpunkte sind erreichbar? Welche Konfigurationen erhöhen unnötig die Angriffsfläche?

Ein einzelner Check ist besser als Blindflug. Ein wiederkehrender Check ist besser als ein einzelner Audit. Und ein verständlicher, teilbarer Report ist besser als ein technisches Finding, das niemand priorisiert.

Genau hier setzt +Analytics Pro an: WordPress Security wird nicht als einmaliger Expertentest verstanden, sondern als wiederholbarer, verständlicher und operationalisierbarer Bestandteil von Website-Qualität.