What a resource chain loop actually is
Every page pulls in supporting files: CSS to style it, JavaScript to make it work, web fonts, images, sometimes a dozen third-party scripts. Each of those is a separate HTTP request. Normally a request returns 200 and the file arrives. Sometimes it returns a redirect (301, 302, 307, 308) that points somewhere else, and the browser follows it. A short redirect is harmless. A chain is several redirects stacked in a row. A loop is the failure mode: the chain circles back to a URL it already visited, so it can never reach a real file.
Concretely, imagine your page references /assets/app.css. That URL 301s to /assets/app.css/ (someone added a trailing-slash rule). The trailing-slash version 301s back to /assets/app.css because a different rule strips slashes off asset paths. The two rules fight each other forever. The browser hits its redirect ceiling, gives up, and the stylesheet simply does not load. That is RE-021.
Why this hurts more than a normal broken link
A broken page link costs you one dead click. A looping resource can wreck the page it lives on. If the failed file is your main stylesheet, the page renders as unstyled HTML. If it is a critical script, interactive components die. If it is a hero image, you get a gap and a layout shift. Users see a half-built page and bounce.
For search, the damage is quieter but real. Browsers cap redirects at around 20 hops before aborting, and Googlebot is far stricter with resources, giving up after only a handful. When Google renders your page for indexing and a resource loops, it renders the broken version, which can mean missing content, failed lazy-loaded elements, or a Core Web Vitals hit from the layout shift. You are also burning crawl budget: every attempt is wasted round trips against a request that structurally cannot succeed.
How the loop forms: a diagram
Common causes I see in the wild
Loops almost never come from one bad line. They come from two well-meaning rules that individually look fine and collide on a specific URL shape:
- Trailing-slash wars: one rule adds slashes, another removes them, and asset paths get caught in the crossfire.
- HTTP-to-HTTPS plus www rules stacked badly, where the protocol rule and the host rule keep handing the request back to each other.
- CDN and origin disagreeing: the CDN redirects to a canonical host, the origin redirects back to the CDN host.
- Case-sensitivity rules that lowercase a path the app then re-uppercases.
- Old asset URLs pointing to a "moved assets" redirect that circles back after a later migration.
How to detect it
You cannot eyeball this from the page source. You have to watch the requests. Here is the toolkit that actually finds RE-021:
| Tool | What to look for | Best for |
|---|---|---|
| Chrome DevTools, Network tab | Resource stuck pending, or a red ERR_TOO_MANY_REDIRECTS; expand the request to see the hop list | Confirming a single page fast |
| Screaming Frog | Enable rendering, check the Redirect Chains report and the Response Codes tab for resources | Finding it site-wide |
| Sitebulb | Redirect loop and redirect chain hints flagged with the full hop path | Audits with clear reporting |
| curl -IL | Run against the exact asset URL and watch the Location headers repeat | Proving the loop at the server |
| Server access logs | Same asset path hit many times in one page load with 3xx status | Catching it in production |
My fastest check: curl -sIL https://yoursite.com/assets/app.css. If the Location headers start repeating, you have your loop and the exact two URLs that are fighting.
How to fix it, step by step
- Capture the full hop list. Run
curl -ILagainst the failing resource and write down every URL and status until it repeats. The two URLs that recur are your culprits. - Find the two rules. Check your server config (Nginx
rewrite/return, Apache.htaccessRewriteRules), your CDN redirect rules, and any framework-level redirect middleware. One rule sends A to B, another sends B back to A. - Decide the one canonical form for that asset URL: with or without trailing slash, which host, which protocol. Pick one and commit.
- Remove or scope the conflicting rule so it no longer touches asset paths. Excluding
/assets/or your static directory from the offending rewrite usually ends the fight cleanly. - Better yet, reference the canonical URL directly in your HTML and build output so no redirect is needed at all. A resource that returns 200 in one hop is the goal.
- Re-test with
curl -ILand DevTools, then re-crawl in Screaming Frog to confirm no other assets share the same shape.
Do this, not that
- Serve every asset at a single canonical URL that returns 200 directly
- Reference that final URL in your templates and build output
- Scope broad rewrite rules so they skip your static asset paths
- Re-crawl after any redirect or host change to catch new loops
- Test with curl -IL before shipping redirect rules
- Stack trailing-slash and strip-slash rules without excluding assets
- Let the CDN and origin each redirect to the other's host
- Assume a resource is fine because the page "mostly" renders
- Point asset references at a URL you know redirects
- Ship redirect changes without re-testing the static files
What good looks like
A healthy resource request is boring: the browser asks for /assets/app.css, the server answers 200 with the file, done. No Location header, no chain, no loop. In DevTools the request shows one row, green, with a real size and a fast time. In Screaming Frog every internal resource sits at status 200 with a redirect-chain length of zero. That is the bar. Anything above one hop on a static asset is worth questioning; a loop is never acceptable.
FAQ
Is a resource chain loop the same as a redirect chain?
Will Google still index my page if a resource loops?
How many redirects before a browser gives up?
Why does the loop only affect some assets?
A full technical audit maps every redirect chain and loop across your pages and resources, tells you which two rules are fighting, and gives you the exact fix order.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
