# Warum sollten www. und Apex-Domains zusammengeführt werden? (Die Bedeutung von 301/308 Redirects) Haben Sie moderne Browser wie Chrome, Edge oder Safari in letzter Zeit genauer beobachtet? Wenn Sie `www.naver.com` oder `www.google.com` in die Adressleiste eingeben, verschwindet das `www` nach kurzer Zeit und nur noch die Apex-Domain bleibt sichtbar. Sogar mobile `m.`-Domains werden oft ausgeblendet. Dies liegt an der von modernen Browsern implementierten Richtlinie zum Ausblenden von **„trivialen Subdomains“**, um die Adressleiste optisch zu vereinfachen. Für Nutzer mag eine kürzere Adresse angenehmer sein, doch als Webentwickler sollte man einen Schritt weiterdenken. Denn es ist ein entscheidender Unterschied, ob **„der Browser etwas ausblendet“** oder ob **„es sich tatsächlich um separate Domains handelt“**. ![Flussdiagramm zum Vergleich vor und nach der Anwendung von Redirects](/media/whitedec/blog_img/77ecb43d3845413385e9e0ebf6cc351f.webp) ## DNS und Such-Bots sehen 'www' sehr genau {#sec-e0d49c76d3ea} Für den tatsächlichen DNS-Prozess oder [[Suchmaschinen-Roboter]] (wie Googlebot) sind `www.example.com` und `example.com` eindeutig unterschiedliche Ziele. Wenn beide Adressen eine `200 OK`-Antwort zurückgeben und denselben Inhalt anzeigen, ist dies technisch gleichbedeutend mit dem Betrieb von zwei Websites, die „doppelten Inhalt“ aufweisen. Sehen wir uns direkt mit dem `curl`-Befehl an, wie globale IT-Unternehmen dieses Problem lösen. **1. Das Beispiel von Yahoo Japan** ```bash $ curl -I https://yahoo.co.jp/ HTTP/2 301 location: https://www.yahoo.co.jp:443/ ... ``` Yahoo Japan leitet bei Zugriff auf die Apex-Domain mit einem `301 Moved Permanently` Redirect auf die `www`-Adresse um. **2. Das Beispiel von Google** ```bash $ curl -I https://google.com/ HTTP/2 301 location: https://www.google.com/ ... $ curl -I https://www.google.com/ HTTP/2 200 ... ``` Auch Google macht es so. Wenn Sie `google.com` aufrufen, wird auf `www.google.com` weitergeleitet, und erst die `www`-Domain gibt letztendlich eine `200`-Antwort zurück. ## Warum ist ein Redirect auf eine der beiden Varianten zwingend erforderlich? {#sec-cf467e61a55d} Es geht nicht nur darum, dass es „ordentlicher aussieht“. Es gibt klare Gründe für SEO (Suchmaschinenoptimierung) und betriebliche Effizienz. ### 1. Die Grenzen des Canonical Tags {#sec-9531d19b126b} Viele Entwickler denken, dass es ausreicht, das ``-Tag zu setzen. Doch das Canonical Tag ist lediglich ein „Hinweis“ für Suchmaschinen. Die Tatsache, dass Bots beide URLs crawlen müssen, ändert sich nicht, und dabei wird **Crawl-Budget** verschwendet. Die Bots würden sozusagen eine „Kopie“ eines bereits vorhandenen Artikels crawlen, anstatt neue Inhalte Ihrer Website zu indexieren. ### 2. Die Verteilung des Link Juice {#sec-c445aae506c3} Wenn andere Websites im Web auf Ihre Inhalte verlinken, fügen manche das `www` hinzu, andere lassen es weg. Wenn keine Weiterleitung eingerichtet ist, verteilt sich die Autorität (Authority), die die Seite aufbauen sollte, auf zwei Domains, was sich nachteilig auf das Ranking in Suchmaschinen auswirkt. --- ## Die Lösung: Erzwingen von Redirects auf Webserver-Ebene {#sec-e499a7960796} Diese Verarbeitung ist am effizientesten auf **Webserver-Ebene (Infrastruktur)**, wie bei [[Nginx]] oder Apache, und nicht auf Anwendungsebene (Django, Node.js etc.). Denn die sofortige Weiterleitung durch den Server, bevor die Anfrage die Anwendung erreicht, verbraucht weniger Ressourcen und ist schneller. Im Folgenden finden Sie ein Beispiel für eine Nginx-Konfiguration, die alle Anfragen auf die Apex-Domain (`https://example.com`) vereinheitlicht, wenn Sie `example.com` betreiben. (Wenn Sie stattdessen auf www vereinheitlichen möchten, ändern Sie einfach die Zieladresse.) ```nginx # 1. www (HTTP) -> Apex (HTTPS) server { listen 80; listen [::]:80; server_name www.example.com; return 308 https://example.com$request_uri; } # 2. www (HTTPS) -> Apex (HTTPS) server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; return 308 https://example.com$request_uri; } # 3. Apex (HTTP) -> Apex (HTTPS) server { listen 80; listen [::]:80; server_name example.com; return 308 https://example.com$request_uri; } # 4. 실제 서비스 로직 (Apex HTTPS 200 OK) server { listen 443 ssl http2; server_name example.com; # ... 서비스 설정 및 Proxy Pass 등 } ``` > **Tipp:** Der Grund für die Verwendung des Statuscodes `308` anstelle von `301` ist, dass `308 Permanent Redirect` die HTTP-Methode (POST, PUT usw.) beibehält und somit in modernen Webumgebungen sicherer ist. ## Fazit {#sec-ad06e7ff5f93} Nur weil der Browser die Adresse ausblendet, sollte der Server nicht untätig bleiben. Wenn `www`- und `Apex`-Domains koexistieren und beide eine `200`-Antwort liefern, überprüfen Sie sofort Ihre Webserver-Einstellungen. Eine klare Weiterleitung auf eine der beiden Varianten ist die grundlegendste und wichtigste Aufgabe, um Suchmaschinen die Identität Ihrer Website eindeutig zu vermitteln.