Bulk Redirect Checker — Check Every Redirect After a Migration
Upload your old-to-new URL mapping and verify every redirect is working correctly — right status code, right destination, destination returning 200. Free, no account needed.
Up to 100 URL pairs per batch. CSV and XLSX supported. Status codes default to 301 if not specified.
The Two Types of Redirect Problems
After a site migration, redirect problems fall into two categories, and they require different approaches to catch.
Discovery problems — you don't know what a URL is doing.
Maybe you suspect a redirect loop. Maybe you're not sure if a URL is redirecting at all. For this, use the Bulk URL Status Checker, which shows you what any URL does when you request it.
Validation problems — you know what a URL should do, but you need to confirm it's actually doing it.
You have a redirect map: 100 old URLs each mapped to a specific new URL with a specific status code. You need to verify every single one. For this, use this tool: paste or upload your map and get a row-by-row verdict.
What This Tool Checks
Four sequential checks per URL pair. The first failing check determines the result badge.
- Does the old URL actually redirect?
- The first check is whether the source URL returns a 3xx status code at all. If it returns 200, the redirect isn't in place — the page is live at the old URL. If it returns 404, the old URL is broken. Either way, the redirect is not working.
- Is the status code correct?
- A 301 (permanent) redirect tells search engines to transfer ranking signals to the new URL. A 302 (temporary) redirect does not — link equity stays at the old URL. The tool checks whether the actual redirect type matches what you specified. A 302 is flagged as a warning (not a failure) because 302 may be intentional for genuinely temporary moves.
- Does the redirect go to the right place?
- Even if the redirect type is correct, the URL might point to the wrong destination. This is common when redirect rules in .htaccess or a redirect plugin have a pattern match that works for most URLs but misfires on some. The tool compares the actual final URL against the expected final URL.
- Is the destination working?
- The last check is whether the destination URL itself returns a 200 OK. A redirect that leads correctly to its intended destination but that destination returns a 404 still fails the migration. This check catches broken destination pages that need to be fixed independently of the redirect rules.
How to Prepare Your Redirect Map
The tool accepts a CSV or XLSX file with two or three columns. No headers are required, but they are supported and auto-detected.
| Column | Name | Value | Required? |
|---|---|---|---|
| A | Old URL | Full URL of the source. Must include https:// | Required |
| B | New URL | Full URL of the expected destination. Must include https:// | Required |
| C | Status Code | Expected redirect type: 301 or 302. Defaults to 301 if blank. | Optional |
The quickest way to build this file is to start from the redirect map you used to plan the migration. If you used a spreadsheet to map old URLs to new URLs before implementation, add a column for the expected status code and upload it directly here. The tool ignores any extra columns.
Understanding the Result Badges
Each row gets exactly one verdict. The badge tells you the type of problem; the expanded row view shows the full redirect chain.
All checks passed: the old URL redirects, the status code matches what you specified, the redirect points to the correct destination, and the destination returns a 200 OK.
The old URL redirects, and the status code may be correct, but the final URL does not match your expected destination. Check your redirect rules for this specific URL — a pattern match may be misfiring.
The old URL returns a 4xx or 5xx error directly — it is not redirecting and it is not serving content. The redirect rule for this URL was either never implemented or has been misconfigured as an error rather than a redirect.
The redirect is working and goes to the correct destination, but the status code is 302 instead of 301 (or vice versa). If 302 was intentional, dismiss this warning. If it should be permanent, update the redirect rule in your server configuration.
The old URL returns a 200 OK instead of a redirect. The page is still live at the old address and is not redirecting anywhere. This can happen when redirect rules were deployed to a CDN or proxy but the origin server still serves the old content, or when a redirect plugin is not active for this URL.
The redirect is correct in every way — right type, right destination — but the destination itself returns a 4xx or 5xx error. This is a content problem, not a redirect problem: the destination page needs to be fixed or the redirect map updated to point to a working page.
The expected new URL was reached but it then redirects to yet another URL — meaning the destination you specified isn't a stable endpoint. Update your redirect map to point directly to the true final URL so you don't chain two redirects together.
The redirect eventually lands on the correct destination with the right status code, but it goes through one or more intermediate URLs to get there (old → intermediate → new instead of old → new). Chains waste crawl budget, add latency for users, and dilute link equity at each hop. Expand the row to see the full chain and update your redirect rule to point directly to the final destination.
When Should You Run This Tool?
Before launch. Test your redirect map against a staging or pre-production environment where the redirect rules have been deployed. Catch misconfigured patterns before real users and search engines hit them.
On launch day. After switching DNS or going live, run the full redirect map against the live site. This is the most important check: it confirms the production environment has the same redirect configuration as staging.
One week after launch. Repeat the check after Google has started recrawling. Some redirects may have worked initially but been disrupted by cache invalidation, CDN configuration changes, or CMS plugin updates.
After any major platform update. CMS upgrades, plugin updates, or server configuration changes can silently break existing redirects. Monthly re-validation of your redirect map catches these regressions.
Related tools in your workflow:
- → Bulk URL HTTP Status Checker — not sure what your URLs are currently doing? Discover redirects first
- → Bulk Indexability Checker — after confirming redirects, verify the new pages are fully indexable
- → Robots.txt Validator — make sure your robots.txt isn't blocking the new URLs
- → XML Sitemap Checker — verify your sitemap reflects the new URL structure
Frequently Asked Questions
What is the difference between this tool and the Bulk URL Status Checker? ▾
The Bulk URL Status Checker shows you what a URL does: paste in a list of URLs and see what status code each one returns and where it redirects to. It's a discovery tool — useful when you don't know what a URL is doing. The Bulk Redirect Checker is a confirmation tool — you already know what each URL should do (because you have a redirect map), and you want to verify that it's actually doing it. The Bulk Redirect Checker compares actual behaviour against expected behaviour and tells you where there's a mismatch.
Why does the tool flag 302 redirects as a warning rather than a failure? ▾
A 302 redirect is a temporary redirect — it signals to search engines that the move is not permanent, so link equity stays at the source URL. In most migration scenarios, 301 permanent redirects are the correct choice. However, 302 redirects are sometimes intentional — for A/B tests, seasonal campaign pages, or pages that will return to their original URL. Since the tool doesn't know whether your 302 is intentional, it flags it as a warning for you to review rather than automatically marking it as wrong.
What happens if a redirect chain has more than one hop? ▾
The tool follows redirect chains up to 5 hops deep. The result is based on the final destination URL and status code — the comparison against your expected final URL uses the actual endpoint after all hops are resolved. If a URL redirects through multiple steps before reaching the expected destination, it still passes as long as the status code of the first hop matches, the final URL matches, and the final destination is 200 OK. However, unnecessary redirect hops (A → B → C when A → C would suffice) waste crawl budget. The expanded row view shows the full chain so you can identify and eliminate unnecessary hops.
How many URLs can I check at once? ▾
The free version supports up to 100 URL pairs per batch. This covers most site migrations for small to medium sites. For larger migrations involving thousands of URLs, run the batches in groups of 100, or use Screaming Frog SEO Spider to validate redirects at greater scale.
Does this tool check JavaScript redirects or meta refresh redirects? ▾
No — this tool only checks HTTP-level redirects (3xx status codes in the server response). JavaScript redirects (window.location, react-router navigation) and HTML meta refresh tags are not detected. This is the same limitation Google's own crawlers face: HTTP redirects are processed before any JavaScript executes. If your redirect implementation relies on JavaScript, it may not be processed correctly by Googlebot.