WordPress erzeugt URLs ohne www, während Kampagnenlinks die www-Variante verwenden. Beide Hosts liefern Status 200, und unterschiedliche CDN- und Serverregeln erzeugen unnötige Redirect-Ketten.
Mit und ohne wwwsind technisch verschiedene Hostnamen. Wählen Sie einen kanonischen HTTPS-Host, machen Sie beide Eingänge TLS-fähig und leiten Sie die Alternative direkt weiter. WordPress, Sitemap und Integrationen müssen dieselbe Wahl verwenden.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was die kanonische Hostwahl bedeutet
Die Wahl zwischen www.example.comund example.comist keine Geschwindigkeitsoption. Sie legt fest, welche Adresse WordPress ausgibt, welche URL in Canonicals und Sitemaps erscheint und welche Domain externe Callbacks verwenden.
Der alternative Host braucht trotzdem gültiges DNS und ein passendes Zertifikat. Erst nach erfolgreichem TLS-Handshake kann er per HTTP-Redirect auf die kanonische Adresse verweisen.
Ein realistisches WordPress-Beispiel
HTTP ohne wwwleitet zuerst zu HTTP mit wwwund danach zu HTTPS. Der HTTPS-Aufruf ohne wwwliefert dagegen direkt die Website aus. Canonical und Sitemap widersprechen sich, und das Zertifikat deckt nur einen Host ab.
Das Team ergänzt den fehlenden Namen im Zertifikat, setzt WordPress auf https://example.comund ersetzt die Regeln durch einen einzigen Redirect von jeder alternativen Variante auf denselben Pfad und dieselbe Query am kanonischen Host.
Warum Konsistenz wichtig ist
Uneinheitliche Hosts verteilen Links, Cookies, Cache-Einträge und Suchsignale auf mehrere Adressen. OAuth-Callbacks, Zahlungsanbieter und Webhooks können fehlschlagen, wenn sie nur eine Variante kennen. Mehrstufige Redirects erhöhen zudem Latenz und erschweren die Diagnose.
Eine Umstellung ist sinnvoll, wenn beide Hosts Inhalte ausliefern oder WordPress und Infrastruktur verschiedene Varianten bevorzugen. Eine funktionierende bestehende Wahl muss nicht allein aus optischen Gründen geändert werden.
Der einfache Weg für Einsteiger
- Wählen Sie den Host, der künftig überall verwendet werden soll.
- Prüfen Sie DNS und Zertifikat für beide Varianten.
- Sichern Sie aktuelle WordPress-URLs und Redirect-Regeln.
- Stellen Sie WordPress-Adresse und Website-Adresse auf den kanonischen HTTPS-Host.
- Richten Sie genau eine direkte Weiterleitung für die Alternative ein.
- Prüfen Sie Sitemap, Canonicals, Login, Formulare und externe Callbacks.
Der technische Weg
Testen Sie alle vier Eingänge – HTTP und HTTPS jeweils mit und ohne www– für Startseite, tiefen Pfad und Query-Parameter. Nur der kanonische HTTPS-Host sollte Status 200 liefern; alle anderen Varianten sollten in einem Sprung dorthin führen.
- Kontrollieren Sie Host-Bindungen an CDN und Ursprung.
- Prüfen Sie Cookie-Domain, OAuth- und Zahlungs-Callbacks sowie Webhooks.
- Vergleichen Sie Canonical,
hreflang, Sitemap und interne Links. - Lehnen Sie unbekannte Hostnamen ab, statt sie offen weiterzuleiten.
Risiken, häufige Fehler, Backup und Rollback
Ein alternativer Host ohne Zertifikat scheitert vor dem Redirect. Zu breite Host-Regeln können offene Weiterleitungen erzeugen, während parallele Regeln in CDN, Server und Plugin leicht Schleifen bilden.
- Ändern Sie Hostwahl und Cookie-Domain nicht ohne Sitzungstest.
- Bewahren Sie die vorherigen WordPress- und Redirect-Werte auf.
- Prüfen Sie API-Endpunkte und Medien-URLs mit.
- Rollen Sie zurück, wenn Login, Callback oder Sitemap nicht mehr konsistent funktioniert.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige Kontrolle des gewählten HTTPS-Hosts. Sie können damit relevante sichere Adressen und unterstützte SSL-Einstellungen zentral prüfen, nachdem DNS und Zertifikate für beide Eingänge vorbereitet wurden.
Erfassen Sie zuerst die aktuelle WordPress-Adresse und Website-Adresse sowie die aktive Redirect-Regel. Legen Sie dann den kanonischen Host fest und nehmen Sie nur die dazugehörige unterstützte WordPress-Änderung vor. Testen Sie anschließend alle vier HTTP-/HTTPS-Varianten, Login, Administration, REST, Formulare und externe Callbacks. Canonical-Tags und Sitemap müssen ebenfalls den gewählten Host ausgeben.
Der SSL Manager kann kein Zertifikat an einem externen CDN ergänzen, keine DNS-Einträge ändern und keine Serverregel außerhalb von WordPress ersetzen. Diese Ebenen müssen separat und eindeutig konfiguriert werden. Bewahren Sie deshalb die vorherigen URL-Werte und Redirect-Regeln auf. Falls eine Sitzung, ein Callback oder ein tiefer Pfad nach der Änderung fehlschlägt, stellen Sie die WordPress-Werte zurück und korrigieren die Weiterleitung am verantwortlichen Endpunkt. Ziel ist ein direkter, pfaderhaltender Redirect auf einen einzigen sicheren Host.
Passende AIOWS-Artikel
- Cloudflare Flexible SSL verursacht eine WordPress-Weiterleitungsschleife
- HTTP mit .htaccess auf HTTPS in WordPress umleiten
- HTTPS-Canonical-URLs und Sitemaps in WordPress
Fazit und empfohlener Weg
Bereiten Sie beide Hostnamen mit DNS und TLS vor, wählen Sie einen kanonischen HTTPS-Host und richten Sie alle URL-Erzeuger darauf aus. Die alternative Variante sollte Pfad und Query in genau einem Redirect erhalten.
