Why Googlebot could not follow your redirect, and how to find the broken hop

What the error means

Google tried to follow a redirect from this URL and failed. The page is not indexed because Google never reached a destination it could use.

Why Google rejects it

Googlebot follows a limited number of redirect hops. Loops, very long chains, redirects to an empty or malformed URL, and URLs that grow too long on each hop all make the redirect impossible to complete.

How to fix it

1. Trace the URL hop by hop and write down every step until it ends or repeats.
2. Break loops: find the two rules that send traffic back and forth (often http/https or trailing slash rules fighting each other) and remove one.
3. Shorten chains so each old URL redirects straight to the final URL.
4. Fix redirects that point to empty, relative or malformed locations.
5. After fixing, use URL Inspection's live test, then click Validate fix in the report.

Common causes

Redirect loop

Two or more URLs redirect to each other, so Google cannot reach a final page. This can happen when both a CDN and application rewrite host, protocol, or slash variants in opposite directions. Test the exact URL and inspect every Location response.

Chain exceeds practical crawl handling

A URL may redirect through several old slugs before reaching the current page. Google reports redirect errors for chains that are too long or otherwise invalid. Collapse the chain so each old URL points directly to the final destination.

Malformed or empty redirect target

A rewrite rule can produce a bad Location value, an empty destination, or a URL that exceeds length limits. Check server logs and rule order, especially after a migration or plugin change.

HTTP and host rules conflict

Separate rules for HTTP-to-HTTPS, www-to-bare domain, locale, or trailing slash can bounce a request between versions. Decide the final URL format and make each layer converge on it in one direction.

Fix it on your platform

On Shopify

1. Review URL redirects in Shopify admin for chains and self-references. Shopify handles many platform URL changes, but custom domains, apps, and external proxies can add their own redirects.
2. If a reverse proxy or CDN sits in front of Shopify, check its host and HTTPS rules against Shopify's primary domain configuration; avoid a rule that sends the destination back to the source host.
3. Update internal links to the final URL and remove redundant intermediate redirects after confirming old paths are covered by a direct mapping.
4. Test both the old path and final product URL from outside the admin session.

On WooCommerce

1. Use an HTTP redirect trace to inspect each Location header and identify whether WordPress, a redirect plugin, the web server, or a CDN creates each hop.
2. Set one canonical scheme and host in WordPress and at the server. Remove rules that alternate slash, www, or HTTPS behavior.
3. Update redirect plugin entries to point directly to the final permalink. Check for conflicting plugins before adding another rule.
4. After permalink changes, resave Settings > Permalinks if routes fail, then test the destination page and its old URL.

On other platforms

1. Use the hosting or platform redirect manager to reduce each obsolete URL to one direct redirect to its final equivalent.
2. Inspect CDN, load balancer, and application redirects together. A rule may look valid alone but loop when another layer rewrites the same URL.
3. Keep only one version of protocol, hostname, slash format, and locale as the final destination.
4. Log the exact status and Location headers for each request rather than relying on the browser address bar alone.

How to confirm it is fixed

1. Trace the affected URL from an unauthenticated client and confirm it reaches a final 200 response without loops or unnecessary hops.
2. Test representative URLs for each affected pattern, including HTTP/HTTPS, www/non-www, old product slugs, and language paths.
3. Run the bulk status check to view redirect chains and final destinations for a URL set.
4. Use URL Inspection after the fix and check the final destination's indexing state; Search Console may continue to show the earlier crawl result until recrawled.

A worked example

Hypothetical case: a store changes its domain from www to the bare host and turns on HTTPS at the same time. Its CDN redirects HTTPS bare-host URLs to www, while the application redirects www back to bare-host HTTPS. Visitors may see an intermittent error, and Google reports Redirect error for product URLs. The owner traces response headers, changes the CDN to use the same final bare-host HTTPS destination as the application, and removes a duplicate plugin rule. Direct tests of old HTTP/www paths now reach one final product page. They update the sitemap and check the destination separately in Search Console.

Other errors like this