How to Handle Internal Links During a Site Migration
Internal links are the part everybody forgets, because the redirects hide the problem completely. The site works, nothing appears broken and every internal link is quietly routing through a redirect it should never have needed. It is also the easiest thing in this entire subject to get right.
The Redirects Hide The Problem
After a migration, internal links pointing at old addresses still work. The redirects catch them, the visitor arrives at the right page and nothing anywhere reports a fault. That is precisely why this gets missed.
What a check would show. Nothing wrong.
Click any link and it works. Run a broken link check and it finds none, because none of them is broken. The site behaves correctly by every ordinary measure, which is what makes the problem invisible rather than merely overlooked.
What is actually happening. An unnecessary detour.
Every one of those links asks for an address that no longer holds anything, gets told where the content moved and then asks again. Two requests where one would do, repeated across every link on the site.
Why it survives so long. Nothing prompts a fix.
Problems get attention when something complains. This complains to nobody, so it can persist through several years and a second migration, by which point those links are travelling through two redirects rather than one.
Why it is worth a page. The effort is trivial.
Almost nothing else in this subject combines a real issue with a fix this straightforward, which is the argument in block seven.
Why It Matters Anyway
Every internal link should point at the address the content actually lives at. Not because a redirect fails. The indirection is entirely avoidable. It is your own site doing it to itself.
The claim we are not making. A quantified leak.
Plenty of writing on this subject asserts that a specific proportion of value is lost through each redirect. No published source supports a figure. The vendor's own documentation says something rather different about permanent redirects, as reported on our redirects guide. We do not repeat numbers nobody can attribute.
The argument that does hold. Correctness.
An internal link is a statement the site makes about itself. Pointing it at an address that has moved is stating something that is no longer true, then relying on a correction mechanism to compensate. That is worth fixing on its own terms.
The practical cost. Requests, multiplied.
Each redirected link is an extra round trip before anything appears. On a page carrying thirty internal links, that adds up. On a site where every template link is affected it adds up everywhere at once.
The one that matters most. Dependency.
Links routed through redirects work only while the redirects exist. Correcting them means the site no longer depends on a mechanism somebody may tidy away in three years.
Update Them In The Content, Not With Redirects
Redirects exist to protect the links you cannot reach. Internal links are entirely within your own control, so they should simply be correct.
What redirects are actually for. Other people's links.
Every link another site has ever made. Every bookmark. Every address in an old email or a printed document. None of those can be edited by you, which is exactly why a safety net is needed.
Why internal links are different. You own both ends.
The link and its destination are both yours. There is no reason to route your own traffic through a correction mechanism designed for things you cannot change.
What the distinction prevents. A growing dependency.
A site that relies on redirects for its own navigation has made those redirects load-bearing. Sites that migrate twice end up with internal links pointing at addresses from two generations ago, all working, all through chains.
When to do it. During the build, ideally.
Correcting links while pages are being created costs nothing. Doing it afterwards is a separate task somebody has to be given, which is block seven.
Where They Hide
A sweep of page content finds a fraction of a site's internal links. The rest live in places nobody thinks to look. Those are frequently the ones repeated across every page.
Navigation. The most repeated links on the site.
Menu items appear on every page. One wrong address in a menu is that address wrong thousands of times.
Footers. Rarely reviewed by anybody.
Frequently containing older links to policies, contact routes and sections that were reorganised at some point.
Links inside the content. The obvious ones.
Written by people, over years, pointing at whatever the address was at the time.
Image links and buttons. Easily missed.
An address attached to an image or a button is not text, so it does not appear in a text review.
Anything hard-coded into a template. The most stubborn.
Addresses written into a template rather than generated. These survive content changes entirely, because the content is not where they live.
Preserve The Structure, Not Just The Links
Correcting addresses is the mechanical half. The other half is whether the same pages still link to each other at all, which a rebuild changes routinely without anybody deciding to.
What the linking structure describes. How the site understands itself.
Which pages support which, what belongs under what and which pages the site treats as important. That is expressed almost entirely through internal links rather than through anything anybody writes down.
What a rebuild does to it. Rearranges it silently.
New templates link differently. A page that used to be reached from twelve places is now reached from two. Nothing was deleted. Its position within the site has changed considerably.
Why it goes unnoticed. No address broke.
Every link works. The map is complete. The redirects are clean. And the site is describing a different hierarchy from the one it described last month.
What to do about it. Record it beforehand.
The pre-migration crawl captures which pages link to which. Comparing that afterwards is the only way to see structural change, which is another use for a record taken while the old site still existed.
Navigation Changes Are Structural Changes
A redesign that removes items from a menu has changed what the site emphasises. That is a migration decision wearing the clothes of a design decision. It is almost never recorded as one.
Why menus get trimmed. Good reasons, mostly.
Cleaner navigation is easier to use, while a menu with fourteen items serves nobody. Reducing it is frequently the right call for visitors, which is why the decision is made on those grounds alone.
What else it does. Demotes whatever was removed.
A section reached from every page is being treated as central. The same section reached only from a sub-page two levels down is being treated as peripheral. Nothing about the content changed.
Why this is worth raising during the build. It can be balanced.
A page removed from the main menu can still be linked prominently from elsewhere. That preserves its position while achieving the simpler navigation the designer wanted. It costs nothing if raised at the right time.
What to record. What moved and why.
So that if that section declines afterwards, nobody spends three weeks investigating the redirects.
Check It After Launch
This is one of the first post-launch checks and one of the easiest things to correct, which is an unusual combination and the reason it belongs early in the first week.
What the check looks for. Links that redirect.
Not links that break. Links that work by being redirected, which is a different thing and the reason an ordinary broken link check will not find them.
Why it is worth doing early. Everything else is harder.
Most post-launch problems require diagnosis, decisions and somebody with access. This one requires replacing an address with another address, in places you already control.
Where to start. Templates before content.
A single link in a navigation or footer template affects every page. Correcting those first fixes the largest number of instances for the smallest amount of work.
Where the rest of this sits. The surrounding stages.
The map is in URL mapping for a site migration, the mechanism is in how to implement 301 redirects, what to watch afterwards is in monitoring after migration. The full series is on the website migration guide.
They work.
That is why
nobody looks.
Internal links corrected rather than left to the redirects, templates fixed first because one link there is that link on every page, the linking structure compared against the record so a quiet demotion is visible, menu removals raised during the build while they can still be balanced, with no figure quoted that nobody can attribute.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
