Redirect Checker

What is a redirect checker and what does it catch?

A redirect checker shows, step by step, which addresses a server sends you through before you land on the final page. This redirect checker lists the HTTP status code, the URL and the response time for every hop. Then it gives the chain a Healthy, Could be better or Problem badge, so you can read it at a glance.

In particular, the tool catches these cases:

• Chain: the URL needs two or more redirects to reach the final page.
• Temporary code: a permanent move uses 302, 303 or 307.
• Loop: the addresses point at each other and the chain never ends.
• Security downgrade: one hop drops from HTTPS to HTTP.
• Broken target: the chain ends in 404, 410 or a 5xx error.

My team and I run this check on every site migration, every HTTPS switch and every change of URL structure. In SEO consulting projects, some of the most expensive problems we find come from redirects nobody ever looked at. Also, the tool changes nothing on your site; it only reads status codes and never keeps page content.

Permanent or temporary: which redirect code should you use?

The decision comes down to one question: will the old URL come back? If not, use a permanent code; if yes, use a temporary one. In its redirects documentation, Google treats 301 and 308 as a signal that the target should be canonical. By contrast, it does not use 302, 303 or 307 for that purpose.

• 301: permanent moves, HTTPS switches and domain changes. This is your default.
• 308: permanent like 301, but the request method stays the same. That makes it the right fit for URLs that receive POST requests, such as forms or APIs.
• 302 and 307: short campaigns, maintenance or tests. 307 also keeps the method.
• 303: sending users to a result page after they submit a form.

In practice, the most common mistake I see is not a conscious choice but a default. For example, the Apache Redirect directive sends 302 when you leave out the status. Likewise, a Location header set with the PHP header function returns 302 unless you say otherwise. So after you write the rule, look at the Type card in the tool; if it does not say Permanent, set 301 explicitly.

Why are redirect chains a problem?

A chain means a URL needs more than one redirect to reach the final page. Here is a typical case: http://example.com first goes to https://example.com, then to the www version and finally to the version with a trailing slash. Every hop is a separate request for browsers and for Googlebot. If the chain jumps to another host, the browser also has to open a new connection.

Chains rarely appear in one go; instead, they build up over the years:

• Three separate rules for HTTPS, www and the trailing slash run one after another.
• A new migration sits on top of the rules from an older one.
• Menus and content still link to the old URL, so every click starts the chain again.

Google's site move guide also advises redirecting straight to the final destination. To fix a chain, merge your server rules so each old URL reaches the final address in one step. Point old rules at the new final address too. In addition, update internal links and the URLs in your XML sitemap. I covered the speed side in detail in how site speed affects SEO.

How do redirect loops and HTTPS downgrades happen?

In a loop, the addresses point at each other and the chain never ends. After a while the browser gives up, and Chrome shows ERR_TOO_MANY_REDIRECTS. The tool, on the other hand, stops as soon as the chain returns to an address it has already visited. It then sets the badge to Problem.

These are the loop causes I run into most often:

• CDN and server fighting: in Flexible SSL mode, Cloudflare connects to your server over HTTP. If the server then redirects HTTP to HTTPS, you get a loop; the Cloudflare documentation recommends Full or Full (strict) mode instead.
• Conflicting www rules: the server rule adds www while a plugin or panel setting removes it again.
• CMS address settings: the WordPress site address and the server rule point at different versions.

An HTTPS downgrade, meanwhile, is a hop that goes from an https URL to an http one. Usually an old rule still has the target written with http. Visitors drop to an unencrypted connection at that hop, and the browser marks the page as Not secure. Moreover, the Page indexing report in Google Search Console lists loops and overly long chains as Redirect error. I explain how to read that report in my Search Console guide.

Four versions test: do http, https and www end at one address?

Anyone can reach a domain in four ways: http and https, with and without www. On a healthy site all four end at a single final address, and each uses at most one redirect. Otherwise several copies of the same page stay live, and Google decides for itself which one to treat as canonical.

The 4 versions mode checks these four addresses in turn and takes the 200 address reached by most versions as the shared target. Ideally, the Same target card reads 4/4. These are the patterns I see most often:

• 3/4: one version serves its own page without redirecting. For example, the https://www version also stays live, so the same content sits at two URLs.
• Chained http + www: http://www first goes to the bare domain and only then to https. Rewrite the rule so it reaches the final address in one step.
• Unreachable version: if there is no www record in DNS, that version never connects. Check the record with the DNS lookup tool.

Which version you pick does not change rankings on its own; in other words, consistency is what matters. Use the chosen version in canonical tags, in the sitemap and in internal links as well.

Redirect checker checklist after a site migration

On migration day, my first job is to test the old URLs that bring the most traffic and the most backlinks, one by one. For a full site, a crawler is the better tool. However, for eyeballing critical URLs, a redirect checker is fast and clear. Work through these steps:

1. Prepare a mapping table of old and new URLs; every row should lead to exactly one final address.
2. Pick samples from every template: home page, category, product or service, blog post and old campaign URLs.
3. For every sample, the Type card should read Permanent and the Redirects card should read 1.
4. Confirm that the final address returns 200 and that the content really replaces the old page.
5. Add the new URLs to the sitemap, update canonical tags and submit the new sitemap in Search Console.
6. Over the following weeks, watch the Redirect error row in the Page indexing report.

I collected every stage of a move in my website migration SEO checklist. If you are in the middle of a redesign, the guide on protecting SEO during a redesign will help too.

What can't the tool see, and how should you read the results?

Put simply, the tool only reads the server's HTTP responses; it does not run the page like a browser. That is why some redirects stay invisible here:

• Meta refresh: a redirect inside the page's HTML. Google reads an instant meta refresh as permanent and a delayed one as temporary.
• JavaScript redirects: Google only sees them if it manages to render the page. For that reason, use them only when a server side redirect is impossible.
• Visitor specific rules: redirects based on language, country, device or cookies. The tool sends its requests with its own user agent from our server's location, so the chain in your browser may differ.

If the tool shows a final 200 but your browser opens a different page, the cause is most likely in this group. Also, do not read the time value as an absolute figure, because it comes from our server. What matters is the difference between hops: when one hop is clearly slower than the others, that server is usually the problem.

If you want to combine the results with a broader technical review, my technical SEO tips are a good place to start.