Fix redirect errors in Google Search Console

A redirect error means Google could not complete a redirect path. The cause may be a loop, an excessively long chain, a bad or empty destination, or a URL that keeps growing until it exceeds the length Google can process. Start with the exact affected URL and trace its responses before changing anything.

The old address and its destination are separate checks. A working destination does not repair a broken route to it, and repairing the route does not automatically get the destination indexed.

What a redirect error means

Google lists four redirect failures in its Page indexing documentation^[1]Source 1Page indexing documentationView source ↗: long chains, loops, excessive URL length, and bad or empty URLs within a chain.

The similar-looking “Page with redirect” status describes a non-canonical address that redirects elsewhere. Its target may or may not be indexed. That status alone does not tell you the redirect is broken. Our Page with redirect guide covers expected moves and old URL cleanup.

Observation	What to investigate	First useful check
Redirect error in Search Console	Google encountered a redirect failure	Trace the exact source URL
Page with redirect	The source redirects elsewhere	Check whether the move is intended
ERR_TOO_MANY_REDIRECTS in Chrome	That browser request could not finish redirecting	Look for repeated URLs or conflicting rules
Destination returns 404 or 5xx	A separate destination availability problem	Inspect that response and its logs

A redirect that reaches an error page still needs attention. However, a destination's 404, noindex directive or server error should not automatically be called the same Search Console redirect classification.

Trace the redirect chain before changing rules

Open Indexing → Pages → Redirect error and select an affected address. Record its last crawl date, then compare that date with recent migrations, SSL changes, plugin updates and deployments.

Choose a representative URL from each pattern. A whole-site HTTPS loop deserves a different investigation from one retired product path. Prioritize important landing pages, URLs with useful incoming links, and rules affecting many addresses.

Workflow: collect the failing path

1. Copy the complete reported URL, including protocol, hostname, slash and query string.
2. Request it while signed out and record each status and destination.
3. Stop at the final response, a repeated URL or a broken destination.
4. Save the trace and time before editing the responsible rule.

Record each Location header

In Chrome DevTools, open Network, enable Preserve log, and load the source URL. Inspect document requests, their status codes and response headers. A redirect's Location header tells the client where to go next.

For a command-line check, this curl request uses GET and prints the response headers along the path:

curl -sS -L --max-redirs 10 -D - -o /dev/null "https://example.com/old-guide"

On Windows, use curl.exe and replace /dev/null with NUL. The command's ten-redirect limit is a diagnostic setting. Reaching it means this check stopped; inspect the recorded sequence to understand why.

GET matters because some sites respond differently to HEAD requests. If a checker uses HEAD, repeat with GET before deciding visitors or crawlers receive the same result. Also note whether the result depends on a login, cookie, region or cached response.

Google says Googlebot generally follows up to ten redirect hops for general web content, with different behavior possible for other crawlers. That is a processing limit, not a target for your redirect design. Prefer a direct route from the old address to its relevant final page. Google's HTTP status guidance^[2]Source 2Google's HTTP status guidanceView source ↗ explains the crawler distinction.

Fix redirect loops at the layer creating them

A loop has no final page. For example, /old-guide sends a visitor to /new-guide, but a second rule sends /new-guide back to /old-guide. Changing both responses from 302 to 301 would leave the loop intact.

Identify which component owns each hop: CDN, reverse proxy, web server, application or CMS plugin. Correct the conflicting rule there. Adding another redirect without removing the conflict often makes diagnosis harder.

Check HTTPS and hostname rules

Compare HTTP and HTTPS, www and non-www, and slash variants. Look for two layers enforcing different preferred versions.

Cloudflare documents a specific example: Flexible encryption connects to the origin over HTTP. If the origin redirects every HTTP request to HTTPS, the interaction can loop. Review the encryption mode and origin configuration together. A move to Full or Full (strict) requires a correctly configured origin certificate; changing a setting blindly can create a different outage. See Cloudflare's redirect-loop troubleshooting^[3]Source 3Cloudflare's redirect-loop troubleshootingView source ↗.

For other reverse proxies, check whether the application correctly recognizes the original request's scheme through the host's supported configuration. An application that mistakes every HTTPS visit for HTTP may keep trying to upgrade it.

Check CMS redirects and broad matching rules

In WordPress, review redirect plugins alongside hosting redirects and server rules. A path-level plugin may conflict with a site-wide domain or HTTPS rule. Export the existing configuration before making changes, then change one known cause at a time.

With pattern-based redirects, test the intended source, the destination, a neighboring path and a query-string variant. A rule meant for /old/ should not accidentally match its own target. Use your platform's documented syntax rather than pasting an unrelated Apache rule into another server.

Repair long chains and bad redirect targets

A chain can terminate successfully while still taking unnecessary steps. After repeated migrations, an original address may pass through several retired versions. Update the original mapping to the current equivalent, then check the other old entry points too.

Trace pattern	Likely problem	Correction to test
A → B → A	Circular rules	Remove the conflicting hop and choose one destination
A → B → C → D	Accumulated migration chain	Point each old source directly to D where appropriate
A → blank or malformed target	Broken destination construction	Repair the redirect rule or template
Query string grows at every hop	Repeated parameter appending	Stop duplicating parameters and define the intended target
A → 404 or 503	Unavailable destination	Restore it or choose a relevant replacement

Read the actual header before declaring a target invalid. Location: /new-guide is a valid relative reference when resolved against the requested URL. RFC 9110's Location definition^[4]Source 4RFC 9110's Location definitionView source ↗ explicitly supports relative references. An absolute URL is not required simply because a redirect failed.

For permanent moves, use an appropriate permanent server-side redirect, normally 301 or 308. Use temporary redirects when the move is temporary. A 302 response is not inherently broken, and changing its code cannot fix a bad target. Google recommends permanent server-side redirects for lasting URL changes in its redirect implementation guidance^[5]Source 5Redirect implementation guidanceView source ↗.

Check the final destination separately

Once the route finishes, open the final address directly. Confirm that it serves the expected content and response, rather than a login page, challenge screen or unrelated homepage.

For a destination you want indexed, check its crawl access, indexing directives and canonical choice. Use the robots.txt versus noindex guide when those controls disagree. If the destination fails with a server response, investigate the 5xx server error separately.

Update internal links and sitemap entries to the intended canonical destination. Keep useful old redirects for incoming links and bookmarks. Removing a working redirect just to reduce a report count can break access that still matters.

Validate redirect error fixes in Search Console

Retest the exact source and relevant variants after deployment. If a CDN cached the old response, refresh the affected cache through your platform's normal process, then repeat the public request.

Workflow: verify the repair

1. Save a fresh trace showing the intended route and final response.
2. Repeat the conditions that originally failed, including affected URL variants.
3. Inspect the source and destination separately in Search Console.
4. Validate the repaired issue and keep the fix time with your evidence.

Use URL Inspection to compare Google's recorded crawl with the current test. Review the destination's own indexing result rather than assuming a passing source test establishes its index status or canonical selection. Google's URL Inspection documentation^[6]Source 6URL Inspection documentationView source ↗ describes the distinction between indexed information and live testing.

After fixing the affected scope, use Validate fix in the issue report. If validation fails, examine the remaining example instead of repeatedly restarting it. The report can lag behind the live repair; compare crawl dates with your deployment time. There is no fixed deadline for indexing recovery.

Fix a redirect error with a verified route

Pick one affected URL now and save its complete path. Identify the first repeating, unnecessary or invalid hop, correct the rule responsible, and test the route again from the original address.

Keep the source URL, before-and-after trace, changed rule, deployment time and destination check together. That record gives your developer or host a reproducible problem and makes a returning error much easier to diagnose.

Sources

1. Google Search Console Help. Page indexing documentation.

2. Google Search Central. Google's HTTP status guidance.

3. developers.cloudflare.com. Cloudflare's redirect-loop troubleshooting.

4. IETF. RFC 9110's Location definition.

5. Google Search Central. Redirect implementation guidance.

6. Google Search Console Help. URL Inspection documentation.