Resource Redirect Broken

What a broken resource redirect is

Your page references a supporting file, say /js/cart.js. Instead of returning the file directly, the server 301s that URL to /assets/js/cart.js. So far normal. The problem: that destination does not exist. It returns a 404, or a 410 gone, or a 500 server error. The redirect worked perfectly and delivered the browser to a dead page. The script never loads. That is RE-015, a resource redirect that terminates in a broken response.

The distinction matters. This is not a redirect loop, which never resolves. It is not a slow redirect chain, which resolves eventually. It is a redirect that resolves cleanly to something broken. The final status code is the whole story: a resource redirect is healthy only if it ends in a 200. End in anything else and the resource is effectively missing.

Why this quietly breaks pages

Because the redirect itself succeeds, this hides better than a plain missing file. The server logs look busy and functional. But the browser ends up with nothing usable. If the dead resource is your stylesheet, the page renders as raw unstyled HTML. If it is a script that builds navigation or a cart, that feature is simply gone. If it is an image or font, you get blank boxes and layout shift.

For SEO the cost compounds. When Googlebot renders the page for indexing and a critical resource redirects to a 404, it renders the broken version. Content injected by that script may never appear in the index. Layout-shift and largest-contentful-paint metrics degrade, which feeds into Core Web Vitals. And every crawl of that page spends requests following a redirect to a dead end, wasting crawl budget on a file that can never load.

The path, drawn out

Common causes

• A migration that moved files and left a redirect rule pointing at the new path, but the file never actually landed there.
• Deleted assets that still have a redirect rule sending traffic to a location that was also removed.
• CDN purge or misconfiguration where the redirect target host returns a 5xx or a 404 for that path.
• Cache-busting hashes: the HTML references an old hashed filename that redirects to a "latest" path that has since changed hash and 404s.
• Typos in the redirect target, a wrong folder or a stray character that sends the file into a dead path.
• Plugin or theme updates that rename asset directories while old rewrite rules survive.

How to detect it

My go-to: curl -sIL https://yoursite.com/js/cart.js and look at the last status line. If it ends in anything other than 200, you have RE-015 and the exact broken target is right there in the Location headers.

How to fix it, step by step

1. Get the final status and target. Run curl -IL on the failing resource. Note the last URL and its status code.
2. Decide the correct live URL. Find where the file actually exists and returns 200. If the file is genuinely gone, you need to restore it or replace the reference.
3. Fix the reference, not just the redirect. Update your HTML, template, or build output to point directly at the live 200 URL. A resource should never rely on a redirect to be found.
4. Repair or remove the redirect rule. If the redirect must stay for legacy reasons, repoint it at the live file. If nothing needs it, delete it so the request is clean.
5. Restore or replace missing files. If the asset was deleted by mistake, redeploy it. If it is obsolete, remove the reference from the page entirely rather than leaving a dead call.
6. Re-test and re-crawl. Confirm a single 200 with curl -IL and DevTools, then re-crawl in Screaming Frog to catch other assets sharing the same broken target.

Do this, not that

What good looks like

A healthy resource returns 200 in one hop, no redirect at all. If a redirect exists for legacy reasons, it resolves to a live 200 file in a single, short step. In DevTools the request row is green with a real size. In Screaming Frog every internal resource has a final status of 200 and no broken redirect targets. The Console is clean of "failed to load resource" errors. That is the standard: not "the redirect fires," but "the file arrives."

FAQ