How to Migrate WordPress Without Downtime or Broken Links

If you want to migrate a WordPress site without downtime, the safest approach is to build the new site in parallel, test it on a temporary URL, and only switch DNS after you have verified links, media, forms, and redirects. Most broken migrations happen because people move files and change DNS before the new environment is fully tested.

If your site is already down, or the move is tangled with missing pages, mixed content, or redirect problems, start with a backup and a clear rollback plan. If you want help from an engineer who does this all day, you can request a free diagnosis before committing to any fix.

What “no downtime” migration actually means

In practice, “no downtime” does not mean the internet never notices a change. It means visitors keep reaching a working version of your site while you prepare the new one, then the switch happens in a way that is quick enough that most users never see a broken page.

The goal is simple:

• the old site stays live until the new site is ready
• the new site is tested before it receives real traffic
• URLs, redirects, and assets are mapped correctly
• search engines and users land on the right pages after the move

The symptoms of a bad migration

If a migration went wrong, you usually see one or more of these signs:

• home page loads, but inner pages return 404 errors
• links point to the old domain or an old subdirectory
• images, CSS, or JavaScript files still load from the previous server
• login, checkout, or form submissions stop working
• the site is reachable, but WordPress admin is slow or incomplete
• HTTPS warnings or mixed-content messages appear in the browser
• Google Search Console reports crawling or indexing issues after launch

Why migrations break

Most migration problems come from one of a few causes:

• Bad search-and-replace that misses serialized data or updates the wrong URLs
• DNS changes too early, before the new server is ready
• Missing redirects when the domain, path, or permalink structure changes
• Incomplete file transfer so uploads, themes, or plugins are missing
• Cache conflicts that serve old pages or broken assets after launch
• SSL and mixed-content issues when HTTPS is not configured cleanly
• Host differences such as PHP version, memory limits, or database settings

If you are moving because the current site is already unstable, read WordPress Site Broke After an Update? Here's What Happened and How to Fix It as well, because the same kinds of compatibility issues often show up during host changes.

Safe migration checklist: easiest path first

1. Make a full backup before you touch anything

Back up both the files and the database. Store a copy somewhere separate from the server you are moving away from. If the migration fails, a clean backup is what lets you recover without turning a small issue into an outage.

2. Build the new site in a staging or temporary environment

Do not swap DNS first. Clone the site to the new host or server and use a temporary domain, staging URL, hosts-file override, or host-provided preview link so you can inspect it without affecting visitors. Exact options vary by host.

3. Confirm the server matches WordPress requirements

Check PHP version, database version, memory limits, and file permissions before launch. A site can look fine during import and then fail under real traffic if the new server is too restrictive or too different from the old one.

4. Replace URLs carefully

If the domain changes, update old URLs to the new domain in the database using a tool that understands WordPress data structures. A plain text replacement can break serialized data and widget settings. Afterward, spot-check pages, menus, widgets, and media links.

For deeper preparation around environment differences, see PHP Version Upgrades: What Breaks and How to Prepare.

5. Fix permalinks and redirect rules before launch

Open Settings > Permalinks and save the structure again after migration. This often refreshes rewrite rules. If URLs are changing, map old paths to new ones with 301 redirects so users and search engines do not hit dead ends.

Keep the redirect plan focused on the pages that actually changed. Blanket redirects to the home page may look tidy, but they create a poor user experience and can weaken SEO signals.

6. Test the important pages, not just the homepage

Check the pages that matter most: services, blog posts, contact forms, search, checkout, login, and any custom post types. The homepage can load perfectly while a hidden template, archive, or form endpoint is broken.

7. Verify media and assets

Look for missing images, broken CSS, and JavaScript errors in the browser console. These often point to stale URLs, incomplete uploads, or a cache that still points to the old server. If the site uses a CDN, confirm the CDN is pulling from the right origin.

8. Switch DNS only when the new site is proven

Lower the DNS TTL in advance if your host or DNS provider allows it. Then make the DNS change during a quiet window. Even with a well-planned migration, some visitors may see the old server while records propagate, so keep the old site available until traffic settles.

9. Clear caches in the right order

After launch, clear any page cache, server cache, CDN cache, and browser cache rules that could preserve old content. If you clear the wrong layer or only one layer, you can end up chasing ghost issues that are just cached copies.

10. Watch logs and monitor the first 24 hours

Check error logs, uptime, and key user journeys after the move. The first day often reveals issues that did not show up in staging, especially if traffic volume, bots, or payment activity differ from what you tested.

How to prevent broken links after a move

Broken links are usually preventable if you plan the URL structure before the migration begins.

• keep the same domain and path structure when possible
• create a redirect map for every URL that changes
• update internal links in content, menus, buttons, and widgets
• check image URLs in page builders and custom fields
• submit the new sitemap in Google Search Console after launch
• use 301 redirects, not temporary redirects, for permanent moves

If you changed domains and now see redirect chains or loops, you may also find the steps in Locked Out of WordPress Admin: Why It Happens and How to Fix It useful, since migrations sometimes expose cookie and URL issues at login.

Common migration mistakes to avoid

When to call a professional

Get help if the migration involves a live store, a membership site, a complex multisite setup, a domain change, or a server move you cannot easily roll back. It is also worth bringing in an engineer if you already launched and now see missing pages, login problems, redirect loops, or SEO-impacting 404s.

That is exactly the kind of work Mend handles: senior WordPress engineers fix broken sites fast, usually the same day, using a backup-first workflow and a plain-English report of what changed. If you want a flat quote before any work starts, you can get a free diagnosis or go straight to Emergency Rescue if the site is already in trouble.

If you prefer a secure handoff, you can connect the site without sharing passwords through Mend Connect.

How to make the next migration easier

A clean migration is easier when the site is maintained regularly. Keep plugins, themes, and WordPress updated, document where redirects live, and avoid custom changes that only one person understands. If you run ongoing maintenance, the next move is much less risky.

For sites that need ongoing help after the migration, a maintenance plan can reduce future surprises with updates, backups, security, and monitoring. That matters most when the site is business-critical and there is no time to debug during office hours.

Bottom line: migrate in stages, test before cutover, and treat redirects as part of the migration, not an afterthought. If you are already stuck, Mend can take over the messy part and get the site moved cleanly.