Redirect Checker

A redirect checker shows what really happens when someone types your domain into a browser in any of its common forms. Our free redirect test requests four starting addresses, http:// and https://, each with and without www, and follows every redirect hop by hop. For each hop you see the status code, the Location header it sent and how long the server took to answer. The result then gives one clear verdict: do all four versions reach the same canonical URL, each in a single permanent redirect? Because every hop is labelled as permanent (301 or 308) or temporary (302, 303 or 307), it doubles as a 301 redirect checker. It also flags long chains, loops and versions that do not load at all, and you can copy the result or export it as CSV.

How to use the Redirect checker

1. 1 Enter your domainType the domain only, such as example.com. You do not need to add http, https or www, because we test all four combinations for you.
2. 2 Run the checkWe request the home page of each version without automatically following redirects, so every hop, its status code, its Location header and its response time are recorded.
3. 3 Read the verdictThe first check says whether every version reaches one canonical URL in one permanent hop. If not, it lists exactly which version fails and why: a chain, a temporary redirect, a different final URL or no answer.
4. 4 Look at each chainEach version gets its own card showing every step from the starting address to the final page, with the redirect type spelled out and the time per hop.
5. 5 Fix, re-test and shareUpdate your server, CMS or CDN rules so every version goes to the canonical URL in one 301, then run the redirect checker again. Copy the result or export the CSV to attach to a ticket.

What a URL redirect is

A redirect is a server response that tells a browser or search engine the content lives at a different address. Instead of returning the page, the server sends a 3xx status code and a Location header naming the new URL, and the client requests that address instead. Done well, the visitor barely notices.

Every site needs at least a few redirects. Your domain can be reached as http://example.com, http://www.example.com, https://example.com and https://www.example.com, and to a search engine those are four separate URLs. Redirects are how you consolidate them into one preferred version, and how you move visitors from old pages to new ones after a site change.

301 vs 302 vs 307 vs 308: which redirect to use

The redirect codes differ in two ways: whether the move is permanent or temporary, and whether the browser may change the request method, for example turning a form POST into a GET.

For search, the permanent or temporary part is what counts. In practice the choice is simple: if the old address is never coming back, use 301, or 308 if your server or CDN prefers it. If it really will come back soon, use 302 or 307. Domain-level redirects such as http to https and www to non-www are permanent by nature.

• 301 Moved Permanently: the standard choice for http to https, www to non-www and moved pages.
• 308 Permanent Redirect: also permanent, but the request method must stay the same. Common on modern hosting and CDNs, and treated as permanent by Google.
• 302 Found: a temporary redirect. Use it only when the original URL really will come back, such as a short maintenance page.
• 307 Temporary Redirect: temporary and method-preserving. Browsers also show an internal 307 when HSTS forces https, which you may see in browser tools but not from a server-side check like ours.
• 303 See Other: sends the client to a different URL with a GET request, usually after a form is submitted. It should not be used for domain-level redirects.

What Google says about redirects and SEO

Google's Search Central documentation on redirects describes two groups. For permanent server-side redirects (301 and 308), Googlebot follows the redirect and the indexing pipeline uses it as a strong signal that the target should be canonical. For temporary redirects (302, 303 and 307), Googlebot follows the redirect, but the indexing pipeline treats it as only a weak signal, so the old URL may stay in search results.

Google recommends a permanent server-side redirect whenever you need to change the URL shown in search results, and says it follows up to 10 redirect hops; beyond that, Search Console reports a redirect error. For site moves, Google's guidance is to keep redirects in place for as long as possible, generally at least a year.

That is the whole story you need for most decisions: permanent moves get 301 or 308, temporary ones get 302 or 307, and every hop you remove makes the first visit faster and the signal clearer. Meta refresh and JavaScript redirects can also be followed by Google, but server-side redirects are the most reliable choice.

Redirect chains and redirect loops explained

A redirect chain is a series of redirects where the first destination redirects again before a page finally loads. A typical example is http://example.com sending visitors to https://example.com, which then sends them to https://www.example.com. Each step works on its own, but together they add a round trip for every hop, and the time column in the result shows what each hop costs.

Chains usually build up over time. A site moves to https and someone adds a rule. Later it switches to www and a second rule is added. Then a page is renamed and a third redirect points at a URL that itself redirects. Nobody notices, because the browser follows every hop silently.

A redirect loop is a chain that never ends: URL A redirects to B, and B redirects back to A. The browser gives up with an error such as "too many redirects", so the page never loads for anyone. Our checker records every URL it visits and reports a loop as soon as one comes up a second time.

• Canonical URL, no redirect: the preferred version answers 200 itself. Ideal.
• One permanent hop: every other version goes straight to the canonical URL. Ideal.
• One hop, but temporary: replace the 302 or 307 with a 301 or 308.
• Two hops or more: a chain. Combine the rules so each version is redirected once. Three or more is flagged as a long chain.
• Loop or does not load: visitors arriving this way see an error. Fix this before anything else.

Reading the redirect checker results

The verdict comes first: every version reaches one URL in one permanent hop, or a list of the versions that do not and why. The canonical URL is the address most versions end on, preferring https when there is a tie.

Below it, the remaining checks break the problem down. All versions end on one URL fails if you are serving two copies of your site. The HTTPS check fails if any http:// starting address ends on a page that is still http. The hops check warns when a chain takes more than two hops, and the redirect type check lists every hop that used a 302, 303 or 307. Versions that do not load are listed with the status or error and, if they redirected first, the URL where they stopped.

Each card shows the steps for one version. Every hop has its URL, the Location header exactly as the server sent it (useful when a server sends a relative path), the redirect type and the response time. Times are measured from our server and include connecting, so treat them as a guide rather than a lab measurement.

We send a HEAD request for each hop, and if the server rejects HEAD we try again with GET. Each chain is followed for up to ten hops, and every hop passes through our private-network guard.

What a redirect checker shows that your browser hides

When you type an address into a browser, you only see where you end up. The browser follows every redirect automatically and does not show the status codes on the way, so a two-hop chain that uses a 302 looks exactly the same as a single clean 301.

Browsers also remember permanent redirects and HSTS, so after you change your redirect rules your own browser can keep showing the old behavior. A server-side redirect test like this one starts fresh on every run, with no cache and no HSTS memory, so it shows what a first-time visitor or a search engine crawler actually receives.

This tool is built for domain-level redirects, so it tests the home page of the four versions of your domain. To check where a specific page redirects, use the HTTP status code checker for one URL, or the Bulk Redirect Checker to test up to 100 old URLs against a redirect map after a migration.

How to set up 301 redirects on Apache, Nginx, Cloudflare and WordPress

Decide on your canonical address first: https, plus either www or non-www. Then pick one layer to own the domain-level redirect. Most chains and loops happen because two layers each add a rule, for example the CDN adding https and the server adding www.

• Apache: put the rules in .htaccess or the virtual host. Combine the https and www conditions into one rule so both are fixed in a single 301, as in the examples below. On WordPress sites, place custom rules above the # BEGIN WordPress block, because WordPress can rewrite the lines between its own markers.
• Nginx: use a separate server block for http and for the non-preferred hostname, each returning 301 to the full canonical URL, then reload Nginx.
• Cloudflare: under Rules, a redirect rule (single redirect) with a wildcard pattern can send www to non-www, or the reverse, with a 301 at the edge. Always Use HTTPS handles http to https. Set the SSL/TLS mode to Full or Full (strict): Flexible mode with a server that forces https causes an endless loop.
• WordPress: set both WordPress Address and Site Address under Settings, General to your canonical https URL. A mismatch in protocol or www is a common cause of loops. For individual old pages, a redirect plugin or the redirect manager in your SEO plugin adds 301s from the dashboard.
• Shopify: under Settings, Domains, set your primary domain and redirect all traffic to it. Shopify handles https automatically.
• After any change, run the redirect checker again. Change one layer at a time so you know which edit made the difference.

How to fix redirect chains, 302s and loops

Start by finding where redirects are currently set. They can live in several layers at once: the CDN, the web server configuration, an .htaccess file, the CMS and a plugin. Use the Location header in each hop to see which layer answered: a CDN, a server rule and a CMS often redirect to slightly different forms of the same address, such as with or without a trailing slash.

Then remove duplicate rules so only one layer handles http to https and www, and point that rule straight at the final URL. Replace any 302 used for a permanent move with a 301 or 308. If a loop appears after enabling a CDN or a security plugin, undo that change first and test again.

Finally, update your own references. Canonical tags, the XML sitemap, internal links and the property you use in Search Console should all use the canonical URL, so your site never sends visitors or crawlers through a redirect in the first place. The Broken Link Checker lists internal links that still point at redirected addresses.

Redirect best practice

When you move individual pages, map each old URL to its closest new equivalent before launch, and redirect them one to one. Sending a whole section to the home page is quicker to set up, but search engines often treat those redirects as soft 404s and the old pages lose their value.

Keep permanent redirects in place for at least a year after a move, and indefinitely for domain-level rules, because old links and bookmarks keep sending visitors for a long time. Once https is working reliably, consider adding an HSTS header so browsers go straight to the secure version on later visits.

After a migration or URL restructure, test a list of important inner pages with the Bulk Redirect Checker to confirm each reaches its new address in one hop, and recheck the domain variants here.

Examples you can copy

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

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

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

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate lines here
    return 301 https://www.example.com$request_uri;
}

Request URL:  https://www.example.com/*
Target URL:   https://example.com/${1}
Status code:  301
Preserve query string: on

# Apache (.htaccess)
Redirect 301 /old-page/ https://example.com/new-page/

# Nginx (inside the server block)
location = /old-page/ { return 301 https://example.com/new-page/; }

curl -sI http://example.com/ | grep -iE "^(HTTP|location)"
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/

Common mistakes to avoid

Frequently asked questions