Free to explore: filter winning sites by DR, traffic and niche  ·  Try the live explorer →

Redirect error in Search Console: fixes

A tangled loop of cables

The redirect error Google Search Console status sits under Not indexed in the Page indexing report, and it is worth handling before most of its neighbours. Page with redirect, which looks similar, is usually a redirect working as intended. This status is the opposite: the URL never reached a page Google could index, so whatever value it had is stuck at the start of a broken path. The good news is that redirect errors are deterministic. Unlike a server error, they fail the same way every time, so they are easy to reproduce and confirm fixed.

What the redirect error Google Search Console status means

Semrush’s guide to Google Search Console errors sums it up: “Redirect errors occur when a redirect fails for some reason.” Google’s own Page indexing documentation is more specific. It lists four causes, and every redirect error falls into one of them.

Google’s causeWhat it looks likeFix
“a redirect chain that was too long”A URL that hops through several redirects before arrivingPoint the first URL straight at the final one
“a redirect loop”A redirects to B, which redirects back to AFind the two rules disagreeing and remove one
“a redirect URL that eventually exceeded the max URL length”Each hop adds to the URL until it becomes too longStop the rule that appends on every pass
“a bad or empty URL in the redirect chain”A redirect with a malformed or missing destinationCorrect the target in the rule
A redirect loop error in a browser

Loops: two systems disagreeing

Most loops are not a single rule pointing at itself. They come from two layers that each enforce a different version of the same URL. A CMS setting that forces www.example.com while a server rule forces example.com will bounce a request between them forever. So will an SEO plugin adding a trailing slash while a server rewrite strips it.

A classic version involves HTTPS. If a CDN connects to your origin over HTTP while the origin redirects all HTTP traffic to HTTPS, the origin keeps sending the CDN to HTTPS, the CDN keeps fetching over HTTP, and the visitor sees a browser error saying the page redirected too many times.

Loops are also the cause most likely to appear suddenly across a whole site. A new plugin, a changed hostname setting or a CDN switched on during a launch can create one in minutes, and every URL that passes through the conflicting rules fails at once. If the report shows a large group appearing on a single date, look at what changed that day before tracing individual URLs.

A diagram of redirect hops

The fix is to decide which layer owns each rule. Hostname and protocol are best handled once, as close to the edge as possible. Individual page redirects belong in one place, whether that is a plugin or the server, not both. Our comparison of 301 and 302 redirects covers choosing the right code once you know where the rule lives; Semrush’s advice is to use proper status codes, 301 for permanent moves and 302 for temporary ones.

Chains, long URLs and empty targets

Google’s crawlers “follow up to 10 redirect hops”, according to its documentation on HTTP status codes. That is a ceiling, not a target. Chains build up over years: an old HTTP URL redirects to HTTPS, then to the new hostname, then to a renamed slug, then to a merged article. Each step was reasonable when added. The fix is to rewrite the first rule so it points directly at the final destination, which our guide to redirect chains walks through.

A very long URL in an address bar

Over-long URLs usually come from a rule that appends rather than replaces. A redirect that adds a parameter such as ?lang=en to every request it handles, and is then hit again by its own output, grows the URL on each pass until it exceeds the limit. Empty or bad targets come from typos, a destination field left blank in a plugin, or a variable in a server rule that resolved to nothing.

Conflicting plugin settings

How to diagnose and fix redirect errors

  1. Trace the chain. Request the URL with a tool that shows every hop rather than just the end result. The response headers show each status code and Location header in turn.
  2. Identify which cause applies. A URL that reappears in the trace is a loop. A trace that keeps going is a chain. A growing URL is the length problem. A missing or malformed Location is a bad target.
  3. Find the rule behind each hop. Check the CMS, SEO plugin, server configuration and CDN in turn. Disabling one layer at a time on a staging copy isolates the conflict quickly.
  4. Verify redirect targets. Every destination should return 200 and be the page you intend.
  5. Update internal links. Semrush advises: “update internal links on your site to point directly to the new URLs, reducing the need for redirects.” The same applies to your sitemap.
  6. Validate the fix. Once a live URL Inspection test reaches the destination, use Validate fix in the Page indexing report.

A header trace for a clean single redirect looks like this:

Inspecting HTTP headers

After validation, the URLs should move from redirect error to page with redirect, which is where a working redirect belongs. Our post on page with redirect covers what to check there.

A validate-fix button in a report

What the report cannot tell you

The limitation is that Search Console tells you a redirect failed, not which system caused it. On a site with a CMS, an SEO plugin, a server config and a CDN, any of the four can add a hop, and the report shows only the outcome. The trace tells you the sequence of URLs; mapping each hop to the rule that produced it is manual work. Keeping all page-level redirects in one place is the most useful habit for making that work short.

It also cannot tell you about chains that are still under Google’s limit. A URL that takes several hops and then succeeds is reported as working, even though it slows every visit and every crawl. Audit long chains on purpose rather than waiting for them to break. If a redirect ends at a page that then fails, the URL may surface instead as a server error (5xx) or a 404, depending on what the destination returns.

Frequently asked questions

What causes a redirect error in Search Console?

Google lists four causes: a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the maximum URL length, or a bad or empty URL in the chain.

How many redirects will Google follow?

Google’s documentation says its crawlers follow up to 10 redirect hops. Aim for a single hop from any old URL to its final destination.

Is a redirect error the same as page with redirect?

No. Page with redirect means the redirect worked and the destination is indexed. A redirect error means Google could not reach a destination at all.

Should I use a 301 or a 302 when fixing it?

Use a 301 for a permanent move and a 302 for a temporary one. The code does not cause a redirect error, but the wrong one sends the wrong signal once the redirect works.

The takeaway Trace the redirect, match it to one of Google’s four causes, and fix the rule behind it, usually by making one system responsible for each kind of redirect. Then point internal links straight at the final URL.