Migrate WordPress Without Downtime or Broken Links

If you want to migrate a WordPress site without downtime or broken links, the safest approach is to build the new site in parallel, verify every URL before switching DNS, and keep redirects in place for anything that changes. Most migration problems come from rushing the cutover, copying the wrong database values, or forgetting that images, forms, and internal links may still point to the old domain.

The good news: a clean migration is very doable. With a backup-first plan, a staging copy, and a short launch checklist, you can move hosts, change domains, or relocate to a new server without visitors seeing errors.

What usually goes wrong during a WordPress migration

When a migration fails, the symptoms are usually obvious but the cause is not. You may see 404s on old links, missing images, login problems, broken styles, or a site that briefly goes offline while DNS changes propagate. Sometimes the homepage works but deep links do not. Sometimes the site loads, but forms, search, or checkout fail because the new environment differs from the old one.

The most common causes are:

• Changing the site URL or home URL incorrectly
• Forgetting to replace old internal links in content and menus
• Missing redirects from old URLs to new ones
• Moving to a host with different PHP, database, or caching behavior
• Skipping a search-and-replace for serialized data
• DNS or SSL changes not being prepared before launch
• Media files, custom uploads, or plugin assets not copied completely

The safest migration plan: build, verify, switch, then monitor

If you only remember one thing, remember this: do not change the live site first. Create the new site in a separate location, verify it thoroughly, then switch traffic only when you are ready. That gives you a rollback path if something unexpected appears.

1) Back up everything before you touch anything

Take a full backup of files and the database on the current site. If your host offers snapshots, use them too. Keep at least one copy you can restore quickly and one copy stored off the server if possible. If the site is busy or mission-critical, this is the point where a mistake becomes expensive, so do not skip it.

2) Clone the site to staging or a temporary domain

Set up the new environment on staging, a subdomain, or a temporary URL provided by your host. Copy the WordPress files and database there. If you are changing hosts, make sure the new server matches the needed PHP version, database version, and extensions for your themes and plugins.

If the site is large, use your host’s migration tool or a carefully tested migration plugin. The exact method depends on your setup, but the goal is always the same: reproduce the live site as faithfully as possible before any public switch.

3) Search and replace the old domain correctly

If the domain is changing, every reference to the old domain needs attention. That includes post content, menu links, widgets, theme settings, page builder data, and sometimes plugin options. This is one of the most common reasons a migration looks “mostly fine” but still has broken links or missing assets.

Use a tool that understands WordPress data structures. Simple text replacement can damage serialized data and break settings. For a safe approach, follow a proper guide on fixing a broken WordPress site after changes and treat the migration as a controlled change, not a copy-paste job.

4) Update WordPress URLs only when you are sure the clone is correct

On the staging copy, confirm the WordPress Address and Site Address are correct in Settings or in configuration if they are defined there. If these values are wrong, you can end up with login loops, redirect issues, or a site that keeps pointing visitors to the old address.

Be careful if your host or a plugin overrides these values in wp-config.php. If the live site is still working, make changes on the clone first and test before altering production.

5) Test links, media, forms, and key pages before launch

Do not limit your test to the homepage. Check a sample of category pages, single posts, product pages, contact forms, login, search, checkout, and any custom templates. Click internal links from several different pages and open image files directly. This catches the kinds of broken paths that are easy to miss in a visual scan.

Pay special attention to:

• Internal links in menus and button blocks
• Image URLs and file permissions
• PDFs, downloads, and other media assets
• Form submissions and email notifications
• WooCommerce cart, checkout, and account pages if applicable

6) Prepare redirects before the DNS switch

If any paths are changing, set up 301 redirects before launch or at the moment of switch. That preserves SEO value and prevents visitors from landing on dead pages. Redirects are especially important if the migration changes structure, not just hosting.

If your old URLs are still indexed, or if a content cleanup happens during the move, document the mapping from old URLs to new ones. That prevents the classic “we launched, but Google and old bookmarks are full of 404s” problem.

For a deep dive on redirect-related 404s, it can help to compare your symptoms with Why WordPress Pages 404 but the Homepage Works.

7) Lower DNS TTL before the cutover

If you control DNS, reduce the TTL a day or two before launch so changes propagate faster. This will not eliminate propagation entirely, but it can shorten the window where some visitors reach the old server while others reach the new one.

When the time comes, update DNS carefully and keep the old hosting account active long enough to catch stragglers. That reduces downtime and gives you a safety net if something needs to be rolled back.

8) Keep the old site available during propagation

One of the best ways to avoid downtime is simply not to shut off the old environment too early. Leave the old host running until DNS has settled and you have confirmed the new site is serving real traffic correctly. If you are moving domains, the old site can also help with redirects and validation.

That overlap period matters because DNS changes are not instant for everyone. Some visitors, ISPs, and caches update faster than others.

How to avoid broken links after the move

Broken links after migration usually come from one of three places: old content URLs, hardcoded theme/plugin URLs, or missing redirect rules. Fixing them requires a little detective work.

Audit internal links

Scan posts, pages, nav menus, widgets, and custom blocks for links that still use the old domain or old paths. This is especially important if you changed from HTTP to HTTPS, moved from a temporary URL to the real domain, or changed permalink structure.

Check hardcoded references in theme files and plugins

Some themes and plugins store full URLs in templates, CSS, JavaScript, or settings. If the move reveals images missing from headers, sliders, or footers, this is often the reason. Search the codebase for the old domain and verify anything that should have been rewritten actually was.

Make sure media files came across intact

WordPress media usually lives in wp-content/uploads. If that folder is incomplete, permissions are wrong, or the migration tool missed files, image URLs may still resolve but return 404 errors. That is why testing images directly is so important.

Common migration mistakes to avoid

• Editing the live site before the clone is tested
• Using search-and-replace tools that do not handle serialized data safely
• Forgetting to update the site URL and home URL correctly
• Changing DNS before redirects and SSL are ready
• Assuming the homepage working means the rest of the site is fine
• Shutting down the old host immediately after the DNS change
• Not checking forms, checkout, and email after the move

When migration issues are more than a DIY fix

If the site is live, revenue-generating, or already showing signs of damage, stop before making more changes. A migration gone wrong can quickly turn into a chain of issues: redirect loops, lost content, broken checkout, indexation problems, or a site that looks fine to you but fails for visitors in certain regions or on certain caches.

This is a good time to bring in a senior WordPress engineer if you need the move completed fast, if the site is large or custom, or if you are unsure whether a database search-and-replace has already damaged content. Mend can handle these kinds of migrations on a backup-first workflow, with a plain-English report of what changed and a fixed-or-your-money-back guarantee. If you want a safe quote before work begins, start with free diagnosis. If the site is down or the migration has already gone sideways, use Emergency Rescue.

If you want a professional to take the cutover, redirect audit, and post-launch checks off your plate, that is exactly the kind of thing Mend is built for. You can also connect securely without sharing passwords through Mend Connect.

How to prevent downtime on future migrations

The best migrations are repeatable. Treat the process like a release, not a one-time scramble. Keep a documented checklist, lower DNS TTL before every planned move, maintain current backups, and test the site on staging whenever the theme, plugins, or server stack changes.

If migrations are part of normal operations for your team, a Care Plan can help keep updates, backups, security, and uptime monitoring under control so the next move is easier and less risky.

Bottom line

A WordPress migration without downtime is mostly about discipline: clone first, verify thoroughly, redirect properly, and switch traffic only when the new site is truly ready. Most broken-link problems are preventable if you test beyond the homepage and handle URLs with care.

If you are already in the middle of a move and something feels off, stop digging. A clean recovery is faster than untangling a half-finished migration later.