WordPress-Sicherheit und Performance, kompletter Leitfaden für Administratoren 2025

Eine professionelle WordPress-Seite zu betreiben ist mehr als Texte schreiben. Es ist kontinuierliche Arbeit an drei Säulen: Sicherheit, Sichtbarkeit (Analytik/SEO) und Performance. Dieser Beitrag erweitert eine Schulungspräsentation und prüft jede Empfehlung gegen die offizielle Dokumentation: das WordPress Advanced Administration Handbook, die Sicherheitsseite von WordPress.org, die Serveranforderungen, OWASP und die Dokumentation von Google. Jeder Abschnitt enthält Schritte, die Sie heute umsetzen können.

#WordPress absichern ohne Security-Plugin

Viele denken, teure “Security Pro” Plugins seien nötig, um WordPress abzusichern. Das ist ein Mythos. Die stärksten Schutzmaßnahmen arbeiten auf Server-Ebene, bevor eine Anfrage überhaupt PHP ausführt. Ein Schichtenmodell, das bei der Infrastruktur beginnt und zur Anwendung hin aufbaut, ist verlässlicher als der alleinige Einsatz von Plugins.

#Updates, ungenutzte Plugins und Nulled-Themes

Updates: Laut der Sicherheitsseite von WordPress.org wird offiziell nur die jeweils neueste WordPress-Version unterstützt; das Sicherheitsteam (laut derselben Seite mehr als 50 Fachleute) portiert Fixes nur aus Kulanz auf ältere Versionen zurück. Der Hardening-Leitfaden ergänzt zwei Fakten: Automatische Updates gibt es seit WordPress 3.7, und Details zu behobenen Sicherheitslücken werden meist veröffentlicht. Eine alte Version wird also mit jeder Woche ohne Update leichter angreifbar.

PHP: Die offiziellen Anforderungen empfehlen PHP 8.3 oder höher, MySQL 8.0 oder höher (alternativ MariaDB 10.11 oder höher) und HTTPS-Unterstützung. WordPress läuft noch auf PHP 7.4 und MySQL 5.5.5, beide Versionen haben aber das Ende ihres Lebenszyklus erreicht, und die Seite warnt selbst, dass sie die Website Sicherheitslücken aussetzen können. Läuft Ihr Server noch mit PHP 7.x, ist das Update die erste Aufgabe.

Themes und Plugins: Löschen Sie (nicht nur deaktivieren) alles, was Sie nicht nutzen. Jede Datei auf dem Server ist ein möglicher Angriffsvektor. Deaktivierte Plugins lassen sich weiterhin ausführen, wenn ein Angreifer ihre Dateien direkt aufruft, deshalb ist nur das vollständige Entfernen sicher.

Quelle: Laden Sie niemals “Premium gratis” Plugins von Torrents (Nulled). Eine Nulled-Kopie ist Code, den ein unbekannter Dritter verändert hat, den Sie nicht prüfen können und der keine Updates erhält. Der offizielle Leitfaden verlangt, WordPress nur von WordPress.org herunterzuladen; für Plugins und Themes ist das Gegenstück das offizielle Verzeichnis oder die Website des Autors.

#Welche wp-config.php-Einstellungen die Sicherheit erhöhen

Fügen Sie diese Zeilen in Ihre Konfigurationsdatei ein, um typische Angriffe zu blockieren:

// Dateibearbeitung aus Admin blockieren
define( 'DISALLOW_FILE_EDIT', true );

// SSL für Login und Panel erzwingen
define( 'FORCE_SSL_ADMIN', true );

// Datenbank-Präfix ändern (NUR bei Installation!)
$table_prefix = 'wp_a1b2_'; // Statt des Standards wp_

DISALLOW_FILE_EDIT entzieht allen Benutzern die Berechtigungen edit_themes, edit_plugins und edit_files. Der Hardening-Leitfaden nennt die Grenze klar: Das Hochladen schädlicher Dateien verhindert die Konstante nicht, sie schließt aber einen üblichen Weg nach dem Diebstahl eines Administratorkontos. Zum Präfix erklärt derselbe Leitfaden, dass viele veröffentlichte SQL-Injection-Angriffe wp_ voraussetzen; ein anderes Präfix blockiert also zumindest einen Teil davon. Vorbereitete Abfragen im Code ersetzt es nicht.

#XML-RPC deaktivieren und Revisionen begrenzen

// In wp-config.php: Revisionen begrenzen
define( 'WP_POST_REVISIONS', 5 );

// In einem mu-plugin, nicht in wp-config.php
add_filter( 'xmlrpc_enabled', '__return_false' );
remove_action( 'wp_head', 'wp_generator' );

Zwei Korrekturen zu Schnipseln, die im Netz kursieren. Erstens gibt es in WordPress keine Konstante XMLRPC_ENABLED; es gibt den Filter xmlrpc_enabled (seit Version 3.5), und der deaktiviert nur Methoden, die eine Authentifizierung erfordern. Pingbacks antworten weiter. Wenn Sie XML-RPC nicht nutzen, sperren Sie xmlrpc.php auf dem Server, wie die Regel unten zeigt. Zweitens funktioniert remove_action() nicht in der wp-config.php, weil die WordPress-Funktionen dort noch nicht geladen sind; der Aufruf gehört in ein Plugin oder nach wp-content/mu-plugins/.

#Sensible Dateien per .htaccess sperren

Die .htaccess (auf Apache/LiteSpeed) ist Ihr erster Wächter. Legen Sie Regeln an, die den Zugriff auf sensible Dateien sperren, bevor irgendein PHP-Code läuft.

Zugriff auf sensible Dateien sperren (Syntax von Apache 2.4, wie im offiziellen Leitfaden):

<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php)">
Require all denied
</FilesMatch>

Die Direktiven Order deny,allow und Deny from all stammen aus Apache 2.2; unter Apache 2.4 funktionieren sie nur über das Kompatibilitätsmodul mod_access_compat. Sperren Sie xmlrpc.php nur, wenn kein Dienst darauf angewiesen ist: Die WordPress-App oder Jetpack können es brauchen.

wp-login.php per IP beschränken, wenn Sie von festen Adressen aus arbeiten. Das ist das Beispiel aus dem offiziellen Leitfaden gegen Brute-Force-Angriffe, mit Dokumentationsadressen, die Sie durch Ihre eigenen ersetzen:

<Files "wp-login.php">
Require ip 203.0.113.15 203.0.113.16
</Files>

#Welche Dateirechte WordPress braucht

Der Hardening-Leitfaden nennt konkrete Werte: Verzeichnisse auf 755, Dateien auf 644, so setzen es auch die automatischen Updates. Das Stammverzeichnis, wp-admin/, wp-includes/ und wp-content/plugins/ sollten nur für Ihr Benutzerkonto beschreibbar sein, wp-content/ zusätzlich für den Webserver. Für die wp-config.php empfiehlt er 440 oder 400, damit nur der Eigentümer und der Webserver sie lesen können. Er erwähnt auch die Möglichkeit, die Datei ein Verzeichnis oberhalb der Installation abzulegen, mit dem Hinweis, dass manche Fachleute den Nutzen für gering halten.

find /pfad/zu/wordpress/ -type d -exec chmod 755 {} \;
find /pfad/zu/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 /pfad/zu/wordpress/wp-config.php

Für die Datenbank gilt dasselbe Prinzip: Der normale Betrieb braucht nur SELECT, INSERT, UPDATE und DELETE. Der Leitfaden rät aber davon ab, ALTER oder DROP zu entziehen, weil Updates und manche Plugins das Schema ändern. Ein eigener Datenbankbenutzer pro Website kostet dagegen nichts.

#HTTP-Sicherheitsheader in der .htaccess

Setzen Sie Header, die vor verbreiteten Angriffen wie Clickjacking und MIME-Sniffing schützen. Die Werte folgen dem OWASP HTTP Headers Cheat Sheet:

# Sicherheitsheader
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header set X-XSS-Protection "0"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header unset X-Powered-By

Viele ältere Anleitungen empfehlen X-XSS-Protection: 1; mode=block. OWASP sagt das Gegenteil: den Header nicht senden oder auf 0 setzen, weil der damit aktivierte Browserfilter auf ansonsten sicheren Seiten XSS-Probleme erzeugen konnte. Echter Schutz vor XSS ist eine Content Security Policy, die Inline-JavaScript verbietet. OWASP bevorzugt DENY oder die CSP-Direktive frame-ancestors gegenüber X-Frame-Options; SAMEORIGIN ist bei WordPress der übliche Kompromiss, weil der Customizer die Website in einem iframe derselben Domain lädt. Mit HSTS vorsichtig umgehen: Ein abgelaufenes Zertifikat sperrt Besucher für die gesamte max-age aus, also erst aktivieren, wenn HTTPS auf allen Subdomains funktioniert.

#Zwei-Faktor-Authentifizierung (2FA) in WordPress

Aktivieren Sie 2FA für alle Administratorkonten. Der offizielle Leitfaden gegen Brute-Force-Angriffe sagt es direkt: Der WordPress-Kern liefert keine 2FA mit, Sie brauchen also ein vertrauenswürdiges Plugin oder einen Identitätsanbieter. Plugins wie Two Factor (gepflegt von WordPress-Mitwirkenden), WP 2FA oder Google Authenticator bieten das an. Derselbe Leitfaden nennt drei weitere Maßnahmen: keinen Benutzernamen admin, lange und einzigartige Passwörter mit Passwortmanager, und eine Begrenzung der Anfragen an wp-login.php und xmlrpc.php am Rand des Netzes (WAF oder CDN) oder im Webserver, weil ein Sicherheits-Plugin bei einem großen Angriff weiter PHP-Ressourcen verbraucht.

#WordPress-Backups richtig anlegen

Der offizielle Backup-Leitfaden teilt die Aufgabe in zwei Teile, die zusammengehören: die Datenbank (Beiträge, Kommentare, Einstellungen) und die Dateien (Kern, Plugins, Themes, Uploads). Eine reine Datenbankkopie stellt die Website nicht wieder her. Empfohlener Rhythmus: wöchentlich für kleine Websites, täglich für Websites mit viel Aktivität und immer vor einem Update. Bewahren Sie 3 bis 5 aktuelle Backups an verschiedenen Orten und auf verschiedenen Medien auf. Bei der Wiederherstellung zuerst die Dateien zurückspielen, dann die Datenbank importieren; haben sich die Zugangsdaten geändert, die wp-config.php anpassen. Der Hardening-Leitfaden ergänzt, dass Backups verschlüsselt und mit unabhängig gespeicherten Hashes geprüft werden sollten, damit eine Manipulation auffällt.

#Welche OWASP Top 10 2025 Risiken WordPress betreffen

Die Sicherheitsseite von WordPress.org gibt an, dass das Sicherheitsteam den Kern gegen Bedrohungen wie die OWASP Top Ten härtet. Die Ausgabe 2025 taugt als Checkliste für Administratoren, weil mehrere Kategorien Entscheidungen im Dashboard oder auf dem Server betreffen, nicht den Code des Kerns:

Zu den Logs erklärt der Hardening-Leitfaden, dass Server-Logs IP, Zeitpunkt und Aktion zeigen und Versuche von XSS, Dateieinbindung, Verzeichnistraversierung und Brute-Force sichtbar machen. Er empfiehlt Werkzeuge wie OSSEC und das Herausfiltern von Rauschen, damit wichtige Alarme nicht untergehen.

#Google Search Console und GA4 für WordPress

Sie können nicht managen, was Sie nicht messen. Google Search Console (GSC) und Google Analytics 4 (GA4) sind Augen und Ohren Ihres Business.

#Was Sie wöchentlich in der Google Search Console prüfen

Der einzige Ort, wo Google mit Ihnen über Ihre Seite “spricht”. Für jeden WordPress-Administrator, dem Sichtbarkeit in der Suche wichtig ist, ist es das wichtigste Werkzeug.

1. Sitemap: Stellen Sie sicher, dass Sie die Sitemap eingereicht haben (meist domain.com/sitemap_index.xml, erzeugt vom SEO-Plugin). Prüfen Sie, dass alle wichtigen URLs enthalten sind und keine Verarbeitungsfehler auftreten.
2. Indexierungsfehler: Prüfen Sie wöchentlich die “Seiten”-Sektion. Suchen Sie nach 404 und 5xx Fehlern. Ein 404 auf einer URL mit Links oder Traffic ist ein verlorener Besuch; ein wiederholter 5xx deutet auf ein Serverproblem.
3. Core Web Vitals: GSC sagt Ihnen direkt, ob Ihre Seite schnell genug lädt (LCP), rechtzeitig auf Interaktionen reagiert (INP) und visuell stabil ist (CLS). Achten Sie auf Felddaten echter Nutzer, denn die zählt der Bericht.

#Welche Core Web Vitals Grenzwerte eine Seite erfüllen muss

Laut web.dev hat eine Seite gute Core Web Vitals, wenn sie alle drei Grenzwerte beim 75. Perzentil der Seitenaufrufe erfüllt, getrennt gemessen für Mobilgeräte und Desktop:

Das 75. Perzentil bedeutet, dass die meisten Besuche den Grenzwert erreichen müssen, nicht nur der Durchschnitt. Deshalb garantiert ein schneller Labortest aus dem eigenen Büro keinen grünen Bericht in der GSC.

#Schlüsselereignisse in GA4 einrichten

GA4 unterscheidet sich vom alten UA. Es fokussiert auf Events statt auf Seitenaufrufe, und das verändert, wie man den Erfolg einer Website misst.

• Messen Sie nicht nur “Besuche”. Konfigurieren Sie Schlüsselereignisse: Formularabsendung, Telefonklick, PDF-Download. Google hat den Begriff umbenannt: Was in GA4 früher Conversions hieß, heißt jetzt Schlüsselereignisse, und “Conversion” bezeichnet die Messung im Zusammenhang mit Google Ads.
• Denken Sie an die DSGVO. Consent Mode v2 übermittelt die Einwilligungsentscheidung des Besuchers an die Google-Tags. Laut Google-Dokumentation ergänzt Version 2 die Parameter ad_user_data und ad_personalization zu den bestehenden ad_storage und analytics_storage. Consent Mode ersetzt weder das Consent-Banner noch die Rechtsgrundlage, er sorgt nur dafür, dass die Tags die Wahl des Nutzers respektieren.
• Legen Sie eigene Events für Ihre Geschäftsziele an: Angebotsanfragen, Newsletter-Anmeldungen, WhatsApp-Klicks, Terminbuchungen.

#WordPress schneller machen mit Hosting und Caching

Eine schnelle Seite verbessert Nutzererlebnis und Core Web Vitals, die Google im oben beschriebenen GSC-Bericht misst.

#Welches Hosting eine schnelle WordPress-Seite braucht

Sie können keine Seite auf 5€/Jahr Hosting optimieren. Der offizielle Optimierungsleitfaden hält fest, dass der Wechsel auf einen Server mit SSD- oder NVMe-Laufwerken, mehr CPU und mehr Arbeitsspeicher viel ausmachen kann. Suchen Sie Hosting mit:

• NVMe-Platten für schnelle Datenbank-I/O.
• Redis/Memcached Support (Datenbank im RAM) für Object Caching.
• LiteSpeed (LSCache) oder Nginx Server für effiziente Verarbeitung der Anfragen.

Derselbe Leitfaden gibt zwei oft vergessene Hinweise: kein DNS und keinen Mailserver auf dem WordPress-Server betreiben. Für Kontaktformulare ein Formular-Plugin mit externem Versanddienst nutzen.

#Bilder in WordPress optimieren

Bilder sind meist die schwersten Ressourcen einer Seite, und das LCP-Element ist oft ein Bild.

• Lazy Loading: WordPress macht das seit Version 5.5 standardmäßig, Optimierungs-Plugins geben mehr Kontrolle über iframes und Videos. Das Hauptbild im sichtbaren Bereich nicht lazy laden, sonst verzögert sich der LCP.
• Formate: Nutzen Sie WebP oder AVIF. Laut Google ist verlustbehaftetes WebP 25 bis 34 % kleiner als ein vergleichbares JPEG bei gleicher SSIM-Qualität, verlustfreies WebP 26 % kleiner als PNG.
• Abmessungen: Laden Sie keine Fotos mit 4000px in einen Blog, dessen Textbreite 800px beträgt. Vor dem Hochladen verkleinern.

#Page Cache und Object Cache (Redis) in WordPress

Ihre Seite sollte nicht für jeden Besucher PHP generieren. Nutzen Sie Caching auf mehreren Ebenen:

• Page Cache: Speichert fertiges HTML auf der Festplatte für sofortige Antworten. Laut offiziellem Optimierungsleitfaden kann das Cachen von Seiten als statische Dateien weitgehend statische Seiten um ein Vielhundertfaches beschleunigen.
• Object Cache (Redis): Hält Ergebnisse von Datenbankabfragen im Arbeitsspeicher. Entscheidend für WooCommerce und große Seiten, wo sich dieselben Abfragen ständig wiederholen.
• OPcache: Hält kompilierten PHP-Code im Speicher; der offizielle Leitfaden führt ihn als Beschleuniger, der alle PHP-Dateien schneller macht, nicht nur WordPress.
• Browser-Cache: Setzen Sie Ablauf-Header, damit Browser statische Dateien lokal speichern.

#CDN und Edge Computing für WordPress

Für Websites mit internationalem Publikum spiegelt ein CDN wie Cloudflare Bilder und andere statische Dateien auf Server in der Nähe jedes Nutzers; der offizielle Leitfaden nennt das als Antwort auf die geografische Entfernung zwischen Server und Besucher. Edge Computing geht einen Schritt weiter und führt Serverlogik nahe beim Nutzer aus, um die Latenz zu senken. Ein CDN mit WAF ist auch der richtige Ort, um Anfragen an wp-login.php zu begrenzen.

#Welches Plugin WordPress langsam macht

Der offizielle Optimierungsleitfaden schlägt eine einfache Methode vor: Plugins gezielt deaktivieren und nach jeder Änderung die Serverleistung messen. Bremst eines davon stark, lesen Sie seine Dokumentation, fragen Sie im Support-Forum oder suchen Sie eine Alternative mit ähnlichen Funktionen. Die Entwicklerwerkzeuge von Firefox oder Chrome haben Performance-Panels, die für eine erste Messung reichen. Für die Datenbank empfiehlt derselbe Leitfaden InnoDB, die Standard-Engine von MySQL, und die Umstellung alter MyISAM-Tabellen.

#Laufendes Performance-Monitoring

Richten Sie Performance-Monitoring mit Werkzeugen wie DebugBear oder SpeedCurve ein. Sie erkennen Performance-Regressionen automatisch, sodass Sie handeln können, bevor Nutzer es merken.

#Wie oft sollte man WordPress warten

Eine WordPress-Seite zu pflegen ist ein Prozess, keine einmalige Aktion. Legen Sie einen festen Plan fest:

• Täglich: Backups prüfen (automatisch) bei Websites mit viel Aktivität und Sicherheitsalarme beobachten.
• Wöchentlich: Plugins aktualisieren, GSC prüfen, Fehlerlogs lesen und bei kleinen Websites das wöchentliche Backup anlegen.
• Monatlich: Geschwindigkeits-Audit, Benutzer-Überprüfung (hat jemand ohne Berechtigung Admin-Zugang?) und Datenbankbereinigung.
• Vierteljährlich: Vollständiges Sicherheitsaudit, Prüfung der installierten Plugins, Test-Wiederherstellung eines Backups und Aktualisierung des Notfallplans.

Sicherheit und Performance sind keine Projekte mit Enddatum, sondern laufende Prozesse.

Mehr über unsere WordPress-Sicherheitsaudits.