301-Weiterleitungen: Wann man sie einsetzt, wie man sie einrichtet und wie man sie prüft

Kurz gesagt: Eine 301-Weiterleitung teilt Browsern und Suchmaschinen mit, dass eine URL dauerhaft umgezogen ist. Google behandelt 301 und 308 als starkes Signal, dass das Ziel die kanonische URL sein soll; 302 und 307 sind temporär und lassen die alte URL bestehen. Jede Website sollte nur unter einer Adresse antworten: http://, https://, www und non-www müssen alle in einem einzigen Schritt auf dieselbe finale URL weiterleiten. Behalte Weiterleitungen mindestens ein Jahr bei, aktualisiere interne Links auf die finale Adresse und prüfe die gesamte Kette, nicht nur das Ziel.

Funktionieren Weiterleitungen, sieht man sie nicht. Tun sie es nicht, sind die Symptome diffus: Rankings verteilen sich auf www und non-www, eine Migration kostet monatelang Traffic, eine Startseite lädt eine Sekunde länger, weil sie über drei Adressen springt. Die meisten dieser Probleme findest du in einer Minute, indem du jede Version deiner Adresse bis zum Ende verfolgst.

Dieser Leitfaden behandelt die Weiterleitungstypen und wie Google sie behandelt, die Host-Versionen, die jede Website zusammenführen muss, Ketten und Schleifen, die Einrichtung auf gängigen Servern, die Funktionsweise unseres kostenlosen Redirect-Checkers und die Behebung jedes gemeldeten Problems.

Was eine Weiterleitung ist

Eine Weiterleitung ist eine Antwort, die sagt „diese Ressource liegt woanders“ und die neue Adresse in einem Location-Header nennt. Der Browser ruft die neue Adresse automatisch auf. Eine serverseitige Weiterleitung sieht auf der Leitung so aus:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

Der Statuscode sagt Clients, wie sie den Umzug behandeln sollen. MDN unterscheidet dauerhafte Weiterleitungen, nach denen Crawler „die ursprüngliche URL aktualisieren“, und temporäre, die Crawler „nicht speichern“.

Die Weiterleitungsdokumentation von Google stuft außerdem einen sofortigen meta refresh (0 Sekunden) und einen JavaScript-location-Wechsel als dauerhaft ein, einen verzögerten Meta-Refresh als temporär. Google empfiehlt, wann immer möglich serverseitige dauerhafte Weiterleitungen zu verwenden, und sagt, man solle „JavaScript-Weiterleitungen nur verwenden, wenn serverseitige oder Meta-Refresh-Weiterleitungen nicht möglich sind“, weil das Rendering fehlschlagen kann.

Warum Weiterleitungen für SEO wichtig sind

Sie bündeln Duplikate. Googles Leitfaden zur Kanonisierung nennt Weiterleitungen „ein starkes Signal, dass das Weiterleitungsziel kanonisch werden soll“. Ohne sie können sich Signale wie Links auf mehrere URLs für denselben Inhalt verteilen.

Sie tragen umgezogene Seiten durch eine Migration. Ändern sich URLs, sagt eine 301 von jeder alten URL auf ihr neues Pendant Google, dass es sie im Index austauschen soll, und leitet Besucher alter Links auf die richtige Seite.

Sie schützen HTTPS. Google „bevorzugt HTTPS-Seiten gegenüber gleichwertigen HTTP-Seiten als kanonisch“, und derselbe Leitfaden nennt eine Weiterleitung von HTTP auf HTTPS als eine Möglichkeit, das zu verstärken.

Sie kosten Zeit. Jeder Hop ist ein weiterer Roundtrip, bevor die Seite zu laden beginnt. In mobilen Netzen ist eine Kette aus drei Weiterleitungen eine spürbare Verzögerung, bevor etwas erscheint.

Eine Website, eine Adresse

Für einen Crawler sind dies vier verschiedene Websites, auch wenn sie dieselbe Seite zeigen:

http://example.com/
http://www.example.com/
https://example.com/
https://www.example.com/

Wähle eine aus, meist die HTTPS-Version mit oder ohne www, und lass die anderen drei mit einer einzigen 301 direkt darauf antworten. Ob mit oder ohne www, ist Geschmackssache; entscheidend ist, dass nur eine Version mit 200 antwortet. Stelle außerdem sicher, dass das TLS-Zertifikat sowohl example.com als auch www.example.com abdeckt, sonst schlägt die Weiterleitung von https://www fehl, bevor sie greifen kann.

Dieselbe Regel gilt innerhalb der Website: Antworten /pricing und /pricing/ beide mit 200, wähle eine Form und leite die andere weiter.

Ketten und Schleifen

Eine Kette ist eine Weiterleitung, die zu einer weiteren Weiterleitung führt. Am häufigsten werden Protokoll und Host in getrennten Schritten behandelt:

http://www.example.com/  301 →  https://www.example.com/  301 →  https://example.com/

Googles Crawler „folgen bis zu 10 Weiterleitungs-Hops“ (HTTP status codes and Google Search), eine Kette mit zwei Hops verliert die Seite also nicht. Aber Googles Leitfaden zum Website-Umzug sagt, man solle „Weiterleitungsketten vermeiden“ und „direkt zum endgültigen Ziel“ weiterleiten; ist das nicht möglich, sollen Ketten kurz bleiben, „idealerweise nicht mehr als 3 und weniger als 5“. Besucher zahlen in jedem Fall für jeden Hop.

Eine Schleife ist eine Kette, die nie endet: A leitet auf B und B zurück auf A, oft weil sich eine HTTPS-Regel auf dem Server und eine andere im CDN widersprechen. MDN weist darauf hin, dass Browser Schleifen erkennen und einen Fehler anzeigen, die Seite ist dann schlicht nicht erreichbar.

So richtest du eine 301-Weiterleitung ein

Apache (.htaccess oder Virtual Host), alle Versionen auf https://www.example.com zusammenführen:

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

Für eine einzelne Seite genügt Redirect 301 /old-page https://www.example.com/new-page. Beachte: Ein Redirect ohne Code sendet laut MDN standardmäßig eine 302.

Nginx, mit einem Server-Block, der jede andere Version abfängt:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate lines here for the 443 listener
    if ($host = example.com) { return 301 https://www.example.com$request_uri; }
    if ($scheme = http)      { return 301 https://www.example.com$request_uri; }
    # ... the site itself
}

Viele Setups nutzen stattdessen getrennte Server-Blöcke; beides funktioniert, solange jede Version in einem Schritt die finale Adresse erreicht.

Next.js, in next.config.js:

module.exports = {
  async redirects() {
    return [
      { source: '/old-blog/:slug', destination: '/blog/:slug', permanent: true },
    ]
  },
}

Laut Next.js-Dokumentation sendet permanent: true eine 308 und permanent: false eine 307, um die Anfragemethode zu erhalten. Google behandelt 308 als dauerhaft, das passt also.

CDNs und Hoster. Die meisten CDNs und Hosting-Panels bieten Weiterleitungsregeln und einen Schalter „Immer HTTPS verwenden“. Nutze für jede Aufgabe eine Ebene: Stellt das CDN HTTP auf HTTPS um und leitet der Origin-Server zusätzlich Hosts weiter, entsteht eine Kette mit zwei Hops, oder eine Schleife, wenn beide sich widersprechen.

WordPress. Die Website-Adresse unter Einstellungen › Allgemein legt den kanonischen Host fest; WordPress leitet andere Hosts darauf weiter. Für Weiterleitungen einzelner Seiten nutze ein Redirect-Plugin oder den Redirect-Manager deines SEO-Plugins und bevorzuge für die Host-Zusammenführung Serverregeln.

Wie der Searvia Redirect-Checker funktioniert

Der Redirect-Checker nutzt dieselbe Engine wie unser Website-SEO-Checker: Gib eine Domain ein, und er prüft deine Startseite und die Dateien drumherum mit 38 Checks in etwa 20 Sekunden und zeigt zuerst die drei Checks, um die es bei diesem Tool geht. Das leisten sie.

Weiterleitungen und doppelte Versionen (mittlere Priorität). Der Checker nimmt die eingegebene Domain, entfernt www. und öffnet vier Adressen: http:// und https://, jeweils mit und ohne www. Er folgt jeder bis zu sechs Weiterleitungen und erfasst, wo sie endet und welchen Statuscode jeder Hop hat. Eine Version besteht, wenn sie mit ausschließlich dauerhaften Weiterleitungen (301 oder 308) auf demselben Schema und Host endet wie die finale Adresse deiner Startseite. Das Ergebnis:

• Fehler, wenn eine Version woanders endet, zum Beispiel https://example.com mit einer eigenen Seite antwortet, während https://www.example.com deine Hauptseite ist, oder wenn eine Version in einer Weiterleitungsschleife endet oder mehr als sechs Weiterleitungen braucht.
• Warnung, wenn eine Version eine temporäre Weiterleitung (302, 303 oder 307) nutzt oder die eingegebene Adresse mehr als einen Weiterleitungs-Hop braucht, gezählt ab https:// plus dem eingegebenen Host, bevor sie antwortet.
• Bestanden, wenn jede Version mit dauerhaften Weiterleitungen auf derselben Website landet und die Hauptadresse einen Hop oder keinen braucht.

Der Bericht listet jede der vier Versionen mit ihrer finalen URL, den Weiterleitungscodes unterwegs (zum Beispiel 301 › 301) und einem Haken oder Kreuz auf. Versionen, die sich nicht auflösen lassen oder nicht erreichbar sind, etwa ein www-Host ohne DNS-Eintrag, werden ausgelassen statt als Fehler gewertet.

HTTPS (hohe Priorität). Er ruft http:// plus deinen Host ab, ohne Weiterleitungen zu folgen. Er besteht, wenn die Website über HTTPS funktioniert und die HTTP-Anfrage mit einem 3xx antwortet, dessen Location mit https:// beginnt. Er schlägt fehl mit „HTTP does not redirect to HTTPS“ oder „The site does not work over HTTPS“. Antwortet reines HTTP gar nicht, lässt sich die Weiterleitung nicht testen, und der Check zeigt einen Hinweis statt Bestanden oder Fehler.

Seitenstatus (hohe Priorität). Die finale Seite muss mit einem 2xx-Status antworten. Ein 4xx oder 5xx schlägt fehl.

Was nicht geprüft wird

• Meta-Refresh- und JavaScript-Weiterleitungen. Es werden nur HTTP-Weiterleitungen verfolgt. Eine Version, die per Meta-Tag weiterleitet, erscheint als auf sich selbst endend.
• Unterseiten. Nur Adressen der Startseite werden getestet. Für Weiterleitungen einzelner Seiten nach einer Migration crawlst du die Liste der alten URLs.
• Hop-Anzahl pro Version. Die Hop-Warnung zählt nur die Hops deiner Hauptadresse; eine dauerhafte Kette mit zwei Hops bei http://www zeigt ihre Codes in der Tabelle (301 › 301), senkt das Ergebnis aber nicht. Nutze curl, um die URL jedes Hops zu sehen.

So siehst du jeden Hop mit URL und Code:

curl -sIL http://www.example.com/ | grep -iE '^(HTTP|location)'

Das Ergebnis lesen

Die Gesamtnote umfasst alle 38 Checks, gewichtet nach Priorität (hoch 10, mittel 5, niedrig 2; eine Warnung zählt halb), mit einer Liste „Fix these first“ und einem teilbaren Berichtslink.

So behebst du jedes vom Checker gemeldete Problem

1. Manche Versionen leiten nicht auf die Hauptversion weiter

1. Lege die finale Adresse fest: https://www.example.com oder https://example.com.
2. Notiere in der Tabelle des Berichts, welche Versionen auf der falschen URL enden.
3. Richte für jede eine 301 direkt auf die finale Adresse ein und behalte den Pfad bei ($request_uri in Nginx, $1 in Apache).
4. Endet die abweichende Version auf einem ganz anderen Host, prüfe das DNS: Ein alter A-Record für www kann auf eine Parking-Seite oder einen früheren Host zeigen.
5. Stelle sicher, dass auch Canonical-Tags, Sitemap und interne Links die finale Adresse verwenden; eine Weiterleitung, die deinem Canonical widerspricht, sendet widersprüchliche Signale.
6. Starte den Redirect-Checker erneut.

2. Die Adresse durchläuft mehrere Weiterleitungen

1. Führe den Befehl curl -sIL für die eingegebene Adresse aus und lies die Kette.
2. Fasse die Schritte zusammen: eine Regel, die jede nicht finale Version direkt auf die finale URL schickt, wie in den Apache- und Nginx-Beispielen oben.
3. Leiten CDN und Origin beide weiter, lass nur eines von beiden das tun. Typischerweise übernimmt das CDN HTTP auf HTTPS und der Origin nichts, oder der Origin macht beides und das CDN reicht Anfragen durch.
4. Aktualisiere Links, die du kontrollierst: Logo-Link, Navigation, E-Mail-Signaturen, Social-Profile und Anzeigenziele sollten auf die finale Adresse zeigen.

3. HTTP leitet nicht auf HTTPS weiter

1. Bestätige, dass HTTPS mit einem gültigen Zertifikat funktioniert, das sowohl die nackte Domain als auch www abdeckt.
2. Richte eine dauerhafte Weiterleitung von jeder http://-URL auf ihr https://-Pendant ein und behalte den Pfad bei.
3. Sobald alles über HTTPS läuft, erwäge HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains), damit Browser die HTTP-Anfrage ganz überspringen. Google nennt HSTS als weitere Möglichkeit, HTTPS als kanonisch zu verstärken. Der Security-Headers-Checker testet es.

4. Die Website funktioniert nicht über HTTPS

Installiere ein Zertifikat (Let's Encrypt ist kostenlos, und die meisten Hoster automatisieren es), stelle sicher, dass es jeden verwendeten Hostnamen abdeckt, und richte dann die HTTP-auf-HTTPS-Weiterleitung aus Schritt 3 ein. Als Nächstes räumst du Mixed Content auf, also Skripte oder Bilder, die noch über http:// geladen werden.

5. Die Startseite antwortet nicht mit 200

Ein 5xx bedeutet ein Serverproblem; prüfe die Fehlerprotokolle. Ein 403 bedeutet oft, dass eine Firewall oder ein Bot-Schutz automatisierte Anfragen ablehnt, womöglich auch Suchmaschinen-Crawler. Ein 404 auf der Startseite heißt meist, dass eine Weiterleitung Besucher auf einen nicht mehr existierenden Pfad schickt. Korrigiere das Ziel und prüfe erneut.

6. Temporäre Weiterleitungen, Schleifen oder lange Ketten

1. Suche die Zeile mit dem Kreuz und lies ihre Codes. Ein 302, 303 oder 307 zwischen Host-Versionen sollte zu einer 301 oder 308 werden; prüfe Server, CDN und Plugins, denn die temporäre Variante ist oft ein Standardwert (ein einfaches Apache-Redirect sendet eine 302).
2. Eine Schleife bedeutet meist, dass sich zwei Ebenen widersprechen, etwa ein CDN, das HTTPS auf HTTP schickt, während der Origin HTTP auf HTTPS schickt. Schalte eine davon ab.
3. Ersetze eine Kette mit mehr als sechs Hops durch eine Regel, die direkt auf die finale Adresse geht, wie in Schritt 2.

Weiterleitungen bei einer Migration

Ändern sich URLs, sind die oben genannten Regeln auf Host-Ebene nur der Anfang. Googles Hinweise zum Website-Umzug ergänzen:

1. Ordne jede alte URL ihrem neuen Pendant zu, anhand von Sitemaps, Server-Logs, Analytics und deinem CMS. Alles auf die Startseite weiterzuleiten, ist kein Mapping.
2. Leite direkt zum endgültigen Ziel weiter, nie auf eine URL, die ihrerseits weiterleitet.
3. Gib jeder neuen URL ein selbstreferenzierendes Canonical, aktualisiere interne Links und stelle sicher, dass jede Sitemap die neuen URLs auflistet.
4. Behalte die Weiterleitungen so lange wie möglich bei, im Allgemeinen mindestens ein Jahr.

Für internationale Websites gilt eine weitere Regel von Google: Leite Besucher nicht automatisch anhand von Standort oder Browsersprache zwischen Sprachversionen um, denn „der Googlebot-Crawler stammt üblicherweise aus den USA“ und sieht die anderen Versionen womöglich nie (mehrregionale Websites). Unser hreflang-Leitfaden behandelt die Alternative.

Praxisbeispiel (hypothetisch)

Das Folgende ist ein hypothetisches Beispiel, keine echten Daten. Bramble & Co, ein erfundener Möbelshop, ist auf eine neue Plattform umgezogen. Der Redirect-Checker meldet:

Die nackte Domain mit https:// antwortete mit der vollständigen Website statt weiterzuleiten: Die neue Plattform bediente beide Hosts, und nur der alte Server hatte die Host-Regel. Die Codes zeigten außerdem, dass http://bramble.example/ zwei Hops brauchte und der erste eine 302 war. Das Team richtete im CDN eine einzige 301-Regel für jede nicht finale Version ein, entfernte die eigene HTTPS-Weiterleitung der Plattform, um eine Kette zu vermeiden, und startete den Check erneut: Alle vier Versionen enden nun in einem Hop auf https://www.bramble.example/.

Eine Redirect-Checkliste für 15 Minuten

1. Führe den kostenlosen Redirect-Checker für deine Domain aus.
2. Bestätige, dass alle vier Versionen auf einer Adresse enden.
3. Prüfe die Codes jeder Version im Bericht (oder mit curl -sIL): ein Hop, Status 301 oder 308.
4. Prüfe, ob Canonicals, Sitemap und interne Links die finale Adresse verwenden.
5. Stelle sicher, dass das Zertifikat sowohl die nackte Domain als auch www abdeckt.
6. Teste nach einer Migration eine Stichprobe alter URLs und behalte die Weiterleitungen mindestens ein Jahr bei.

So hilft dir Searvia

Der kostenlose Redirect-Checker folgt jeder Version deiner Adresse und prüft HTTPS und den Status der Startseite in einem teilbaren Bericht. In einem Searvia-Account crawlt das Site-Audit die gesamte Website jede Woche und markiert interne Links, die auf Weiterleitungen zeigen, weitergeleitete oder defekte URLs in der Sitemap und Seiten, die Fehler liefern, damit du überall direkt auf finale Adressen verlinken kannst. Das Uptime-Monitoring überwacht deine Website rund um die Uhr und warnt dich, wenn sie ausfällt oder ihr Zertifikat bald abläuft, also dann, wenn HTTPS-Weiterleitungen am häufigsten brechen. Die vollständige Reihenfolge technischer Prüfungen findest du in unserem Leitfaden zum technischen SEO-Audit.