Redirect error: loops, long chains and broken Location headers

See every hop

Follow the chain without a browser, since browsers cache 301s and hide the path:

curl -sIL -o /dev/null -w "%{url_effective} after %{num_redirects} redirects\n" https://example.com/old-page/
curl -sIL https://example.com/old-page/ | grep -iE "^(HTTP|location)"

The second command prints each status and Location header in order. You are looking for one of four patterns:

• The same URL appearing twice: a loop.
• More hops than you can justify, typically protocol, then host, then slash, then the real redirect.
• A Location that is empty, relative in a way that resolves wrongly, or contains spaces or an unencoded character.
• A target that grows on each hop, such as a query string appended again and again until the URL exceeds the length a server accepts.

Loops specific to WordPress

HTTPS loop behind a proxy. The CDN or load balancer talks to your origin over plain HTTP while WordPress is configured for https://. WordPress sees an insecure request, redirects to HTTPS, the proxy fetches over HTTP again, and so on. Set the CDN's SSL mode to encrypt all the way to the origin, or make sure the proxy passes the X-Forwarded-Proto header and the server honours it.

Host mismatch. Settings → General says https://example.com while a server rule or the CDN forces www. WordPress redirects to the bare domain, the server sends it back. Pick one host and configure both layers to agree.

Two rules that undo each other. A redirect from /a/ to /b/ and an older one from /b/ to /a/. In Hydrogen SEO, search Hydrogen SEO → Redirections for both paths and delete or correct one; the redirection manager guide lists the rules for safe sources and targets. Also check .htaccess and any second redirect plugin, because rules in different layers cannot see each other.

Trailing slash disagreement. The server strips the slash, WordPress adds it back according to the permalink structure. Remove the server rule and let WordPress decide.

Collapsing a long chain

Each redirect should point at the final destination. If /2019/guide/ goes to /guide/, which goes to /guides/seo/, edit the first rule to target /guides/seo/ directly. Order the normalisation rules so that protocol and host are fixed in a single hop: one rule that sends any non-canonical origin to https://example.com plus the original path is better than separate HTTP and www steps. The step-by-step version is in our guide to fixing redirect chains, and the redirect rule generator flags chains in a list of old and new URLs before you deploy them.

Malformed targets

An empty Location usually comes from code that redirects to a variable which turned out to be blank, for example a "redirect after login" option with no value. A target with a doubled scheme (https://https://) or a missing slash after the host comes from string concatenation in a rule. Fix the rule at its source; these are not Google problems and they fail for people as well.

After the fix

Repeat the curl trace and confirm a single 301 followed by a 200. Run Test live URL in URL Inspection on the starting URL; it should now report "Page with redirect" or, if you removed the redirect, a fetchable page. Then choose Validate fix on the Redirect error row of the Page indexing report. Clear the CDN cache first, because cached 301 responses outlive the rule that produced them.