
Element Code: RE-017
What an internal redirect error is
This is a two-hop failure. You have an internal link, one page on your site pointing to another. The target URL responds with a 3xx redirect, which is fine on its own. The problem is where that redirect ends up: an error status. A 404 Not Found, a 410 Gone, or a 5xx server error. So the full chain reads link, then redirect, then dead end.
It is worse than a plain broken link because it hides. A quick glance at the link target shows a 301 or 302, which most people read as "handled, moving on." Only when you follow the redirect to its final hop do you see it terminates in an error. Screaming Frog and Sitebulb surface this as a redirect chain whose final status code is not 200, which is exactly the case you never want to ship.
Why it hurts SEO and users
Three separate costs stack up here, and none of them are theoretical.
- Users hit an error. Someone clicks a link on your own site and lands on a Not Found page. That is a self-inflicted bounce, and it erodes trust in the page they came from.
- Crawl budget leaks. Googlebot follows the redirect, spends a request, and gets an error for its trouble. On a large site, thousands of these paths pull the crawler away from pages that actually deserve attention. Google's own guidance is clear that redirect chains and dead ends are wasted crawl effort.
- Link equity evaporates. A working internal link passes signals to the target. When the target redirects into a 404, whatever ranking value you meant to pass simply stops. You built an internal link that funnels authority into a hole.
The link is also a maintenance smell. If it points at a redirect that later broke, other links across the site probably point at the same stale URL, and they will break the same way.
How to detect it
- Crawl with Screaming Frog. Run a full crawl, then use the Redirect Chains report (Reports menu). Sort by the final status code and pull everything where the chain ends in 4xx or 5xx. That report gives you the source page, the redirecting URL, and the dead final hop in one row.
- Cross-check in Search Console. The Pages report under Indexing lists "Not found (404)" and "Server error (5xx)" URLs. If a flagged URL is one your internal links redirect into, you have confirmation from Google's side.
- Read server logs. Filter for 404 and 5xx responses served to Googlebot, then trace the referring URLs. Logs show you the real-world frequency, so you know which broken paths actually get hit.
- Use Sitebulb for the visual map. Its redirect and broken-link views make it easy to see clusters, like a whole section linking to one retired URL that now redirects to nothing.
Redirect outcomes reference
| Chain final status | What it means | Action |
|---|---|---|
| 200 OK | Redirect resolves to a live page | Repoint link to skip the hop |
| 404 Not Found | Final URL does not exist | Relink or restore target |
| 410 Gone | Content intentionally removed | Remove the internal link |
| 5xx Server error | Target server failing | Fix server or relink |
How to fix it, step by step
- Find the real destination. Decide what the link was meant to reach. Usually there is a live equivalent: the current product page, the replacement article, the section landing page.
- Edit the source link directly. Change the href on the linking page to the final working URL. Point at the 200, not at the redirect and definitely not at the error. Skipping the hop entirely is the correct move even when the redirect works.
- If nothing replaces it, remove the link. When the target is genuinely gone with no equivalent, delete the internal link rather than leaving it pointing at a redirect to a 404.
- If the target should exist, restore or fix it. A 5xx often means a broken template or a server issue, not a missing page. Fix the root cause so the URL returns 200, then keep the link.
- Recrawl and confirm. Run the crawl again and check that the redirect-chains report is clean and every internal link resolves to a 200 in one hop.
DO vs DON'T
- Link straight to the final 200 URL
- Follow every redirect to its last hop before trusting it
- Remove links whose target is permanently gone
- Fix 5xx targets at the server level
- Recrawl to confirm a clean chain report
- Trust a 301 without checking where it lands
- Leave links pointing at redirects that hit errors
- Add another redirect to paper over the first
- Ignore low-traffic pages: crawlers still walk them
- Assume the CMS updated old links for you
What "good" looks like
Every internal link resolves to a live 200 page in a single hop. No chains, no dead ends, no surprise 404 at the bottom of a redirect. Your Screaming Frog redirect-chains report comes back empty, and Search Console stops reporting internal URLs as not found. Users click and land where they expect, crawlers spend their budget on pages that matter, and the link equity you built into your internal linking actually reaches its destination.
FAQ
Why not just add a redirect to fix the broken final URL?
Does one internal redirect error really matter?
The final page is a 410, not a 404. Same thing?
How do I catch these before they ship?
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.







