Internal Redirected URLs: How to Fix Internal Links to Redirects

What this check flags

This check fires when a crawl finds internal links whose target URL responds with a 3XX status code, usually a 301 (permanent) or 302 (temporary) redirect to another internal URL. The destination page is fine. The problem is the path to it: instead of linking directly to the page that actually renders, your own site is linking to an address that bounces visitors and crawlers one extra hop before they arrive.

Sitebulb calls this hint "Internal Redirected URLs", Screaming Frog reports it as "Internal Redirection (3XX)", and most other crawlers have an equivalent. Whatever the label, the underlying condition is identical: a link that should be direct is not.

Why it matters

Let's be honest first: a single, clean 301 hop loses approximately nothing in ranking terms. Google's Gary Illyes and John Mueller have both stated that 30X redirects no longer dilute PageRank, and Google uses redirects mainly as a canonicalization signal that consolidates everything onto the destination URL. So if you are worried that one redirect is silently draining your rankings, you can relax. It is not.

The real costs are smaller but still real:

Extra latency for users. Every redirect is an additional request and response cycle before the browser even starts fetching the real page. On mobile connections that hop is noticeable.

Crawl waste at scale. Google's crawl budget documentation for large sites explicitly recommends avoiding long redirect chains because they have a negative effect on crawling. Each redirect a crawler follows is a wasted fetch that could have gone to a page you actually want indexed. On a 200-page site this is irrelevant; on a 200,000-page site it adds up.

Chains grow over time. Today's single hop becomes tomorrow's chain. You rename a slug, then migrate to HTTPS, then restructure a category, and suddenly that old link passes through three redirects. Googlebot stops following after a handful of hops, at which point the destination may not get crawled from that link at all. Fixing links while the hop count is one keeps the problem from compounding.

Where it comes from

Almost every flagged URL traces back to one of a few familiar sources:

HTTP to HTTPS. Old links written with http:// still work because your server redirects them, but every one of them is an avoidable hop.

Trailing slash and case normalization. Linking to /services when the canonical URL is /services/, or to /Blog/ when the server lowercases everything, triggers a redirect on every click.

Renamed slugs. You retitle a post, the CMS updates the permalink and adds a redirect, but every existing internal link to the old slug now goes through that redirect.

Site migrations and restructures. Domain changes, category reshuffles, and platform moves leave behind whole layers of redirect rules that internal links keep hitting years later.

How to diagnose

You need two pieces of information for every flagged URL: where the link lives (the source page) and where the redirect ends up (the final destination). In Sitebulb, open the hint and use Export Hint Data, which includes example linking URLs and tells you whether the link sits in navigation or in content. In Screaming Frog, go to Bulk Export, then Response Codes, then Internal, then Redirection (3XX) Inlinks, which gives you a source and destination column for every offending link.

Then sort the export by source. If the same redirected URL appears on hundreds of pages, the link almost certainly lives in a template, menu, footer, or sidebar widget, and one edit fixes hundreds of instances at once.

How to fix

The fix is mechanical: change each internal href so it points at the final URL the redirect resolves to, not the redirecting one.

<!-- Bad: link target 301s to the real page -->
<a href="http://example.com/old-services">Our services</a>

<!-- Good: link straight to the final, canonical URL -->
<a href="https://example.com/services/">Our services</a>

Work in this order:

1. Templates, menus, and footers first. A redirected link in your main navigation appears on every page of the site, so a single edit removes thousands of flagged instances. This is always the highest-leverage starting point.

2. In-content links next. Use the crawler export as your worklist. On WordPress, a search-and-replace tool can swap an old URL across all posts in one pass; just match exact URLs to avoid collateral edits.

3. Leave the redirects in place. They still serve external backlinks, bookmarks, and search engine memory of the old URLs. You are fixing the links, not removing the safety net.

4. Re-crawl to confirm. The hint count should drop sharply after the template fixes and approach zero after the content pass.

Common mistakes

Chasing every redirect on a tiny site. If you have fifty pages and a dozen redirected internal links, the SEO impact of fixing them is close to zero. Fix the template-level ones, then spend your time on something that moves rankings.

Deleting the redirect instead of fixing the link. Removing the redirect rule turns every remaining reference, internal or external, into a 404. Update hrefs first; only retire redirects that genuinely receive no traffic, and even then cautiously.

Pointing links at an intermediate URL. Always link to the final resolving URL. Updating a link from hop one to hop two of a chain just trades one redirect for another.

FAQ