Eine WordPress-Website ist oft unter zwei Hostnamen erreichbar: mit und ohne www. Bleiben beide Varianten parallel bestehen, entstehen doppelte URLs, unnötige Weiterleitungsschritte und mitunter fehlerhafte Login-, OAuth- oder Webhook-Abläufe. Eine saubere .htaccess-Regel führt jede Anfrage direkt auf die festgelegte Hauptdomain.
Sie erfahren, welche Voraussetzungen beide Hostnamen erfüllen müssen, wie eine eng gefasste Apache-Regel aussieht und wie Sie die Umstellung prüfen, ohne andere Weiterleitungen zu stören.
Inhaltsverzeichnis
Was die Vereinheitlichung bewirkt
Bei der Host-Kanonisierung wird eine Variante als verbindliche Adresse festgelegt. Apache beantwortet Anfragen an die andere Variante mit einer dauerhaften Weiterleitung und übernimmt dabei Pfad sowie Query-String. Aus http://www.example.com/konto/?ref=mailwird beispielsweise in einem Schritt https://example.com/konto/?ref=mail.
Die Regel greift erst, nachdem die Anfrage den Webserver erreicht hat. Deshalb müssen beide Hostnamen im DNS eingerichtet sein und durch das TLS-Zertifikat abgedeckt werden. Ein Zertifikatsfehler auf dem abweichenden Host lässt sich nicht nachträglich mit .htaccessbeheben.
Ein typisches WordPress-Szenario
WordPress ist auf die Non-WWW-Adresse eingestellt, während eine ältere CDN-Regel HTTP zunächst auf HTTPS und anschließend auf WWW umleitet. Apache schickt die Anfrage danach wieder auf Non-WWW. Besucher erleben mehrere Sprünge oder sogar eine Schleife; ein OAuth-Callback kann wegen der abweichenden Rücksprungadresse scheitern.
Die Lösung besteht nicht in einer weiteren Regel. Zuerst wird entschieden, welcher Host künftig gilt. Danach werden CDN, WordPress-Adressen, Sitemaps, interne Links und Integrationen auf dasselbe Ziel ausgerichtet. Erst dann übernimmt eine einzige Hostregel die alten Aufrufe.
Warum eine Hauptdomain wichtig ist
Eine eindeutige Adresse bündelt Suchsignale und macht Cookies, Caches sowie Callback-URLs berechenbarer. Sie verhindert außerdem, dass Besucher je nach Einstieg unterschiedliche URL-Varianten erhalten. Die Umstellung ist sinnvoll, wenn beide Varianten bereits erreichbar sind oder alte Links weiterhin funktionieren sollen.
Sie ersetzt jedoch keine DNS-, TLS- oder Proxy-Konfiguration. Liegt die Weiterleitung bereits beim CDN oder Load Balancer, sollte sie möglichst dort und nicht zusätzlich im Apache-Origin gepflegt werden.
Der sichere Einstieg
- Wählen Sie die endgültige Hauptdomain und prüfen Sie die Werte für WordPress-Adresse und Website-Adresse.
- Kontrollieren Sie DNS und Zertifikat für beide Hostnamen.
- Sichern Sie die aktive
.htaccessund halten Sie einen vom WordPress-Backend unabhängigen Dateizugriff bereit. - Entfernen oder deaktivieren Sie konkurrierende Hostweiterleitungen beim CDN, Hoster oder in Plugins.
- Fügen Sie nur die benötigte Regel ein und testen Sie beide Hosts über HTTP und HTTPS.
Prüfen Sie neben der Startseite auch tiefe Pfade, Query-Strings, Anmeldung, Formulare, Webhooks und externe Rücksprungadressen. Jede Variante sollte genau einmal auf dieselbe HTTPS-Zieladresse weiterleiten.
Die technische Umsetzung
Für Non-WWW als Ziel kann Apache den angefragten Host exakt prüfen und anschließend auf die gewünschte Adresse umleiten. Die Hostbedingung sollte keine beliebigen fremden Domains erfassen:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Für WWW als Ziel wird die Bedingung entsprechend auf ^example\.com$gesetzt. Der vorhandene Query-String bleibt bei dieser Form erhalten. Hinter einem Reverse Proxy muss außerdem feststehen, ob Apache den öffentlichen Host unverändert erhält und welche Ebene HTTP auf HTTPS umstellt.
Platzieren Sie die Hostregel vor dem von WordPress verwalteten Permalink-Block. Ändern Sie den Inhalt zwischen den WordPress-Markierungen nicht dauerhaft von Hand, weil WordPress diesen Abschnitt neu schreiben kann. Testen Sie zunächst mit einer temporären Weiterleitung, wenn Browser- oder CDN-Caches eine falsche 301-Antwort lange festhalten könnten.
Risiken, Backup und Rollback
Zu weit gefasste Hostbedingungen können offene Weiterleitungen erzeugen. Mehrere zuständige Ebenen führen häufig zu Ketten oder Schleifen. Weitere Risiken sind ein Zertifikat, das nur einen Host abdeckt, veraltete Cookie-Domains und externe Dienste, deren erlaubte Callback-URL noch auf die alte Variante zeigt.
Bewahren Sie die vorherige .htaccessaußerhalb des Webroots auf. Bei einem Fehler stellen Sie diese Datei über das Hosting-Panel oder SFTP wieder her und leeren nur die betroffenen Caches. DNS und Zertifikat werden separat zurückgesetzt, falls sie Teil der Umstellung waren.
Wie AIOWS unterstützt:
Wie AIOWS Htaccess Editor hilft
AIOWS Htaccess Editor bietet in unterstützten Apache-Umgebungen eine verwaltete Oberfläche für Änderungen an der .htaccess. Vor dem Speichern legt das Modul automatisch eine Sicherung an. Das ist besonders hilfreich, wenn eine Hostregel ergänzt oder eine konkurrierende Anweisung entfernt werden soll.
Vor der Bearbeitung sollte dennoch geklärt sein, welche Datei tatsächlich für die Website gilt und ob CDN oder Hoster bereits weiterleiten. Tragen Sie die Regel eng begrenzt ein, speichern Sie sie und prüfen Sie unmittelbar die vier Kombinationen aus HTTP, HTTPS, WWW und Non-WWW. Zusätzlich sollten mindestens eine Unterseite und eine URL mit Query-String getestet werden.
Das Modul kann weder fehlende DNS-Einträge noch Zertifikate oder vorgelagerte Proxy-Regeln korrigieren. Auch bei einem nicht erreichbaren WordPress-Backend bleibt deshalb ein unabhängiger Serverzugang wichtig.
Passende AIOWS-Artikel
- WordPress von WWW auf Non-WWW weiterleiten
- WordPress von Non-WWW auf WWW weiterleiten
- HTTPS in WordPress per .htaccess erzwingen
Fazit
Legen Sie zuerst eine Hauptdomain fest, machen Sie beide Hostnamen per DNS und TLS erreichbar und lassen Sie nur eine Ebene weiterleiten. Eine exakt begrenzte .htaccess-Regel hält Pfad und Query-String intakt; Tests aller vier URL-Varianten zeigen, ob die Umstellung ohne Kette funktioniert.
