301-Weiterleitung prüfen: Ketten, Schleifen und der Weg zu HTTPS

Warum Weiterleitungen Aufmerksamkeit brauchen

Eine Weiterleitung ist eine Antwort mit Statuscode 3xx und einem Location-Header, und Browser wie Crawler rufen daraufhin die dort genannte URL auf. Einmal ist das harmlos. Auf vielen Websites passiert es aber drei- oder viermal hintereinander: http://beispiel.de leitet auf https://beispiel.de, das auf https://www.beispiel.de, das auf https://www.beispiel.de/ und das schließlich auf die Startseite mit Sprachpräfix. Jeder Hop ist ein eigener Roundtrip mit DNS-Auflösung, TLS-Handshake und Wartezeit.

Für Suchmaschinen kommt hinzu, dass Weiterleitungen Signale übertragen: Ein Link auf die alte URL soll für die neue zählen, eine gecrawlte URL soll den Index aktualisieren. Bei einer direkten 301-Weiterleitung funktioniert das zuverlässig. Bei einer langen Kette, einem falschen Statuscode oder einem Ziel, das selbst 404 liefert, geht dieser Zusammenhang verloren.

301, 302, 307 und 308: Welcher Statuscode wohin gehört

Der Statuscode sagt dem Client, ob die Verschiebung dauerhaft oder vorübergehend ist. Das entscheidet darüber, ob Google die neue URL in den Index übernimmt und ob Browser die Weiterleitung cachen.

• 301 Moved Permanently: dauerhaft. Suchmaschinen übernehmen die Ziel-URL in den Index und übertragen die Signale der alten URL. Der Standard für http zu https, www zu non-www und für den Domainumzug.
• 302 Found: vorübergehend. Die alte URL bleibt im Index, das Ziel wird nicht kanonisch. Richtig für Wartungsseiten oder eine saisonale Aktion, falsch für alles, was bleiben soll.
• 307 Temporary Redirect: wie 302, aber die HTTP-Methode bleibt erhalten, ein POST bleibt ein POST. Chrome zeigt außerdem den HSTS-Redirect, der nie den Server erreicht, in den Entwicklertools als internen 307 an.
• 308 Permanent Redirect: wie 301 mit erhaltener Methode. Sinnvoll für APIs, bei Websites mit reinen GET-Aufrufen ohne Unterschied zu 301.

Google behandelt 301 und 308 gleichwertig und wertet auch ein lange bestehendes 302 als dauerhaft. Verlassen solltest du dich darauf nicht: Wer eine Seite dauerhaft verschiebt, setzt 301. Viele Hoster-Panels und CMS-Plugins setzen standardmäßig 302, deshalb gehört der Statuscode in jede Prüfung.

Eine kanonische Variante: http, www und Trailing Slash

Jede Website ist unter mindestens vier Adressen erreichbar: mit und ohne https, mit und ohne www. Kommen Trailing Slash, Groß- und Kleinschreibung oder ein index.html dazu, sind es schnell acht Varianten derselben Seite. Genau eine davon ist die kanonische Adresse, alle anderen müssen mit einem einzigen 301 direkt auf sie zeigen.

Ob www oder nicht, ist eine Geschmacksfrage ohne SEO-Auswirkung. Wichtig ist nur, dass du dich festlegst, die Entscheidung in Sitemap, Canonical-Tags, internen Links und Search Console einheitlich abbildest und die andere Variante nicht ebenfalls mit 200 auslieferst. Zwei erreichbare Varianten bedeuten doppelte Inhalte und geteilte Signale. Beim Trailing Slash gilt dasselbe: /impressum und /impressum/ sind für Google zwei URLs.

Der Redirect von http auf https ist der einzige, der keine Wahl lässt. Er gehört auf jeden Hostnamen, den die Domain bedient, also auch auf www. Fehlt er dort, bleibt diese Variante unverschlüsselt erreichbar und HSTS greift nie.

Weiterleitungsketten und Schleifen

Eine Weiterleitungskette (Redirect Chain) entsteht, wenn das Ziel einer Weiterleitung selbst wieder weiterleitet. Typisch sind drei getrennt gepflegte Regeln: Der Hoster leitet http auf https, die Serverkonfiguration www auf non-www, und das CMS hängt den Trailing Slash an. Jede Regel ist für sich korrekt, zusammen ergeben sie drei Hops.

Googlebot folgt bis zu zehn Weiterleitungen in einer Kette und bricht danach ab; die Ziel-URL wird dann nicht gecrawlt und in der Search Console als Weiterleitungsfehler gemeldet. Schon vorher kostet jeder Hop Crawl-Budget, verzögert die Indexierung neuer Inhalte und schwächt die Zuordnung von Links zur Zielseite.

Die Regel ist deshalb einfach: Jede Weiterleitung zeigt direkt auf die endgültige URL. Wurde eine Seite von /alt auf /neu und später auf /neuer verschoben, änderst du die erste Regel auf /neuer, statt die zweite dranzuhängen. Beim Kanonisieren fasst du http, www und Trailing Slash in eine Regel zusammen. Eine Ausnahme ist die HSTS-Preload-Liste: Sie verlangt, dass http://beispiel.de zuerst auf https://beispiel.de zeigt. Ist www deine kanonische Variante, sind dort zwei Hops unvermeidbar, mehr aber nicht.

Eine Weiterleitungsschleife (Redirect Loop) ist der Sonderfall, bei dem die Kette zu ihrem Anfang zurückkehrt. Klassisch ist ein CMS, das auf https umleitet, hinter einem Proxy oder CDN, das per http mit dem Server spricht: Das CMS sieht immer http, leitet um, der Proxy liefert wieder http, endlos. Browser zeigen ERR_TOO_MANY_REDIRECTS, die Seite ist unerreichbar. Die Lösung ist, den Header X-Forwarded-Proto des Proxys auszuwerten oder den Redirect nur am Proxy zu machen.

Weiterleitung beim Domainumzug

Beim Wechsel der Domain ist die Weiterleitung das wichtigste Werkzeug, um Rankings zu behalten. Entscheidend ist, dass jede alte URL per 301 auf ihre genaue Entsprechung auf der neuen Domain zeigt, nicht alles pauschal auf die neue Startseite. Google wertet eine Massenweiterleitung auf die Startseite als Soft 404, und die Signale der Unterseiten gehen verloren.

1. Alle URLs der alten Domain aus Sitemap, Serverlogs und Search Console sammeln.
2. Für jede URL das Ziel auf der neuen Domain festlegen. Bleibt die Struktur gleich, reicht eine Regel mit $request_uri, sonst brauchst du eine Zuordnungstabelle.
3. Bestehende Ketten auf der alten Domain auflösen, dann die alte Domain per 301 in einem Hop auf die neue leiten.
4. Das Zertifikat der alten Domain verlängern, solange die Weiterleitung läuft. Ein 301 über https funktioniert nur mit gültigem Zertifikat.
5. In der Search Console die Adressänderung melden und die alte Domain mindestens ein Jahr, besser dauerhaft, weiterleiten lassen.

# nginx: alte Domain 1:1 auf die neue leiten
server {
    listen 80;
    listen 443 ssl;
    server_name alte-domain.de www.alte-domain.de;
    ssl_certificate     /etc/letsencrypt/live/alte-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/alte-domain.de/privkey.pem;
    return 301 https://neue-domain.de$request_uri;
}

Konfiguration für nginx, Apache und Caddy

Die Beispiele leiten http und www in einem einzigen Schritt auf https://beispiel.de und behalten dabei Pfad und Query-String. Bei nginx gehört der Redirect in einen eigenen server-Block, nicht als if-Konstrukt in den Hauptblock. Bei Apache liegt die Regel in der .htaccess oder besser direkt im VirtualHost. Caddy leitet http automatisch auf https, du musst nur die www-Variante kanonisieren.

# nginx: http (beide Hosts) und https://www in einem Hop auf https://beispiel.de
server {
    listen 80;
    listen [::]:80;
    server_name beispiel.de www.beispiel.de;
    return 301 https://beispiel.de$request_uri;
}

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

# Apache (.htaccess oder VirtualHost, mod_rewrite)
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://beispiel.de%{REQUEST_URI} [R=301,L]

# Caddy (Caddyfile), http zu https uebernimmt Caddy selbst
www.beispiel.de {
    redir https://beispiel.de{uri} permanent
}

beispiel.de {
    root * /var/www/beispiel
    file_server
}

Der HTTPS-Block für www.beispiel.de braucht ein Zertifikat, das www abdeckt, sonst sehen Besucher eine Zertifikatswarnung, bevor der Redirect greift. Bei Apache prüft %{HTTPS} off hinter einem Proxy nicht das, was du erwartest; dort ersetzt du die Bedingung durch %{HTTP:X-Forwarded-Proto} !https.

Typische Fehler

Die meisten Probleme entstehen nicht durch eine falsche Regel, sondern durch mehrere richtige Regeln an verschiedenen Stellen: beim Hoster, im Webserver, im CMS und im CDN. Diese Muster tauchen bei fast jeder Prüfung auf.

• Kette aus http, https, www und Trailing Slash: drei oder vier Hops, weil jede Regel woanders gepflegt wird. Regeln an einer Stelle zusammenfassen.
• Schleife durch Proxy oder CDN: Der Server sieht nur http und leitet endlos um. X-Forwarded-Proto auswerten oder den Redirect an den Proxy verlagern.
• Weiterleitung auf 404: Die Regel zeigt auf eine URL, die es nicht mehr gibt. Für Google ist das eine gelöschte Seite, die Signale der alten URL verfallen.
• 302 statt 301 für dauerhafte Änderungen: Die alte URL bleibt im Index, die neue wird nicht kanonisch.
• Gemischte Groß- und Kleinschreibung: /Impressum und /impressum sind auf Linux-Servern verschiedene Ressourcen und für Google zwei URLs. Intern einheitlich klein verlinken und per Regel normalisieren.
• Weiterleitung per Meta-Refresh oder JavaScript: Google behandelt beides nicht als sauberes 301, und Crawler ohne JavaScript sehen gar keine Weiterleitung. Immer serverseitig umleiten.
• Pfad oder Query-String geht verloren: Die Regel leitet ohne $request_uri auf die nackte Domain, und jeder Deep Link landet auf der Startseite.

Weiterleitungen prüfen: Redirect Checker und curl

Der Browser ist zum Prüfen ungeeignet: Er folgt der Kette so schnell, dass du nur das Ergebnis siehst, er cached 301-Antworten und blendet den HSTS-Redirect als internen 307 ein. Mit curl siehst du jeden Hop einzeln:

curl -sIL http://www.beispiel.de/impressum | grep -iE '^(HTTP|location)'

Der Redirect Checker von DomainWarn macht dasselbe ohne Terminal: Er zeigt die vollständige Kette mit dem Statuscode jedes Hops, der Ziel-URL und der Anzahl der Hops und markiert Ketten, Schleifen und Ziele, die nicht mit 200 antworten. Prüfe damit jede Einstiegsvariante: http und https, mit und ohne www, mit und ohne Trailing Slash, und mindestens eine tiefe URL mit Query-String.

Wiederhole die Prüfung nach jedem Hosterwechsel, jedem CMS-Update und jeder Änderung an CDN oder Proxy. Genau dort entstehen neue Hops, ohne dass jemand sie bewusst einbaut.

Häufige Fragen

Wie viele Weiterleitungen sind noch in Ordnung?

Eine. Jede Einstiegs-URL sollte mit genau einem 301 auf der kanonischen Adresse landen. Zwei Hops sind vertretbar, wenn die HSTS-Preload-Liste den Redirect auf denselben Host verlangt. Alles darüber ist eine Kette, die du kürzen solltest, auch wenn Google technisch bis zu zehn Hops folgt.

Verliere ich mit einem 301 Linkkraft?

Google hat 2016 erklärt, dass Weiterleitungen keinen PageRank mehr verlieren. In der Praxis ist eine direkte Weiterleitung auf eine thematisch passende Seite trotzdem die einzige Variante, bei der Rankings zuverlässig übergehen. Ketten, Weiterleitungen auf die Startseite und Weiterleitungen auf 404 verlieren Signale, egal was der Statuscode sagt.

Wie lange muss ich die Weiterleitung nach einem Domainumzug behalten?

Mindestens ein Jahr, damit Google alle Signale überträgt und du Backlinks umstellen kannst. Besser dauerhaft: Alte Links in Foren, Verzeichnissen und E-Mails funktionieren sonst irgendwann nicht mehr, und eine aufgegebene Domain kann nach Ablauf von Dritten registriert werden.