Fixing Internal Links After a Site Migration
After a migration, redirects catch visitors who arrive from old links. Your own pages should not need them. Yet most migrated sites still link internally to old addresses: in body text, buttons, footers, image links and product descriptions written years ago. Each of those links sends visitors and crawlers through a redirect, and some land on a 404.
Just as often, the new navigation quietly drops links to pages that used to be prominent. This guide shows how to find both problems, rewrite old links in bulk using the redirect map, and restore the internal links your important pages had before.
Two different problems under one heading
The Site Migration Audit's internal link check tends to surface two separate issues, and they need different fixes.
1. Links that point at old addresses
These still work for a visitor, because the redirect catches them, but every click and every crawl takes an extra request. Some point at old URLs that were never mapped, and those end on a 404. They are mostly a clean-up job: find each old address and replace it with the new one.
2. Links that no longer exist at all
A new design often changes the navigation. A category that sat in the main menu is moved into a sub-menu; related-product blocks disappear; a sidebar of popular articles is dropped. The pages still exist and are not broken, but they now receive far fewer internal links. Search engines use internal links to discover pages and to judge their relative importance, so a page that loses most of its links can slip even when its redirect and content are perfect.
Where old links hide on a migrated site
| Location | Why old links survive there | How it is fixed |
|---|---|---|
| Main menu, footer, header | Menus were rebuilt by hand and someone pasted old addresses, or a menu item points at a custom URL rather than a page object. | Edit once in the menu or template; the change applies everywhere. |
| Body text of pages and posts | Imported content keeps every link exactly as it was written. | Bulk find and replace, guided by the redirect map. |
| Product and category descriptions | Written in an editor years ago with absolute links to old paths. | Bulk edit through export and import, or the platform's API. |
| Reusable blocks, widgets and banners | Stored separately from pages, so a page-level search misses them. | Edit the block or widget itself. |
| Image links and media | Images link to old attachment pages or to files on the old domain. | Replace the file addresses, and remove links to attachment pages. |
| Hard-coded template code | A developer wrote a path into a theme file or component. | Change the code, ideally to a generated link. |
| Canonical, hreflang and sitemap entries | Not clickable links, but crawlers follow them too. | Covered by the canonical and sitemap guides in this hub. |
Finding old links with a crawl
Crawl the new site with redirects recorded rather than silently followed. Most desktop crawlers can export every internal link whose target returned a 3xx or 4xx, together with the page it appeared on and the anchor text. In Screaming Frog, for example, the bulk export for redirection inlinks and client error inlinks gives exactly this list.
From that export you want three columns: the source page, the link target and the status code. Then add a fourth column by looking up the target in the redirect map, which gives the address the link should use instead.
=IFERROR(XLOOKUP(B2, RedirectMap!A:A, RedirectMap!B:B), "NOT IN MAP")Rows marked NOT IN MAP are old addresses that the redirect map missed. They need a decision
in the map first, and then the link can be updated. The redirect
map guide covers how to add them.
Because the crawl starts from the home page, it will not find links on pages that are no longer linked from anywhere. Add the full list of new URLs from the sitemap as extra start points, so orphaned pages are crawled and their links checked too.
Rewriting links in bulk safely
A site with thousands of old links cannot be fixed page by page. The safe approach is a scripted replacement that uses the redirect map as its only source of truth, run first as a preview.
WordPress
WP-CLI's search-replace command handles serialised data correctly, which a plain SQL
UPDATE does not, so page builder and widget settings are not corrupted. Always take a database
backup and run a dry run first.
# preview: how many changes, and in which tables
wp search-replace 'https://old-example.co.uk' 'https://www.example.co.uk' --dry-run --report-changed-only --skip-columns=guid
# path changes from the redirect map, one pair at a time
wp search-replace '/shop/oak-desk-120cm.html' '/furniture/desks/oak-desk-120/' --dry-run --report-changed-only --skip-columns=guidReplacing paths one pair at a time is fine for a few hundred rows. Generate the commands from the spreadsheet rather than typing them, and sort the pairs so longer old paths run before shorter ones, or a short path can match inside a longer one and produce a broken address.
Shopify and other hosted platforms
Export products, collections, pages and blog posts to CSV, replace the old addresses in the body HTML columns with a script, and import the files again. Test with a handful of rows first, because imports can overwrite other fields. Menus are edited under Online Store, Navigation. Larger stores often use the Admin API instead, which avoids the full export and import.
Headless CMSs and custom databases
Rich text fields in a headless CMS are usually stored as structured JSON rather than HTML, so a text replace can break them. Use the CMS's own migration scripts or management API to walk every entry, update link nodes and republish.
example.co.uk on its own also changes email addresses, image CDN hosts and subdomains. Replace
the full https://old-example.co.uk string, and preview the result.The fix, step by step
Step 1
Crawl the new site and list links to old addresses
Crawl the live site with redirects recorded rather than followed, using the home page and the full sitemap as start points so orphaned pages are included. Export every internal link whose target returns a redirect or an error, with the source page, target and anchor text. Add a column that looks up each target in the redirect map to get its correct new address, and flag targets that the map does not contain at all.
Step 2
Group the links by where they are stored
Sort the export by target and count how many source pages share it. A target linked from nearly every page lives in a menu, header, footer or sidebar. Targets linked from one section usually come from a template or reusable block. The long tail of targets on single pages is in body content. Label each group with where it is stored, because that decides which tool fixes it and how many links one change will correct.
Step 3
Fix navigation and template links first
Edit the menus, footer, header, widgets, reusable blocks and theme or component files so each link points at the final new address. Where a menu item was entered as a custom URL, replace it with a link to the page itself, so it updates automatically if the page moves again. These few changes usually remove most of the flagged links, because each one appears on every page that uses the template.
Step 4
Rewrite content links using the redirect map
Back up the database or export the content, then run a scripted replacement driven
only by the redirect map, starting with a dry run. In WordPress use WP-CLI search-replace,
which respects serialised data. On hosted platforms edit exported CSV files or use the API, and in a
headless CMS update link nodes through its management API. Run the longest old paths first so no replacement
matches inside another.
Step 5
Replace hard-coded old-domain and staging hosts
Search the content, settings and theme files for the old domain, any http version and the staging host, and replace them with the new https address or with root-relative paths. Check image sources, download links, iframes and the site address settings as well as normal links. Replace the full host including the scheme, never a bare domain name, so email addresses and third-party hosts that contain the same words are left alone.
Step 6
Compare internal links to key pages before and after
From the old crawl, take the number of internal links pointing at each of your most important pages, and compare it with the new crawl using the mapped addresses. Any page that has lost a large share of its links needs them restored: add it back to the navigation, category listings, related-content blocks or relevant body text. Pay particular attention to pages that were in the old main menu.
Step 7
Recrawl and block old links from returning
Run the crawl again and confirm the export of links to redirects and errors is empty, or contains only links you have decided to leave. Rerun the Site Migration Audit to check its internal link findings. Then stop the problem returning: remove old pages from editors' link pickers, add a check for the old domain to the deploy or publishing process, and schedule a monthly crawl for the first year.
Restoring the link structure, not just the addresses
Rewriting old addresses fixes the plumbing. Recovering rankings sometimes also needs the old shape of the site. Compare the two crawls by the number of internal links, often called inlinks, that each important page receives.
| Page | Inlinks before | Inlinks after | Likely cause |
|---|---|---|---|
| Oak desks category | Linked from every page | Linked from one hub page | Removed from the main menu in the redesign |
| Delivery information | Linked from every product | Linked from the footer only | Product template no longer includes the delivery link |
| Buying guide article | Dozens of related-post links | A handful | New theme has no related-posts block |
Exact counts matter less than the direction. You do not need to recreate the old site link for link, but a page that the business depends on should not become hard to reach. Restore links through the things visitors actually use: menus, category pages, breadcrumbs, related items and contextual links in articles.
Watch click depth too. If a page was two clicks from the home page before the move and is now five, crawlers and visitors are less likely to reach it. The Internal Links Guide explains how to plan link structure beyond the migration itself.
Edge cases worth checking
- Relative links that change meaning. A link written as
../guides/resolves differently if the page moved to a deeper or shallower folder. Root-relative links such as/guides/are safer. - Links with fragments and parameters.
/old-page#deliveryor/old-page?colour=oakmay not match a map row written for the bare path. Handle the base path, then keep the fragment. - Case and trailing slashes. A link to
/About-Usor/serviceswithout the slash may redirect even after the rewrite if the new site is strict. Use the exact canonical form. - JavaScript navigation. Menus built in JavaScript may not appear in a basic crawl.
Crawl with rendering on, and make sure important links are real
<a href>elements. - Links in PDFs and emails. You cannot rewrite links in sent emails or downloaded files. These rely on redirects, which is one reason to keep them long term.
1. Do internal links through a 301 redirect hurt SEO?
A single redirect does not stop search engines following the link, and signals still pass. The problems are practical. Every link through a redirect costs an extra request for crawlers and visitors, slows page loads slightly, and depends on the redirect staying in place forever. Across thousands of links that adds up, and any old address missing from the redirect map becomes a broken link. Pointing internal links straight at the new URLs removes all of that risk.
2. Should I rely on redirects instead of updating internal links?
Redirects are meant for links you do not control, such as other websites, bookmarks and old emails. Your own links are under your control, so updating them is the cleaner choice. Relying on redirects also makes the site fragile: if a rule is removed or the redirect map is replaced in a later project, every internal link that depended on it breaks at once. Keep the redirects, but do not make your own site need them.
3. How do I find internal links to my old domain?
Crawl the new site and export links whose target is on another host, then filter for the old domain. Also search the database or content exports for the old domain as text, because a crawl only finds links on pages it can reach. Remember image sources, iframes and download links, which crawlers may list separately from normal links. In WordPress, a WP-CLI search-replace dry run reports how many matches exist in each table without changing anything.
4. Is it safe to run find and replace on the whole WordPress database?
It is safe if you use a tool that understands serialised data, such as WP-CLI search-replace or a well-established search and replace plugin, take a full backup first, and run a dry run. A plain SQL replace can corrupt serialised settings when the length of a string changes, which can break widgets and page builder layouts. Skip the guid column, replace full addresses including the scheme, and check a sample of pages afterwards.
5. My new navigation has fewer links. Will that affect rankings?
It can, if pages that matter lose most of their internal links. Search engines use internal links to find pages and to judge which ones the site considers important. A simpler menu is fine, but make sure key categories, services and top articles are still linked from somewhere prominent, such as category pages, breadcrumbs, related content or contextual links in articles. Compare internal link counts for your top pages before and after the migration to find the losses.
6. Should internal links be absolute or relative after a migration?
Either works for search engines, as long as they resolve to the correct canonical address. Root-relative links, which start with a slash, survive future domain changes and work on staging without editing. Absolute links are clearer in exported content and emails but need replacing if the domain changes again. Avoid document-relative links such as ../page, which break when pages move between folders. Whatever you choose, be consistent, and let templates and menus generate links rather than hard-coding them.
The Site Migration Audit compares your pre-migration crawl with the live site, finds lost URLs, validates redirects and audits internal links, so links still pointing at old addresses show up in one list.
Open Migration Audit Fixes →