Is there a free bulk redirect checker with no signup?

Yes, this one. You can check up to 100 URLs per run, with no account and no daily limit on the number of runs, so you do not have to split a migration list across several sessions. Results export to CSV.

How many URLs can I check at once?

100 per run. If your list is longer, split it and run it in parts. Each run exports to CSV, so the parts recombine easily in a spreadsheet.

Do redirect chains hurt SEO?

Google’s guidance for large sites is to avoid long redirect chains because they have a negative effect on crawling, and Google’s crawlers follow up to 10 redirect hops by default. So the documented cost is a crawling cost, and a chain that reaches 10 hops will not be followed to the end. Aim for one hop. Beyond crawling, we do not make claims about ranking impact that we cannot source.

Does Google follow meta refresh redirects?

Yes. Google interprets an instant meta refresh as a permanent redirect and a delayed meta refresh as a temporary one. A server-side 301 is still the more reliable choice, and Google advises using JavaScript redirects only when server-side and meta refresh redirects are both impossible. This checker follows meta refresh redirects and marks those steps in the chain.

What is the difference between a 301 and a 308 redirect?

For Google, nothing meaningful: both are permanent, and both are a strong signal that the redirect target should be canonical. The difference is in the request itself. A client may change a POST to a GET when it follows a 301, while a 308 preserves the request method and body. If real POST requests hit the URL, use 308.

Why does this tool show a different redirect than my browser?

Because the check runs from our servers under the user-agent you chose, and a server can vary its response by requesting IP address, geography, user-agent and cookies. A redirect is a response, not a fixed property of a URL, so your browser and this checker can both be right and still disagree. The user-agent and timestamp used for your run are shown above the results.

Can it check redirects for a whole site?

No. It checks the list of URLs you paste. Finding redirects you do not already know about means crawling the site, which is a different job and needs a crawler rather than a list checker.

Can it check the URLs in my sitemap?

Not directly. Our sitemap checker finds your sitemap and live-checks the URLs in it, including the ones that redirect, so use that when the list you care about is everything in your sitemap. Use this tool when you already have a list of your own, or an old-to-new mapping to verify.

Does a working redirect mean the new URL will be indexed?

No. A redirect can resolve perfectly onto a page that is set to noindex, canonicalises to a different URL, or is blocked in robots.txt. That is why this checker reports the destination’s canonical tag, X-Robots-Tag header and meta robots tag alongside the status code.

Free tool

Bulk Redirect Checker

Paste up to 100 URLs, one per line. We trace every hop, flag loops, and tell you which results are a problem. Up to 100 URLs per run, no signup, no daily limit.

URLs to check, one per line

0 / 100 URLsUp to 100 URLs per run. No signup. No daily check limit.

Check as

What this bulk redirect checker does

A bulk redirect checker tests many URLs at once and reports what each one does: the status code, every redirect hop along the way, and the URL you finally land on. This one also gives you a verdict for each result, so you finish with a decision rather than a column of numbers.

The full chain. Every hop in order, with its status code, destination and response time. A hop is one redirect: a single request that answers with a 3xx status and points somewhere else. Two hops means two redirects before you arrive.
Loop detection. If a URL sends you back somewhere you have already been, the check stops and tells you which step the loop starts at.
The final status and URL. Where the chain actually ends, and what that destination returned.
Indexability of the destination. The final URL’s canonical tag, X-Robots-Tag header and meta robots tag, so you can see whether the page you land on can be indexed at all.
Meta refresh support. Not every redirect is a 3xx. If a page redirects with a meta refresh tag, we follow it and mark that step in the chain.
Your choice of user-agent, including Googlebot, so you can see what a crawler is served rather than what a browser is served.
A verdict, with the reason and the fix.

What it does not do: it does not crawl your site to find redirects you do not already know about. It checks the list you give it. If you need to discover unknown redirects across an entire site, you need a crawler rather than a list checker.

How to read your results

Every URL gets one verdict, set by the most serious thing we found, plus any other notes that apply.

Verdict	What it means	Typical cause	What to do
OK	No redirect, or a single hop ending on a working page	http to https, or apex to www	Nothing
Check	It works, but something about it may not be what you intended	A temporary redirect on a permanent move, a destination that canonicalises elsewhere, or a meta refresh	Confirm it is deliberate
Fix	It works today but is costing you something	A chain of two or more hops, a destination set to noindex, or a URL that landed somewhere other than the target you supplied	Change it
Broken	It does not work	A loop, a dead end (4xx), a server error (5xx), or a chain that reaches Google’s 10-hop limit	Fix before you ship
Blocked	We could not get a reliable answer	The host rate-limited us (429), a bot-protection layer intercepted the request, or the connection timed out	Re-run, or check that URL from inside your own network. Treat it as unknown, not as a pass

That last row matters more than it looks. A rate-limited request is not a successful check. Some tools count a 429 as a pass, which quietly turns an unverified URL into a green tick. We label it and tell you the result is not reliable.

How many redirects will Google follow?

By default, Google’s crawlers follow up to 10 redirect hops. Google adds two qualifications: specific products’ crawlers may have different limits, and Google Inspection Tools does not follow redirects at all. So a chain that reaches 10 hops is a hard failure for crawling, and a chain that is merely long is a soft one.

Ten is a ceiling, not a target. Google’s own guidance for large sites is to avoid long redirect chains because they have a negative effect on crawling. In practice, aim for one hop. Every URL in a two-hop chain can usually be pointed straight at its final destination, which removes a request for every visitor and every crawler.

One thing we will not tell you, because we cannot source it: how much ranking value a chain costs. Google documents the cost of long chains in terms of crawling. We have not found a Google statement putting a number on lost ranking signal, so we do not repeat the versions of that claim you will see elsewhere.

301, 302, 307 and 308 compared

Two different things get confused here. Permanence is about how Google treats the redirect for canonicalisation. Method preservation is about what your browser or client does with a POST request. They are not the same axis, so both are shown.

Code	Permanence	Google’s canonicalisation signal	Request method on POST	Use when
301 Moved Permanently	Permanent	Strong. Google uses the target as the canonical URL	The client may change POST to GET	The move is permanent and you want the new URL indexed
308 Permanent Redirect	Permanent	Strong. Google treats it as equivalent to 301	Method and body are preserved	Same as 301, but the request is an API call or a form POST that must survive
302 Found	Temporary	Weak. Google does not treat the target as canonical on this basis	The client may change POST to GET	The original URL is coming back
307 Temporary Redirect	Temporary	Weak, like 302	Method and body are preserved	A temporary move that must not turn a POST into a GET
303 See Other	Temporary	Weak, like 302	The client must change the method to GET	After a form submission, to send the user to a result page
Instant meta refresh	Google reads it as permanent	Treated as a permanent redirect	n/a	Only when you cannot set a server-side redirect
Delayed meta refresh	Google reads it as temporary	Treated as a temporary redirect	n/a	Avoid

The single most common real mistake this table catches: a permanent move served as a 302. It works, users never notice, and Google treats the destination as a weak signal rather than the canonical URL. This checker flags any temporary code in a chain as Check for exactly that reason.

When a redirect lands somewhere that cannot be indexed

A 200 at the end of a chain means the request succeeded. It does not mean the destination can rank. Three ways a technically correct redirect still fails:

The destination is set to noindex, in a meta robots tag or an X-Robots-Tag header. The redirect works perfectly and the page is still excluded from search. This is common on staging templates that reach production, and on paginated or filtered pages used as redirect targets.
The destination canonicalises somewhere else. You redirect /old-product to /new-product, and /new-product carries a canonical pointing at /category/new-product. Your redirect is now two steps away from the URL Google will actually index.
The destination is disallowed in robots.txt. Google can be told to go there and told not to crawl it at the same time.

We report the destination’s canonical, X-Robots-Tag and meta robots for every checked URL, because a redirect audit that stops at the status code misses all three. If you need a full picture of a single destination, run it through our indexability checker, or check the canonical specifically with the canonical tag checker.

Check a redirect map, not just a list

Most redirect checkers answer one question: does this URL redirect? On a migration, that is the wrong question. You already know the URL redirects. You need to know whether it redirects to the URL you intended.

Switch the tool to Redirect map mode and paste pairs instead of single URLs:

https://old.example.com/blue-widgets,https://example.com/products/blue-widgets
https://old.example.com/red-widgets,https://example.com/products/red-widgets

Each row is checked and then compared against the destination you supplied. You get Match or Mismatch, and where there is a mismatch, both URLs side by side. A row that redirects perfectly to the wrong page is a Fix, not an OK.

So that a Mismatch is worth trusting, here is exactly what we treat as the same URL by default:

Scheme and hostname are compared case-insensitively.
Default ports (:80 on http, :443 on https) are removed.
A trailing slash is ignored.
The fragment (anything after a #) is ignored, because it is never sent to the server.
Common tracking parameters (utm_*, gclid, fbclid) are ignored.
Internationalised domains are compared in their ASCII form.
Path case is respected, because paths are case-sensitive on most servers and ignoring it would hide a real class of migration bug.
Any other query parameter is respected.

Each of those can be switched off under advanced options. If you turn strict comparison on, the two URLs must match character for character.

Why your results may differ from your browser

Because this check runs from our servers, not from your machine. A redirect is not a fixed property of a URL. It is a response, and a server can vary its response by requesting IP address, geography, user-agent, cookies and login state. Your browser and this checker can both be right and still disagree.

This is not theoretical. On 29 July 2026 we requested http://google.com from four independent clients within a few minutes of each other:

Client	Result
A public redirect checker	301 to 302 to 200, two hops, ending on https://www.google.com/?gws_rd=ssl
A second public redirect checker	301 to 200, one hop
A third public redirect checker	429, rate limited, ending on a bot-protection page
A direct request from our own client, run under two different user-agents	301 to 200, one hop

Four clients, three different answers, same URL, same day. Nothing was broken. The third tool’s requests were being throttled at its own egress address. We did not isolate which factor caused each difference, so we describe what we observed rather than explaining more than we can support.

It gets narrower than that. On the same day we ran the same URL through two different HTTP clients on one machine, on one network, sending the same user-agent string, within the same minute. One returned 301 to 200. The other returned 301 to 302 to 200, picking up an extra hop to HTTPS. So if this checker reports a different chain than the one you see in your browser, that on its own tells you nothing is wrong with either. It tells you a redirect is a response, not a property of a URL.

What this means in practice:

When two tools disagree, check the user-agent first. It is the variable you control and the one most likely to change the answer.
A result from any tool describes one vantage point at one moment. Ours states the user-agent and timestamp above the results table for exactly this reason.
If a URL only misbehaves from outside your network, suspect a CDN rule, a geo rule or a bot-protection layer rather than your redirect configuration.

When to run a bulk redirect check

Before a migration cutover, against staging, so you find the wrong mappings while they are still cheap to fix.
Immediately after the cutover, against production, because staging rules and production rules diverge more often than anyone expects.
After an HTTPS or www change, where a single misconfigured rule turns every URL on the site into a two-hop chain.
After an e-commerce or CMS restructure, when category and product URLs move in bulk and the old ones are still earning links.
As part of deploy QA, on the URLs in your marketing emails, ads and documentation, which break silently and are noticed last.

How this tool works

No redirect checker we tested publishes its method. Here is ours.

Where requests come from: Our servers, not your browser. The user-agent used is stated with each run.
User-agent: Whichever you select. The default is a standard desktop browser string, and the exact string used is shown above your results.
Method: GET by default. HEAD is available under advanced options, but returns no page body, so canonical, meta robots and meta refresh cannot be read.
Hop limit: We follow up to 10 hops, matching the limit Google documents for its own crawlers, and report the chain as Broken if it gets that far.
Timeouts: Each request times out after 8 seconds, and each URL has a 13 second budget for its whole chain. A timeout is reported as Blocked, never as a pass.
Redirect types followed: HTTP 3xx responses and meta refresh. JavaScript redirects are not executed, because we do not render pages, and we say so rather than guessing.
Cookies: Not sent.
What we store: Submitted URLs are held only for as long as the run and its rate-limiting window require, and are not used for anything else. Do not paste credentials in query strings.
Limits: 100 URLs per run, checked in batches of 10. There is no signup and no daily check quota, only a generous per-address fair-use cap.

Frequently asked questions

Is there a free bulk redirect checker with no signup?: Yes, this one. You can check up to 100 URLs per run, with no account and no daily limit on the number of runs, so you do not have to split a migration list across several sessions. Results export to CSV.
How many URLs can I check at once?: 100 per run. If your list is longer, split it and run it in parts. Each run exports to CSV, so the parts recombine easily in a spreadsheet.
Do redirect chains hurt SEO?: Google’s guidance for large sites is to avoid long redirect chains because they have a negative effect on crawling, and Google’s crawlers follow up to 10 redirect hops by default. So the documented cost is a crawling cost, and a chain that reaches 10 hops will not be followed to the end. Aim for one hop. Beyond crawling, we do not make claims about ranking impact that we cannot source.
Does Google follow meta refresh redirects?: Yes. Google interprets an instant meta refresh as a permanent redirect and a delayed meta refresh as a temporary one. A server-side 301 is still the more reliable choice, and Google advises using JavaScript redirects only when server-side and meta refresh redirects are both impossible. This checker follows meta refresh redirects and marks those steps in the chain.
What is the difference between a 301 and a 308 redirect?: For Google, nothing meaningful: both are permanent, and both are a strong signal that the redirect target should be canonical. The difference is in the request itself. A client may change a POST to a GET when it follows a 301, while a 308 preserves the request method and body. If real POST requests hit the URL, use 308.
Why does this tool show a different redirect than my browser?: Because the check runs from our servers under the user-agent you chose, and a server can vary its response by requesting IP address, geography, user-agent and cookies. A redirect is a response, not a fixed property of a URL, so your browser and this checker can both be right and still disagree. The user-agent and timestamp used for your run are shown above the results.
Can it check redirects for a whole site?: No. It checks the list of URLs you paste. Finding redirects you do not already know about means crawling the site, which is a different job and needs a crawler rather than a list checker.
Can it check the URLs in my sitemap?: Not directly. Our sitemap checker finds your sitemap and live-checks the URLs in it, including the ones that redirect, so use that when the list you care about is everything in your sitemap. Use this tool when you already have a list of your own, or an old-to-new mapping to verify.
Does a working redirect mean the new URL will be indexed?: No. A redirect can resolve perfectly onto a page that is set to noindex, canonicalises to a different URL, or is blocked in robots.txt. That is why this checker reports the destination’s canonical tag, X-Robots-Tag header and meta robots tag alongside the status code.

After you fix the redirects

Fixing a redirect is only half the job. The URLs still have to get indexed, and that is where a migration usually goes quiet: the redirects are correct, and the new URLs sit unindexed for weeks while nobody is watching.

Once your verdicts are clean, run the destinations through our bulk index checker to see which of them Google has actually indexed. If you would rather be told when one of them drops out, that is what SearchOptimo does.

Sources

Google Search Central: Redirects and Google Search. Redirect types, permanence, meta refresh interpretation, JavaScript redirect guidance.
Google Search Central: HTTP status codes, network and DNS errors. The 10-hop crawler limit, and the strong versus weak signal treatment of 301, 302, 303, 307 and 308.
Google Search Central: Large site owner’s guide to managing crawl budget. Guidance on avoiding long redirect chains.
IETF RFC 9110: HTTP Semantics, sections 15.4.2, 15.4.3, 15.4.4, 15.4.8 and 15.4.9. Request-method behaviour for each redirect status code.

Facts last verified: 29 July 2026. Found something wrong? Tell us and we will correct it and note the change here.

SearchOptimo sells index monitoring. This tool is free and requires no account.