Internal Redirected URLs: Point Links to the Final Destination

What "Internal Redirected URLs" means

This issue flags internal links on your own site that point to a URL which does not return a normal 200 OK response. Instead, the linked URL answers with a 3XX redirect (most commonly a 301 permanent redirect or a 302 temporary redirect) that bounces the request onward to a different, final URL.

In plain terms: a link in your navigation, body copy, or footer is pointing at an old or non-canonical address. The page still loads for the visitor because the redirect quietly forwards them, so the problem is invisible in a browser. But under the hood, every click and every crawl request takes an extra step it should not have to take. The fix is simple in concept: change the link so it targets the destination URL directly.

Why pointing internal links at redirects is wasteful

A redirect is not free. Each one carries three small costs that add up across a site:

Extra hops

When a search engine crawls a link that redirects, it has to fetch the first URL, read the redirect response, then fetch the destination. That is two requests where one would do. Multiply that by thousands of internal links and you are spending crawl budget on round trips instead of on discovering and refreshing real content. Screaming Frog describes this directly: you should not link internally to redirecting URLs, because doing so wastes crawl budget and causes latency.

Slight equity loss and dilution

Redirects are designed to pass the value of a link to the destination, and Google generally does pass it. But the cleanest, most reliable signal is always a direct link to the canonical 200 URL. Routing internal authority through a redirect adds an interpretation step and removes any ambiguity benefit you would get from a direct, unambiguous link. Linking straight to the final URL guarantees the full signal lands where you want it.

Slower crawling and a slower experience

Every redirect adds latency. For a human, one redirect is barely noticeable, but for a crawler working through your whole site it compounds, and for users on slow connections each extra hop is real waiting time. Direct links keep both crawlers and people moving.

301 vs 302: a nuance worth knowing

The redirect type does not change the recommendation, but it does change the urgency.

A 301 (and its strict cousin 308) signals a permanent move. If an internal link points at a 301, the destination is almost certainly the address you should be linking to anyway, so updating the link is a clean, lossless improvement.

A 302 (and 307) signals a temporary move. Here you should pause before mass-editing links: confirm whether the redirect is genuinely temporary or whether it is a permanent move mislabeled as a 302. Google has noted that a long-lived 302 tends to be treated more like a 301 over time, especially when internal and external links point to the destination. If the move is permanent, fix the redirect to a 301 first, then point your links at the destination. If it is truly temporary, leave the link as-is until the situation resolves.

How to diagnose

A crawler is the fastest way to find these. In Screaming Frog, run a crawl and open the Response Codes tab, filter to Redirection (3XX), and use the Inlinks panel for each redirecting URL to see exactly which of your pages link to it. The "All Redirects" report shows the source page, the redirecting URL, the final destination, and the number of hops. Sitebulb and other crawlers expose the same data under their redirect reports.

You can also spot-check a single URL from the command line to see the chain and the final landing point:

curl -sIL https://example.com/old-page/ | grep -i "HTTP/\|location"

# Example output:
# HTTP/2 301
# location: https://example.com/new-page/
# HTTP/2 200      <-- this is the URL your links should target

How to fix

The fix is to replace the redirecting URL in your link with the final 200 destination. Do not remove the server-side redirect itself, leave that in place so any external links and bookmarks still work. You are only changing where your own internal links point.

Work through it like this:

1. Export the redirect report from your crawler (source URL + final destination).
2. Group links by where they live: navigation/menu, templates, body content.
3. Edit the link target from the redirecting URL to the final 200 URL.
   Before:  <a href="/old-page/">
   After:   <a href="/new-page/">
4. Fix template/menu links first (they generate the most internal links).
5. Re-crawl and confirm the 3XX inlinks count drops to zero.

Prioritize sitewide elements such as the main menu, footer, and reusable content blocks, because a single redirecting link in a template can multiply across every page on the site. Once those are clean, sweep the in-content links.

Common mistakes

The single most frequent cause is a site migration or URL restructure where the redirects were set up correctly but the internal links were never updated to match. The redirects mask the problem, the site "works," and the stale links quietly sit there for months. After any migration, updating internal links to the new final URLs is a required cleanup step, not an optional one.

Other recurring slip-ups: relying on the redirect "because Google passes equity anyway" and never cleaning up; fixing the visible menu but forgetting hard-coded links inside blog posts or widgets; and editing a link to point at another redirecting URL, which creates a chain. Always verify your new target returns a 200 before you call it done.

FAQ