A redirect checker shows you the status codes. That is the easy half. Whether a redirect actually works — whether Google follows it and keeps the page it lands on — is decided by two things no status code shows: the robots.txt of every host on the way, and the index signals of the destination. The tool above reports both, alongside the chain itself.

301, 302, 307, 308: what each one tells Google

A redirect is a response that says “not here, there”. The code says for how long.

• 301 Moved Permanently — the page has moved for good. Google transfers the old URL’s signals to the new one and, over time, replaces the old URL in the index. This is the code for a moved page, a changed slug, a domain migration.
• 308 Permanent Redirect — the same promise as a 301, with one technical difference: the request method is preserved (a POST stays a POST). For a page fetched by a crawler, 301 and 308 are equivalent.
• 302 Found and 307 Temporary Redirect — the page is elsewhere for now. Google keeps indexing the old URL and comes back to check. Right for a maintenance page, an A/B test, a geo hand-off. Wrong for a page that has moved, because you are asking Google to keep the address you just abandoned.
• 303 See Other — a redirect after a form submission. It should not appear on a page URL at all.

Google has said since 2016 that no PageRank is lost through any 3xx redirect, so the old fear that a 302 “leaks” value is out of date. What a 302 still does is keep the wrong URL in the index. Google eventually treats a 302 that never changes as permanent, but “eventually” is measured in months, and a 301 says it on day one.

Redirect chains: the http → https → www hop nobody meant to write

Here is the most common chain on the web:

http://example.com/page      301 →  https://example.com/page
https://example.com/page     301 →  https://www.example.com/page
https://www.example.com/page 200

Nobody designed it. One rule upgrades HTTP to HTTPS; another rule adds the www. Each is correct on its own, and together they charge every old link two round trips before the page starts loading. The fix is one rule that sends http://example.com/page straight to the final URL.

Googlebot follows up to ten hops in a chain, then gives up and reports a redirect error. Long before ten, a chain is already costing you: each hop is a separate request, a separate delay, and on a large site a separate slice of crawl budget. A single hop is the shape to aim for; two is worth fixing; five is a bug.

Loops

A loop is a chain that arrives back where it started: /a to /b to /a. Nothing ever loads, for anyone. The usual causes are two rules that disagree — an HTTPS rule and a www rule pointing in opposite directions — or a cookie check that redirects clients without cookies to a page that sets the cookie and redirects back. Googlebot does not keep cookies, so a chain that works in your browser can loop for Google. The checker above does not keep cookies either, which is the point.

Meta refresh and JavaScript redirects

Not every redirect is sent by the server. A page can answer 200 and then forward the visitor from inside the HTML:

<meta http-equiv="refresh" content="0; url=https://example.com/new">

<script>window.location.href = "https://example.com/new";</script>

Google handles both, with caveats. An instant meta refresh (0 seconds) is treated much like a permanent redirect; a delayed one is treated as temporary at best, and the visitor stares at a blank page while it counts down. A JavaScript redirect is only seen once Google renders the page, which happens later than the crawl and costs more. Most other crawlers — link checkers, social scrapers, AI crawlers, monitoring tools — never follow either. If you control the server, send a 301 or 308 instead; it is one line of configuration and it works for every client.

The robots.txt trap: a redirect Google is not allowed to see

This is the check other redirect tools skip, and it is the one that quietly undoes migrations. Google never fetches a URL that robots.txt disallows. So if the URL that redirects is blocked, Google never sees the redirect behind it:

User-agent: *
Disallow: /old-blog/

# /old-blog/post → 301 → /blog/post   ← Google never requests /old-blog/post

The redirect is real, your browser follows it, every redirect checker reports a clean 301 — and Google keeps the old URL in its index exactly as it was, because it is not permitted to ask that URL anything. The new page never inherits the old one’s links. It happens most often after a migration, when someone disallows the retired section “to be safe”, and it is invisible unless you test each hop against the robots.txt of its host. The tool above does, and names the Disallow line when it finds one. To test the other direction — pages your sitemap lists that robots.txt blocks — use the robots.txt & sitemap checker.

What is at the end of the chain

A redirect passes the old URL’s signals to the destination. Whether the destination can hold them is a separate question, and it has four common bad answers.

• A 404 or 410. The redirect works and lands on a page that is gone. Google follows the chain, finds nothing, and drops the old URL along with whatever links pointed at it. Redirect to the page that replaced it, or to the closest live page.
• A noindex. The destination carries <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header. You are redirecting into a page that tells Google to forget it. Usually a staging setting that shipped, or a template-level tag nobody revisited.
• A canonical pointing elsewhere. The destination declares rel="canonical" to a third URL. Google will treat that one as the real page, which makes your one-hop redirect a two-hop chain in disguise.
• The homepage. Redirecting a specific old page to the front door is the reflex fix, and Google treats it as a soft 404: the old URL is dropped and nothing reaches the homepage. If no page replaced the old one, an honest 404 or 410 is better.

Googlebot, smartphones and browsers: who lands where

Some redirects depend on who is asking. Geo routing sends a visitor to a country site; device detection sends phones to m.example.com; and, less innocently, some setups show crawlers one page and people another. Google’s spam policies call the last one a sneaky redirect. The checker follows every chain three times — as desktop Googlebot, as smartphone Googlebot, and as a desktop Chrome — and flags the case where they end on different URLs. Google indexes with the smartphone crawler first, so when phones are sent somewhere else, that somewhere else is the page that counts.

One caveat: many hosts verify Googlebot by IP address and answer 403 or 429 to anything that merely claims to be it. When that happens the report says so and follows the chain as a browser instead. A 403 for this checker says nothing about the real Googlebot; the URL Inspection tool in Search Console is the word on what Google itself sees.

How to test 301 redirects after a migration

1. Export the old URLs — from the old sitemap, from Search Console’s pages report, from your analytics — and write down where each should land. A migration without this map is a guess.
2. Paste them into the bulk mode above, twenty at a time. Every row shows the status chain and flags: chain, temporary, client-side, ends 404, loop.
3. Open anything flagged in the single-URL mode for the full report — the robots.txt check and the destination’s index signals are only run there.
4. Fix, then re-check. Results are cached for ten minutes, so a fix shows up on the next run rather than the next day.
5. Leave the redirects in place. Google’s guidance is to keep them for at least a year; old links do not expire, so there is rarely a reason to remove them at all.

Frequently asked

Does a 301 redirect lose PageRank?

No. Google confirmed in 2016 that 3xx redirects no longer lose PageRank. What a redirect can lose is relevance — a page about one thing redirected to a page about another is treated as a soft 404 — and time, when the chain is long.

How long should a redirect stay in place?

At least a year, per Google, and in practice for as long as anything links to the old URL. Removing a redirect turns every one of those links back into a 404.

Does Google follow JavaScript redirects?

Yes, once it renders the page, which happens after the crawl and not on every visit. It is slower and less certain than a server redirect, and other crawlers do not follow it at all. Use it only when you have no access to the server configuration.

Should I redirect http to https, or www to non-www, first?

Neither — do both in one hop. Whatever the visitor typed, the first response should send them to the final canonical form of the URL: https://, your chosen host, the right path. Two rules that each do half the job are how chains are born.

Why does this checker get a 403 when the page opens fine for me?

Because the site is verifying crawlers. Cloud firewalls answer 403 to a Googlebot user agent from any IP that is not Google’s, and some answer 403 to any automated client. The report follows the chain as a browser when that happens, and says so.

How often is a result cached?

Ten minutes per URL. Fix a redirect, wait a moment, and check again. The bulk mode is not cached at all.