www-Redirect: mit oder ohne www

Warum www und non-www einen Redirect brauchen

Technisch ist www.example.com eine Subdomain von example.com. Beide können auf unterschiedliche Server zeigen und unterschiedliche Inhalte ausliefern. Deshalb behandeln Suchmaschinen https://example.com/seite und https://www.example.com/seite als zwei getrennte URLs.

Antworten beide mit 200 OK, hast du folgende Probleme:

• Duplicate Content: Google muss raten, welche Version die kanonische ist. Meistens liegt es richtig – aber du gibst die Kontrolle ab.
• Verteilte Signale: Backlinks auf beide Varianten werden nur dann gebündelt, wenn Google sie korrekt zusammenfasst.
• Chaos in der Webanalyse: Sitzungen und Referrer verteilen sich auf zwei Hostnamen, und Cookies des einen Hosts fehlen auf dem anderen.

Ein permanenter 301- oder 308-Redirect vom nicht bevorzugten auf den bevorzugten Host räumt damit auf. Er vererbt PageRank und ist ein starkes Kanonisierungssignal.

Mit oder ohne www – was ist besser?

Für SEO ist es egal. Google bevorzugt keine der beiden Varianten. Wichtig ist nur, dass du dich festlegst und dabei bleibst. Ein paar technische Punkte können die Entscheidung trotzdem beeinflussen:

Aspekt	www.example.com	example.com
DNS	Kann ein CNAME sein, lässt sich also leicht auf ein CDN oder eine Hosting-Plattform zeigen	Die Apex-Domain kann kein normaler CNAME sein; nötig sind A/AAAA-Records oder anbieterspezifisches ALIAS/CNAME-Flattening
Cookies	Cookies bleiben auf www und landen nicht auf anderen Subdomains	Cookies mit Domain-Attribut gelten für alle Subdomains, etwa auch für static.example.com
Optik	Klassisch, im Druck sofort als Webadresse erkennbar	Kürzer und moderner

Hat deine Website schon Geschichte, bleib bei dem Host, den Google aktuell in den Suchergebnissen zeigt und auf den die meisten Backlinks verweisen. Ein Wechsel ohne triftigen Grund kostet dich nur eine Runde Recrawling.

Alle Signale einheitlich halten

Der Redirect ist das stärkste Signal, sollte aber nicht das einzige sein. Sagen deine Canonical-Tags „www“, während der Redirect auf die Variante ohne www schickt, sendest du widersprüchliche Signale – und Google wählt womöglich eine Canonical-URL, die du nicht wolltest.

• Canonical-Tags müssen den bevorzugten Host und HTTPS verwenden: <link rel="canonical" href="https://example.com/seite">.
• XML-Sitemaps enthalten nur finale URLs, die mit 200 antworten – niemals URLs, die weiterleiten.
• Interne Links, Navigation und hreflang-Angaben zeigen direkt auf den bevorzugten Host, damit kein interner Klick einen Redirect auslöst.
• CMS-Einstellungen wie die Website-Adresse in WordPress müssen zum bevorzugten Host passen. Sonst leiten CMS und Server sich gegenseitig hin und her, und am Ende steht eine Schleife.
• Search Console: Die alte Einstellung „Bevorzugte Domain“ gibt es nicht mehr. Leg eine Domain-Property an, die alle Hosts und Protokolle abdeckt, und überlass die Arbeit Redirects und Canonicals.

Snippets für den Redirect

Alle folgenden Beispiele kombinieren die Host-Vereinheitlichung mit HTTPS, sodass jede Variante die finale URL in einem Hop erreicht. Ersetz example.com durch deine Domain.

Apache: www auf ohne www

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Apache: ohne www auf www

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

Wird TLS an einem Proxy oder Load Balancer terminiert, ersetz %{HTTPS} off durch %{HTTP:X-Forwarded-Proto} !https. Weitere Beispiele findest du im .htaccess-Guide, und der .htaccess-Generator baut dir die Regeln zusammen.

nginx: www auf ohne www

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    root /var/www/example.com;
}

Für die umgekehrte Richtung tauschst du die Hostnamen: Der HTTP-Block und der HTTPS-Block für example.com liefern https://www.example.com$request_uri zurück, und der www-Block liefert die Inhalte aus. Getrennte Server-Blöcke mit return sind schneller und übersichtlicher als if ($host ...)-Bedingungen. Mehr dazu im nginx-Guide oder direkt per nginx-Generator.

Andere Plattformen

Auf gemanagten Plattformen stellst du das meist im Dashboard ein statt in einer Config-Datei. Bei Vercel und Netlify fügst du beide Domains hinzu und markierst eine als primär, die andere leitet die Plattform dann um (siehe Vercel und Netlify). Bei Cloudflare nutzt du eine Redirect Rule. In WordPress legt die Website-Adresse den bevorzugten Host fest, und WordPress leitet die andere Variante selbst um – vorausgesetzt, beide erreichen dieselbe Installation.

Bevorzugten Host bei einer bestehenden Website wechseln

Manchmal gibt es gute Gründe, die Seite zu wechseln – etwa weil die neue Hosting-Plattform nur einen CNAME auf www unterstützt. Behandle das wie einen kleinen Umzug:

1. Stell Canonical-Tags, interne Links, hreflang und die XML-Sitemap zuerst auf den neuen Host um, spätestens aber zeitgleich mit dem Redirect.
2. Dreh die Richtung des Redirects um. Prüf, dass keine alte Regel noch in die Gegenrichtung zeigt – sonst hast du eine Schleife.
3. Pass bestehende Redirects an anderer Stelle deiner Konfiguration an, deren Ziele noch den alten Host enthalten, damit daraus keine Ketten werden.
4. Lass den Redirect dauerhaft stehen. Links auf den bisherigen Host gibt es noch jahrelang.

Nutzt du in der Search Console eine Domain-Property, deckt sie beide Hosts ab. Deine Berichte laufen also ohne Unterbrechung weiter, während Google den Wechsel verarbeitet.

Typische Stolperfallen

• Fehlender DNS-Eintrag: Hat www gar keinen DNS-Record, kann der Redirect nie greifen. Beide Hosts müssen auf einen Server zeigen, der antwortet.
• Zertifikat nur für einen Host: Eine Anfrage an https://www.example.com scheitert mit einem Zertifikatsfehler, bevor überhaupt umgeleitet wird. Das Zertifikat braucht beide Namen, oder du nutzt zwei Zertifikate.
• Zwei getrennte Redirects: Eine Regel für HTTPS und eine zweite für www erzeugen bei manchen Varianten eine Redirect-Kette. Kombinier sie wie oben gezeigt.
• Pfad geht verloren: Leitest du alles auf die Startseite, statt $request_uri bzw. %{REQUEST_URI} mitzunehmen, werden Deeplinks zu Soft 404s.
• Temporäre Statuscodes: Ein 302 funktioniert zwar für Nutzer, ist aber nur ein schwaches Kanonisierungssignal. Nimm 301 oder 308.
• Mehrere Ebenen im Clinch: CDN, Server und CMS erzwingen jeweils einen anderen Host und schieben die Anfrage hin und her. Ein Klassiker für ERR_TOO_MANY_REDIRECTS.

Alle vier Varianten prüfen

Dein Setup stimmt, wenn alle vier Kombinationen auf derselben URL landen, jeweils mit höchstens einem Hop:

Anfrage	Erwartet (bevorzugt: https://example.com)
http://example.com/seite	301 → https://example.com/seite
http://www.example.com/seite	301 → https://example.com/seite
https://www.example.com/seite	301 → https://example.com/seite
https://example.com/seite	200 OK

Eine einzelne URL prüfst du im Redirect Checker. Alle vier Varianten plus einen Deeplink mit Query-String kippst du am besten in den Bulk-Checker. Stellst du gleichzeitig auf HTTPS um, lies auch HTTP auf HTTPS umleiten – dort geht es um HSTS und Mixed Content.