How Do You Find and Fix Internal Links That Point to Redirects?

How do you find and fix internal links that point to redirects?

You crawl your own site, export the redirected internal URLs with the pages that link to them, then edit those links to point at the final destination. It is a two hour job on most sites, it needs no developer, and it is one of the few technical fixes where the work is obvious once you can see the list.

This comes up on every site that has been alive for more than a year. Slugs change, posts get renamed, a category gets restructured, and the redirects get created correctly. What nobody goes back to fix is the hundreds of internal links still pointing at the old address.

This walkthrough is written for one specific situation: you run a content site, you did not build every page yourself, and you suspect your internal linking has drifted. Here is how to check.

Why does this matter if the redirect already works?

Because a redirect is a second request, and you are choosing to make every crawler and every visitor take it on a path you fully control. External links to old URLs need redirects. Your own links do not, because you can just edit them.

There is a signalling reason too. Google's documentation states plainly that permanent redirects show the new redirect target in search results, while temporary redirects show the source page in search results. If someone on your team set a temporary redirect by accident, your internal links are pointing at a URL that search results may still attribute to the old page.

The third reason is that this problem compounds quietly. One redirect is nothing. A site where every third internal link is redirected is a site where nobody has audited anything in two years, and that usually correlates with other problems worth finding.

What exactly is a redirect chain?

It is the version of this problem that has got worse over time. Screaming Frog defines an internal redirect chain as internal URLs that redirect to another URL, which also then redirects, and notes that each redirect is referred to as a hop. Its tool classifies the issue as a warning at medium severity.

Chains form for a boring reason. A page moves, you redirect A to B. Later B moves, and you redirect B to C without touching the first rule. Now A goes to B goes to C, and every internal link still pointing at A takes the long route.

When you fix internal links you should flatten the redirect rules at the same time, so that A points directly to C. Otherwise you have cleaned up the symptom on your own pages while leaving the chain in place for every external link and bookmark that still uses the old address.

Step one: how do you crawl your own site?

Use a desktop crawler and point it at your homepage. Screaming Frog is the one I reach for, and Sitebulb and Ahrefs Site Audit are the alternatives people usually name. What matters is that the tool follows internal links and records the response code of every URL it finds.

Before you start the crawl, do one thing that saves an hour later. Make sure the crawler is set to crawl your canonical hostname, with or without the www prefix, exactly as your site actually serves. Half the redirect reports I have seen from clients were really one hostname redirect being counted several thousand times. It is also worth checking the current limits of whichever crawler you choose on the vendor's own site, because those change.

Let the crawl finish completely. A partial crawl gives you a partial list, and there is nothing more annoying than fixing forty links and then discovering you missed the section with three hundred.

Step two: how do you get the list of pages doing the linking?

Filter the crawl results to response codes in the 300 range, then use the inlinks view for each of those URLs. That is the critical step, because the list of redirected URLs on its own tells you nothing about where to go and edit. You need the source page, not the destination.

Export that as a spreadsheet with three columns you actually care about: the page containing the link, the old URL it points to, and the final destination after the redirect resolves. Everything else in the export is noise for this particular job.

If your crawler offers a redirect chains report, export that too and keep it beside the first file. It is how you spot the cases where the final destination is two or three hops away rather than one, which changes how you write the replacement link.

Step three: which links do you fix first?

Sort by the number of pages linking to each redirected URL, and start at the top. One old URL linked from ninety pages is a single find and replace that fixes ninety links. One old URL linked from a single page is a five minute edit you can do whenever.

Then look at the navigation, the footer, and any component that appears site wide. A redirected link in a global element is technically one link and practically thousands, and it is usually the single highest value fix in the whole exercise.

Leave two categories alone for now. Links inside old posts that you plan to delete, and links pointing at URLs where the destination is itself wrong. The second one is a content decision rather than a technical fix, and it will slow you down if you mix the two jobs together.

Step four: how do you actually edit the links?

For links inside CMS content, a controlled find and replace on the rich text field is the fastest route, whether you do that through your CMS interface or its API. Replace the full old URL with the full new URL rather than a fragment, because a partial match will eventually catch a slug you did not intend.

Work on a copy first and check a sample of the changed items before you write anything back. I run this kind of edit as a dry run that prints every intended change, reads the output, and only then repeats it for real. On a site with hundreds of posts, a sloppy replace is much more expensive than the problem you started with.

For links in templates, navigation, or hard coded page content, edit them where they live and publish. Then re-crawl and confirm the count has dropped. If the number has not moved, your change did not go live, which happens more often than anyone admits. I covered the sibling version of this job in finding and fixing broken links on a Webflow site.

What about the redirect rules themselves?

Flatten the chains and check the type of each rule. Google's own documentation orders redirect methods by how likely Google is able to interpret them correctly, and states that a server side redirect has the highest chance of being interpreted correctly. That is the standard to aim for wherever your platform lets you set one.

Be careful with JavaScript redirects in particular. Google states that while it attempts to render every URL Googlebot crawled, rendering may fail for various reasons, and that if you set a JavaScript redirect, Google might never see it if rendering of the content failed. A redirect that might not be seen is not a redirect you want load bearing.

Where the redirect settings live differs by platform, so check your own platform's official documentation rather than a blog post, including a blog post like this one. The principle is stable. The interface is not, and it changes more often than the advice about it gets updated. If you want the deeper version of what these rules communicate, I wrote what a 301 actually tells a search engine.

How do you stop this happening again?

Make the slug a decision rather than an afterthought. Most redirected internal links exist because someone renamed a post for a reason that felt important at the time and was not. If a slug is good enough to publish, it is good enough to keep.

When a rename is genuinely necessary, treat the internal link update as part of the same task rather than a follow up. Create the redirect, run the crawl, fix the inbound internal links that day. The job takes ten minutes at the moment of change and hours six months later.

I run this audit on my own archive on a schedule, because with more than 350 published articles the drift is invisible until you measure it. If you are planning a larger restructure rather than a cleanup, the right starting point is a mapping exercise, which I set out in building a redirect map before a site migration.

What should you do next?

Crawl your site this week and filter to the 300 responses. If the count is under twenty, fix them in one sitting and move on with your life. If it is in the hundreds, you have found something worth a proper afternoon, and the top ten offenders will cover most of it.

Whatever the number turns out to be, write it down with today's date. The value of this audit is not the first pass, it is having a baseline so the next crawl tells you whether things are drifting again.

I do this for client sites often enough that I can usually guess the answer before the crawl finishes, and I am usually too low. If you want someone to run the audit and hand you the list with the fixes prioritised, reach out and let's chat.