Erweiterte Header für WordPress konfigurieren
Schritt-für-Schritt: Origin-Agent-Cluster über send_headers-Hook, HTTPS-Redirect in .htaccess, WWW-Normalisierung und WordPress-spezifische Header entfernen.
Erweiterte Header auf WordPress
WordPress bietet zwei Wege für HTTP-Header: den send_headers-Hook in functions.php für dynamisch gesetzte Header und die .htaccess-Datei für server-seitige Redirects und statische Header. Beide Methoden ergänzen sich: PHP-seitige Header für Origin-Agent-Cluster, .htaccess für Redirects.
Alle Änderungen in functions.php immer im Child-Theme vornehmen — nicht im Parent-Theme. Bei .htaccess-Änderungen: Neue Regeln immer vor dem # BEGIN WordPress-Block einfügen.
Origin-Agent-Cluster über functions.php setzen
Der WordPress-Hook send_headers wird ausgeführt, bevor WordPress Inhalte ausgibt — der ideale Zeitpunkt für HTTP-Header. Die PHP-Funktion header() sendet den Origin-Agent-Cluster: ?1-Header für alle WordPress-Seiten.
// functions.php des Child-Themes (NICHT das Parent-Theme!)
add_action( 'send_headers', function() {
// Prozess-Isolation gegen Spectre (RFC 8941: ?1 = true)
header( 'Origin-Agent-Cluster: ?1' );
} );WP Super Cache, W3 Total Cache und ähnliche Plugins liefern gecachte HTML-Dateien direkt aus — ohne PHP-Ausführung. In diesem Fall müssen Security-Header auf Server-Ebene (Apache-Direktive oder Nginx add_header) gesetzt werden, da der WordPress-Hook nicht ausgeführt wird.
HTTPS-Redirect konfigurieren
WordPress muss auf zwei Ebenen auf HTTPS umgestellt werden: in den WordPress-Einstellungen (damit WordPress interne Links korrekt generiert) und in der .htaccess (damit direkte HTTP-Anfragen auf Apache-Ebene umgeleitet werden, bevor WordPress geladen wird).
// 1. WordPress-Einstellungen anpassen (Einstellungen → Allgemein)
// WordPress-Adresse: https://example.com
// Website-Adresse: https://example.com
// 2. .htaccess — VOR dem # BEGIN WordPress Block einfügen
# HTTP → HTTPS Redirect
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# BEGIN WordPress
# (WordPress-eigene Regeln folgen hier)# BEGIN WordPress-Kommentar stehen. Andernfalls überschreibt WordPress bei nächster Permalink-Änderung die .htaccess und entfernt Ihre Regel. WWW-Normalisierung in .htaccess
Für WordPress auf Apache fügen Sie die WWW-Normalisierung direkt in der .htaccess ein — ebenfalls vor dem # BEGIN WordPress-Block. Stellen Sie außerdem in Einstellungen → Allgemein sicher, dass die WordPress-URL ohne www eingetragen ist.
# .htaccess — WWW → non-WWW (VOR # BEGIN WordPress)
<IfModule mod_rewrite.c>
RewriteEngine On
# www.example.com → example.com (301)
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
# HTTP → HTTPS (kombiniert mit WWW-Redirect)
RewriteCond %{HTTPS} off
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]
</IfModule>
# BEGIN WordPressAuf Nginx-Servern funktioniert .htaccess nicht. Konfigurieren Sie Redirects in der Nginx-Konfigurationsdatei mit separaten Server-Blöcken — wie in der Nginx-Anleitung beschrieben.
Veraltete und überflüssige Header entfernen
WordPress sendet standardmäßig mehrere Header, die Technologie-Details preisgeben oder veraltet sind: X-Pingback verrät die WordPress-Installation, der Link-Header mit REST-API-URL ist unnötig, und PHP setzt X-Powered-By mit der PHP-Version. Alle lassen sich mit functions.php entfernen.
// functions.php — WordPress-spezifische Header entfernen
// X-Pingback Header entfernen (verrät WordPress-Installation)
add_filter( 'wp_headers', function( $headers ) {
unset( $headers['X-Pingback'] );
return $headers;
} );
// WordPress REST API Link-Header entfernen
remove_action( 'template_redirect', 'rest_output_link_header', 11 );
// X-Powered-By über PHP-Konfiguration
// In php.ini: expose_php = Off
// Oder in .htaccess: php_flag expose_php Off
// X-XSS-Protection NICHT setzen — aus Browsern entfernt (2023)Nach allen Änderungen: curl -sI https://example.com | grep -iE "(origin-agent|x-pingback|x-powered|x-xss)". Origin-Agent-Cluster sollte erscheinen, alle anderen genannten Header sollten fehlen.
Wie steht Ihre Domain bei Erweiterte Header?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Wie setze ich Origin-Agent-Cluster in WordPress?
Über den send_headers-Hook in der functions.php des Child-Themes: add_action("send_headers", function() { header("Origin-Agent-Cluster: ?1"); }); Diese Methode ist WordPress-konform und wird bei jedem Seitenaufruf ausgeführt, bevor Ausgaben gesendet werden.
Soll ich die HTTPS-Einstellung in WordPress oder in .htaccess konfigurieren?
Beides ist nötig. In WordPress: Einstellungen → Allgemein → WordPress-Adresse und Website-Adresse auf https:// ändern. In .htaccess: Den RewriteRule-Block für HTTP→HTTPS ergänzen. Nur WordPress zu ändern reicht nicht — direkte HTTP-Anfragen gehen an Apache/Nginx, nicht an WordPress.
Verliere ich beim WWW-Redirect meine WordPress-Permalinks?
Nein. Die RewriteRule für WWW-Normalisierung greift vor den WordPress-Rewrite-Regeln. Stellen Sie sicher, dass die Regel VOR dem WordPress-Block in .htaccess steht (vor dem # BEGIN WordPress Kommentar). WordPress-eigene Regeln nach dem # END WordPress-Block werden nicht überschrieben.
Welche WordPress-spezifischen Header sollte ich entfernen?
X-Pingback (verrät WordPress-Installation), Link-Header mit rel=https://api.w.org/ (verrät WordPress REST API), X-Powered-By (PHP-Version). Alle lassen sich über functions.php mit remove_action("wp_head", "rsd_link") und header_remove() entfernen.
Kann ich statt functions.php ein Plugin für die Header nutzen?
Ja — Plugins wie "Security Headers" oder "HTTP Headers" erlauben die Konfiguration ohne Code-Änderungen. Der Nachteil: Plugin-Dependencies und Overhead bei jedem Request. Die functions.php-Methode ist leichtgewichtiger und bleibt unabhängig von Plugin-Updates.
Wie teste ich, ob die Header in WordPress korrekt gesetzt werden?
Mit curl -sI https://example.com | grep -i origin-agent-cluster oder in den Browser DevTools (F12 → Netzwerk → Antwort-Header). Testen Sie nach Änderungen in .htaccess immer mit apachectl configtest oder nginx -t, je nach Server.
Gibt es Konflikte zwischen WordPress-Caching-Plugins und Security-Headern?
Ja, möglicherweise. Caching-Plugins wie W3 Total Cache oder WP Super Cache können gecachte Seiten ohne die dynamisch gesetzten Header ausliefern. Stellen Sie sicher, dass Security-Header entweder auf Server-Ebene gesetzt werden oder vom Caching-Plugin respektiert werden. Die .htaccess-Methode ist caching-sicherer.