Redis als Objekt-Cache für WordPress einrichten und absichern

WordPress fragt bei jedem Seitenaufruf dieselben Optionen, Menüs, Benutzerdaten und Beitragslisten aus der Datenbank ab. Der eingebaute Objekt-Cache hält diese Ergebnisse nur für die Dauer eines einzigen Aufrufs im Arbeitsspeicher und vergisst sie danach. Ein persistenter Objekt-Cache mit Redis speichert sie über Aufrufe hinweg und entlastet so die Datenbank, vor allem im Adminbereich, bei WooCommerce-Shops und bei Seiten mit vielen angemeldeten Benutzern. Diese Anleitung zeigt, wie Sie Redis auf einem eigenen Server bereitstellen, das Plugin „Redis Object Cache“ einrichten, die Verbindung in der wp-config.php sauber konfigurieren und einen Ausfall von Redis so abfangen, dass Ihre Website nicht stillsteht.

Voraussetzungen

• WordPress: Das Plugin verlangt laut wordpress.org mindestens WordPress 4.6 und ist bis WordPress 7.1.2 getestet. Diese Anleitung wurde mit WordPress 7.1.2 und Plugin-Version 3.0.0 geprüft.
• PHP: mindestens 7.2 laut Plugin-Seite, im Test PHP 8.4. Die PHP-Erweiterung PhpRedis ist optional, ohne sie nutzt das Plugin die mitgelieferte Bibliothek Predis.
• Redis-Server: entweder beim Hoster als Zusatzoption gebucht (dann liefert der Hoster Host, Port und Passwort) oder selbst installiert auf einem eigenen Server bzw. VPS mit SSH-Zugang und Root-Rechten. Für eine typische Unternehmenswebsite genügen 64 bis 256 MB Arbeitsspeicher für Redis.
• Zugriff: WordPress-Benutzer mit der Rolle Administrator sowie Schreibzugriff auf wp-config.php per SFTP oder SSH. WP-CLI ist hilfreich, aber nicht zwingend.
• Backup: eine aktuelle Sicherung von Dateien und Datenbank, mindestens eine Kopie der wp-config.php. Wie das geht, beschreibt die Anleitung Backup-Strategie für WordPress.

Auf reinem Shared Hosting ohne Redis-Angebot können Sie diese Anleitung nicht umsetzen. Prüfen Sie im Kundenmenü oder beim Support, ob Redis verfügbar ist, bevor Sie das Plugin installieren.

Schritt 1: Prüfen, ob sich ein Objekt-Cache lohnt

Ein persistenter Objekt-Cache beschleunigt Datenbankabfragen, nicht die Auslieferung fertiger HTML-Seiten. Das unterscheidet ihn von einem Seiten-Cache. Er bringt am meisten, wenn viele Abfragen nicht aus einem Seiten-Cache bedient werden können: im Backend, im Warenkorb, in Mitgliederbereichen, bei Suchergebnissen. Eine kleine Visitenkarten-Website mit gutem Seiten-Cache merkt oft wenig davon.

WordPress gibt selbst eine Empfehlung ab. Öffnen Sie Werkzeuge > Website-Zustand. Die Prüfung schlägt einen persistenten Objekt-Cache vor, wenn bestimmte Schwellen überschritten sind. Im Quelltext von WordPress 7.1 (class-wp-site-health.php) stehen diese Grenzwerte: mehr als 500 automatisch geladene Optionen oder mehr als 100.000 Byte davon, oder mindestens 1.000 Einträge in einer der Tabellen für Kommentare, Optionen, Beiträge, Terms oder Benutzer. Multisite-Installationen bekommen die Empfehlung immer.

Verifizieren: Unter „Werkzeuge > Website-Zustand“ erscheint entweder die Empfehlung, einen persistenten Objekt-Cache zu verwenden, oder die Prüfung ist bestanden. Notieren Sie sich zusätzlich die Ladezeit einer Backend-Seite wie „Beiträge“, um später vergleichen zu können.

Schritt 2: Redis installieren und absichern

Bucht Ihr Hoster Redis für Sie, überspringen Sie die Installation und notieren Host, Port, Passwort und gegebenenfalls die Datenbanknummer. Auf einem eigenen Debian- oder Ubuntu-Server installieren Sie Redis aus den Paketquellen:

sudo apt update
sudo apt install redis-server
redis-server --version

Im Test unter Debian 13 installierte das Paket Redis 8.0.2. Die Standardkonfiguration in /etc/redis/redis.conf bindet Redis an 127.0.0.1 -::1 und aktiviert protected-mode. Lassen Sie das so, wenn WordPress auf demselben Server läuft: Redis darf nicht aus dem Internet erreichbar sein. Zwei Einstellungen ergänzen Sie in /etc/redis/redis.conf:

requirepass EIN-LANGES-ZUFALLSPASSWORT
maxmemory 256mb
maxmemory-policy allkeys-lru

Warum diese Werte: Ohne maxmemory wächst Redis unbegrenzt. Die Voreinstellung noeviction (im Test ausgelesen) verweigert Schreibbefehle, sobald ein Limit erreicht ist; die FAQ des Plugins nennt als Folge die Meldung „OOM command not allowed“. Mit allkeys-lru verdrängt Redis laut Redis-Dokumentation die am längsten nicht genutzten Schlüssel. Für einen reinen Cache ist das richtig, denn jeder verdrängte Eintrag wird bei Bedarf einfach neu aus der Datenbank geladen. Das Passwort schützt zusätzlich, falls andere Prozesse oder Benutzer auf dem Server Zugriff auf den Port haben.

sudo systemctl restart redis-server
redis-cli -a 'EIN-LANGES-ZUFALLSPASSWORT' --no-auth-warning ping
redis-cli -a 'EIN-LANGES-ZUFALLSPASSWORT' --no-auth-warning config get maxmemory-policy

Alternativ betreiben Sie Redis als Container; die Anleitung Redis mit Docker installieren beschreibt das. Wer eine Lizenz ohne Einschränkungen bevorzugt, findet in Valkey mit Docker einen kompatiblen Ersatz.

Verifizieren: ping antwortet mit PONG, config get maxmemory-policy zeigt allkeys-lru. Ein redis-cli ping ohne Passwort muss scheitern (im Test: NOAUTH Authentication required.).

Schritt 3: Verbindung in der wp-config.php festlegen

Legen Sie vor der Änderung eine Kopie der wp-config.php an. Ein Tippfehler in dieser Datei legt die ganze Website lahm. Tragen Sie die Konstanten oberhalb der Zeile /* That's all, stop editing! Happy publishing. */ ein. Die Installationsanleitung des Plugins betont das ausdrücklich: Weiter unten definierte Konstanten wirken nicht, die typische Folge ist die Meldung NOAUTH Authentication required.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'EIN-LANGES-ZUFALLSPASSWORT' );
define( 'WP_REDIS_DATABASE', 0 );        // 0 bis 15
define( 'WP_REDIS_PREFIX', 'firma-de:' ); // je Website eindeutig
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

Wichtig ist WP_REDIS_PREFIX: Laufen mehrere Websites oder eine Staging-Kopie gegen denselben Redis-Server, verhindert ein eigener Präfix, dass sich die Installationen gegenseitig Cache-Einträge überschreiben. Die ältere Konstante WP_CACHE_KEY_SALT ist laut Plugin-Dokumentation veraltet und durch WP_REDIS_PREFIX ersetzt. Mit WP-CLI setzen Sie dieselben Werte ohne Editor:

wp config set WP_REDIS_HOST 127.0.0.1
wp config set WP_REDIS_PASSWORD 'EIN-LANGES-ZUFALLSPASSWORT'
wp config set WP_REDIS_PREFIX firma-de:

Das Passwort steht damit im Klartext in der wp-config.php. Das ist bei Datenbankzugangsdaten nicht anders. Umso wichtiger sind korrekte Dateirechte, siehe wp-config.php härten.

Verifizieren: php -l wp-config.php meldet „No syntax errors detected“, die Website lädt weiterhin normal. Noch ist der Cache nicht aktiv.

Schritt 4: Plugin installieren und Objekt-Cache aktivieren

Installieren Sie unter Plugins > Neues Plugin hinzufügen das Plugin „Redis Object Cache“ von Till Krüss und aktivieren Sie es. Es erscheint danach unter Einstellungen > Redis. Auf dem Reiter „Überblick“ zeigt es den Status; mit der Schaltfläche „Objekt-Cache aktivieren“ kopiert das Plugin die Datei object-cache.php nach wp-content/. Diese sogenannte Drop-in-Datei lädt WordPress vor allen Plugins; erst sie macht den Cache wirksam. Das Aktivieren des Plugins allein ändert noch nichts.

Per WP-CLI sieht das so aus:

wp plugin install redis-cache --activate
wp redis enable
wp redis status

Im Labor meldete wp redis enable „Success: Object cache enabled.“, der Status danach auszugsweise:

Status: Connected
Client: Predis (v2.4.1)
Drop-in: Valid
Disabled: No
Ping: PONG
Errors: []
Redis Version: 8.0.2

Die Zeile „Client“ zeigt, welche Bibliothek spricht. Ist die PHP-Erweiterung PhpRedis installiert, nutzt das Plugin sie laut Dokumentation automatisch, sonst Predis. Beides funktioniert. Hat der Webserver keine Schreibrechte auf wp-content/, kann das Plugin die Drop-in-Datei nicht anlegen; dann kopieren Sie wp-content/plugins/redis-cache/includes/object-cache.php manuell nach wp-content/object-cache.php.

Direkt nach der Aktivierung empfiehlt die FAQ des Plugins, alte Transients aus der Datenbank zu entfernen, denn neue Transients landen künftig in Redis:

wp transient delete --all

Verifizieren: wp cache type gibt Redis aus, und unter „Werkzeuge > Website-Zustand“ steht bei den bestandenen Tests „Ein persistenter Objekt-Cache wird verwendet“.

Schritt 5: Wirkung kontrollieren

Rufen Sie einige Seiten im Frontend und im Backend auf und prüfen Sie danach Redis direkt:

redis-cli -a 'EIN-LANGES-ZUFALLSPASSWORT' --no-auth-warning info keyspace
redis-cli -a 'EIN-LANGES-ZUFALLSPASSWORT' --no-auth-warning --scan --pattern 'firma-de:*' | head

Die Schlüssel tragen Ihren Präfix, gefolgt vom Tabellenpräfix und der Cache-Gruppe, im Test etwa x2lab:wp:terms:last_changed oder x2lab:wp:site-options:1-notoptions. Die Kennzahlen keyspace_hits und keyspace_misses aus info stats zeigen, wie oft ein Eintrag gefunden wurde. Nach einigen Aufrufen sollten die Treffer deutlich überwiegen; im Labor standen nach wenigen Aufrufen 54 Treffer 14 Fehlversuchen gegenüber. Das Plugin sammelt zusätzlich eigene Messwerte im Reiter „Metriken“ unter „Einstellungen > Redis“.

Vergleichen Sie die Ladezeit der Backend-Seite aus Schritt 1. Wird WordPress mit aktivem Cache langsamer, ist laut Plugin-FAQ etwas defekt: Prüfen Sie, ob der Status „Connected“ lautet, und messen Sie mit redis-cli --latency-history, ob Redis zu langsam antwortet oder an seine Speicher- oder CPU-Grenze stößt.

Verifizieren: Die Anzahl der Schlüssel steigt nach Seitenaufrufen, die Trefferquote nimmt zu, und der Reiter „Diagnose“ zeigt keine Fehler.

Schritt 6: Ausfall von Redis einplanen

Mit aktivem Drop-in hängt Ihre Website von Redis ab. Im Test beendeten wir Redis bei laufender Website: WordPress antwortete sofort mit HTTP 500 und der Seite „Error establishing a Redis connection. To disable Redis, delete the object-cache.php file in the /wp-content/ directory.“ Legen Sie deshalb vorher fest, wie Sie reagieren:

• Notschalter: define( 'WP_REDIS_DISABLED', true ); in der wp-config.php umgeht den Cache, ohne die Drop-in-Datei zu löschen. wp redis status zeigte danach „Status: Disabled (via config constant)“. Alternativ löschen Sie wp-content/object-cache.php.
• Überwachung: Nehmen Sie den Redis-Dienst in Ihre Überwachung auf und aktivieren Sie den automatischen Neustart des Dienstes. Ein Uptime-Monitor auf die Startseite meldet den Fehler 500 ebenfalls.
• Kein Dauerzustand mit WP_REDIS_GRACEFUL: Die Konstante unterdrückt den Fehler; im Test lieferte die Seite ohne Redis wieder HTTP 200. Die Plugin-Dokumentation führt sie aber ausdrücklich als nicht unterstützt und warnt vor Datenfehlern. Setzen Sie sie höchstens bewusst und befristet.

Mit Redis kommt ein weiterer Dienst hinzu, der Updates, Überwachung und im Fehlerfall schnelles Eingreifen braucht. Plugin, Drop-in und Redis-Server müssen zueinander passen, sonst meldet der Reiter „Diagnose“ einen veralteten Drop-in. Wer die laufende Pflege der Website nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Einrichtung und Wartung der Firewall.

Verifizieren: Sie wissen, wo die wp-config.php liegt, haben den Notschalter einmal auf einer Testkopie ausprobiert und erhalten eine Meldung, wenn Redis nicht läuft.

Typische Fehler

Meldung	Ursache	Lösung
Error: Object cache could not be enabled. Redis server is unreachable: Connection refused [tcp://127.0.0.1:6379]	Redis läuft nicht oder lauscht auf anderem Host oder Port	systemctl status redis-server, WP_REDIS_HOST und WP_REDIS_PORT prüfen
`AUTH` failed: WRONGPASS invalid username-password pair or user is disabled.	Falsches Passwort in WP_REDIS_PASSWORD	Wert mit requirepass abgleichen
NOAUTH Authentication required	Passwort fehlt oder Konstante steht unterhalb von „stop editing“	Konstante weiter oben in die wp-config.php verschieben
„Error establishing a Redis connection“, HTTP 500	Redis ist bei aktivem Drop-in ausgefallen	Redis starten oder WP_REDIS_DISABLED setzen
OOM command not allowed	maxmemory erreicht, Richtlinie noeviction	maxmemory-policy allkeys-lru setzen
Veraltete Inhalte trotz Änderung	Ein Plugin arbeitet nicht sauber mit persistentem Cache	wp cache flush, Gruppe über WP_REDIS_IGNORED_GROUPS ausnehmen

Häufige Fragen

Ersetzt der Objekt-Cache einen Seiten-Cache?

Nein. Der Objekt-Cache speichert Ergebnisse einzelner Abfragen, ein Seiten-Cache speichert fertige HTML-Seiten. Beide ergänzen sich. Seiten lassen sich im Objekt-Cache auch nicht einzeln ausnehmen, denn er arbeitet nicht URL-bezogen.

Werden Transients in Redis gespeichert?

Ja. Die Transients-API nutzt bei aktivem Objekt-Cache Redis statt der Tabelle wp_options. WP-CLI weist beim Befehl wp transient delete --all darauf hin, dass er dann nur Datenbankeinträge löscht; alle Transients leeren Sie mit wp cache flush.

Gehen Daten verloren, wenn ich den Cache leere?

Nein, sofern Redis nur als Cache dient. Alle Inhalte liegen weiterhin in der Datenbank. Nach dem Leeren arbeitet die Website kurz langsamer, bis der Cache wieder gefüllt ist.

Können mehrere Websites einen Redis-Server teilen?

Ja, mit je eigenem WP_REDIS_PREFIX oder eigener WP_REDIS_DATABASE (0 bis 15). Beachten Sie, dass „Cache leeren“ ohne weitere Einstellungen die gesamte Redis-Datenbank leert. Getrennte Datenbanknummern verhindern, dass eine Website den Cache der anderen löscht.

Wie entferne ich den Objekt-Cache wieder?

Unter „Einstellungen > Redis“ auf „Objekt-Cache deaktivieren“ klicken oder wp redis disable ausführen. Das entfernt die Datei wp-content/object-cache.php. Danach das Plugin deaktivieren und die WP_REDIS_-Konstanten aus der wp-config.php löschen.

Testumfang

Wir haben die Anleitung in einer Testinstanz mit WordPress 7.1.2 durchgespielt, von der Installation per WP-CLI bis zum Speicherlimit mit allkeys-lru. Außerdem haben wir Redis absichtlich gestoppt und ein falsches Passwort gesetzt, um die Fehlermeldungen zu sehen. Nicht geprüft haben wir PhpRedis, Unix-Sockets und das Verhalten unter Last auf einer echten Website. Testen Sie die Einrichtung daher zuerst auf einer Kopie Ihrer Seite.

Fazit

Ein Redis-Objekt-Cache ist schnell eingerichtet: Redis mit Passwort und Speicherlimit, Konstanten an der richtigen Stelle der wp-config.php, Drop-in aktivieren, Status prüfen. Den größten Nutzen haben Shops, Mitgliederbereiche und Websites mit großem Backend. Der Preis ist ein zusätzlicher Dienst, dessen Ausfall die Website sofort mit einem Fehler 500 stoppt; halten Sie daher den Notschalter WP_REDIS_DISABLED bereit und überwachen Sie Redis. Wenn Sie Updates, Backups und Firewall lieber in feste Hände geben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Redis mit Docker installieren
• wp-config.php härten: Salts, Dateibearbeitung, Debug
• Staging-Umgebung für WordPress mit WP-CLI
• Redis Object Cache auf wordpress.org
• Installationsanleitung des Plugins und FAQ
• WP_Object_Cache im WordPress Developer Handbook
• Redis-Dokumentation zur Verdrängung von Schlüsseln