🔧 Flat-price WordPress fixes from $69 — start with a free diagnosis, no card. Get a free diagnosis →

Maintenance

Migrate WordPress Without Broken Links or SEO Loss

Nov 14, 2026 · 9 min read · By the Mend engineering team

If you want to move a WordPress site without breaking links or losing search traffic, the safest approach is to build the new site in parallel, verify every URL before launch, and switch DNS only after you have tested redirects, media, and forms. Most migration problems come from changing domains, paths, or database values too early.

The good news: you can usually avoid downtime if you back up first, keep the old site live until the new one is verified, and use a staging copy or temporary URL for testing. The hard part is not copying files — it is making sure the new environment behaves exactly like the old one.

What usually goes wrong during a WordPress migration

People think a migration fails when the site is unavailable. In practice, the more common failures are subtle:

  • Old links still point to the previous domain or directory.
  • Images and PDFs load from the wrong path, or not at all.
  • Menus, widgets, or forms break because serialized data was not updated correctly.
  • Redirects are missing, so search engines and visitors hit 404s.
  • HTTPS, canonical URLs, or mixed content issues appear after launch.
  • Plugins or themes behave differently on the new host because of PHP, caching, or server rules.

If you are seeing broken pages after a move, start with our WordPress broke after update guide. The symptoms are different, but the debugging steps overlap: isolate what changed, test one layer at a time, and keep a backup ready to restore.

The safest migration pattern: build first, switch later

The cleanest migration is a two-step process: prepare the destination site in a separate location, then point traffic to it only after you confirm it works. That can mean a staging subdomain, a temporary domain, a host-provided preview URL, or a local/private environment.

  1. Make a full backup of the current site. Include the database, wp-content, uploads, and any custom files outside the standard WordPress folders. If your backups have not been tested recently, read The Backup Test Most WordPress Sites Still Skip.
  2. Clone the site to the new server or host. Use a reliable migration tool or manual copy, depending on your setup. The goal is an exact copy, not a partial one.
  3. Test the clone before changing DNS. Check the homepage, key landing pages, post permalinks, forms, checkout, login, and image loading.
  4. Fix any domain or path references inside the copy. This is where many migrations go wrong, especially when moving between domains, subfolders, or HTTPS states.
  5. Lower DNS TTL ahead of time if possible. This can shorten the propagation window, though actual timing still depends on your DNS provider and caches.
  6. Switch traffic only after verification. Once the new site is ready, update DNS or hosting records and keep the old environment available briefly as a fallback.

Step 1: back up the old site before touching anything

Do not migrate first and ask questions later. A fresh backup is your exit plan if the move goes sideways.

  • Back up the database.
  • Back up all WordPress files.
  • Download a copy off the server if possible.
  • Confirm that you can restore that backup somewhere safe.

If your site is mission-critical, this is the moment to slow down. A migration can be technically simple and still expensive to recover from if the backup is missing, incomplete, or unusable.

Step 2: copy the site correctly, not just partially

A WordPress site is more than posts and themes. Depending on your setup, you may also have custom uploads, mu-plugins, cache folders, vendor files, or environment-specific configuration. Make sure you know what your site actually uses before you move it.

At minimum, verify these items:

  • Database — posts, pages, users, options, plugin settings, and serialized data.
  • wp-content — themes, plugins, uploads, and any custom code.
  • Custom files — cron scripts, security rules, or app integrations stored outside WordPress.
  • Server config — rewrite rules, PHP version, memory limits, caching, and SSL settings.

If you are changing hosts, ask whether they provide a migration tool or a cloning workflow. Even then, review the result yourself. Automated copy jobs often miss edge cases.

Step 3: replace URLs safely

Broken links after a migration usually come from incomplete search-and-replace work. WordPress stores some values in a format that can break if you replace text with a plain database query that ignores serialization.

Use a tool or process that understands WordPress data structures. Many migration plugins and WP-CLI-based workflows can do this safely. If you are doing it manually, be careful with:

  • Site URL and home URL values.
  • Internal links in posts and pages.
  • Image and attachment URLs.
  • Widget content and builder data.
  • Hard-coded links inside theme files or custom snippets.

After replacement, scan the site for the old domain. Check menus, footer links, image paths, and embedded files such as PDFs. If the old domain still appears, search engines and users will eventually find it.

Step 4: preserve SEO with redirects, canonicals, and consistent URLs

If the migration includes a domain change, URL restructuring, or HTTP-to-HTTPS move, set up redirects before launch. A 301 redirect tells browsers and search engines where the content moved permanently.

Focus on these rules:

  • Redirect every old URL to its closest matching new URL.
  • Avoid redirecting everything to the homepage unless there is no better match.
  • Keep one preferred version of the site: www or non-www, and http or https.
  • Make sure canonical tags match the final public URLs.

For large moves, test your top pages first: home, about, service pages, product pages, and high-traffic blog posts. You can catch a lot of damage before Google does.

Step 5: test the new site like a visitor and like a search engine

Before you change DNS, open the new site in a browser and walk it like a customer would. Then test it more technically.

  1. Click through main navigation and footer links.
  2. Open several posts and pages with different permalink structures.
  3. Load a few images in full size, not just thumbnails.
  4. Submit forms and confirm delivery.
  5. Log in, log out, and check dashboard access.
  6. Run a crawl or scan for 404s, mixed content, and redirect loops.

Also test on mobile and on at least one private/incognito browser window. Caching can hide problems from you that visitors will still see.

Step 6: launch with a rollback plan

When everything checks out, update DNS or switch the site’s traffic routing. Then keep the old site available long enough to catch surprises from DNS propagation, caches, or lingering sessions.

Your rollback plan should be simple:

  • Know how to point traffic back to the old site.
  • Keep the old database and files intact until the new site is stable.
  • Document what changed so you can reverse it quickly if needed.

This is especially important for stores, membership sites, and lead-generation sites where even a short outage can cost real money.

Common migration mistakes to avoid

Mistake What it causes Better approach
Copying files without the database Missing content, broken settings, login issues Move files and database together
Using a raw database search-and-replace Broken serialized data and corrupted settings Use a WordPress-aware replacement tool
Changing DNS before testing Users see a broken or incomplete site Verify the clone first, then switch
Skipping redirects 404s and SEO loss Map old URLs to new ones
Not checking plugins on the new host Forms, caches, or media fail Test plugin behavior before launch

How to prevent broken links after the move

Broken links are usually preventable. The easiest way to avoid them is to keep the URL structure unchanged unless you have a specific reason to change it.

  • Keep the same permalink settings if possible.
  • Use relative care when editing internal links by hand.
  • Run a link check after launch.
  • Set redirects for deleted or renamed pages.
  • Update hard-coded links in content, widgets, and theme files.

If your migration also involves redesign or content cleanup, resist the urge to combine too many changes at once. The more variables you introduce, the harder it is to find the cause of a broken link or SEO drop.

When to call a professional

Hire help if the site is large, live, revenue-generating, or already fragile. You should also get support if the migration includes domain changes, a multisite setup, WooCommerce, membership access, custom code, or a host move that involves email, DNS, and SSL at the same time.

If you do not have a tested rollback plan, that is another sign to pause. A professional migration should be boring: backup first, verify everything, switch traffic, and document what changed. If you want that done safely and fast, you can start with a free diagnosis at Mend or go straight to an emergency rescue at /start/emergency if the site is already broken.

Mend’s senior engineers handle WordPress fixes with a backup-first workflow, plain-English reporting, and flat pricing. If the migration is already going off the rails, the fastest path is often to let someone experienced stabilize the site and finish the move without guessing.

Bottom line

A WordPress migration does not have to mean downtime or broken links. The safest pattern is simple: back up first, clone the site, verify URLs and behavior before launch, switch traffic only when the new copy is proven, and keep a rollback plan ready. That approach protects your content, SEO, and sanity.

If you want a broader checklist for avoiding surprises, also see Safe WordPress Updates Without Breaking Your Site and How to Migrate WordPress Without Downtime or Broken Links.


Related guides: How to Fix the WordPress 500 Internal Server Error and Locked Out of WordPress Admin: Why It Happens and How to Fix It

Frequently asked questions

Can I migrate WordPress without any downtime at all?

Usually, yes, if you clone the site first, verify it on a temporary URL, and switch DNS only after testing. Small DNS propagation delays can still happen, so plan for a short overlap period.

Why do links break after moving WordPress to a new domain?

The most common cause is old URLs stored in the database or hard-coded into content, widgets, or theme files. A WordPress-aware search-and-replace plus redirects usually fixes it.

Do I need redirects if the page slugs stay the same?

If the domain changes, yes. Even with the same slugs, old URLs should redirect to the new location so visitors and search engines land on the right site.

What should I test before I point the domain to the new host?

Test pages, posts, media, forms, login, caching, SSL, and any store or membership features. Also check for mixed content, 404s, and old-domain references.