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

DNS und Such-Bots sehen 'www' sehr genau

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

$ 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

$ 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?

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

Viele Entwickler denken, dass es ausreicht, das <link rel="canonical" href="...">-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

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

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.)

# 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

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.