Resource URL in Chained Redirect Loop: How to Fix It

What this check flags

This audit flag fires when a page resource, meaning a stylesheet, script, image, or font that your HTML references, responds with a redirect that leads to another redirect, and somewhere down the chain the destination points back to a URL that was already visited. The request goes in a circle and never reaches a URL that answers with a 200 OK, so the resource simply does not exist as far as the browser or crawler is concerned.

Two things make this check specific. First, it is about resources, not pages: the page itself may load fine, but something it needs to render is unreachable. Second, it is about chained loops, not single-hop self-redirects. Each hop looks like a normal redirect, and the loop only appears when you follow the whole chain.

Why multi-hop loops are sneakier than self-loops

A single-hop self-redirect is easy to spot: you request a URL and the Location header hands you the same URL back. A chained loop hides in plain sight because every individual response is valid. Hop one adds a trailing slash. Hop two forces HTTPS. Hop three rewrites the path to a CDN-friendly format that happens to resolve back to the original URL. Test any one rule in isolation and it behaves exactly as intended.

The usual culprit is layering. A typical WordPress stack has at least three places that can issue redirects: the .htaccess file at the server level, a CDN or proxy in front of the origin (Cloudflare page rules or an SSL mode mismatch are classic examples), and one or more plugins handling redirects, caching, or HTTPS enforcement at the application level. Each layer was configured at a different time, and none of them knows the others exist. When their rules disagree about the canonical form of a URL, the request bounces between them forever. A common pattern: the CDN talks to the origin over HTTP, the origin redirects to HTTPS, the CDN downgrades again, and the loop never ends even though no single rule is wrong.

Consequences

The resource never loads

There is no final destination, so the file is a broken reference. A looping stylesheet can leave the page unstyled, a looping script can break interactivity, and a looping font or image degrades the render.

Browsers give up after a fixed limit

Browsers do not follow redirects forever. Chrome and Firefox stop after roughly 20 hops and surface ERR_TOO_MANY_REDIRECTS, and Safari gives up even earlier. Until that limit is hit, the browser burns time and connections chasing the loop.

Rendering and indexing suffer

Google renders pages before indexing them. If the resources needed for rendering are unreachable, Google may evaluate a broken or empty version of your page, and crawl budget is wasted on hops that lead nowhere.

How to diagnose it

Trace the full chain from the command line. The -L flag follows redirects and -I shows headers only, so you can see every hop and its Location header:

$ curl -IL --max-redirs 10 https://example.com/assets/site.css

HTTP/1.1 301 Moved Permanently
location: https://cdn.example.com/assets/site.css

HTTP/1.1 302 Found
location: https://example.com/wp-content/themes/x/site.css

HTTP/1.1 301 Moved Permanently
location: https://example.com/assets/site.css   <-- back to the start

curl: (47) Maximum (10) redirects followed

Once you can see the chain, attribute each hop to its layer. Response headers help: a hop served by Cloudflare carries cf-ray or server: cloudflare headers, while origin hops usually identify Apache or LiteSpeed. To isolate the CDN, query the origin directly with curl --resolve. To isolate plugins, deactivate redirect, cache, and SSL plugins one at a time and re-run the trace, and check .htaccess for RewriteRule and Redirect directives touching the resource path. The loop is always a disagreement between at least two layers.

How to fix it

The cure is consolidation, not another rule on top:

1. Decide the one true URL for the resource, the exact protocol, host, and path that should serve it with a 200.
2. Pick a single layer to own redirection for that path, usually the server config or .htaccess, and write one direct 301 there if a redirect is needed at all.
3. Remove or correct the conflicting rules at the other layers: delete the stale plugin redirect, fix the CDN SSL mode or page rule, or drop the duplicate .htaccess directive.
4. Better still, update the HTML, theme, or template to reference the final URL directly so no redirect is needed for the resource at all.
5. Purge CDN and page caches, then re-run the curl trace until you see a clean result:

$ curl -IL https://example.com/assets/site.css

HTTP/1.1 301 Moved Permanently
location: https://cdn.example.com/assets/site.css

HTTP/1.1 200 OK
content-type: text/css

Common mistakes

Adding yet another redirect to "patch" the loop instead of removing the conflicting rule, which just makes the chain longer. Testing only in a browser with warm cache, where a cached redirect hides the live behavior; always retest with curl or a private window. Fixing the loop at the CDN while the origin rule still exists, so it returns the moment the CDN config changes. And ignoring the flag because "the page loads for me," when render-dependent crawlers are the ones hitting the wall.

FAQ