Bulk Redirect Checker: How-To and Best Tools

A bulk redirect checker takes a list of URLs — hundreds or thousands at once — and reports where each one ends up: the status code at every hop, the length of the redirect chain, and the final destination. You need one after a migration, redesign or URL restructure, because checking redirects one at a time stops being realistic somewhere past a few dozen URLs.

Checking one redirect is easy: paste a URL into a tool, see where it lands, move on. Checking four hundred is a different problem, and exactly the kind of repetitive job software should do. This guide covers when you need bulk checking, what goes wrong with redirects at scale, what a good checker reports, a step-by-step audit process, how to fix what you find, and an honest comparison of the bulk URL redirect checker tools worth knowing.

When you need bulk checking instead of single-URL checking

Checking a single redirect makes sense when you just fixed one link, or a reader reports a misbehaving page. Bulk checking becomes necessary in three situations.

Site migrations. Moving to a new domain or CMS means every old URL needs a working redirect to its new location. A thousand pages means potentially a thousand redirects to verify.

Redesigns and URL restructuring. Even on the same domain, moving from flat URLs to category-based ones changes URLs at scale. Every old URL needs to keep working or redirect somewhere sensible.

Mergers and consolidations. Combining two sites, or merging many posts into fewer pillars, folds years of separate URL history into one domain — sometimes tens of thousands of URLs.

In all three, volume rules out manual checking. You need a tool that takes a list (or crawls a site to build one) and reports on every URL in one batch.

What goes wrong with redirects at scale

Redirect chains

URL A redirects to B, which redirects to C, instead of A going straight to C. Chains usually happen by accident: a migration redirects old URLs to a temporary structure, a later change redirects that structure again, and nobody collapses the two hops into one.

Each hop is another request for the browser and the crawler. Two hops are a minor cost. Chains of five or more, built up over several migrations, slow pages down measurably, and Google stops following after a limited number of hops, so the end of a very long chain may never be reached.

Redirect loops

A redirects to B, which redirects back to A, or a longer chain circles back on itself. Nobody — visitor or crawler — ever reaches a page. Browsers show an error; crawlers give up. Loops usually come from a rule that is too broad, or two rules written separately that conflict.

Redirects that land on 404s

The redirect points at the new location, but the new page was never published, got a different URL than planned, or was deleted later. The visitor follows the redirect and lands on a dead page anyway.

Wrong-destination redirects

Not every broken redirect throws an error. Some quietly send visitors to the wrong page — an old post redirected to the homepage by a catch-all rule instead of to its actual replacement. It looks fine, under-delivers for visitors, and throws away the topical relevance the old URL had. Google can treat a redirect to an irrelevant page as a soft 404.

What a bulk redirect checker reports

HTTP status code. 301 is a permanent redirect, 302 temporary, 404 not found, 200 loaded with no redirect. If you expected a redirect and got a 200, the rule is missing; if you expected a page and got a 404, you have found a real problem.

Chain length. How many hops before the final destination. One is ideal; three or more is worth fixing.

Final destination. Where the URL actually ends up. Compare it with where you meant it to land.

Loop detection. A good checker flags loops explicitly instead of hanging on them.

Status at each hop. Some tools show every hop, not just the start and end. You need that to see where a chain goes wrong.

Step-by-step bulk redirect audit

Step 1: Build the URL list. Combine your old sitemap, every URL that got traffic in analytics over the last year or two, the pages Search Console shows as indexed, and any URLs with backlinks. You want every URL that has ever mattered, not just what is live on the new site. Build this list before a migration, while the old site still exists.

Step 2: Include the variations. Add the http:// versions, www and non-www, trailing-slash variants and any heavily used parameter URLs (old campaign links, for example). These often behave differently from the clean URL.

Step 3: Load the list into a bulk checker. Most accept a pasted list or a CSV/TXT file with one URL per line. Free tiers often cap batch size, so large migrations may need several batches or a paid tool.

Step 4: Run the check and export. You want a spreadsheet with the original URL, status code, chain length and final destination. This is your working document.

Step 5: Filter for problems. Anything that is not a single-hop 301 to the correct destination: 404s, chains longer than one hop, loops, 302s on permanent moves, and destinations that do not match your redirect map.

Step 6: Prioritize by value. A broken redirect on a page that had traffic or backlinks needs fixing today. One on a page nobody visited can wait.

Step 7: Fix, then re-run the same list. Confirm the problems are actually gone instead of assuming the fix worked.

How to fix what you find

Chains: point the original URL directly at the true final destination, then remove the intermediate rules so they do not confuse the next audit.

Loops: trace the rules to find the circular reference — usually two rules written without accounting for each other — and point one of them at the real destination.

Redirects to 404s: check whether the intended page exists under another URL and update the rule. If the content is gone, redirect to the closest relevant page; if nothing relevant exists, a clean 404 or 410 is better than a misleading redirect.

Wrong destinations: update the specific rule. Replace catch-all rules that send whole sections to the homepage with one-to-one mappings where the old pages had traffic or links.

302s on permanent moves: change them to 301s. Both get visitors to the destination, but a 302 signals the move is temporary.

The best bulk redirect checker tools compared

Most tools in this category are decent. The differences that matter are narrow: how many URLs per check, whether you can export, whether it shows every hop, and whether it can re-check on a schedule. Prices change often, so check each vendor's site; the table sticks to how each tool works.

Screaming Frog SEO Spider

The closest thing to a standard for redirect audits. A desktop crawler (Windows, Mac, Linux) that either crawls your whole site or takes a pasted or uploaded list in list mode. You get status codes for every URL, a dedicated redirect chains report and loop detection, all exportable. The free version crawls up to 500 URLs, which covers small sites; the paid licence removes the cap and adds scheduling. It runs on your own machine, so very large crawls are slow, and there is no built-in alert if a redirect breaks later.

Ahrefs Site Audit and Semrush Site Audit

Both crawl your site in the cloud and report redirect chains, loops and redirects to 404s as part of a wider technical audit. Their advantage is context: Ahrefs can tell you which broken redirects sit on URLs with backlinks, and both can run on a schedule. Their drawback is scope and cost if redirect checking is all you need. If you only need your own site, Ahrefs Webmaster Tools gives you Site Audit free for sites you verify.

httpstatus.io

A purpose-built web app: paste a list of URLs, get the status code, full chain and response headers for each, with no installation. The free tier handles smaller batches; paid plans raise the limits. A lean, focused option when you do not need a full SEO platform.

cURL (command line)

Free, installed on most Mac and Linux machines, and unlimited. A short loop checks a file of URLs and writes a tab-separated report:

while read -r url; do
  result=$(curl -s -o /dev/null -L --max-redirs 10 \
    -w '%{http_code}\t%{num_redirects}\t%{url_effective}' "$url")
  printf '%s\t%s\n' "$url" "$result"
done < urls.txt > redirects.tsv

Each line shows the original URL, the final status code, the number of hops and the final URL. A URL that hits the 10-redirect limit is almost certainly in a loop. You build the reporting yourself, but there is no batch cap.

Redirect Path and WhereGoes

Redirect Path is a free browser extension that shows the chain for the page you are viewing. WhereGoes traces one URL with a clear hop-by-hop display. Neither is a bulk tool; both are good for debugging a specific URL your bulk check flagged. Our free Redirect Checker belongs in this group: one URL at a time, every hop with its status code, and flags for loops, chains, 302s used for permanent moves and redirects that land on an error.

Free vs paid: what works at scale

Free tiers across this list top out somewhere between a few hundred URLs and low thousands per check, or limit chain detail. For a small redesign or spot-check, that is enough. For a full migration with thousands of URLs, you are choosing between a paid tool, a cURL script, or running a free tool in batches — which works, but costs more of your time than one paid run. If you only migrate once every few years, many tools offer monthly billing: pay for one month, run the audits, cancel.

Which tool for which job

One-off migration audit: Screaming Frog in list mode, if you are comfortable with a desktop tool. httpstatus.io for smaller batches in a browser. A cURL script if you want no limits.

Ongoing monitoring: a scheduled crawl in Ahrefs or Semrush if you already pay for one, or Screaming Frog's paid scheduler. Spot-check flagged URLs with Redirect Path or WhereGoes.

Staging sites: a desktop crawler, since you can enter basic-auth credentials and it runs from your network. Cloud tools often cannot reach a password- or IP-protected staging site.

How often to re-audit

Redirect problems surface fast after a migration, as search engines recrawl old URLs and analytics starts showing 404 hits. Run a full bulk check two to four weeks after launch and again at about three months.

After that, quarterly suits most sites, to catch rules lost in a later plugin change, server move or redesign. If your URLs rarely change, twice a year is enough; if you restructure content or run many campaign URLs, monthly is worth it. And check every time you delete a page, merge two posts or change a slug — a single broken redirect takes seconds to catch on the day and costs traffic if it waits for the next audit.

Common mistakes during a bulk redirect audit

Building the URL list too late. After the migration you are reconstructing history from analytics and guesswork. Build the master list while the old site is live.

Trusting the redirect map instead of the live result. A spreadsheet of old-to-new URLs is a plan. Typos, server configuration and caching can make the live behavior differ. Check the live URLs after deployment.

Checking a sample. Twenty URLs out of two thousand tells you about twenty URLs. Problems cluster around URL patterns a bulk rule did not quite match, and samples miss them.

Letting the old domain lapse. Redirects only fire while the old domain resolves. Keep the old domain and its rules live for at least a year, longer if it has valuable backlinks.

Forgetting protocol, www and trailing-slash variants. These are exactly the transitions migrations break.

Where RankHive fits

RankHive is not a redirect checker. It does not crawl for chains, loops or broken redirects, so keep one of the tools above for that. Where RankHive touches redirects is the merge case on a WordPress site: when two of your pages compete for the same search in Search Console, it drafts a 301 from the weaker page to the stronger one, with both pages' numbers attached. Nothing changes until you approve it, every redirect is logged, and the Change Log can turn it off again.

FAQ

How many URLs need a bulk checker instead of manual checking?

There is no hard line, but past twenty or thirty URLs manual checking wastes real time. A section redesign (dozens of URLs) up to a full migration (thousands) is bulk-checker territory.

What's a healthy redirect chain length?

One hop. Two is tolerable. Three or more is worth fixing for the performance cost and because long chains are less reliably followed.

Do 302s behave differently from 301s in an audit?

A checker reports both the same way. The difference is intent: 301 signals a permanent move and is right for migrations; 302 signals a temporary one. Flag 302s on permanent changes.

Should I check redirects before or after a migration goes live?

Both. Before, check the planned map against the full list of old URLs to catch gaps. After, check the live site to confirm the rules deployed as planned.

Can a bulk redirect checker find broken internal links too?

Full-site crawlers (Screaming Frog, Ahrefs, Semrush) report broken links, duplicate titles and more in the same crawl. List-based checkers (httpstatus.io, cURL) only check the URLs you give them.

Is it bad to keep lots of old redirects forever?

No. Clean, single-hop 301s can stay indefinitely, and removing them can break old links. The problem is redirects that are chained, broken or pointing to the wrong place.

Do redirect checkers distinguish mobile from desktop?

Most do not, because server-level rules apply the same way to every device. If your site redirects mobile visitors differently, run the check with a mobile user agent; Screaming Frog and some other crawlers let you set one.

What export format should I look for?

CSV opens in any spreadsheet and is easy to filter and share. Avoid tools that only show results on screen for anything you need to act on systematically.

Your job is to keep every old URL landing on the right page in one hop. Run the audit above on a schedule with whichever tool fits, and if part of the work is merging WordPress pages that compete for the same search, let RankHive draft those redirects and ship them after you approve them.