Orphan Only Found via Redirect: How to Fix It

Unlike an orphan island, this page is not linked from anything — not from a live page, not from another orphan. Its sole discovery path is a redirect: an old URL was retired, a 301 points at this one, and that hop is the only reason Google ever landed here. The stakes: redirects pass equity but they are fragile and they are not a navigation strategy. The day someone cleans up "redundant" redirects, or a redirect chain gets flattened, this page silently drops out of the crawlable graph.

A real example: prove it with curl

Say your crawler flags /services/seo-audit/ as reachable only via redirect. Check the URL that supposedly links to it — the old one — and watch it hop straight to the destination with a 301:

$ curl -sI https://example.com/old-audit-page/ | grep -iE 'HTTP|location'
HTTP/2 301
location: https://example.com/services/seo-audit/

$ curl -sI https://example.com/services/seo-audit/ | grep -iE 'HTTP'
HTTP/2 200            # the live page — 200 OK, healthy

The destination returns a clean 200. Nothing is broken. The problem is that /old-audit-page/ is the only thing anywhere that leads to /services/seo-audit/. Grep your crawl export for internal links whose target is the destination and you will find exactly one source: the redirecting URL. Remove that redirect, or let it fall out of a future migration, and the live 200 page becomes an unreachable orphan.

The fix in one move: add a genuine editorial internal link to /services/seo-audit/ from a page in your normal architecture — the services menu, a related case study, the homepage footer if it belongs there. Now the page has a real crawl path that does not depend on a legacy redirect surviving.

Redirect-only vs. the other orphan variants

These are cousins, not the same bug. The island case is covered in orphan linked only from other orphans; the canonical case in isolated URL only found via canonical.

How to detect it

1. Crawl and diff against the sitemap. In Screaming Frog, crawl from the homepage with "Always Follow Redirects" enabled, then include the XML sitemap. Any URL the spider only reached after following a redirect — and never via a direct <a href> — is a candidate.
2. Read the redirect chains report. Reports → Redirects → Redirect Chains. For each destination, check the "Internal → All Inlinks" tab: if the only inlink to the 200 page is the redirecting source (a 3xx), the redirect is its sole path.
3. Confirm with curl. Run curl -sI on the destination (expect 200) and on the suspected source (expect 301/302 with a location header pointing to it). Then grep your export to confirm no other page links directly to the destination.
4. Check Search Console. URL Inspection on the destination will often show it was discovered through the redirecting URL and list no referring internal links of its own.

How to fix it

1. Give the destination a real inbound link. Add at least one contextual editorial link from a live, crawlable page. This is the whole fix — everything else is cleanup.
2. Keep the redirect (for now). Do not rush to delete the old 301. It still passes equity from any external links pointing at the retired URL. Just stop relying on it for internal discovery.
3. Flatten any chain. If the redirect is really A → B → destination, point A straight at the destination. Chains bleed equity and slow crawling. See our guide on redirect loops and self-redirects for the messier cases.
4. Update internal links that still point at the old URL. Any live page linking to the retired source should be edited to link the destination directly, so crawlers and users skip the hop entirely.
5. Re-crawl. Confirm the destination now appears with a direct internal inlink and a sane crawl depth, independent of the redirect.

FAQ

Redirects pass PageRank, so why does this matter?

They do pass equity, but a redirect is a maintenance liability, not a navigation layer. Redirects get pruned during migrations, consolidated by well-meaning devs, and lost when hosting or CDN rules change. Any page whose only lifeline is a single 301 is one cleanup task away from being invisible. A real internal link is durable; a redirect is a patch.

Should I delete the redirect once I add a link?

Not immediately. If the retired URL earned external backlinks or still gets typed/bookmarked traffic, the 301 is doing useful work funneling that equity forward. Keep it, but make sure it is no longer the only way in. Retire it only once you are confident nothing of value points at the old URL.

Does a 302 change anything here?

Yes, for the worse. A 302 signals "temporary," so Google may keep the old URL indexed and treat the destination as a passing stop rather than the canonical page. If the move is permanent, use a 301. Either way, the destination still needs its own real internal link.

The destination returns 200 and gets traffic. Is there really a problem?

The traffic today is masking a single point of failure. It works because the redirect still exists. The check is a forward-looking warning: the moment that redirect goes, so does the page. Fixing it costs one link and removes the risk.

How is this different from a normal orphan?

A normal orphan has no path in except the sitemap. This page does have a path, but it runs through a redirect instead of a link, which makes it look reachable in tools that follow redirects while still being structurally abandoned. Same destination, different discovery mechanism.

Related reading: URL is orphaned · Internal URL redirects back to itself · Redirect map generator · Redirects & HTTP status codes FAQ