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

Eine Website soll k\u00fcnftig ausschlie\u00dflich unter https:\/\/example.com<\/code> erreichbar sein. Die WordPress-Adresse ist bereits ge\u00e4ndert, doch Aufrufe von https:\/\/www.example.com<\/code> schlagen mit einem Zertifikatsfehler fehl. In diesem Fall kann die Weiterleitung noch gar nicht greifen: Der WWW-Host muss zuerst DNS und TLS erfolgreich durchlaufen.<\/p>\n

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\u00fchren und WordPress, CDN, Cookies und externe Integrationen auf denselben kanonischen Host ausrichten.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was die Host-Weiterleitung bewirkt<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum alle Ebenen \u00fcbereinstimmen m\u00fcssen<\/a><\/li>\n
  4. Der einfache Weg<\/a><\/li>\n
  5. Technische Pr\u00fcfung<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. AIOWS Weiterleitungs-Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was die Host-Weiterleitung bewirkt<\/h2>\n

    Die Regel macht die Domain ohne WWW zum kanonischen Host. Ein Aufruf von http:\/\/www.example.com\/pfad?x=1<\/code> soll mit einem dauerhaften Redirect direkt bei https:\/\/example.com\/pfad?x=1<\/code> landen. Pfad und ben\u00f6tigte Query-Parameter bleiben erhalten; nur Protokoll und Host werden vereinheitlicht.<\/p>\n

    Eine Weiterleitung setzt voraus, dass der Quellhost erreichbar ist. F\u00fcr WWW werden deshalb ein g\u00fcltiger DNS-Eintrag, die korrekte Zuordnung im CDN oder Webserver und ein TLS-Zertifikat ben\u00f6tigt. Erst nach dem erfolgreichen TLS-Handshake kann der Server eine HTTPS-Anfrage mit einem 301-Status beantworten.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    Ein Unternehmen tr\u00e4gt https:\/\/example.com<\/code> als WordPress- und Website-Adresse ein. Das CDN kennt jedoch nur die Apex-Domain; f\u00fcr www.example.com<\/code> fehlen Alias und Zertifikat. HTTP-Aufrufe werden umgeleitet, HTTPS-Aufrufe auf WWW scheitern vorher. Das Team erg\u00e4nzt den Host im CDN und im Zertifikat und richtet anschlie\u00dfend eine einzige direkte Weiterleitung zur HTTPS-Apex-Adresse ein.<\/p>\n

    Danach werden eine tiefe Beitrags-URL, ein Formular mit Query-Parameter, Anmeldung und Passwort-Reset gepr\u00fcft. OAuth-Callbacks, Webhooks, Sitemap, Canonical-Tags und Analysefilter verwenden ebenfalls die Domain ohne WWW. Die bevorzugte Adresse selbst antwortet ohne weiteren Host-Redirect.<\/p>\n

    Warum alle Ebenen \u00fcbereinstimmen m\u00fcssen<\/h2>\n

    WordPress, CDN, Reverse Proxy und Webserver k\u00f6nnen jeweils eigene Host- oder HTTPS-Regeln ausf\u00fchren. Zeigt eine Ebene auf Non-WWW und eine andere zur\u00fcck auf WWW, entsteht eine Schleife. Unterschiedliche WordPress-URL-Werte k\u00f6nnen au\u00dferdem Administratorbereich, Medien, Cookies oder REST-Aufrufe auf einen anderen Host schicken als die \u00f6ffentliche Seite.<\/p>\n

    Auch Integrationen behandeln den Host h\u00e4ufig als Sicherheitsmerkmal. OAuth-Anbieter verlangen exakte Callback-URLs, CORS-Regeln vergleichen Origins, und Cookies k\u00f6nnen auf eine bestimmte Domain beschr\u00e4nkt sein. Ein erfolgreicher Test der Startseite gen\u00fcgt daher nicht.<\/p>\n

    Der einfache Weg<\/h2>\n
      \n
    1. Sichern Sie die aktuelle WordPress-, CDN- und Serverkonfiguration.<\/li>\n
    2. Stellen Sie sicher, dass WWW und Non-WWW per DNS erreichbar und durch ein g\u00fcltiges Zertifikat abgedeckt sind.<\/li>\n
    3. Setzen Sie WordPress-Adresse und Website-Adresse auf die gew\u00fcnschte HTTPS-Domain ohne WWW.<\/li>\n
    4. Richten Sie genau eine Weiterleitung ein, die nur den WWW-Host erfasst und direkt zum Non-WWW-Ziel f\u00fchrt.<\/li>\n
    5. Testen Sie beide Hosts \u00fcber HTTP und HTTPS mit tiefen Pfaden, Query-Parametern und wichtigen Anwendungsabl\u00e4ufen.<\/li>\n<\/ol>\n

      Technische Pr\u00fcfung<\/h2>\n

      Rufen Sie jede Ausgangsvariante ohne automatische Weiterleitungsverfolgung auf und notieren Sie Statuscode und Location<\/code>-Header. Erwartet wird h\u00f6chstens ein Redirect zur kanonischen HTTPS-Adresse. Das Ziel muss direkt antworten. Pr\u00fcfen Sie dieselben Anfragen \u00fcber das CDN und, sofern sicher m\u00f6glich, am Ursprungsserver.<\/p>\n

      Bei TLS-Terminierung vor dem Webserver darf nur ein vertrauensw\u00fcrdiger, vom Hoster dokumentierter Forwarded-Header das urspr\u00fcnglich verwendete Protokoll \u00fcbermitteln. Eine ungepr\u00fcfte Header-\u00dcbernahme ist ebenso riskant wie das Ignorieren des Proxys. Kontrollieren Sie au\u00dferdem, ob Pfad, URL-Codierung und erforderliche Query-Parameter unver\u00e4ndert ankommen.<\/p>\n

      Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/h2>\n

      Zu breite Hostbedingungen k\u00f6nnen fremde Domains akzeptieren; eine Gegenregel erzeugt Schleifen. Weitere Fehler sind ein fehlendes WWW-Zertifikat, widerspr\u00fcchliche WordPress-Werte und ungepr\u00fcfte Callback-Adressen. Bewahren Sie die vorherigen URL-Werte und Regelbest\u00e4nde getrennt auf.<\/p>\n

      Wenn Anmeldung, Formulare oder Integrationen nach der Umstellung ausfallen, deaktivieren Sie zun\u00e4chst nur die neue Redirect-Regel und stellen Sie die vorherigen WordPress-Werte wieder her. \u00c4ndern Sie nicht mehrere Ebenen gleichzeitig weiter. Ordnen Sie die Abweichung zuerst DNS, TLS, CDN, Server oder WordPress zu.<\/p>\n

      \n

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

      AIOWS Weiterleitungs-Manager<\/h2>\n

      Mit AIOWS Weiterleitungs-Manager lassen sich unterst\u00fctzte Weiterleitungen innerhalb von WordPress zentral verwalten. F\u00fcr die Hostvereinheitlichung kann eine klar begrenzte Regel den WWW-Host direkt auf die entsprechende Non-WWW-Adresse f\u00fchren. Quelle, Ziel und Statuscode bleiben sichtbar, sodass die beabsichtigte Richtung sp\u00e4ter leichter gepr\u00fcft werden kann.<\/p>\n

      Bevor Sie die Regel aktivieren, m\u00fcssen beide Hosts bereits aufl\u00f6sen und TLS unterst\u00fctzen. Legen Sie au\u00dferdem fest, welche Ebene die kanonische Entscheidung trifft. Nach der Aktivierung pr\u00fcfen Sie HTTP und HTTPS f\u00fcr Startseite, tiefen Pfad und Query-Variante. Anmeldung, Passwort-Reset, Formulare, Webhooks, Medien und Sitemap sollten ausschlie\u00dflich den gew\u00e4hlten Host verwenden; eine nicht passende Nachbar-Domain darf nicht erfasst werden.<\/p>\n

      Der Weiterleitungs-Manager kann weder fehlende DNS-Eintr\u00e4ge noch Zertifikate oder widerspr\u00fcchliche CDN-Regeln reparieren. Er \u00e4ndert auch keine extern hinterlegten Callback-URLs. Entsteht durch die WordPress-Regel ein zus\u00e4tzlicher Sprung oder eine Schleife, wird nur diese Regel zur\u00fcckgenommen. Die Infrastruktur wird anschlie\u00dfend an der tats\u00e4chlich zust\u00e4ndigen Stelle korrigiert.<\/p>\n

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

      Passende AIOWS-Artikel<\/h2>\n