Eine Marke möchte ihre Website künftig unter www.example.comführen. WordPress und mehrere Zahlungs-Callbacks verwenden aber noch die Domain ohne WWW. Wird jetzt nur eine Redirect-Regel ergänzt, entstehen leicht zwei Sprünge, falsche Canonical-URLs oder Sitzungen, die beim Hostwechsel verloren gehen.
Die Umstellung gelingt zuverlässig, wenn WWW nicht nur Ziel des Redirects, sondern der einheitliche öffentliche Host der gesamten Website wird. Dazu gehören WordPress-Einstellungen, CDN, Zertifikate, Cookies und alle Dienste, die absolute URLs speichern.
Was sich bei der Umstellung ändert
Ein permanenter Redirect führt die Apex-Domain direkt zur entsprechenden HTTPS-Adresse mit WWW. Aus https://example.com/angebot?quelle=mailwird https://www.example.com/angebot?quelle=mail. Inhalt, Pfad und benötigte Parameter bleiben gleich; WWW wird zum kanonischen Host.
Auch die nur weiterleitende Apex-Domain muss per DNS erreichbar sein und ein gültiges Zertifikat besitzen. Andernfalls bricht eine HTTPS-Verbindung ab, bevor der Server den Redirect senden kann. Die WWW-Adresse sollte nach der Umstellung ohne weiteren Hostwechsel antworten.
Praxisbeispiel
Ein Shop stellt WordPress-Adresse und Website-Adresse auf https://www.example.comum. Das CDN bedient beide Hosts, doch ein Zahlungsanbieter sendet seine Rückgabe noch an die Apex-Domain. Gleichzeitig ist ein Cookie nur für den alten Host gesetzt. Der erste Test zeigt deshalb einen zusätzlichen Redirect und eine verlorene Sitzung.
Das Team aktualisiert Callback, Cookie-Konfiguration, Sitemap und Canonical-Tags. Anschließend führt die Apex-Domain mit genau einem 301-Redirect zur entsprechenden WWW-URL. Checkout, Anmeldung, Passwort-Reset und Webhooks werden in neuen Sitzungen geprüft; eine vorhandene Subdomain bleibt von der Regel unberührt.
Welche Systeme betroffen sind
Absolute URLs stecken nicht nur in WordPress. CDN-Hostnamen, OAuth-Callbacks, Zahlungsrückgaben, Webhooks, E-Mail-Vorlagen, Open-Graph-Metadaten, hreflang, strukturierte Daten und Analysefilter können weiterhin die Domain ohne WWW ausgeben. Der Redirect hält alte Links funktionsfähig, ersetzt aber nicht die Pflege dieser Quellen.
Besondere Vorsicht gilt bei Multisite, Domain-Mapping sowie getrennten Shop-, API- oder Sprach-Subdomains. Die Regel darf ausschließlich die genaue Apex-Domain erfassen. Eine allgemeine Bedingung wie „Host enthält kein www“ könnte sonst unabhängige Subdomains auf den falschen Host zwingen.
Schrittweise Umstellung
- Exportieren Sie WordPress-URL-Werte und bestehende Redirect-Konfiguration.
- Prüfen Sie DNS und Zertifikat für Apex-Domain und WWW.
- Stellen Sie WordPress, CDN und wichtige URL-Erzeuger auf die HTTPS-WWW-Adresse um.
- Aktualisieren Sie Cookies, OAuth-, Zahlungs- und Webhook-Adressen.
- Aktivieren Sie eine exakte permanente Weiterleitung von der Apex-Domain zu WWW.
- Testen Sie Seiten, Dateien und Anwendungsabläufe über HTTP und HTTPS.
Technische Abnahme
Prüfen Sie jede Host- und Protokollvariante zunächst ohne automatisches Folgen. Statuscode und Location-Header müssen einen direkten Weg zu https://www.example.comzeigen. Verwenden Sie tiefe Pfade, codierte Zeichen und Query-Parameter. Das Ziel liefert anschließend eine normale Antwort mit passendem Canonical.
Vergleichen Sie öffentliche CDN-Antwort und Ursprungsserver, sofern dieser sicher separat getestet werden kann. Berücksichtigen Sie vertrauenswürdig weitergeleitete Protokoll- und Hostinformationen. Leeren Sie Caches erst, nachdem die korrekte Origin-Antwort bestätigt ist, und wiederholen Sie die Abnahme ohne bestehende Cookies.
Risiken, Backup und Rollback
Eine konkurrierende WWW-zu-Apex-Regel erzeugt eine Schleife. Weitere Risiken sind ein fehlendes Zertifikat der Apex-Domain, zu breite Hostbedingungen und nicht aktualisierte Integrationen. Dokumentieren Sie deshalb die zuständige Komponente für jede Hostentscheidung und ändern Sie nicht mehrere Regeln ohne getrennte Tests.
Bei Sitzungs-, Login- oder Callback-Fehlern nehmen Sie die neue Redirect-Regel zurück und stellen die zuvor gesicherten WordPress-Werte wieder her. Prüfen Sie dann Cookies und den betroffenen Dienst einzeln. Ein Zertifikats- oder DNS-Fehler wird in der Infrastruktur behoben, nicht durch weitere WordPress-Regeln.
So unterstützt AIOWS:
AIOWS Weiterleitungs-Manager
AIOWS Weiterleitungs-Manager bietet einen zentralen Ort für unterstützte WordPress-Weiterleitungen. Bei der Umstellung auf WWW lässt sich die Apex-Quelle eindeutig der entsprechenden WWW-Adresse zuordnen. Die Regel bleibt mit Statuscode und Ziel sichtbar und kann getrennt von Weiterleitungen im CDN oder Webserver beurteilt werden.
Vor dem Aktivieren wird geprüft, ob beide Hosts gültig auflösen, TLS funktioniert und WordPress bereits die WWW-Adresse ausgibt. Danach testen Sie eine normale Seite, einen tiefen Pfad, relevante Query-Parameter und eine nicht passende Subdomain. Zusätzlich sollten Anmeldung, Checkout, Formulare, Webhooks und Passwort-Reset ohne Hostwechsel in der Anwendung funktionieren.
AIOWS kann keine Zertifikate ausstellen, DNS-Einträge reparieren oder externe Callback-Adressen aktualisieren. Der Manager beseitigt auch keine Gegenregel in einer vorgelagerten Infrastruktur. Tritt nach der Aktivierung eine Schleife oder ein unerwarteter Treffer auf, deaktivieren Sie die neue WordPress-Regel und verfolgen die Antwortkette bis zu der Komponente, die den zusätzlichen Redirect erzeugt.
AIOWS Weiterleitungs-Manager ansehenAIOWS-Tarife vergleichen
Weiterführende Artikel
- WordPress von WWW auf Non-WWW umstellen
- Probleme mit Trailing-Slash-Weiterleitungen in WordPress
- WWW- und Non-WWW-Regeln in der WordPress-.htaccess
Fazit
Machen Sie WWW zuerst auf allen beteiligten Ebenen zum bevorzugten Host. Eine einzige exakte Weiterleitung hält danach alte Non-WWW-Links erreichbar, ohne Subdomains oder Anwendungsabläufe unnötig zu beeinflussen.
