Redirect Checker

What this checker analyses

The checker crawls each URL hop by hop without using your browser: it requests the headers, reads the Location of every 3xx response and repeats until it reaches the final destination or a loop. For each hop it records the URL, the status code and the response time, so you see where crawling gets lost and what it costs.

How to check your redirects step by step

Nothing to install and no access to your site required: the URLs just need to be reachable from the internet. The trick is which URLs you hand it.

1. 1

   Start from the old URLs, not the new ones. Checking the destination only tells you it exists; what you need to know is what happens to someone arriving through the old link.

2. 2

   Paste them one per line, or use “Paste list” if they live in a spreadsheet or a Search Console export.

3. 3

   If you suspect the server treats bots differently, switch the User-Agent and run it again. Comparing iRankly Bot against Googlebot is the check that uncovers the most problems.

4. 4

   Run the analysis and look at the hop column. Zero means there is no redirect; one is correct; two or more is a chain you can shorten by pointing the first rule at the final destination. If the chain goes through http and through www, merge those two rules into one.

How to read the result

• The chain, hop by hop. Every row is a real request and shows the status code its headers returned. The colour tells you whether it is a redirect (3xx), a valid destination (2xx) or an error (4xx/5xx). What you want is a single hop: source → final destination.
• The hop count. Zero hops means the URL answers directly. One is correct for a redirect. From two upwards you have a chain, and the most common ones chain http to https with www to non-www: two rules that are each correct on their own but together cost an extra hop.
• The time of each hop. Measured separately and totalled. It separates a cheap chain from one that genuinely hurts: three hops at 40 ms is not the same as three hops at 600 ms against a slow server.
• Loops and meta refresh. If a URL reappears in its own chain it is flagged as a loop and the trace stops there: that is the source of the “too many redirects” error. Meta refresh hops are labelled separately, because they are not server redirects.

Check what Googlebot sees, not just your browser

Plenty of servers answer differently depending on who asks: they redirect mobile, serve the bot another version, or block unknown agents. So you can choose which identity makes the request and compare the results.

Migration mode: validate your redirect map

• 1. Paste source and destination

  Turn on migration mode and paste the map you already have: an old URL and the URL it should land on. It is the same file you prepare for .htaccess or for the plugin.

• 2. Run the whole batch

  All of them are checked at once, up to 500 depending on your plan. You do not need the site to be live: you can point it at staging.

• 3. Review only the mismatches

  Each row says whether the real destination matches the expected one, so you can verify the whole map in one pass. The comparison ignores meaningless differences — trailing slash, host casing, default port — so anything flagged red is a genuine fault.

Frequently asked questions about redirects