Zum Inhalt springen

Redirect Checker: Weiterleitungen und Statuscodes prüfen.

Weiterleitungen zu prüfen kann knifflig sein. Gib eine URL ein und sieh jeden Hop, seinen Statuscode und wo die Kette endet.

Beispiele: github.com, http://www.wikipedia.org, apple.com/de

Ergebnis: 2 Weiterleitung(en)

  1. 301

    http://apple.com/de

    Weiterleitung · 10 ms

    Response-Header
    Date:
    Mon, 28 Sep 2026 22:32:47 GMT
    Connection:
    close
    Via:
    http/1.1 ussea4-edge-fx-011.ts.apple.com (acdn/331.16659)
    Cache-Control:
    no-store
    Location:
    https://www.apple.com/de
    Content-Type:
    text/html
    Content-Language:
    en
    X-Cache:
    none
    CDNUUID:
    bd31ba90-88fd-444b-8456-4a5dc6625283-51582175801
    Content-Length:
    306
  2. 301

    https://www.apple.com/de

    Weiterleitung · 151 ms

    Response-Header
    server:
    Apple
    content-type:
    text/html; charset=iso-8859-1
    content-length:
    232
    location:
    https://www.apple.com/de/
    strict-transport-security:
    max-age=31536000; includeSubdomains; preload
    x-frame-options:
    SAMEORIGIN
    x-content-type-options:
    nosniff
    x-xss-protection:
    1; mode=block
    referrer-policy:
    no-referrer-when-downgrade
    content-security-policy:
    default-src 'self' blob: data: *.akamaized.net *.apple.com *.apple-mapkit.com *.cdn-apple.com *.organicfruitapps.com; child-src blob: mailto: embed.music.apple.com embed.podcasts.apple.com https://recyclingprogram.apple.com https://smb.apple.com https://nova.apple.com swdlp.apple.com www.apple.com www.instagram.com platform.twitter.com www.youtube-nocookie.com; img-src 'unsafe-inline' blob: data: *.apple.com *.apple-mapkit.com *.cdn-apple.com *.mzstatic.com; script-src 'unsafe-inline' 'unsafe-eval' blob: *.apple.com *.apple-mapkit.com www.instagram.com platform.twitter.com; style-src 'unsafe-inline' *.apple.com
    cache-control:
    max-age=600
    expires:
    Mon, 28 Sep 2026 22:42:47 GMT
    date:
    Mon, 28 Sep 2026 22:32:47 GMT
    set-cookie:
    geo=US; path=/; domain=.apple.com
  3. 200

    https://www.apple.com/de/

    Finale URL · 137 ms

    Response-Header
    server:
    Apple
    content-type:
    text/html; charset=utf-8
    set-cookie:
    geo=US; path=/; domain=.apple.com
    x-frame-options:
    SAMEORIGIN
    vary:
    Accept-Encoding
    content-security-policy:
    default-src 'self' blob: data: *.akamaized.net *.apple.com *.apple-mapkit.com *.cdn-apple.com *.organicfruitapps.com; child-src blob: mailto: embed.music.apple.com embed.podcasts.apple.com https://recyclingprogram.apple.com https://smb.apple.com https://nova.apple.com swdlp.apple.com www.apple.com www.instagram.com platform.twitter.com www.youtube-nocookie.com; img-src 'unsafe-inline' blob: data: *.apple.com *.apple-mapkit.com *.cdn-apple.com *.mzstatic.com; script-src 'unsafe-inline' 'unsafe-eval' blob: *.apple.com *.apple-mapkit.com www.instagram.com platform.twitter.com; style-src 'unsafe-inline' *.apple.com
    referrer-policy:
    no-referrer-when-downgrade
    strict-transport-security:
    max-age=31536000; includeSubdomains; preload
    x-content-type-options:
    nosniff
    x-xss-protection:
    1; mode=block
    content-encoding:
    gzip
    cache-control:
    max-age=14
    expires:
    Mon, 28 Sep 2026 22:33:01 GMT
    date:
    Mon, 28 Sep 2026 22:32:47 GMT
    content-length:
    40728
  • 2 Weiterleitungen hintereinander. Leite direkt auf die finale URL weiter, das spart Ladezeit und Crawl-Budget.

So liest du das Ergebnis

Der Checker ruft deine URL so auf, wie es ein Browser oder Crawler tun würde – folgt Weiterleitungen aber nicht stillschweigend. Jede Antwort wird festgehalten, sodass du den kompletten Weg von der ersten Anfrage bis zur Seite siehst, die am Ende tatsächlich lädt.

Eine Zeile pro Hop

Jede Anfrage in der Kette steht in einer eigenen Zeile, einem sogenannten Hop. Pro Zeile siehst du:

  • Den Statuscode in einem farbigen Badge. Gelb steht für eine Weiterleitung (3xx, etwa 301, 302, 307, 308), Grün für Erfolg (2xx, meist 200) und Rot für einen Fehler (4xx oder 5xx) oder eine Anfrage, die komplett gescheitert ist, zum Beispiel wegen eines DNS- oder TLS-Problems.
  • Die URL, die in diesem Schritt aufgerufen wurde.
  • Die Art des Hops: „Weiterleitung“ für einen HTTP-Redirect mit Location-Header, „Meta-Refresh-Weiterleitung“, wenn die Seite per HTML-Tag <meta http-equiv="refresh"> weiterleitet, und „Finale URL“ für die letzte Station.
  • Die Antwortzeit in Millisekunden. Jeder Hop kostet einen eigenen Round Trip – deshalb machen lange Ketten Seiten spürbar langsamer, besonders im Mobilfunknetz.

Ein gesundes Ergebnis ist kurz: im Idealfall eine gelbe Zeile mit 301 oder 308 und danach eine grüne Zeile mit 200 auf einer https://-URL.

Hinweise unter der Kette

Unter den Zeilen weist dich der Checker auf Probleme hin, die er gefunden hat:

  • Redirect-Kette: mehrere Weiterleitungen hintereinander. Leite die erste URL direkt auf die finale um, siehe Redirect-Ketten.
  • Temporäre Weiterleitung: ein 302 oder 307, wo ein dauerhafter Umzug eigentlich 301 oder 308 braucht, siehe 301 vs. 302.
  • Meta Refresh: eine Weiterleitung im HTML statt auf dem Server. Ein serverseitiger Redirect ist schneller und zuverlässiger, siehe Meta Refresh.
  • Fehlerseite: Die Kette endet auf einem 4xx- oder 5xx-Status.
  • Kein HTTPS: Die finale URL wird über unverschlüsseltes HTTP ausgeliefert, siehe HTTP auf HTTPS weiterleiten.
  • Kein HSTS: Die finale URL sendet keinen Strict-Transport-Security-Header. Browser schicken die erste Anfrage dann weiterhin über HTTP.

User-Agent

Manche Websites leiten je nach Besucher unterschiedlich weiter: Smartphones auf eine m.-Subdomain, Bots auf eine andere Version oder Desktop-Browser auf eine Sprachseite. Wähl Standard, Chrome (Desktop), Safari (iPhone) oder Googlebot, um die Kette aus Sicht dieses Clients zu sehen. Unterscheiden sich die Ergebnisse, hat deine Website geräte- oder botspezifische Weiterleitungen – dann solltest du sicherstellen, dass der Googlebot auf denselben Inhalten landet wie deine Besucher.

Response-Header, Hop-Limit und Schleifen

Klapp eine Zeile auf, um alle Response-Header dieses Hops zu sehen, etwa Location, Cache-Control, Server oder Strict-Transport-Security. So findest du heraus, welche Ebene eine Weiterleitung auslöst, zum Beispiel ein CDN oder die Anwendung selbst. Für einen genaueren Blick auf die Header gibt es den HTTP-Header-Checker.

Der Checker folgt höchstens 10 Hops – so vielen wie auch der Googlebot. Taucht eine URL in der Kette ein zweites Mal auf, bricht er ab und meldet eine Redirect-Schleife. Willst du viele URLs auf einmal prüfen, etwa nach einem Umzug, nimm den Bulk-Redirect-Checker.

Weitere kostenlose Tools

  • Bulk-Checker

    Prüfe bis zu 20 URLs auf einmal, z. B. deine Redirect-Map nach einem Domain-Umzug. Mit CSV-Export.

  • Header-Checker

    Alle HTTP-Response-Header jedes Hops, inklusive Location, Cache-Control und HSTS.

  • .htaccess-Redirect-Generator

    Erzeuge .htaccess-Regeln für einzelne Seiten, HTTPS- und www-Weiterleitungen.

  • nginx-Redirect-Generator

    Erzeuge nginx-Server-Blöcke und return-Regeln für deine Weiterleitungen.

  • HTTP-Statuscodes

    Alle HTTP-Statuscodes erklärt, mit Hinweisen, wie Google sie behandelt.

  • JSON-API

    Prüfe Weiterleitungen aus Skripten und CI-Pipelines mit einer einfachen JSON-API.

Ratgeber zu Weiterleitungen

Statuscodes

  • 301 vs. 302 Weiterleitung

    Ein 301 sagt „diese URL ist dauerhaft umgezogen“, ein 302 sagt „schau vorübergehend dort nach“. Klingt nach einem kleinen Unterschied, entscheidet aber darüber, welche URL Google indexiert, wie lange Browser sich den Redirect merken und wie leicht du ihn wieder loswirst.

  • 307 vs. 308 Weiterleitung

    307 und 308 sind die strengen Geschwister von 302 und 301: Sie garantieren, dass ein POST ein POST bleibt. Hier erfährst du, was das in der Praxis bedeutet, warum du oft einen 307 siehst, den dein Server nie geschickt hat, und wann ein 308 die bessere permanente Weiterleitung ist.

  • 301-Weiterleitung

    Eine 301-Weiterleitung schickt Besucher und Suchmaschinen dauerhaft von einer alten zu einer neuen URL. Sie ist das Standardwerkzeug bei Relaunch, Domainumzug und geänderten URLs. Hier erfährst du, wie sie funktioniert, wie du sie einrichtest und welche Klassiker du vermeiden solltest.

  • Meta-Refresh- und JavaScript-Weiterleitung

    Nicht jede Weiterleitung passiert auf dem Server. Auch ein Meta-Refresh-Tag oder eine Zeile JavaScript kann Besucher auf eine andere URL schicken. Hier erfährst du, wie diese clientseitigen Weiterleitungen funktionieren, wie Google mit ihnen umgeht und warum sie nur die Notlösung sein sollten.

Server & Plattformen

  • .htaccess-Weiterleitung auf Apache

    So leitest du einzelne Seiten und ganze Domains per .htaccess weiter: mod_alias oder mod_rewrite, fertige Regeln für die typischen Fälle und wie du Schleifen und Ketten vermeidest.

  • Weiterleitungen mit nginx

    Fertige nginx-Konfiguration für 301-Weiterleitungen: einzelne Seiten, Muster, ganze Domains, HTTPS und www in einem Hop und Hunderte URLs per map.

  • Weiterleitungen mit Cloudflare

    Cloudflare kann Weiterleitungen direkt am Edge beantworten, bevor eine Anfrage deinen Server erreicht. So funktionieren Single Redirects, Bulk Redirects und Always Use HTTPS – und so verhinderst du, dass sie sich mit deinem Server in die Quere kommen.

  • Weiterleitungen in WordPress

    In WordPress kannst du URLs auf mehreren Wegen weiterleiten: per Plugin, per Regel in der .htaccess oder mit ein paar Zeilen PHP. Hier erfährst du, welcher Weg wann passt und wie du die typischen Stolperfallen mit Caching und HTTPS umgehst.

  • Weiterleitungen in Next.js

    In Next.js kannst du an vier Stellen weiterleiten: in der Konfiguration, in der Middleware, im Servercode des App Routers und über die Option trailingSlash. Jede davon sendet standardmäßig andere Statuscodes – es lohnt sich also, die Unterschiede zu kennen.

  • Weiterleitungen bei Vercel und Netlify

    Bei Vercel und Netlify fasst du keine Webserver-Konfiguration an. Weiterleitungen stehen in einer Datei in deinem Repository oder im Dashboard, und das Edge-Netzwerk der Plattform liefert sie aus. So funktionieren beide – und hier unterscheiden sie sich.

  • Weiterleitungen mit Microsoft IIS

    IIS bietet dir zwei Wege für Weiterleitungen: die eingebaute HTTP-Umleitung und das URL-Rewrite-Modul. Hier erfährst du, wann du welches nimmst – mit web.config-Beispielen zum Kopieren.

Anwendungsfälle

  • HTTP auf HTTPS umleiten

    Jede HTTP-URL deiner Website sollte mit genau einem permanenten Redirect auf ihrer HTTPS-Version landen. Hier erfährst du, wie du das einrichtest, mit HSTS absicherst und prüfst.

  • www-Redirect: mit oder ohne www

    www.example.com und example.com sind zwei verschiedene Hosts. Entscheide dich für einen, leite den anderen dauerhaft um und sorg dafür, dass der Rest deiner Website mitspielt.

  • Domain-Umzug: die SEO-Checkliste

    Ein Umzug auf eine neue Domain ist gut beherrschbar, wenn jede alte URL auf ihr exaktes Gegenstück weiterleitet. Diese Checkliste führt dich durch die Zeit vor, während und nach dem Umzug.

  • Redirect-Ketten und Redirect-Schleifen

    Jeder zusätzliche Redirect-Hop kostet Zeit, und eine Schleife macht eine Seite komplett unerreichbar. Hier erfährst du, wie Ketten und Schleifen entstehen, wie du sie aufspürst und wieder loswirst.

Alles, was du über Weiterleitungen und Statuscodes wissen musst.

Was ist eine Weiterleitung?

Eine Weiterleitung (Redirect) teilt einem Browser oder Crawler mit, dass der Inhalt einer URL unter einer anderen Adresse zu finden ist. Technisch antwortet der Server mit einem 3xx-Statuscode wie 301 oder 302 und einem Location-Header, der die neue URL enthält. Der Client ruft diese dann automatisch auf, meist ohne dass Besucher etwas davon merken. Weiterleitungen brauchst du, wenn Seiten umziehen, wenn du von HTTP auf HTTPS umstellst, www und ohne www zusammenführst oder auf eine neue Domain wechselst. Daneben gibt es clientseitige Weiterleitungen per HTML-Meta-Refresh oder JavaScript. Serverseitige Redirects sind aber schneller und für Suchmaschinen zuverlässiger. Mit dem Checker oben siehst du, welche Art von Weiterleitung eine URL nutzt und wo sie landet.

Warum sind Weiterleitungen für SEO wichtig?

Links und Rankings hängen an URLs. Ändert sich eine URL ohne Weiterleitung, landen Besucher und Crawler auf einer 404-Seite, und alle Signale, die die alte URL gesammelt hat, gehen verloren. Mit einer Weiterleitung folgt Google zur neuen URL und vererbt den PageRank. Alle gängigen Codes (301, 302, 303, 307, 308) geben PageRank weiter, sie unterscheiden sich aber darin, wie deutlich sie Google sagen, welche URL indexiert werden soll: 301 und 308 sind ein starkes Kanonisierungssignal, 302 und 307 ein schwaches. Unnötige Hops kosten Ladezeit und Crawl-Budget. Leite also jede geänderte URL auf ihr passendstes Gegenstück um, nutz für dauerhafte Umzüge einen dauerhaften Code und vermeide Ketten. Mehr dazu im Ratgeber zur 301-Weiterleitung.

Welche Statuscodes für Weiterleitungen gibt es?

Für echte Weiterleitungen gibt es fünf Statuscodes. 301 Moved Permanently und 308 Permanent Redirect stehen für einen dauerhaften Umzug, 302 Found und 307 Temporary Redirect für einen vorübergehenden. Der Unterschied innerhalb der Paare: Bei 307 und 308 muss der Client die Anfragemethode beibehalten, ein POST bleibt also ein POST. Nach 301 und 302 wechseln Browser dagegen meist zu GET. 303 See Other fordert ausdrücklich ein GET auf die neue URL an, typischerweise nach dem Absenden eines Formulars. 300 und 304 gehören zwar zum 3xx-Bereich, sind aber keine Weiterleitungen im üblichen Sinn. Lies dazu 301 vs. 302, 307 vs. 308 und die Übersicht der Statuscodes.

Was ist eine Redirect-Kette und warum solltest du sie vermeiden?

Eine Redirect-Kette sind mehrere Weiterleitungen hintereinander, etwa http://example.com → https://example.com → https://www.example.com → https://www.example.com/start/. Jeder Hop ist ein zusätzlicher Round Trip, der die Seite ausbremst, vor allem im Mobilfunknetz. Google folgt bis zu 10 Hops, doch jeder davon kostet Crawl-Budget, und nach 10 Hops wird die URL gar nicht mehr erreicht. Ketten wachsen meist mit der Zeit: Ein Relaunch setzt neue Weiterleitungen auf alte, oder HTTPS- und www-Regeln greifen nacheinander. Lös sie auf, indem du jede alte URL direkt aufs finale Ziel leitest und HTTPS und www in einer Regel zusammenfasst. Wie das geht, zeigt der Ratgeber zu Redirect-Ketten.

Wie entsteht eine Redirect-Schleife?

Eine Redirect-Schleife entsteht, wenn URL A auf B weiterleitet und B – direkt oder über Umwege – wieder auf A. Browser geben dann mit einem Fehler wie ERR_TOO_MANY_REDIRECTS auf. Typische Ursachen sind zwei Regeln, die sich widersprechen (eine ergänzt www, die andere entfernt es), eine HTTPS-Weiterleitung hinter einem Proxy oder CDN, das TLS beendet, sodass der Server nie HTTPS sieht, widersprüchliche Regeln für den Slash am Ende oder eine CMS-Einstellung, die nicht zur Serverkonfiguration passt. Der Checker erkennt Schleifen, sobald sich eine URL wiederholt, und zeigt dir jeden Hop – so siehst du, welche zwei Regeln sich in die Quere kommen. Die Response-Header verraten, welche Ebene weiterleitet. Bei Cloudflare ist der SSL-Modus „Flexibel“ ein häufiger Auslöser, siehe Cloudflare-Ratgeber.

Ist ein Meta Refresh so gut wie eine 301-Weiterleitung?

Nicht ganz. Ein Meta Refresh ist ein HTML-Tag wie <meta http-equiv="refresh" content="0; url=https://example.com/">. Der Server antwortet zunächst mit 200, der Browser lädt die Seite und folgt erst dann der Weiterleitung. Das dauert länger, und Clients, die kein HTML auswerten – viele Tools und API-Clients –, folgen ihr gar nicht. Google versteht Meta Refreshs durchaus: Ein sofortiger (Verzögerung 0) gilt als dauerhafte Weiterleitung, ein verzögerter als vorübergehende. Setz einen Meta Refresh nur ein, wenn du den Server nicht konfigurieren kannst, etwa bei manchen statischen Hostern. Sonst ist ein 301 oder 308 die bessere Wahl. Mehr im Ratgeber zum Meta Refresh.

Wie lange solltest du Weiterleitungen bestehen lassen?

So lange wie möglich. Google empfiehlt, Weiterleitungen nach einem Website-Umzug mindestens ein Jahr lang aktiv zu lassen, weil es dauert, bis alle Signale übertragen und die neuen URLs vollständig indexiert sind. Aus dem Netz verschwinden die alten URLs nach einem Jahr aber trotzdem nicht: Externe Links, Lesezeichen, E-Mails und alte Drucksachen zeigen weiter darauf. Entfernst du die Weiterleitungen, landen diese Besucher auf einer 404-Seite und Links verlieren ihren Wert. Ein paar Regeln weiter mitzuschleppen kostet dagegen kaum etwas. Bei einem Domainwechsel solltest du außerdem die alte Domain behalten, damit sie niemand anderes übernimmt. Was du sonst noch einplanen musst, steht in der Checkliste zum Domain-Umzug.

Wie leite ich HTTP auf HTTPS und www auf ohne www um?

Leg eine kanonische Variante fest, zum Beispiel https://example.com, und leite alle anderen Varianten per 301 oder 308 dorthin um. Entscheidend ist, dass das in einem Hop passiert: http://www.example.com sollte direkt auf https://example.com führen und nicht über https://www.example.com. Unter Apache kombinierst du beide Bedingungen in einer Regel, unter nginx nutzt du getrennte Server-Blöcke, die jeweils direkt die finale URL zurückgeben. Läuft HTTPS überall, ergänzt du einen HSTS-Header, damit Browser die HTTP-Anfrage künftig überspringen. Schritt-für-Schritt-Anleitungen findest du unter HTTP auf HTTPS weiterleiten und www-Weiterleitung. Teste danach alle vier Varianten mit dem Checker.

Wie richte ich eine Weiterleitung unter Apache oder nginx ein?

Unter Apache schreibst du die Regeln meist in die .htaccess im Hauptverzeichnis deiner Website, etwa Redirect 301 /alte-seite/ https://example.com/neue-seite/ für eine einzelne Seite oder eine RewriteRule aus mod_rewrite für Muster. Bei nginx gibt es keine .htaccess: Dort trägst du return 301 https://example.com/neue-seite/; in einen location- oder server-Block ein und lädst nginx neu. Beide erlauben jeden beliebigen Statuscode. Korrekte Regeln erzeugen dir unsere Generatoren: der .htaccess-Generator und der nginx-Generator. Hintergründe und weitere Beispiele stehen in den Ratgebern zur .htaccess-Weiterleitung und zur nginx-Weiterleitung.

Warum zeigt mein Browser ein anderes Ergebnis als der Checker?

Browser cachen dauerhafte Weiterleitungen. Hast du eine URL einmal aufgerufen, die mit 301 oder 308 geantwortet hat, springt der Browser womöglich direkt zum alten Ziel, ohne den Server erneut zu fragen – auch wenn du die Regel inzwischen geändert hast. Der Checker schickt dagegen immer eine frische Anfrage ohne Cookies und Cache und zeigt dir, was der Server gerade tatsächlich ausliefert. Weitere Gründe für Abweichungen sind Cookies (etwa für eine Sprach- oder Login-Weiterleitung), dein Standort oder eine Regel für bestimmte User-Agents. Probier im Checker einen anderen User-Agent aus oder teste nach dem Leeren des Caches in einem privaten Fenster. Ist ein CDN im Spiel, leer auch dessen Cache.