# How do I fix broken links after a WordPress migration?

> Crawl the new site to find every 404 and broken reference, then fix each by redirecting the old URL with a 301, repairing the internal link to point at the new URL, or restoring a missing page or image. Broken links after a migration come from unmapped URLs, hardcoded old links, and unmigrated media. A crawl surfaces them all so none are missed. WPBuildAI crawls the migrated site, maps the redirects, and rewrites internal links so nothing dead-ends.

Source: https://wpbuildai.com/fix-broken-links-wordpress-after-migration/
By lawrence-arya · 2026-06-26

---
To fix broken links after a WordPress migration, the method is the same one that should have prevented them: crawl the whole site and act on what you find. A crawl surfaces every 404 and broken reference, and each gets one of three fixes, redirect the old URL with a 301, repair the internal link to point at the new URL, or restore a missing page or image. The breaks come from URLs that changed while references did not follow. WPBuildAI crawls the migrated site, maps the redirects, and rewrites internal links so nothing dead-ends.

Be wary of fixing this by stacking another plugin on the pile, because Patchstack found that [91 percent of the 11,334 WordPress vulnerabilities disclosed in 2025 were in plugins while only six were in core](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/), and a link-checker left installed long after the migration is exactly the kind of forgotten dependency that ages badly.

## Where the broken links come from

A migration changes URLs, and three kinds of reference fail to keep up, which is the whole source of post-migration broken links. Internal links hardcoded to the old URLs now point at addresses that no longer exist. Images still reference the old media library, which the move may have left behind, so they break when the old site comes down. And old URLs that visitors and search engines still hit have no redirect, so they 404. The content itself moved fine; what broke is the web of references pointing at the old addresses. The 2024 [Web Almanac](https://almanac.httparchive.org/en/2024/) shows how many internal links and media references a typical site carries, which is why these breaks scatter across pages and are easy to miss by hand. Only a crawl finds them all, because no person can manually check every link on every page.

## The three kinds of breakage

Separating the breaks by type tells you how to fix each. First, unmapped old URLs: external links, bookmarks, and search results pointing at old addresses that now 404, fixed with redirects. Second, hardcoded internal links: links inside your own content or navigation that were written with the old URLs and now point nowhere, fixed by repairing the link to the new URL. Third, unmigrated or mis-referenced media: images and files still pointing at the old media library or a path that did not move, fixed by re-hosting and updating the reference. These three have different fixes, and a complete repair addresses all of them, not just the most visible. Treating "broken links" as one undifferentiated problem leads to fixing the obvious 404s while leaving hardcoded internal links and broken images in place, which is why naming the three kinds matters.

## Redirect inbound, repair internal

The two main fixes serve different links, and using the right one for each keeps the result clean. Redirects handle inbound links and bookmarks you do not control: a 301 sends the old URL to the new one, which is the only way to fix a link that lives on someone else's site or in a search index, the basis of the [URL mapping template](/website-url-mapping-template-excel-automated/), and Google's [redirects guidance](https://developers.google.com/search/docs/crawling-indexing/301-redirects) confirms the 301 carries the ranking signal across. Repairs handle your own internal links: update them to point at the new URL directly, which is cleaner than leaning on a redirect, because it avoids an unnecessary hop and keeps your internal-link graph pointing at live URLs. A complete fix uses both: redirects for what you cannot edit, repairs for what you can. Because a small set of pages carries most traffic, Ahrefs found in its [search traffic study](https://ahrefs.com/blog/search-traffic-study/) that fixing the links on those high-value pages matters most.

## A worked example: a migration's broken-link audit

Picture a site freshly migrated where things look fine until you crawl it. The crawl returns a list: 40 old URLs returning 404 with no redirect, 120 internal links across various pages still hardcoded to old URLs, and 30 images referencing the old media library. Each group gets its fix. The 40 unmapped URLs get 301s to their new equivalents, catching the external links and bookmarks. The 120 internal links are rewritten to the new paths, so the site's own navigation and in-content links point at live URLs in one hop. The 30 images are re-hosted on the new site and their references updated, so they will not vanish when the old site is decommissioned. Without the crawl, the team would have noticed maybe a handful of these by chance and shipped the rest broken. The crawl turned an invisible, scattered problem into a finite, fixable list, which is the whole value of auditing rather than spot-checking.

## Finding them: crawl, do not sample

The single most important thing is completeness, which means crawling the whole site, not sampling a few pages. Broken links scatter unpredictably: a hardcoded old URL might sit in one paragraph of one old post, an image reference might be in a widget on a template, an unmapped URL might be a page no one remembers. Checking a sample finds the breaks on the pages you happened to check and misses the rest, which then surface later as visitor complaints or ranking dips. A crawl that follows every internal link and checks every reference reports every 404 and broken resource across the site, turning the scattered problem into one list. This is the same completeness principle behind a migration's URL inventory: you cannot fix what you have not found, and only a full crawl finds it all. Sampling feels faster but guarantees you ship some broken links.

## Confirm nothing was missed

Even a thorough crawl benefits from a second check, because the crawl finds internal breaks while Search Console finds external ones. Crawl the whole site to catch internal broken links and missing media, then watch Search Console over the following weeks, since it surfaces external links and old URLs that real users and Googlebot are still hitting, following Google's [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). The two sources cover both sides: the crawl sees your site from the inside, Search Console sees how the outside world requests it. Unfixed URLs often show up as [soft 404s](/why-am-i-getting-soft-404-errors-after-website-redesign/), and you verify the redirects you added actually resolve with [a check that your 301s work](/check-if-301-redirects-are-working-correctly/). Missing images are handled as in [migrating images without broken links](/blog/how-to-migrate-wordpress-images-and-media-without-broken-links/). Combining the crawl and Search Console is what gives confidence that nothing was missed.

## Preventing them next time

Fixing broken links after the fact is the recovery path; the better version is to prevent them during the migration, with the same crawl-first discipline. Before launch, crawl the old site to inventory every URL and reference, map each old URL to a 301, plan to re-host the media, and rewrite internal links to the new paths as part of the build rather than afterward. Done that way, the new site launches with no unmapped URLs, no hardcoded old links, and no hotlinked media, so there are no broken links to fix. The post-migration repair described here is what you do when that prevention was skipped, but the inputs are identical, a complete crawl and a redirect map, which is why a migration done crawl-first rarely produces the broken-link cleanup that an ad-hoc one requires.

## Common mistakes fixing broken links

The recurring errors all leave some breaks unfixed. Sampling pages instead of crawling the whole site finds the obvious 404s and misses the scattered internal and media breaks. Fixing only the 404s, and ignoring hardcoded internal links and broken images, leaves two of the three breakage types in place. Relying on redirects for internal links, instead of repairing them, leaves your own navigation bouncing through unnecessary hops. Leaving images hotlinked to the old domain means they break later when it is retired. And skipping the post-launch Search Console watch misses the external links still hitting old URLs. Each is avoided by the complete approach: crawl the whole site, fix all three breakage types with the right tool for each, re-host media, and confirm with Search Console afterward, which leaves the migrated site with nothing dead-ending.

## Key points to remember

Broken links after a WordPress migration come from changed URLs whose references did not follow, in three forms: unmapped old URLs that 404, hardcoded internal links pointing at old addresses, and media still referencing the old library. Find them all by crawling the whole site, not sampling, then fix each with the right tool: 301 redirects for inbound links you do not control, direct repairs for your own internal links, and re-hosting for media. Confirm completeness by combining the crawl with a Search Console watch over the following weeks, and prevent the whole problem next time with a crawl-first migration. WPBuildAI crawls the migrated site, maps redirects, and rewrites internal links, so nothing dead-ends; send your site URL for a fixed quote.

Not affiliated with WordPress or Lovable.