Jeder Seitenaufruf einer WordPress-Website startet PHP, lädt Plugins und Theme und stellt mehrere Datenbankabfragen. Bei wenigen Besuchern fällt das kaum auf, bei Lastspitzen durch einen Newsletter, eine Anzeige oder Bots wird der Server zum Engpass. Ein Page-Cache speichert die fertig erzeugte HTML-Seite und liefert sie beim nächsten Aufruf direkt aus, ohne WordPress erneut zu durchlaufen. Diese Anleitung zeigt am Beispiel des Plugins WP Super Cache, wie Sie das Page-Caching einrichten, prüfen, ob es wirklich greift, Seiten gezielt ausnehmen und typische Cache-Probleme beheben. Alle Schritte wurden im Labor mit WordPress 7.1.2 und WP Super Cache 3.1.3 nachvollzogen.

Voraussetzungen

WordPress: WP Super Cache 3.1.3 verlangt laut Plugin-Seite mindestens WordPress 6.8 und ist bis WordPress 7.1 getestet. Im Labor lief WordPress 7.1.2 auf Apache 2.4.
PHP: mindestens PHP 7.4 laut Plugin-Seite, im Labor PHP 8.4.
Permalinks: eine sprechende Permalink-Struktur wie „Beitragsname“ unter Einstellungen > Permalinks. Die Plugin-Beschreibung setzt benutzerdefinierte Permalinks für den Supercache voraus.
Zugriff: ein Konto mit der Rolle Administrator. Für Kontrolle und Fehlerbehebung zusätzlich SFTP- oder SSH-Zugang, weil das Plugin in wp-config.php und wp-content schreibt.
Kein zweites Cache-Plugin: Zwei Page-Cache-Plugins nutzen dieselbe Datei wp-content/advanced-cache.php und stören sich gegenseitig. Deaktivieren Sie vorhandene Cache-Plugins zuerst.
Backup: eine aktuelle Sicherung von Dateien und Datenbank, mindestens von wp-config.php und .htaccess. Wie Sie das vor einer Änderung schnell erledigen, zeigt WordPress vor Änderungen sichern.

Schritt 1: Verstehen, was der Page-Cache tut und was nicht

Ein Page-Cache speichert die komplette HTML-Ausgabe einer Seite als Datei. Der nächste Besucher derselben Adresse bekommt diese Datei, WordPress selbst läuft dabei nicht oder nur minimal. Das Entwickler-Handbuch von WordPress nennt Caching den schnellsten Weg zu mehr Leistung, warnt aber, dass viel dynamischer Inhalt die Einrichtung erschwert.

Daraus folgt:

Profitieren werden vor allem abgemeldete Besucher. Angemeldete Benutzer sehen die Werkzeugleiste und persönliche Inhalte, sie bekommen in der Standardeinstellung keine Seite aus dem Cache.
Alles, was pro Besucher anders sein muss, darf nicht im Cache landen: Warenkorb, Kundenkonto, Formulare mit Sicherheitstoken, personalisierte Hinweise.
Ein Page-Cache ersetzt weder den Object Cache noch das Browser-Caching für Bilder, CSS und JavaScript. Er setzt an einer anderen Stelle an.

Im Labor brauchte die Startseite beim ersten Aufruf 0,245 Sekunden zum Erzeugen, der zweite Aufruf kam nach etwa 0,03 Sekunden aus dem Cache. Die absoluten Werte hängen von Server und Theme ab.

Verifizieren: Notieren Sie, welche Seiten Ihrer Website personalisiert sind (Shop, Mitgliederbereich, Formulare). Diese Liste brauchen Sie in Schritt 4.

Schritt 2: WP Super Cache installieren und Caching einschalten

Öffnen Sie Plugins > Plugin hinzufügen, suchen Sie nach „WP Super Cache“ (Autor Automattic), installieren und aktivieren Sie das Plugin. Alternativ per WP-CLI:

wp plugin install wp-super-cache --activate
wp plugin list --status=active

Schon beim Aktivieren verändert das Plugin Ihre Installation. Im Labor fanden sich danach diese Änderungen:

Datei	Änderung
`wp-config.php`	neue Zeilen `define('WP_CACHE', true);` und `WPCACHEHOME`
`wp-content/advanced-cache.php`	neu, lädt den Cache vor WordPress
`wp-content/wp-cache-config.php`	neu, enthält alle Plugin-Einstellungen
`wp-content/cache/`	neu, hier liegen die zwischengespeicherten Seiten

Die Konstante WP_CACHE sorgt dafür, dass WordPress beim Start die Datei advanced-cache.php lädt. Fehlt eines von beiden, cacht das Plugin nichts, auch wenn im Backend alles eingeschaltet aussieht.

Das Caching selbst ist nach der Aktivierung noch aus. Gehen Sie zu Einstellungen > WP Super Cache, Reiter „Easy“, wählen Sie „Caching An (Empfohlen)“ und klicken Sie auf „Update-Status“. Laut Plugin gilt damit: kein Caching für angemeldete Besucher, Modus „Simple“, „Cache Rebuild“ und eine Bereinigung alle 10 Minuten bei 30 Minuten Lebensdauer.

Verifizieren: Prüfen Sie per SFTP oder SSH, ob die Dateien aus der Tabelle vorhanden sind:

grep -n "WP_CACHE" wp-config.php
ls wp-content/advanced-cache.php wp-content/wp-cache-config.php

Erwartet wird eine Zeile mit define('WP_CACHE', true); und beide Dateinamen ohne Fehlermeldung.

Schritt 3: Prüfen, ob Seiten wirklich aus dem Cache kommen

Der häufigste Irrtum beim Testen: Sie sind im Backend angemeldet und sehen deshalb nie eine Seite aus dem Cache. Testen Sie immer abgemeldet, am einfachsten in einem privaten Browserfenster oder mit curl.

Rufen Sie eine Seite zweimal auf und sehen Sie sich das Ende des Quelltextes an. WP Super Cache hängt HTML-Kommentare an:

<!-- Dynamic page generated in 0.245 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2026-09-30 19:41:06 -->

<!-- super cache -->

Entscheidend ist der Zeitstempel. Bleibt er bei mehreren Aufrufen gleich, kommt die Seite aus dem Cache. Die Zeile „super cache“ zeigt, dass eine statische Supercache-Datei ausgeliefert wurde. Auf der Kommandozeile geht das so, ersetzen Sie die Adresse durch Ihre eigene:

curl -s https://www.example.com/ | tail -n 4
curl -s -o /dev/null -w "%{time_total}\n" https://www.example.com/

Im Labor ergab der zweite Befehl beim ersten Aufruf 0,044 Sekunden und danach Werte um 0,001 Sekunden. Die Dateien liegen unter wp-content/cache/supercache/HOSTNAME/.

Alternativ nutzen Sie im Reiter „Easy“ die Schaltfläche „Cache testen“. Hinter Cloudflare oder einem anderen Proxy kann dieser Test laut Plugin fehlschlagen.

Verifizieren: Abgemeldet zeigen zwei Aufrufe derselben Seite denselben Zeitstempel im Kommentar „Cached page generated by WP-Super-Cache“. Angemeldet sehen Sie die Werkzeugleiste und keinen solchen Kommentar. Genau dieses Verhalten ergab der Labortest.

Schritt 4: Personalisierte Seiten vom Cache ausnehmen

Seiten, die für jeden Besucher anders aussehen müssen, gehören nicht in den Cache. Sonst sieht ein Besucher womöglich fremde Inhalte, oder Formulare scheitern an abgelaufenen Sicherheitstoken.

Öffnen Sie den Reiter „Erweitert“ und scrollen Sie zu „Akzeptierte Dateinamen & Abgewiesene URIs“. Dort haben Sie zwei Werkzeuge:

Seitentypen: Häkchen für Einzelne Beiträge, Seiten, Startseite, Archive, Suchseiten, Feeds und andere. Ein gesetztes Häkchen bedeutet hier „nicht cachen“.
Rejected URL Strings: Zeichenketten, eine pro Zeile. Enthält die aufgerufene Adresse eine davon, wird die Seite nicht gecacht. Speichern Sie mit „Strings speichern“.

Die Standardwerte wp-.*\.php und index\.php lassen Sie stehen. Für ein Kontaktformular und einen Kundenbereich ergänzen Sie etwa:

wp-.*\.php
index\.php
/kontakt/
/mein-konto/

Im Labor wurde /kontakt/ eingetragen. Danach fehlte auf dieser Seite der Cache-Kommentar bei jedem Aufruf, die Startseite kam weiterhin aus dem Cache. Die Einträge gelten als Teilstring, /kontakt/ trifft also auch /kontakt/danke/.

Verifizieren: Rufen Sie eine ausgenommene Seite abgemeldet zweimal auf. Im Quelltext darf kein Kommentar „Cached page generated by WP-Super-Cache“ stehen, und im Ordner wp-content/cache/supercache/ entsteht für diese Adresse kein Unterordner.

Schritt 5: Lebensdauer, Bereinigung und Cache leeren

Cache-Dateien veralten. Wenn Sie einen Beitrag bearbeiten, löscht WP Super Cache die zwischengespeicherte Fassung dieses Beitrags. Im Labor wurde der Titel einer Seite geändert, der nächste abgemeldete Aufruf zeigte sofort den neuen Titel mit neuem Zeitstempel. Anders sieht es bei Inhalten aus, die sich außerhalb des Beitrags ändern: Seitenleiste, Menü, Fußzeile, Preise aus einem anderen Plugin. Diese bleiben so lange alt, bis die Cache-Datei abläuft oder Sie den Cache leeren.

Im Reiter „Erweitert“ steuern Sie unter „Expiry-Time & Garbage-Collection“ zwei Werte:

Cache Timeout: wie viele Sekunden eine Datei als frisch gilt. Das Plugin nennt 3600 Sekunden als Ausgangspunkt, das Easy-Paket setzt 1800 Sekunden. Der Wert 0 schaltet die Bereinigung ab.
Scheduler: „Timer“ in Sekunden oder „Clock“ zu einer festen Uhrzeit (UTC), wann veraltete Dateien gelöscht werden.

Die Bereinigung läuft über WP-Cron. Laut Plugin-Dokumentation funktioniert sie nicht, wenn WordPress wp-cron.php nicht erreicht.

Den ganzen Cache leeren Sie über den Eintrag „Cache leeren“ in der Werkzeugleiste oder über die gleichnamige Schaltfläche im Reiter „Easy“. Tun Sie das nach Änderungen an Menü, Widgets und Theme.

Spätestens hier wird klar, dass ein Cache laufende Pflege bedeutet: Nach jedem Update von WordPress, Theme oder Plugins sollten Sie prüfen, ob die Seiten noch korrekt ausgeliefert werden, und das Cache-Plugin selbst muss aktuell bleiben. Wer diese Kontrollen nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und legt wöchentlich ein Backup auf externem Speicher ab.

Verifizieren: Klicken Sie in der Werkzeugleiste auf „Cache leeren“ und rufen Sie die Startseite abgemeldet auf. Der Zeitstempel im Cache-Kommentar muss neuer sein als vorher.

Schritt 6: Auslieferungsmodus „Simple“ oder „Expert“ wählen

Im Reiter „Erweitert“ legt die „Cache-Auslieferungsmethode“ fest, wer die Cache-Datei ausliefert:

Modus	Wie	Vorteil	Nachteil
Simple	PHP liefert die Datei aus	keine Änderung an `.htaccess`, vom Plugin empfohlen	PHP startet bei jedem Aufruf kurz
Expert	Apache mod_rewrite liefert die Datei direkt aus	PHP läuft gar nicht, entlastet bei Lastspitzen	schreibt Regeln in `.htaccess`, Fehler können die Website lahmlegen

Im Labor schrieb der Expert-Modus einen Block # BEGIN WPSuperCache an den Anfang der .htaccess. Danach fehlte bei abgemeldeten Aufrufen der Header X-Powered-By: PHP, die Seite kam also ohne PHP aus dem Dateisystem. Angemeldete Aufrufe liefen weiter über PHP.

Für die meisten kleinen Unternehmensseiten reicht „Simple“. Der Unterschied liegt im Bereich von Millisekunden, das Risiko einer fehlerhaften .htaccess fällt weg. Läuft Ihre Website auf Nginx, wertet der Server die .htaccess nicht aus. Der Modus „Simple“ braucht laut Plugin-Beschreibung keine Rewrite-Regeln und ist dort der naheliegende Weg.

Verifizieren: Nach dem Umschalten auf „Expert“ laden Sie Startseite, eine Unterseite und das Backend. Alle drei müssen normal erscheinen. Prüfen Sie abgemeldet den Header mit curl -sI https://www.example.com/. Fehlt X-Powered-By, greift der Expert-Modus.

Typische Fehler

Kein Cache-Kommentar im Quelltext: Meist sind Sie angemeldet. Testen Sie im privaten Fenster. Fehlt der Kommentar dann immer noch, prüfen Sie, ob define('WP_CACHE', true); in wp-config.php steht und wp-content/advanced-cache.php existiert. Laut Plugin-Dokumentation hilft es, advanced-cache.php zu löschen und die Einstellungsseite neu zu öffnen.
Meldung „WP Super Cache is installed but broken“: Der Pfad in advanced-cache.php oder die Konstante WPCACHEHOME zeigt nicht auf den Plugin-Ordner, etwa nach einem Umzug. Lösung wie oben: Datei löschen, Einstellungsseite öffnen.
Besucher sehen alte Menüs: Cache leeren, gegebenenfalls „Cache Timeout“ verkürzen.
Website-Zustand meldet „Das Vorhandensein eines Seiten-Caches kann nicht erkannt werden“: Der Test unter Werkzeuge > Website-Zustand ruft die eigene Startseite per Loopback-Anfrage ab. Im Labor scheiterte das mit cURL error 7: Failed to connect, obwohl der Cache funktionierte. Ursache ist dann die Loopback-Verbindung, nicht der Cache. Prüfen Sie den Cache mit Schritt 3 und die Loopback-Anfragen separat.
Alle Unterseiten liefern 404, die Startseite geht: Die WordPress-Regeln in der .htaccess sind beschädigt, etwa nach Handarbeit am WPSuperCache-Block. Im Labor antwortete Apache mit „The requested URL was not found on this server.“ Öffnen Sie Einstellungen > Permalinks und klicken Sie ohne Änderung auf „Änderungen speichern“, WordPress schreibt die Regeln dann neu.
Reste nach dem Deaktivieren: Im Labor entfernte das Deaktivieren advanced-cache.php, den Cache-Ordner und die Zeile WP_CACHE. Übrig blieben wp-content/wp-cache-config.php und der WPSuperCache-Block in der .htaccess, auch nach dem Löschen des Plugins. Löschen Sie beides von Hand, mit Backup der .htaccess.

Häufige Fragen

Brauche ich einen Page-Cache, wenn mein Hoster schon cacht?

Meist nicht. Zwei Cache-Schichten erschweren die Fehlersuche. Fragen Sie Ihren Hoster, ob ein Server-Cache aktiv ist und wie Sie ihn leeren.

Funktioniert WP Super Cache mit WooCommerce?

Warenkorb, Kasse und Kundenkonto dürfen nicht gecacht werden. Tragen Sie deren Adressen unter „Rejected URL Strings“ ein und testen Sie den Bestellvorgang abgemeldet vollständig, am besten zuerst auf einer Staging-Umgebung.

Muss der Cache-Ordner ins Backup?

Nein. Die Dateien unter wp-content/cache/ entstehen jederzeit neu. Schließen Sie den Ordner aus, das spart Speicher und Zeit. Hinweise dazu finden Sie in der Anleitung zur Backup-Strategie für WordPress.

Testumfang

Wir haben WP Super Cache unter WordPress 7.1.2 mit Apache im Labor eingerichtet und Cache-Kommentare sowie Antwortzeiten mit curl geprüft. Außerdem haben wir den Expert-Modus mit seinen .htaccess-Regeln ausprobiert und nachgesehen, welche Reste nach dem Löschen des Plugins bleiben.

Nginx, die CDN-Funktion und WooCommerce haben wir nicht getestet. Wenn Sie so etwas einsetzen, probieren Sie die Einstellungen am besten zuerst auf einer Kopie Ihrer Website aus.

Fazit

Ein Page-Cache ist der wirksamste einzelne Schritt für schnellere Seitenaufrufe bei abgemeldeten Besuchern. Mit WP Super Cache im Modus „Simple“ ist er in wenigen Minuten eingerichtet. Die eigentliche Arbeit liegt danach im Prüfen: Kommt die Seite wirklich aus dem Cache, sind personalisierte Seiten ausgenommen, und wird der Cache nach Änderungen geleert? Behalten Sie beim Deaktivieren die Reste in .htaccess und wp-content im Blick. Wenn Sie Updates und Kontrollen nach Updates nicht selbst übernehmen möchten, übernimmt das die WordPress-Wartung mit persönlicher Betreuung.

Weiterführende Anleitungen und Quellen

Weiterführende Anleitungen:

Quellen: