Broken links are one of the most common things to surface after a migration — internal links leading to errors, images not loading, or links still pointing back to the old site. They are almost always a symptom of one underlying cause (stored URLs that were not updated), and once you understand that, fixing them is systematic rather than a game of whack-a-mole. This guide explains why links break after a migration and exactly how to find and fix them, at the root and individually.

You will learn why links break after a migration, the root cause behind most of them, how to find broken links across your site, the primary fix (a database search-and-replace), how to handle redirects for genuinely changed URLs, and how to verify the links are fixed. By the end you will be able to resolve post-migration broken links methodically, addressing the cause rather than chasing each symptom.

Why links break after a migration

Links break after a migration primarily because URLs are stored throughout your site’s database and content, and a migration can leave those stored URLs pointing at the old location instead of the new one. When your address changes in any way — a new domain, a switch to HTTPS, a move that involved a temporary URL, or even hard-coded old URLs — the links, image references, and other URLs saved in your database still refer to where the site used to be.

The result manifests in several ways that all look like ‘broken links’: internal links that lead to errors or the wrong place, images that fail to load (because their stored URL points to the old host), and links that visibly point back to the old site’s domain. On a pure same-domain host move these problems are usually minimal, but on any URL-changing migration they are common and expected until fixed.

So the reason links break is that a migration changes where the site lives but does not automatically update every URL baked into the database and content — those stale references are the breakage. Understanding this reframes the problem: you are not dealing with dozens of unrelated broken links, but with one underlying issue (stale stored URLs) showing up in many places. That reframing is what makes the fix systematic rather than an endless individual hunt.

The root cause behind most broken links

The single root cause behind the great majority of post-migration broken links is stored URLs in the database that still reference the old location. WordPress and similar systems save absolute URLs in many places — in post and page content, in settings, in image references, in widget and plugin configuration — and all of those persist through a migration, still pointing to the old address unless deliberately updated.

This is why post-migration broken links tend to appear in bulk and share a pattern: they all point to the old domain or old location, because they all come from the same source — the un-updated URLs in the database. A single missing image and a hundred broken internal links can have the identical cause. This is enormously helpful, because it means one root-cause fix (updating those stored URLs) resolves most of them at once.

So before hunting individual broken links, recognise that most of them are one problem wearing many faces: stale stored URLs. The primary fix, therefore, is not to correct each link by hand but to update all the stored URLs across the database in a single operation — a search-and-replace. Chasing individual broken links without addressing this root cause is the whack-a-mole trap; fixing the stored URLs at the source is what makes the problem vanish comprehensively.

Finding broken links across your site

To fix broken links thoroughly, you first want to find them, and there are several ways to locate broken links across your site:

• Click through key pages: manually check your most important pages and their links, images, and navigation — quick for spotting the obvious, prominent breakages.
• A broken-link checker tool: online or plugin-based crawlers scan your whole site and report every broken link and missing image, giving a comprehensive list.
• Browser developer tools: the console flags failed resource loads (like images) on a page, revealing which URLs are failing.
• Check for old-domain references: search your site or database for any remaining references to the old domain/location, which are your stale URLs.

A crawler-style broken-link checker is the most thorough way to get a complete picture, since it visits every page and tests every link and image, catching breakages you would miss by manual clicking. But for a migration, the most telling check is searching for remaining references to your old domain or location — because those are the root-cause stale URLs, and finding them confirms the scope of the search-and-replace you need. So use a broken-link checker for completeness, and look specifically for old-location references to target the underlying cause. Finding the breakages both confirms the problem and lets you verify the fix afterward.

The primary fix: search-and-replace

The primary fix for post-migration broken links is a database search-and-replace: updating every stored reference to the old URL so it points to the new one, in a single operation across the whole database. Because most broken links stem from stale stored URLs, this one fix resolves the majority of them at once — the systematic solution to what looks like many separate problems.

You run it with a serialisation-aware tool (a dedicated safe search-replace script, a reputable plugin, or WP-CLI), searching for your old URL and replacing with your new URL — and it is critical to use such a tool rather than a naive find-and-replace, because WordPress stores some data in a serialised format that a blind replace corrupts. The tool updates the URLs throughout the database (content, settings, references) safely, so all those stale links now point to the new location.

So the primary fix is a proper, serialisation-safe search-and-replace of the old URL to the new one across the database. After running it, the images that were loading from the old host now load from the new one, the internal links now point to the new site, and the bulk of your broken links are resolved in that single pass. This root-cause fix is far more effective than correcting links individually, and it is the first thing to do about post-migration broken links — address the source, and most of the symptoms disappear together.

Handling redirects for changed URLs

A search-and-replace fixes links that pointed to the old location by updating them to the new one — but there is a related case it does not cover: individual URLs whose actual path changed in the migration, where old inbound links (and search-engine entries) still expect the old path. For these, the fix is not search-and-replace but redirects.

If your migration changed URL paths (not just the domain) — for instance, restructuring your permalinks so a page that was at one path is now at another — then external links and bookmarks to the old paths, and search engines’ indexed old URLs, will break unless you redirect them. The fix is 301 redirects mapping each changed old URL to its new counterpart, so anyone (or any search engine) hitting the old path is sent to the new one.

So distinguish the two cases: stale stored URLs pointing at the old location are fixed by search-and-replace (updating them to the new location), while genuinely changed URL paths need 301 redirects (so old links to those paths still work). A domain change needs comprehensive redirects from every old-domain URL to its new-domain equivalent; a same-domain restructure needs redirects for the paths that changed. Handling redirects for changed URLs, alongside the search-and-replace for stale stored URLs, covers both sources of post-migration link breakage — the internal stale references and the external links to moved URLs.

Verifying the links are fixed

After running the search-and-replace and setting up any needed redirects, verify that the broken links are actually resolved — both to confirm success and to catch anything the root-cause fixes missed. Re-run the broken-link checker you used to find the problems, and confirm the previously-broken links now work: internal links resolve to the new site, images load, and there are no remaining references to the old location.

Check specifically that the symptoms are gone: the images that were failing now display, the internal links that led nowhere now go to the right pages, and a search of your site or database for old-domain references now returns nothing (or only intentional ones). For changed URLs, test a few old paths and confirm they redirect correctly to their new counterparts. This confirms both the search-and-replace and the redirects did their jobs.

If a few broken links remain after the root-cause fixes, they are the genuine one-offs — a hard-coded link somewhere the search-and-replace did not reach, or a link to a page that no longer exists — and now, having eliminated the bulk with the systematic fix, you can address these individually, which is manageable since there should be few. So verification confirms the root-cause fixes worked and isolates any true stragglers for individual attention. When the checker comes back clean, your images load, your links resolve, and no old-location references remain, the post-migration broken-link problem is fully fixed — resolved at the root, then finished off at the edges.

FAQs

How do I fix broken links after a migration?

Address the root cause first: most broken links come from URLs stored in your database still pointing at the old location, so run a serialisation-safe database search-and-replace to update the old URL to the new one across the whole database — this fixes the bulk at once. Then set up 301 redirects for any URL paths that genuinely changed, and verify with a broken-link checker, addressing any few remaining one-offs individually.

Why do links break after migrating a website?

Because URLs are stored throughout your database and content (in posts, settings, image references, plugin config), and a migration that changes your address leaves those stored URLs pointing at the old location. The result is internal links leading to errors, images failing to load, and links pointing back to the old site. It’s one underlying issue — stale stored URLs — showing up in many places.

What causes most broken links after a migration?

Stored URLs in the database that still reference the old location. WordPress saves absolute URLs in content, settings, image references, and configuration, and these persist through a migration pointing at the old address unless updated. That’s why post-migration broken links appear in bulk and all point to the old domain — they share one root cause, which one search-and-replace fixes comprehensively.

How do I find broken links on my site?

Use a broken-link checker (an online or plugin-based crawler that scans your whole site and reports every broken link and missing image) for completeness; click through key pages for the obvious ones; use browser developer tools’ console to spot failed resource loads; and specifically search your site or database for remaining references to your old domain — those are the stale URLs at the root of the problem.

What’s the difference between search-and-replace and redirects for broken links?

Search-and-replace fixes stale stored URLs by updating them from the old location to the new one across your database — for links that were internal references pointing at the old site. Redirects (301s) handle URLs whose actual path changed in the migration, so old inbound links and search-engine entries to the old paths still work. Stale stored URLs → search-and-replace; genuinely moved URLs → redirects. You often need both.

How do I verify broken links are fixed?

Re-run the broken-link checker and confirm the previously-broken links now work — internal links resolve to the new site, images load, and a search for old-domain references returns nothing (or only intentional ones). Test a few old paths redirect correctly if URLs changed. Any few links still broken after the root-cause fixes are genuine one-offs to address individually, which is manageable once the bulk is resolved.

The bottom line

Broken links after a migration look like dozens of separate problems but almost always trace to one root cause: URLs stored throughout your database and content — in posts, settings, image references, and plugin configuration — still pointing at the old location after your address changed. That is why they appear in bulk, all referencing the old domain, and it is enormously good news, because it means one root-cause fix resolves most of them at once rather than requiring an endless individual hunt. The primary fix is a database search-and-replace, run with a serialisation-aware tool (never a naive find-and-replace, which corrupts WordPress’s serialised data), updating every stored old URL to the new one across the whole database in a single pass — after which the images that were failing load, the internal links that led nowhere resolve, and the bulk of the breakage simply disappears.

One related case the search-and-replace does not cover is URLs whose actual path changed in the migration, where old external links and search-engine entries still expect the old path — those need 301 redirects mapping each old URL to its new counterpart, so distinguish the two: stale stored URLs pointing at the old location get search-and-replace, genuinely moved URLs get redirects, and a URL-changing migration often needs both. Find the breakages with a broken-link checker and by searching for old-location references, apply the root-cause fixes, then verify by re-running the checker and confirming the symptoms are gone and no old-domain references remain — at which point any few links still broken are genuine one-offs you can fix individually, manageable now that the systematic fix has cleared the bulk. Address the cause, not each symptom, and post-migration broken links go from an overwhelming game of whack-a-mole to a methodical fix that resolves comprehensively at the root and finishes cleanly at the edges.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Broken links after a migration almost all come from one root cause: stored URLs in your database still pointing at the old location. Fix it with a serialisation-safe search-and-replace (old URL to new) across the database — resolving the bulk at once. Add 301 redirects for any URL paths that genuinely changed. Find breakages with a link checker and by searching for old-domain references; verify the fix, then address any few remaining one-offs individually.