Eine Website soll künftig ausschließlich unter https://example.comerreichbar sein. Die WordPress-Adresse ist bereits geändert, doch Aufrufe von https://www.example.comschlagen mit einem Zertifikatsfehler fehl. In diesem Fall kann die Weiterleitung noch gar nicht greifen: Der WWW-Host muss zuerst DNS und TLS erfolgreich durchlaufen.
Eine belastbare Umstellung betrifft daher mehr als eine einzelne Redirect-Regel. Dieser Beitrag zeigt, wie Sie WWW direkt auf die HTTPS-Adresse ohne WWW führen und WordPress, CDN, Cookies und externe Integrationen auf denselben kanonischen Host ausrichten.
Was die Host-Weiterleitung bewirkt
Die Regel macht die Domain ohne WWW zum kanonischen Host. Ein Aufruf von http://www.example.com/pfad?x=1soll mit einem dauerhaften Redirect direkt bei https://example.com/pfad?x=1landen. Pfad und benötigte Query-Parameter bleiben erhalten; nur Protokoll und Host werden vereinheitlicht.
Eine Weiterleitung setzt voraus, dass der Quellhost erreichbar ist. Für WWW werden deshalb ein gültiger DNS-Eintrag, die korrekte Zuordnung im CDN oder Webserver und ein TLS-Zertifikat benötigt. Erst nach dem erfolgreichen TLS-Handshake kann der Server eine HTTPS-Anfrage mit einem 301-Status beantworten.
Ein realistisches WordPress-Beispiel
Ein Unternehmen trägt https://example.comals WordPress- und Website-Adresse ein. Das CDN kennt jedoch nur die Apex-Domain; für www.example.comfehlen Alias und Zertifikat. HTTP-Aufrufe werden umgeleitet, HTTPS-Aufrufe auf WWW scheitern vorher. Das Team ergänzt den Host im CDN und im Zertifikat und richtet anschließend eine einzige direkte Weiterleitung zur HTTPS-Apex-Adresse ein.
Danach werden eine tiefe Beitrags-URL, ein Formular mit Query-Parameter, Anmeldung und Passwort-Reset geprüft. OAuth-Callbacks, Webhooks, Sitemap, Canonical-Tags und Analysefilter verwenden ebenfalls die Domain ohne WWW. Die bevorzugte Adresse selbst antwortet ohne weiteren Host-Redirect.
Warum alle Ebenen übereinstimmen müssen
WordPress, CDN, Reverse Proxy und Webserver können jeweils eigene Host- oder HTTPS-Regeln ausführen. Zeigt eine Ebene auf Non-WWW und eine andere zurück auf WWW, entsteht eine Schleife. Unterschiedliche WordPress-URL-Werte können außerdem Administratorbereich, Medien, Cookies oder REST-Aufrufe auf einen anderen Host schicken als die öffentliche Seite.
Auch Integrationen behandeln den Host häufig als Sicherheitsmerkmal. OAuth-Anbieter verlangen exakte Callback-URLs, CORS-Regeln vergleichen Origins, und Cookies können auf eine bestimmte Domain beschränkt sein. Ein erfolgreicher Test der Startseite genügt daher nicht.
Der einfache Weg
- Sichern Sie die aktuelle WordPress-, CDN- und Serverkonfiguration.
- Stellen Sie sicher, dass WWW und Non-WWW per DNS erreichbar und durch ein gültiges Zertifikat abgedeckt sind.
- Setzen Sie WordPress-Adresse und Website-Adresse auf die gewünschte HTTPS-Domain ohne WWW.
- Richten Sie genau eine Weiterleitung ein, die nur den WWW-Host erfasst und direkt zum Non-WWW-Ziel führt.
- Testen Sie beide Hosts über HTTP und HTTPS mit tiefen Pfaden, Query-Parametern und wichtigen Anwendungsabläufen.
Technische Prüfung
Rufen Sie jede Ausgangsvariante ohne automatische Weiterleitungsverfolgung auf und notieren Sie Statuscode und Location-Header. Erwartet wird höchstens ein Redirect zur kanonischen HTTPS-Adresse. Das Ziel muss direkt antworten. Prüfen Sie dieselben Anfragen über das CDN und, sofern sicher möglich, am Ursprungsserver.
Bei TLS-Terminierung vor dem Webserver darf nur ein vertrauenswürdiger, vom Hoster dokumentierter Forwarded-Header das ursprünglich verwendete Protokoll übermitteln. Eine ungeprüfte Header-Übernahme ist ebenso riskant wie das Ignorieren des Proxys. Kontrollieren Sie außerdem, ob Pfad, URL-Codierung und erforderliche Query-Parameter unverändert ankommen.
Risiken, häufige Fehler, Backup und Rollback
Zu breite Hostbedingungen können fremde Domains akzeptieren; eine Gegenregel erzeugt Schleifen. Weitere Fehler sind ein fehlendes WWW-Zertifikat, widersprüchliche WordPress-Werte und ungeprüfte Callback-Adressen. Bewahren Sie die vorherigen URL-Werte und Regelbestände getrennt auf.
Wenn Anmeldung, Formulare oder Integrationen nach der Umstellung ausfallen, deaktivieren Sie zunächst nur die neue Redirect-Regel und stellen Sie die vorherigen WordPress-Werte wieder her. Ändern Sie nicht mehrere Ebenen gleichzeitig weiter. Ordnen Sie die Abweichung zuerst DNS, TLS, CDN, Server oder WordPress zu.
So unterstützt AIOWS:
AIOWS Weiterleitungs-Manager
Mit AIOWS Weiterleitungs-Manager lassen sich unterstützte Weiterleitungen innerhalb von WordPress zentral verwalten. Für die Hostvereinheitlichung kann eine klar begrenzte Regel den WWW-Host direkt auf die entsprechende Non-WWW-Adresse führen. Quelle, Ziel und Statuscode bleiben sichtbar, sodass die beabsichtigte Richtung später leichter geprüft werden kann.
Bevor Sie die Regel aktivieren, müssen beide Hosts bereits auflösen und TLS unterstützen. Legen Sie außerdem fest, welche Ebene die kanonische Entscheidung trifft. Nach der Aktivierung prüfen Sie HTTP und HTTPS für Startseite, tiefen Pfad und Query-Variante. Anmeldung, Passwort-Reset, Formulare, Webhooks, Medien und Sitemap sollten ausschließlich den gewählten Host verwenden; eine nicht passende Nachbar-Domain darf nicht erfasst werden.
Der Weiterleitungs-Manager kann weder fehlende DNS-Einträge noch Zertifikate oder widersprüchliche CDN-Regeln reparieren. Er ändert auch keine extern hinterlegten Callback-URLs. Entsteht durch die WordPress-Regel ein zusätzlicher Sprung oder eine Schleife, wird nur diese Regel zurückgenommen. Die Infrastruktur wird anschließend an der tatsächlich zuständigen Stelle korrigiert.
AIOWS Weiterleitungs-Manager ansehenAIOWS-Tarife vergleichen
Passende AIOWS-Artikel
- WordPress von Non-WWW auf WWW umstellen
- Probleme mit Trailing-Slash-Weiterleitungen in WordPress
- WWW- und Non-WWW-Regeln in der WordPress-.htaccess
Fazit
Bereiten Sie DNS und TLS für beide Hosts vor und lassen Sie danach genau eine Regel direkt zur kanonischen HTTPS-Adresse ohne WWW führen. WordPress und externe Integrationen sollten künftig nur noch diesen Host ausgeben.
