Skip to content

Redirect checker: test redirects and status codes.

Checking redirects can be tough. Enter a URL and see every hop, its status code and where it finally ends.

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

Result: 1 redirect(s)

  1. 301

    http://github.com

    Redirect · 330 ms

    Response headers
    Content-Length:
    0
    Location:
    https://github.com/
  2. 200

    https://github.com/

    Final URL · 701 ms

    Response headers
    date:
    Mon, 28 Sep 2026 22:02:17 GMT
    content-type:
    text/html; charset=utf-8
    content-language:
    en-US
    vary:
    X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With, X-GitHub-Client-Version, Accept-Language, Sec-Fetch-Site,Accept-Encoding, Accept, X-Requested-With
    etag:
    W/"8909a4fd423da3698cefab1e4ce0d537"
    cache-control:
    max-age=0, private, must-revalidate
    strict-transport-security:
    max-age=31536000; includeSubdomains; preload
    x-frame-options:
    deny
    x-content-type-options:
    nosniff
    x-xss-protection:
    0
    referrer-policy:
    origin-when-cross-origin, strict-origin-when-cross-origin
    content-security-policy:
    default-src 'none'; base-uri 'self'; child-src github.githubassets.com github.com/assets-cdn/worker/ github.com/assets/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com *.rel.tunnels.api.visualstudio.com wss://*.rel.tunnels.api.visualstudio.com github.githubassets.com objects-origin.githubusercontent.com copilot-proxy.githubusercontent.com proxy.individual.githubcopilot.com proxy.business.githubcopilot.com proxy.enterprise.githubcopilot.com *.actions.githubusercontent.com wss://*.actions.githubusercontent.com productionresultssa0.blob.core.windows.net productionresultssa1.blob.core.windows.net productionresultssa2.blob.core.windows.net productionresultssa3.blob.core.windows.net …
    server:
    github.com
    content-encoding:
    gzip
    accept-ranges:
    bytes
    set-cookie:
    _gh_sess=QUasbiCQ1qu%2FmUkfSYEmmXDjGb%2BqjrnT%2FoPJF47M4gro4C8jm8qtb%2FzVNjMoOd0ReXZzS0Midbw0tjLj13TvDdxND1%2F9HZtlNI4ZoLQ9fBGytv5J4wr%2Fhs0eP%2BaN5GMXqZErGoC5BO25vMReEgsQR2oA321IndQYOR5QKLXQSXW2OKb4tMLGGs2wQFRZ96ChNjok7AeVIlLhqm0EOSEgp1llkzUKfLQMfp8cnGCBE%2FSFdShpbkvkY3GDwzrzmE4X6e%2Bw1y%2F%2B%2FSfvaMrGBdH4mg%3D%3D--4oCpcgDCUsu9sxfm--9y2KzkTnJ3Xr5phbQkqEMg%3D%3D; path=/; HttpOnly; secure; SameSite=Lax
    set-cookie:
    _octo=GH1.1.170823119.1790632940; expires=Tue, 28 Sep 2027 22:02:20 GMT; domain=.github.com; path=/; secure; SameSite=Lax
    set-cookie:
    logged_in=no; expires=Tue, 28 Sep 2027 22:02:20 GMT; domain=.github.com; path=/; HttpOnly; secure; SameSite=Lax
    x-github-request-id:
    9D98:380511:1DBDBB:1DD03F:6ABAE3EB
    x-github-edge-region:
    fra
  • Looks good: the redirect chain ends on a working HTTPS page.

How to read the result

The checker requests your URL exactly like a browser or crawler would, but it doesn't follow redirects silently. Every response is recorded, so you see the complete path from the first request to the page that finally loads.

One row per hop

Each request in the chain is one row, called a hop. A row shows:

  • The status code in a colored badge. Amber means a redirect (3xx, e.g. 301, 302, 307, 308). Green means success (2xx, usually 200). Red means an error (4xx or 5xx) or a request that failed entirely, for example because of a DNS or TLS problem.
  • The URL that was requested in this step.
  • The type of the hop: "Redirect" for an HTTP redirect with a Location header, "Meta refresh redirect" if the page redirects with an HTML <meta http-equiv="refresh"> tag, and "Final URL" for the last stop.
  • The response time in milliseconds. Every hop adds its own round trip, which is why long chains make pages noticeably slower, especially on mobile connections.

A healthy result is short: ideally one amber row with 301 or 308, followed by one green row with 200 on an https:// URL.

Hints below the chain

Below the rows, the checker points out problems it found:

  • Redirect chain: more than one redirect in a row. Point the first URL straight to the final one. See redirect chains.
  • Temporary redirect: a 302 or 307 where a permanent move probably needs 301 or 308. See 301 vs. 302.
  • Meta refresh: a client-side redirect in the HTML. A server-side redirect is faster and more reliable, see meta refresh.
  • Error page: the chain ends on a 4xx or 5xx status.
  • Missing HTTPS: the final URL is served over plain HTTP. See HTTP to HTTPS.
  • Missing HSTS: the final URL doesn't send a Strict-Transport-Security header, so browsers keep making the first request over HTTP.

User agent

Some sites redirect differently depending on who asks: mobile visitors to an m. subdomain, bots to a different version, or desktop browsers to a language page. Choose Default, Chrome (Desktop), Safari (iPhone) or Googlebot to see the chain as that client would. If the results differ, your site has device- or bot-specific redirects, and you should make sure Googlebot ends up on the same content as your visitors.

Response headers, hop limit and loops

Expand a row to see all response headers of that hop, such as Location, Cache-Control, Server or Strict-Transport-Security. That helps you find out which layer sends a redirect, for example a CDN or the application. For a closer look at headers, use the HTTP header checker.

The checker follows at most 10 hops, the same limit Googlebot uses. If a URL appears a second time in the chain, it stops and reports a redirect loop. To check many URLs at once, for example after a migration, use the bulk redirect checker.

More free tools

  • Bulk checker

    Check up to 20 URLs at once, e.g. your redirect map after a domain migration. Export as CSV.

  • Header checker

    See all HTTP response headers of every hop, including Location, Cache-Control and HSTS.

  • .htaccess redirect generator

    Generate Apache .htaccess rules for single pages, HTTPS and www redirects.

  • nginx redirect generator

    Generate nginx server blocks and return rules for your redirects.

  • HTTP status codes

    All HTTP status codes explained, with notes on how Google treats them.

  • JSON API

    Check redirects from your scripts and CI pipelines with a simple JSON API.

Redirect guides

Status codes

  • 301 vs. 302 redirect

    A 301 says "this URL has moved for good", a 302 says "look over there for now". The difference sounds small, but it affects which URL Google indexes, how long browsers remember the redirect and how easy it is to undo.

  • 307 vs. 308 redirect

    307 and 308 are the strict siblings of 302 and 301: they guarantee that a POST stays a POST. Here is what that means in practice, why you often see a 307 that your server never sent, and when a 308 is the better permanent redirect.

  • 301 redirect

    A 301 redirect permanently sends visitors and search engines from an old URL to a new one. It is the standard tool for relaunches, domain moves and URL changes. Here is how it works, how to set it up and how to avoid the classic mistakes.

  • Meta refresh and JavaScript redirects

    Not every redirect happens on the server. A meta refresh tag or a line of JavaScript can also send visitors to another URL. Here is how these client-side redirects work, how Google handles them and why they should only be your fallback.

Servers & platforms

  • .htaccess redirects on Apache

    Everything you need to redirect pages and whole domains with .htaccess on Apache: mod_alias vs. mod_rewrite, copy-ready rules for the common cases, and how to avoid loops and chains.

  • nginx redirects

    Copy-ready nginx configuration for 301 redirects: single pages, patterns, whole domains, HTTPS and www in a single hop, and hundreds of URLs with map.

  • Redirects on Cloudflare

    Cloudflare can answer redirects at the edge before a request ever reaches your server. Here is how Single Redirects, Bulk Redirects and Always Use HTTPS work, and how to keep them from fighting with your origin.

  • Redirects in WordPress

    WordPress gives you several ways to redirect a URL: a plugin, a rule in .htaccess or a few lines of PHP. This guide shows when to use which, and how to avoid the typical pitfalls with caching and HTTPS.

  • Redirects in Next.js

    Next.js has four places where you can redirect: the config file, middleware, server code in the App Router and the trailingSlash option. Each one sends different status codes by default, so it pays to know which is which.

  • Redirects on Vercel and Netlify

    On Vercel and Netlify you don't touch a web server config. Redirects live in a file in your repository or in the dashboard, and the platform's edge network sends them. Here is how both work and where they differ.

  • Redirects on Microsoft IIS

    IIS gives you two ways to redirect: the built-in HTTP Redirect feature and the URL Rewrite module. Here is when to use which, with web.config examples you can copy.

Use cases

  • Redirect HTTP to HTTPS

    Every HTTP URL on your site should end up on its HTTPS version in exactly one permanent redirect. Here is how to set that up, secure it with HSTS and verify the result.

  • www to non-www redirect (and vice versa)

    www.example.com and example.com are two different hosts. Pick one, redirect the other to it permanently and make sure everything else on your site agrees.

  • Domain migration checklist

    Moving a website to a new domain is manageable if every old URL redirects to its exact counterpart. This checklist walks you through before, during and after the move.

  • Redirect chains and redirect loops

    Every extra redirect hop costs time, and a loop makes a page completely unreachable. Here is how chains and loops arise, how to find them and how to get rid of them.

Everything you need to know about redirects and status codes.

What is a redirect?

A redirect tells a browser or crawler that the content of a URL is available at a different address. Technically, the server answers with a 3xx status code, such as 301 or 302, and a Location header containing the new URL. The client then requests that URL automatically, usually without the visitor noticing. Redirects are used when pages move, when a site switches from HTTP to HTTPS, when you consolidate www and non-www, or when you move to a new domain. There are also client-side redirects via an HTML meta refresh or JavaScript, but server-side redirects are faster and more reliable for search engines. Use the checker above to see which kind of redirect a URL uses and where it ends up.

Why do redirects matter for SEO?

Links and rankings belong to URLs. When a URL changes without a redirect, visitors and crawlers land on a 404, and the signals the old URL has collected are lost. With a redirect, Google follows to the new URL and passes on PageRank. All common redirect codes (301, 302, 303, 307, 308) pass PageRank, but they differ in how strongly they tell Google which URL to index: 301 and 308 are a strong canonicalization signal, 302 and 307 a weak one. Unnecessary hops cost load time and crawl budget. So redirect every changed URL to its closest equivalent, use a permanent code for permanent moves, and avoid chains. The 301 redirect guide explains the details.

Which redirect status codes are there?

There are five status codes for real redirects. 301 Moved Permanently and 308 Permanent Redirect mark a permanent move; 302 Found and 307 Temporary Redirect a temporary one. The difference within each pair: with 307 and 308 the client must keep the request method, so a POST stays a POST, while after 301 and 302 browsers usually switch to GET. 303 See Other explicitly tells the client to fetch the new URL with GET, typically after a form submission. 300 and 304 are also in the 3xx range but are not redirects in the usual sense. Read 301 vs. 302, 307 vs. 308 and the status code reference.

What is a redirect chain and why should I avoid it?

A redirect chain is a series of redirects in a row, for example http://example.com → https://example.com → https://www.example.com → https://www.example.com/home/. Each hop is an extra round trip that slows down the page, especially on mobile networks. Google follows up to 10 hops, but every hop costs crawl budget, and after 10 the URL is not reached at all. Chains usually grow over time: a relaunch adds redirects on top of older ones, or HTTPS and www rules are applied one after another. Fix them by pointing every old URL straight to the final destination and combining HTTPS and www into one rule. The guide on redirect chains shows how.

What causes a redirect loop?

A redirect loop happens when URL A redirects to B and B, directly or via other hops, back to A. Browsers give up with an error like ERR_TOO_MANY_REDIRECTS. Typical causes are two rules that contradict each other (one adds www, another removes it), an HTTPS redirect behind a proxy or CDN that terminates TLS so the server never sees HTTPS, conflicting trailing-slash rules, or a CMS setting that disagrees with the server configuration. The checker detects loops as soon as a URL repeats and shows you each hop, so you can see which two rules are fighting. Look at the response headers of each hop to find out which layer sends the redirect. With Cloudflare, the SSL mode "Flexible" is a common cause, see the Cloudflare guide.

Is a meta refresh as good as a 301 redirect?

Not quite. A meta refresh is an HTML tag like <meta http-equiv="refresh" content="0; url=https://example.com/">. The server first answers with 200, the browser loads the page and only then follows the redirect. That is slower, and clients that don't parse HTML, like many tools and API clients, won't follow it at all. Google does understand meta refreshes: an instant one (delay 0) is treated like a permanent redirect, a delayed one like a temporary redirect. Use a meta refresh only if you can't configure the server, for example on some static hosts. Otherwise, a 301 or 308 is the better choice. More in the meta refresh guide.

How long should I keep redirects in place?

As long as possible. Google recommends keeping redirects after a site move for at least one year, because it takes time until all signals are transferred and the new URLs are fully indexed. But the old URLs don't disappear from the web after a year: external links, bookmarks, emails and old printed material keep pointing to them. If you remove the redirects, those visitors land on a 404 and links lose their value. The cost of keeping a few rules is small. For domain moves, also keep the old domain registered so nobody else can take it over. The domain migration checklist covers what else to plan for.

How do I redirect HTTP to HTTPS and www to non-www?

Pick one canonical version, for example https://example.com, and redirect all other variants to it with a 301 or 308. The important part is to do it in one hop: http://www.example.com should go straight to https://example.com, not via https://www.example.com. On Apache you combine both conditions in one rule, on nginx you use separate server blocks that each return the final URL. Once HTTPS works everywhere, add an HSTS header so browsers skip the HTTP request next time. Step-by-step instructions are in HTTP to HTTPS and www to non-www. Afterwards, test all four variants with the checker.

How do I set up a redirect on Apache or nginx?

On Apache, you usually add rules to the .htaccess file in your web root, for example Redirect 301 /old-page/ https://example.com/new-page/ for a single page, or RewriteRule from mod_rewrite for patterns. On nginx there is no .htaccess; you add return 301 https://example.com/new-page/; inside a location or server block and reload nginx. Both let you choose any status code. The generators create correct rules for you: .htaccess generator and nginx generator. For background and more examples, see the guides on .htaccess redirects and nginx redirects.

Why does my browser show a different result than the checker?

Browsers cache permanent redirects. Once you have visited a URL that answered with 301 or 308, the browser may jump to the old destination without asking the server again, even after you have changed the rule. The checker always sends a fresh request without cookies or cache, so it shows what the server delivers right now. Other reasons for differences are cookies (for example a language or login redirect), your location, or a user agent-specific rule. Try another user agent in the checker, or test in a private window after clearing the cache. If a CDN is involved, purge its cache too.