Redirect Error (GSC Status)

TL;DR — “Redirect error” in Google Search Console means Google tried to follow a redirect for your page but couldn’t — the redirect was broken in some way — so the page didn’t get indexed. It’s something to fix. Don’t confuse it with “Page with redirect,” which is a normal redirect that’s working fine.

What “Redirect error” means

This label means Google encountered a redirect it could not successfully follow to a destination. Evidence for this claim Google reports Redirect error when it could not process a redirect to a destination. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google’s report lists long chains, loops, excessive URL length, and bad or empty redirect URLs as examples. Evidence for this claim Google lists overly long chains, loops, excessive redirect URL length, and bad or empty redirect URLs for this report status. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

When you open the Page Indexing report in Google Search Console (it’s under “Indexing” in the left menu), Google groups the URLs it didn’t index by reason. Redirect error is one of those reasons.

It means Google found a redirect on your URL — a rule that sends visitors from one address to another — and tried to follow it, but couldn’t get to the end. Maybe the redirect pointed to another redirect, which pointed to another, on and on. Maybe two pages redirect to each other in a loop. Maybe the address it was sent to was broken or empty. Whatever the cause, Google gave up, so the page can’t be indexed.

The one thing people get wrong

There’s a different status called “Page with redirect” — and people mix the two up constantly. Here’s the difference in plain terms:

• Redirect error = a broken redirect Google couldn’t follow. You need to fix this.
• Page with redirect = a normal, working redirect. Google followed it fine; the URL just isn’t the “main” version, so it isn’t indexed (the page it points to might be). This is not an error and usually needs no action.

So if you see “Page with redirect,” don’t panic — that’s often exactly what you want. “Redirect error” is the one that means something’s actually broken.

What to do about it

The fix is almost always the same idea: make the redirect go straight to the final page in one hop, instead of bouncing through a chain or looping.

1. Open the URL Inspection tool in Search Console (or just visit the URL in your browser) to see what’s happening.
2. Find where the redirect breaks — the loop, the broken address, or the long chain.
3. Replace it with a single redirect (a 301) pointing directly at the final, working page.
4. Update your own internal links so they point at that final page too.
5. Back in Search Console, click Validate Fix to ask Google to re-check.

Want the technical version — Google’s exact four causes, how to trace a chain on the command line, and the truth about how many redirects Google will follow? Switch to the Advanced tab.

TL;DR — “Redirect error” is a Google Search Console Page Indexing status: Googlebot tried to follow a redirect and couldn’t resolve it, so the page isn’t indexed. Google names four causes — a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the max URL length, or a bad/empty URL in the chain. It is a broken redirect to fix, and it is distinct from “Page with redirect,” which is a working, non-canonical redirect that’s normal and usually needs no action. Diagnose by tracing the chain (curl -IL, URL Inspection, Lighthouse, a crawler), collapse it to a single direct 301 to the final URL, fix internal links, and run Validate Fix. On hop limits: current Google docs publish a 10-hop ceiling and recommend no more than 3/fewer than 5. Mueller’s dated 2014 and 2020 statements describe about five per crawl; the 2014 one also described continuing the remainder later. Patrick’s similar observations are independent. Aim for one hop regardless.

Where this status lives

“Redirect error” appears in Search Console under Page Indexing → “Why pages aren’t indexed.” That table breaks the not-indexed URLs into reasons, and this is one of them. The takeaway up front: it’s a crawl/follow failure, not a quality judgment. Google isn’t telling you the page is low-quality or penalized — it’s telling you it literally couldn’t follow the redirect to a destination, so there was nothing to index.

Google’s four causes — exactly

These are Search Console’s documented report causes, not a universal taxonomy for every redirect implementation bug. Evidence for this claim Google reports Redirect error when it could not process a redirect to a destination. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google separately recommends short, direct redirect paths. Evidence for this claim Google lists overly long chains, loops, excessive redirect URL length, and bad or empty redirect URLs for this report status. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

Google’s Page Indexing documentation is specific. A redirect error means Google experienced one of the following: a redirect chain that was too long, a redirect loop, a redirect URL that eventually exceeded the max URL length, or a bad or empty URL in the redirect chain. That’s the whole list — four failure modes, and every fix maps back to one of them. (The exact wording is in the Quotes tab.)

”Redirect error” vs “Page with redirect” — the contrast that matters most

This is the single most common confusion in the topic, so it’s worth being blunt about it. These are two different Page Indexing statuses:

• Redirect error — Google couldn’t follow the redirect (one of the four causes above). The page can’t be indexed. It’s broken; fix it.
• Page with redirect — Google could follow the redirect; it worked. The URL is simply a non-canonical URL that redirects elsewhere, so this URL won’t be indexed — but the target might be. Google’s own description of it is that it’s a non-canonical URL that redirects to another page, so it won’t be indexed, while the target URL of the redirect might or might not be indexed depending on what Google thinks of that target. This is not an error and usually needs no action.

If your old URLs that you intentionally 301-redirected show up as “Page with redirect,” that’s the system working as designed — don’t go trying to “fix” it. Save your attention for “Redirect error,” which is the one that’s actually broken. (There’s a side-by-side table in the Cheat Sheets tab.)

The four causes, and how to fix each

1. Redirect chain that was too long. A → B → C → D → … instead of A straight to the final URL. Each hop adds latency and another chance for something to break, and a long enough chain means Google doesn’t reach the destination. Fix: collapse the chain. Point the original URL directly at the final destination in a single 301, and remove or update the intermediate rules.

2. Redirect loop. Two or more URLs that redirect back to each other — A → B → A, or a longer cycle. In a browser this is the classic ERR_TOO_MANY_REDIRECTS / “too many redirects” error; Google flags the same root cause. Loops usually come from conflicting rules — HTTP↔HTTPS, www↔non-www, or trailing-slash↔no-slash rules fighting each other. Fix: find the cycle, decide on the single canonical form (e.g. HTTPS, non-www, trailing slash — pick one of each), and make every rule point one direction only.

3. Redirect URL exceeded the max URL length. A redirect that keeps appending to the URL — faulty rewrite rules, runaway query/tracking parameters, or a rule that re-feeds its own output — can grow the target URL past the length limit. This often overlaps with a loop. Fix: find the rule that’s appending parameters and stop it; strip unnecessary tracking params from the redirect target; redirect to a clean, fixed final URL.

4. Bad or empty URL in the redirect chain. Google’s own wording here is generic — a “bad or empty URL” — and it doesn’t name relative URLs as an example. A relative Location value is valid HTTP (the spec has recipients resolve it against the current URL), so relativity by itself isn’t the problem. What actually breaks a hop: an empty Location, a value that doesn’t resolve to any real URL, or a rule that emits garbage instead of a usable target. Fix: trace the hop and confirm exactly what the broken Location value is, then correct the rule so it emits a valid, resolvable target — absolute is the safer default, but the defect is “doesn’t resolve,” not “isn’t absolute.”

How many redirects does Google actually follow?

This is where bad numbers get repeated, so I want to be careful — and this section changed since I last checked it. Google’s crawling-infrastructure documentation now publishes a default: “By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits.” It adds that Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn’t follow redirects at all — so the number even depends on which Google tool is doing the fetching.

Google’s current site-move documentation adds the practical target: avoid chains; if that isn’t possible, keep them to no more than 3 and fewer than 5. That is not another technical ceiling. Ten is what the current crawler documentation says Googlebot can follow; 3-to-5 is the current implementation recommendation.

The familiar five-hop number has a separate, dated evidence trail. In a 2014 webmaster hangout at 46:03, John Mueller described Googlebot following as many as five redirects in one crawl and continuing any remainder in the next crawl. In 2020 he separately said Google follows up to about 5 hops per crawl attempt, and advised fewer than 5 for URLs that are crawled frequently. The 2014 continuation statement was real, not an invented breakdown. But both statements are historical representative guidance; neither is a current guarantee that every long chain will resume, or when.

My own practical cutoff, from years of fixing these, is also around 5 hops, and I’ve independently seen Google pick longer chains back up. Those are practitioner observations, not the basis for Mueller’s 2014 statement and not a platform limit.

None of this changes the practical advice: redirect directly to the final URL in a single hop. One hop sidesteps the entire question about how many the crawler will follow, and it’s faster for users too.

How to diagnose a redirect error

You want to see the redirect Google is choking on:

• URL Inspection (GSC). Live URL Inspection follows the redirect and tests the final URL — but it doesn’t show you the path it took or name the final URL, so it can’t replace a hop-by-hop trace when you need to see where the chain breaks. (A related but different tool — Google’s crawling infrastructure calls it “Google Inspection Tools” — explicitly does not follow redirects at all; don’t assume every “inspection” surface behaves the same way.) Use it to confirm Google’s overall verdict, not to see the chain.
• curl -IL (or a redirect-checker tool) to trace every hop and status code from the command line — the fastest way to spot a chain or loop. Commands are in the Scripts tab.
• Lighthouse. Google’s own doc suggests using a web debugging tool such as Lighthouse to get more detail about the redirect.
• A crawler — Ahrefs Site Audit, Screaming Frog, or Sitebulb — to surface redirect chains and loops at scale across the whole site, which is how you catch the ones you didn’t know about.
• The browser. A loop shows up immediately as ERR_TOO_MANY_REDIRECTS.

How to fix it, step by step

1. Reproduce the redirect (curl / redirect-checker / browser) and identify the broken hop — the loop, the over-length target, the bad URL, or the chain.
2. Replace the chain or loop with a single direct hop to the final URL — and pick the fix based on what that URL is actually supposed to do, not on autopilot. Permanent move → a single 301 (or 308). Genuinely temporary move → 302/303/307 instead, since Google treats permanent and temporary redirects differently for canonical signals. If the old URL shouldn’t redirect at all anymore, restore it to a real 200; if the content is gone for good with no replacement, a 404/410 can be the right answer instead of forcing a redirect. Whatever you land on, no intermediaries.
3. Update internal links so they point at that final URL — don’t keep linking to the old, redirecting address.
4. Re-test with curl/URL Inspection to confirm a clean single redirect (or a direct 200).
5. Validate Fix in Search Console. Note that this queues a re-check — it doesn’t re-index instantly. Resolution still depends on Google recrawling the URL on its own schedule, so don’t expect an immediate status change.

Where these cluster: site migrations

In my experience the bulk of redirect errors are born during migrations — HTTP→HTTPS moves, www/non-www consolidation, domain changes, CMS replatforms, and trailing-slash changes. That’s where chains and loops accumulate, because you end up with layers of redirect rules stacked on top of each other. The discipline that prevents it: maintain a redirect map and point each old URL directly at its final new URL — not at an intermediate URL that itself redirects. If you redirect old → interim → new, you’ve built a chain on day one.

A note on 301 vs 302 (since it comes up)

A redirect error isn’t about which redirect type you used — it’s about the redirect being unfollowable. But while we’re here: 3xx redirects don’t lose PageRank, and Google can come to treat a 302 like a 301 over time (I’ve run that experiment myself — a long-lived 302 between two established sites behaved like a permanent move). Still, for a permanent move, use a 301 to send the clearest canonical signal. Use the right type, and make it a single hop.

Related statuses and concepts

The sibling status “Page with redirect” (covered above) is the normal, non-error counterpart — keep them straight. A redirect chain is the most common underlying cause here, and the Page Indexing report is the GSC report all of these statuses live in. For the bigger picture of how Google decides what to index, see the indexing hub.

AI summary

A condensed take on the Advanced version:

• “Redirect error” = Google couldn’t follow a redirect, so the page isn’t indexed. It’s a Search Console Page Indexing status under “Why pages aren’t indexed.” It’s a follow/crawl failure, not a penalty or quality judgment.
• Four Google-defined causes: a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the max URL length, or a bad/empty URL in the chain. Every fix maps to one of these.
• Not the same as “Page with redirect.” Redirect error = broken, fix it. Page with redirect = a working, non-canonical redirect that’s normal and usually needs no action. This is the #1 confusion in the topic.
• Fix each cause: long chain → collapse to one direct hop matching the URL’s intended behavior; loop → resolve conflicting HTTP/HTTPS, www, and trailing-slash rules; over-length URL → stop the rule appending params; bad/empty URL → trace the actual broken value and emit a valid, resolvable target (relative isn’t automatically the problem).
• Hop count: Google’s crawling documentation now publishes a default of up to 10 redirect hops for Googlebot (Google Inspection Tools follows none at all), while its site-move doc recommends no more than 3/fewer than 5. Mueller’s dated 2014 and 2020 statements describe about 5 hops per crawl; the 2014 statement also described continuing the remainder later. Patrick’s similar field observation and ~5-hop cutoff are independent. Aim for one hop.
• Diagnose with URL Inspection, curl -IL, Lighthouse, and a crawler (Ahrefs Site Audit / Screaming Frog / Sitebulb) for scale.
• Fix workflow: reproduce → find the broken hop → single direct hop to the final URL, using the redirect type (or non-redirect) that matches intent → update internal links → re-test → Validate Fix (queues a re-check on Google’s own recrawl schedule; not instant).
• They cluster during migrations (HTTPS, www, domain, replatform). Prevent them by mapping each old URL directly to its final new URL — never through an interim redirect.

Official documentation

Primary-source documentation from the search engines.

Google

• Page indexing report — the source for the “Redirect error” definition (the four causes) and the separate “Page with redirect” status, plus the suggestion to use a debugging tool like Lighthouse.
• Redirects and Google Search — Google’s redirect doc: redirect types, the preference for server-side redirects, and how permanent vs temporary redirects are treated for canonical signals.
• How HTTP status codes affect Google’s crawlers — Google’s crawling-infrastructure doc; states the current default hop cap (up to 10 for Googlebot) and that Google Inspection Tools doesn’t follow redirects at all.
• Crawling and Indexing — the hub for redirects, canonicalization, and crawl controls.
• URL Inspection Tool — how to inspect a single URL; live URL Inspection follows redirects to test the final URL but doesn’t expose the path it took.

Bing / Microsoft

• Bing Webmaster Guidelines — Bing’s general guidance, including using 301s for permanent moves and avoiding redirect chains.
• Managing redirects – 301s, 302s and canonicals (2011) — Bing’s older but still-cited post on redirect best practices (point old URLs directly at the final destination).

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the four causes of a “Redirect error”

• “Google experienced one of the following redirect errors: A redirect chain that was too long; A redirect loop; A redirect URL that eventually exceeded the max URL length; A bad or empty URL in the redirect chain.” — Google, Page indexing report Help doc. Jump to quote

Google — “Page with redirect” (the non-error status, for contrast)

• “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL. A canonical URL with a redirect can be indexed.” — Google, Page indexing report Help doc. Jump to quote

John Mueller, Google — on how many hops Google follows

• In a 2014 webmaster hangout, Mueller described Googlebot following up to five redirects in one crawl and continuing any remainder in the next crawl. Watch from 46:03
• “Search engines just follow the redirect chain (for Google: up to 5 hops in the chain per crawl attempt).” (Relayed via Search Engine Journal, 2020.) Jump to quote
• “The only thing I’d watch out for is that you have less than 5 hops for URLs that are frequently crawled.” (Relayed via Search Engine Journal, 2020.) Jump to quote

Google — the current default hop cap (crawling infrastructure documentation)

• “By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits.” — Google, “How HTTP status codes affect Google’s crawlers” (Google Crawling Infrastructure docs; updated 2026-02-04; verified live 2026-07-18).
• “Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn’t follow redirects.” — same source (verified live 2026-07-18). Source

Google — the current practical recommendation (site-move documentation)

• “ideally no more than 3 and fewer than 5.” Source

Redirect-error fix checklist

Work through this for each URL (or template) flagged “Redirect error”:

• Confirm it’s actually “Redirect error” and not “Page with redirect” (the latter is usually fine — no action needed).
• Reproduce the redirect with curl -IL (or a redirect checker) and read every hop and status code.
• Identify which of Google’s four causes it is: chain too long, loop, over-max-length URL, or bad/empty URL.
• For a loop, find the conflicting rules (HTTP↔HTTPS, www↔non-www, trailing-slash) and make each redirect point one direction only.
• For a chain, collapse it to a single 301 pointing at the final URL — remove the intermediate hops.
• For an over-length URL, stop the rule appending params and redirect to a clean, fixed target.
• For a bad/empty URL, trace the exact broken Location value first — empty, unresolvable, or garbage, not merely relative — then fix the rule so it emits a valid, resolvable target (absolute is the safer default).
• Confirm the final destination returns 200 (not another redirect, not a 4XX/5XX).
• Update internal links to point at the final URL, not the redirecting one.
• Re-test with curl / URL Inspection — expect one clean redirect or a direct 200.
• Click Validate Fix in Search Console (remember: it queues a re-check; it isn’t instant).

Redirect-error cheat sheets

“Redirect error” vs “Page with redirect” — don’t confuse them

Google’s four causes → diagnosis → fix

Hop counts — what’s actually true

Trace a redirect chain (find the broken hop)

The fastest way to see exactly what Google is choking on is to follow the redirect chain yourself and read every hop and status code.

macOS / Linux

# -I = headers only, -L = follow redirects: prints each hop's status + Location
curl -sIL https://www.example.com/old-page/ | grep -i -E '^(HTTP/|location:)'
# Example of a healthy single hop:
#   HTTP/2 301
#   location: https://www.example.com/new-page/
#   HTTP/2 200
#
# A chain shows multiple 3xx lines before the 200.
# A loop never reaches 200 — you'll see the same URLs repeat (curl stops at its
# --max-redirs limit, default 50).

If you want the full per-hop URL + code list in one line each:

curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old-page/
# Add --max-redirs 10 to cap how far curl will follow (useful for catching loops):
curl -sIL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old-page/

Windows (PowerShell)

# Follows redirects and reports the final status; -MaximumRedirection caps the chain
Invoke-WebRequest -Uri "https://www.example.com/old-page/" -MaximumRedirection 10 |
  Select-Object StatusCode, @{n='FinalUrl';e={$_.BaseResponse.ResponseUri}}

# To see each hop, disable auto-follow and inspect the Location header one step at a time:
Invoke-WebRequest -Uri "https://www.example.com/old-page/" -MaximumRedirection 0 -ErrorAction SilentlyContinue |
  Select-Object StatusCode, @{n='Location';e={$_.Headers.Location}}

Reading the output

• One 3xx then a 200 = a clean single hop. Good.
• Several 3xx lines before the 200 = a chain — collapse it to one 301.
• Same URLs repeating / never reaching 200 = a loop — find the conflicting rules.
• A 3xx pointing at a 4XX/5XX or an empty/garbled Location = a bad/empty URL in the chain — fix the rule.

Once it’s a single direct 301 → 200, re-test, then run Validate Fix in Search Console.

Caveat: -I sends a HEAD request, not GET. Most servers and CDNs redirect the same way regardless of method, but some server configs, CDN rules, or middleware branch on request method — so if a hop looks different than you expect, re-run without -I (a plain curl -sL) to confirm the GET behavior matches before you conclude the fix is wrong.

I have a “Redirect error” — what do I actually fix?

Google’s four causes look similar from a distance (they all end with “the redirect didn’t resolve”), but the fix is different for each. Trace the chain first (curl or the Redirect Checker), then use what you see to pick a branch below.

Whichever branch you land on, the end state is the same: a single direct 301 to a URL that returns 200. Re-test with the Redirect Checker or curl -IL before clicking Validate Fix.

Mistakes that turn into “Redirect error”

• Redirecting old → interim → new instead of old → new. This is the single most common way a “Redirect error” gets born. Every time you migrate (HTTPS, www, domain, CMS replatform) and point the old URL at an already-redirecting interim URL instead of the final one, you’ve built a chain on day one. Do instead: always point the original URL directly at the final destination.
• Stacking canonicalization rules without checking the order. HTTP→HTTPS, www→non-www, and trailing-slash rules each redirect independently; if two of them disagree about direction, you get a loop, not a chain. Do instead: pick one canonical form for each dimension and verify every rule points the same way, not just the one you just edited.
• “Fixing” a redirect by adding another redirect on top. Patching a broken hop by inserting a new rule in front of it usually extends the chain instead of shortening it. Do instead: replace the whole chain with one direct 301, don’t layer another hop onto it.
• Confusing “Redirect error” with “Page with redirect” and trying to “fix” a working redirect. “Page with redirect” is Google successfully following a non-canonical URL to its target — it’s not broken. Do instead: only spend time on URLs actually flagged “Redirect error”; leave “Page with redirect” alone.
• Redirecting to a URL that itself 404s, 5xxs, or is noindexed. Even a single clean hop is useless if the destination doesn’t return 200 and isn’t indexable — Google either can’t finish resolving it or won’t index what it finds. Do instead: confirm the final target returns a real 200 and is indexable before wiring the redirect to it.
• Letting tracking/query parameters get appended on every hop. A rewrite rule that re-feeds its own output (common with tracking or session params) grows the target URL past the max length on a long-lived redirect. Do instead: strip unnecessary parameters and redirect to a clean, fixed URL.
• Clicking Validate Fix and assuming it’s instant. Validate Fix queues a re-check; it doesn’t re-index the page immediately. Do instead: re-test the redirect yourself first (curl / Redirect Checker) so you know it’s actually fixed before you wait on Google’s recrawl.

Prove the redirect is actually fixed

Run these after you collapse a chain, break a loop, or fix a bad/empty URL — before you rely on Search Console to confirm it.

Test 1: Single-hop 301 to a 200

• Test to run — Paste the old URL into the Redirect Checker, or run curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' <url>.
• Expected result — Exactly one 301 (or 308) hop, landing on a final URL that returns 200.
• Failure interpretation — More than one 3xx line before the 200 means the chain isn’t actually collapsed yet; the same URL reappearing means the loop isn’t fixed.
• Monitoring window — Immediate; status codes don’t need to “settle.”
• Rollback trigger — Any additional hop appears, or the final status is a 4XX/5XX instead of 200.

Test 2: No loop, no runaway length

• Test to run — Redirect Chain Mapper on the affected URL, or curl -sIL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' <url> (a low --max-redirs will error out if it’s still looping).
• Expected result — The mapper shows a single straight hop with no repeated URLs, and the target URL length hasn’t grown from appended parameters.
• Failure interpretation — Repeating URLs = the conflicting canonicalization rule is still in place; a longer-than-expected target URL = a rule is still appending parameters.
• Monitoring window — Immediate.
• Rollback trigger — Loop reappears, or the URL length grows again on a re-check days later.

Test 3: Batch-verify at scale after a migration

• Test to run — Run the full old-URL list through SEO Migration Planner & Validator or the Redirect Checker in bulk.
• Expected result — Every mapped old URL resolves in one hop to its intended new URL at 200.
• Failure interpretation — Any URL still showing multiple hops, a loop, or a non-200 target means that row of the redirect map wasn’t actually applied or points at the wrong destination.
• Monitoring window — Immediate for the hop check.
• Rollback trigger — More than a handful of URLs fail the batch check; that’s a sign the redirect map itself (not just one rule) has a systemic error.

Test 4: Search Console re-indexing

• Test to run — Click Validate Fix on the affected URL(s) in the Page Indexing report, then watch the status.
• Expected result — The URL moves off “Redirect error” — ideally to “Page with redirect” (if it’s a non-canonical old URL) or the final URL shows as indexed.
• Failure interpretation — Still showing “Redirect error” after validation completes means the live redirect still isn’t resolving the way you tested it, or Google hasn’t recrawled yet.
• Monitoring window — Validate Fix queues a recheck, not an instant re-index; it depends entirely on Google’s own recrawl schedule for that URL, which isn’t published, so don’t expect it on a fixed timetable.
• Rollback trigger — Validation comes back failed, or the status reappears on a later crawl after initially clearing.

Tools for tracing and fixing redirect errors

• Redirect Checker — paste a single URL and see every hop, status code, and the final destination. The fastest way to confirm whether a flagged URL is now a clean single 301 → 200.
• Redirect Chain Mapper — visualizes the full hop-by-hop path, so a chain or loop is obvious at a glance instead of read line-by-line from raw headers.
• Bulk HTTP Status Code Checker — check many URLs at once, which is how you catch redirect errors across a whole site or a whole redirect map instead of one URL at a time.
• SEO Migration Planner & Validator — built for exactly the scenario where most redirect errors are born: site migrations. Map old URLs directly to their final new URLs (not through an interim hop) and verify the map before and after go-live.
• Google Search Console — URL Inspection. Live URL Inspection follows the redirect and tests the final URL, but it doesn’t expose the hop-by-hop path or name the final URL — pair it with curl -IL or a redirect checker when you need to see where the chain actually breaks.
• curl -IL from the command line, for anyone who wants to trace a hop manually. Commands are in the Scripts tab.
• Ahrefs Site Audit / Screaming Frog / Sitebulb. For surfacing every redirect chain and loop across a whole site at once, which is how you find the ones that never got a support ticket.

Prompts for redirect-error analysis

Feed these prompts actual redirect traces. A language model cannot verify a redirect path from a URL alone.

Diagnose a broken trace

Analyze this redirect trace hop by hop. Identify the first loop, invalid or empty location, excessive chain, or non-success destination. Recommend a single direct redirect from the starting URL to the intended final 200 URL. Trace: [paste statuses and locations].

Review a redirect map before deployment

Review this proposed old-to-new redirect map. Flag self-redirects, loops, multiple hops, conflicting destinations, malformed targets, and redirects to irrelevant pages. Return corrected mappings and a validation checklist. Map: [paste rows].

Convert crawl output into repair groups

Group these redirect errors by shared source pattern and likely rule or template. For each group, state the evidence, the smallest configuration change, affected URL count, and a post-deployment test. Do not invent a target when the intended destination is not present in the data. Rows: [paste crawl export].

Test yourself: Redirect error

Five questions on what “Redirect error” means and how to fix it. Pick an answer for each, then check.

Redirect error

A Google Search Console Page Indexing status meaning Googlebot couldn't follow a redirect — a chain too long, a loop, a URL over the max length, or a bad/empty URL in the chain. It's a broken redirect to fix, not the normal "Page with redirect."

Parent concept: Page Indexing report · Related: Redirect chain, 301 redirect, Page Indexing report

Redirect error

Redirect error is a status in Google Search Console’s Page Indexing report, under “Why pages aren’t indexed.” It means Googlebot tried to follow a redirect for the URL but couldn’t resolve it — so the page wasn’t indexed.

Google defines exactly four causes: a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the max URL length, or a bad or empty URL somewhere in the redirect chain. All four are the same kind of problem — a redirect Google couldn’t follow to the end.

The distinction that trips everyone up: Redirect error is not the same as “Page with redirect.” A redirect error is a broken redirect that needs fixing. “Page with redirect” is a working redirect that simply isn’t the canonical URL, so it won’t be indexed — that one is normal and usually needs no action. If you only remember one thing, remember that one is an error and the other isn’t.

Parent concept: Page Indexing report · Related: Redirect chain, 301 redirect, Page Indexing report

Changelog