{"id":2073,"date":"2026-05-07T15:13:47","date_gmt":"2026-05-07T12:13:47","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2073"},"modified":"2026-08-02T12:09:22","modified_gmt":"2026-08-02T12:09:22","slug":"non-www-in-wordpress-auf-www-weiterleiten","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/non-www-in-wordpress-auf-www-weiterleiten\/","title":{"rendered":"WordPress von Non-WWW auf WWW umstellen"},"content":{"rendered":"

Eine Marke m\u00f6chte ihre Website k\u00fcnftig unter www.example.com<\/code> f\u00fchren. WordPress und mehrere Zahlungs-Callbacks verwenden aber noch die Domain ohne WWW. Wird jetzt nur eine Redirect-Regel erg\u00e4nzt, entstehen leicht zwei Spr\u00fcnge, falsche Canonical-URLs oder Sitzungen, die beim Hostwechsel verloren gehen.<\/p>\n

Die Umstellung gelingt zuverl\u00e4ssig, wenn WWW nicht nur Ziel des Redirects, sondern der einheitliche \u00f6ffentliche Host der gesamten Website wird. Dazu geh\u00f6ren WordPress-Einstellungen, CDN, Zertifikate, Cookies und alle Dienste, die absolute URLs speichern.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was sich bei der Umstellung \u00e4ndert<\/a><\/li>\n
  2. Praxisbeispiel<\/a><\/li>\n
  3. Welche Systeme betroffen sind<\/a><\/li>\n
  4. Schrittweise Umstellung<\/a><\/li>\n
  5. Technische Abnahme<\/a><\/li>\n
  6. Risiken, Backup und Rollback<\/a><\/li>\n
  7. AIOWS Weiterleitungs-Manager<\/a><\/li>\n
  8. Weiterf\u00fchrende Artikel<\/a><\/li>\n
  9. Fazit<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was sich bei der Umstellung \u00e4ndert<\/h2>\n

    Ein permanenter Redirect f\u00fchrt die Apex-Domain direkt zur entsprechenden HTTPS-Adresse mit WWW. Aus https:\/\/example.com\/angebot?quelle=mail<\/code> wird https:\/\/www.example.com\/angebot?quelle=mail<\/code>. Inhalt, Pfad und ben\u00f6tigte Parameter bleiben gleich; WWW wird zum kanonischen Host.<\/p>\n

    Auch die nur weiterleitende Apex-Domain muss per DNS erreichbar sein und ein g\u00fcltiges 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.<\/p>\n

    Praxisbeispiel<\/h2>\n

    Ein Shop stellt WordPress-Adresse und Website-Adresse auf https:\/\/www.example.com<\/code> um. Das CDN bedient beide Hosts, doch ein Zahlungsanbieter sendet seine R\u00fcckgabe noch an die Apex-Domain. Gleichzeitig ist ein Cookie nur f\u00fcr den alten Host gesetzt. Der erste Test zeigt deshalb einen zus\u00e4tzlichen Redirect und eine verlorene Sitzung.<\/p>\n

    Das Team aktualisiert Callback, Cookie-Konfiguration, Sitemap und Canonical-Tags. Anschlie\u00dfend f\u00fchrt die Apex-Domain mit genau einem 301-Redirect zur entsprechenden WWW-URL. Checkout, Anmeldung, Passwort-Reset und Webhooks werden in neuen Sitzungen gepr\u00fcft; eine vorhandene Subdomain bleibt von der Regel unber\u00fchrt.<\/p>\n

    Welche Systeme betroffen sind<\/h2>\n

    Absolute URLs stecken nicht nur in WordPress. CDN-Hostnamen, OAuth-Callbacks, Zahlungsr\u00fcckgaben, Webhooks, E-Mail-Vorlagen, Open-Graph-Metadaten, hreflang, strukturierte Daten und Analysefilter k\u00f6nnen weiterhin die Domain ohne WWW ausgeben. Der Redirect h\u00e4lt alte Links funktionsf\u00e4hig, ersetzt aber nicht die Pflege dieser Quellen.<\/p>\n

    Besondere Vorsicht gilt bei Multisite, Domain-Mapping sowie getrennten Shop-, API- oder Sprach-Subdomains. Die Regel darf ausschlie\u00dflich die genaue Apex-Domain erfassen. Eine allgemeine Bedingung wie \u201eHost enth\u00e4lt kein www\u201c k\u00f6nnte sonst unabh\u00e4ngige Subdomains auf den falschen Host zwingen.<\/p>\n

    Schrittweise Umstellung<\/h2>\n
      \n
    1. Exportieren Sie WordPress-URL-Werte und bestehende Redirect-Konfiguration.<\/li>\n
    2. Pr\u00fcfen Sie DNS und Zertifikat f\u00fcr Apex-Domain und WWW.<\/li>\n
    3. Stellen Sie WordPress, CDN und wichtige URL-Erzeuger auf die HTTPS-WWW-Adresse um.<\/li>\n
    4. Aktualisieren Sie Cookies, OAuth-, Zahlungs- und Webhook-Adressen.<\/li>\n
    5. Aktivieren Sie eine exakte permanente Weiterleitung von der Apex-Domain zu WWW.<\/li>\n
    6. Testen Sie Seiten, Dateien und Anwendungsabl\u00e4ufe \u00fcber HTTP und HTTPS.<\/li>\n<\/ol>\n

      Technische Abnahme<\/h2>\n

      Pr\u00fcfen Sie jede Host- und Protokollvariante zun\u00e4chst ohne automatisches Folgen. Statuscode und Location<\/code>-Header m\u00fcssen einen direkten Weg zu https:\/\/www.example.com<\/code> zeigen. Verwenden Sie tiefe Pfade, codierte Zeichen und Query-Parameter. Das Ziel liefert anschlie\u00dfend eine normale Antwort mit passendem Canonical.<\/p>\n

      Vergleichen Sie \u00f6ffentliche CDN-Antwort und Ursprungsserver, sofern dieser sicher separat getestet werden kann. Ber\u00fccksichtigen Sie vertrauensw\u00fcrdig weitergeleitete Protokoll- und Hostinformationen. Leeren Sie Caches erst, nachdem die korrekte Origin-Antwort best\u00e4tigt ist, und wiederholen Sie die Abnahme ohne bestehende Cookies.<\/p>\n

      Risiken, Backup und Rollback<\/h2>\n

      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\u00e4ndige Komponente f\u00fcr jede Hostentscheidung und \u00e4ndern Sie nicht mehrere Regeln ohne getrennte Tests.<\/p>\n

      Bei Sitzungs-, Login- oder Callback-Fehlern nehmen Sie die neue Redirect-Regel zur\u00fcck und stellen die zuvor gesicherten WordPress-Werte wieder her. Pr\u00fcfen Sie dann Cookies und den betroffenen Dienst einzeln. Ein Zertifikats- oder DNS-Fehler wird in der Infrastruktur behoben, nicht durch weitere WordPress-Regeln.<\/p>\n

      \n

      So unterst\u00fctzt AIOWS:<\/p>\n

      AIOWS Weiterleitungs-Manager<\/h2>\n

      AIOWS Weiterleitungs-Manager bietet einen zentralen Ort f\u00fcr unterst\u00fctzte WordPress-Weiterleitungen. Bei der Umstellung auf WWW l\u00e4sst 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.<\/p>\n

      Vor dem Aktivieren wird gepr\u00fcft, ob beide Hosts g\u00fcltig aufl\u00f6sen, 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\u00e4tzlich sollten Anmeldung, Checkout, Formulare, Webhooks und Passwort-Reset ohne Hostwechsel in der Anwendung funktionieren.<\/p>\n

      AIOWS kann keine Zertifikate ausstellen, DNS-Eintr\u00e4ge 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\u00e4tzlichen Redirect erzeugt.<\/p>\n

      AIOWS Weiterleitungs-Manager ansehen<\/a>AIOWS-Tarife vergleichen<\/a><\/p>\n<\/section>\n

      Weiterf\u00fchrende Artikel<\/h2>\n