Cache-Control für WordPress konfigurieren
Schritt-für-Schritt-Anleitung: Angemeldete Nutzer und Admin-Bereich mit no-store schützen, öffentliche Seiten optimal cachen — mit functions.php ohne Plugin-Abhängigkeit.
Cache-Control in WordPress einrichten
WordPress bietet mit dem send_headers Action Hook einen sauberen Weg, Cache-Control-Header zu setzen — ohne Plugin und ohne Anpassung der Webserver-Konfiguration. Der Hook wird vor der Ausgabe von HTML aufgerufen, sodass Header noch gesetzt werden können.
Diese Anleitung zeigt die Konfiguration in vier Schritten: von der Grundkonfiguration für angemeldete Nutzer über den Admin-Bereich bis zur optimalen Caching-Strategie für öffentliche Seiten und statische Assets.
Cache-Control nach Nutzer-Status setzen
Der send_headers Hook ermöglicht es, Cache-Control-Header basierend auf dem Nutzer-Status zu setzen. Angemeldete Nutzer erhalten private, no-cache, der Admin-Bereich no-store, öffentliche Seiten können gecacht werden.
// functions.php — Cache-Control für WordPress
function set_cache_control_headers() {
if (is_user_logged_in()) {
header('Cache-Control: private, no-cache, must-revalidate');
return;
}
if (is_admin()) {
header('Cache-Control: no-store');
return;
}
header('Cache-Control: public, max-age=3600');
}
add_action('send_headers', 'set_cache_control_headers');Fügen Sie den Code in die functions.php Ihres Child-Themes ein, nicht in die des Parent-Themes. Bei einem Theme-Update würden Änderungen am Parent-Theme sonst überschrieben.
Admin-Bereich und Logout absichern
Der WordPress Admin-Bereich und AJAX-Endpunkte müssen mit Cache-Control: no-store abgesichert werden. Zusätzlich sollte beim Logout Clear-Site-Data gesendet werden, um gecachte Inhalte im Browser zu löschen.
// Zusätzlicher Schutz: Admin-Bereich immer absichern
function set_admin_no_store() {
if (is_admin() || (defined('DOING_AJAX') && DOING_AJAX)) {
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');
}
}
add_action('send_headers', 'set_admin_no_store', 1);
// Logout: Browser-Cache leeren
function clear_cache_on_logout() {
header('Clear-Site-Data: "cache"');
}
add_action('wp_logout', 'clear_cache_on_logout');Clear-Site-Data: "cache"-Header beim Logout löscht alle gecachten Seiten im Browser — ein wichtiger Schutz auf gemeinsam genutzten Geräten (Büro, Bibliothek, Internet-Café). Statische Assets optimal cachen (immutable)
WordPress-Themes und Plugins liefern statische Assets (JS, CSS, Bilder) aus. Diese können in der .htaccess dauerhaft gecacht werden. WordPress fügt automatisch Versionierungs-Parameter (?ver=x.x) hinzu, sodass bei Updates neue Versionen geladen werden.
# .htaccess — Statische Assets in WordPress optimal cachen
<FilesMatch ".(js|css|woff2|woff|ttf)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
<FilesMatch ".(ico|jpg|png|svg|webp)$">
Header set Cache-Control "public, max-age=86400"
</FilesMatch>
# Uploads-Verzeichnis: kurze TTL (Inhalte können sich ändern)
<Directory "/wp-content/uploads/">
Header set Cache-Control "public, max-age=604800"
</Directory>?ver=-Parameter hinzu. immutable ist daher für WordPress-Assets sicher — bei einem Plugin-Update ändert sich die URL durch den neuen Versions-Parameter. Konfiguration verifizieren
Nach der Implementierung prüfen Sie, ob alle Cache-Control-Header korrekt gesetzt werden. Testen Sie sowohl angemeldete als auch nicht angemeldete Anfragen sowie den Admin-Bereich.
# Login-Seite prüfen (angemeldete Nutzer)
curl -sI -b "wordpress_logged_in=test" https://ihre-domain.de/konto | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: private, no-cache, must-revalidate
# Admin-Bereich prüfen
curl -sI https://ihre-domain.de/wp-admin/ | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store
# Öffentliche Seite prüfen
curl -sI https://ihre-domain.de/ | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: public, max-age=3600Der Wolf-Agents Web Security Check prüft automatisch, ob Cache-Control für sensible Bereiche korrekt konfiguriert ist — als Teil der 166 Prüfpunkte mit 8 Punkten für Cache-Control.
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Wie setze ich Cache-Control in WordPress ohne Plugin?
Nutzen Sie den send_headers Action Hook in der functions.php Ihres Child-Themes: add_action("send_headers", "set_cache_control_headers"). In der Hook-Funktion prüfen Sie mit is_user_logged_in() und is_admin(), welche Cache-Control-Direktive gesetzt werden soll.
Sollte ich ein Caching-Plugin für Cache-Control nutzen?
Caching-Plugins wie WP Rocket, W3 Total Cache oder LiteSpeed Cache setzen Cache-Control-Header, aber primär für Performance-Optimierung. Sie behandeln Sicherheits-Anforderungen (no-store für angemeldete Nutzer) oft nicht zuverlässig. Für Sicherheits-Headers ist die functions.php-Methode oder eine Nginx/Apache-Konfiguration verlässlicher.
Was passiert mit dem Cache, wenn ein Nutzer sich ausloggt?
Wenn Sie Cache-Control: private, no-cache, must-revalidate für angemeldete Nutzer setzen, fragt der Browser bei jedem Request nach einer frischen Version. Nach dem Logout sollten Sie zusätzlich wp_set_auth_cookie() nutzen und ggf. Clear-Site-Data: "cache" senden, um gespeicherte Inhalte zu löschen.
Wie funktioniert Cache-Control mit Cloudflare vor WordPress?
Cloudflare respektiert Cache-Control-Header Ihres Servers. Wenn WordPress no-store sendet, cached Cloudflare die Antwort nicht. Für öffentliche WordPress-Seiten können Sie Cloudflare Page Rules (oder Cache Rules) nutzen, um statische Assets aggressiver zu cachen — unabhängig von WordPress-Headern.
Ist der WordPress Admin-Bereich automatisch geschützt?
WordPress sendet für den Admin-Bereich standardmäßig keine strikten Cache-Control-Header. Ein CDN vor WordPress könnte Admin-Antworten cachen. Setzen Sie explizit Cache-Control: no-store für den /wp-admin/-Pfad — sowohl in WordPress (functions.php) als auch in Ihrer Webserver-Konfiguration.