How to migrate your WordPress site without losing SEO rankings

Migrating a WordPress site is like moving house: you can do it in a hurry and lose things along the way, or you can do it with a plan and lose nothing. And here "lose nothing" has a very specific name: SEO rankings.

I've seen companies lose 70% of their traffic in a poorly planned migration and take months to recover it. I've also seen perfect migrations where traffic doesn't even blink. The difference isn't luck: it's preparation. In this article I explain the method we use so a WordPress migration doesn't cost you a single visit.

Before migrating: inventory, redirects and backup

The golden rule: everything starts with an inventory

Before touching anything, you have to know what you have. A migration isn't just moving files: it's moving your entire digital presence. The first step is a complete inventory of the current site:

• All the URLs on the site, especially the ones with traffic. Google Search Console gives them to you with their impressions and clicks.
• The redirects that already exist, so you don't lose them in the process.
• The content: pages, posts, images, downloadable files. Every single thing counts.
• The features: forms, stores, CRM integrations, newsletters. If something isn't migrated, it breaks silently.

This inventory is the treasure map: without it, migrating is rolling the dice. And it's the step that gets skipped the most.

The invisible key: keep the URLs or redirect everything

Here's the heart of SEO in a migration. Google keeps your current site's URLs in its index. If a URL changes or disappears on the new site, Google no longer knows what's there and your page falls out of the index.

There are two possible paths:

• Keep the same URLs: the ideal option. If you can preserve the URL structure, there's nothing to redirect and the risk is minimal.
• 301 redirects: if the URLs change (for example, when restructuring the site), every old URL must have a 301 redirect to its new equivalent. The 301 tells Google "this page has moved here" and transfers authority and rankings.

The fatal mistake is not redirecting, or redirecting everything to the home page. That's the equivalent of moving house and not leaving your new address with anyone: your visitors (and your SEO) get lost.

The redirects checklist

• One 301 redirect for each URL that changes. Never chained.
• No loops: the new URL must not redirect to the old one.
• Checked with a crawling tool after launch.
• Kept for at least 6-12 months, and better yet permanently.

The backup: your safety net

Before starting any migration, you need a complete backup and, above all, a tested one. It sounds obvious, but the number of migrations that start without a working backup is surprising.

The backup must include:

• The site's complete files.
• The database, where all the content lives.
• The access: user accounts, API keys, credentials for external services.
• The hosting configuration settings.

With a tested backup in a safe place, any migration error is a setback, not a catastrophe.

The migration step by step: test environment and cutover

Migrate to a test environment first

Never migrate directly in production. The correct methodology is to migrate first to a test environment (a copy of the site on a temporary domain or subdomain) and do all the checks there. Only when everything works is the real switch made.

What to check in the test environment?

• That all pages load and there are no errors.
• That forms send correctly.
• That images and files aren't broken.
• That redirects work.
• That performance is as expected.

Migrating directly "like crazy" turns every error into an urgent problem with clients in the middle. Migrating with a test turns every error into a task on a list.

The transition: cutover time

Change day arrives and it has to be done with method. Our protocol includes:

• Choosing a low-traffic moment (weekend or night) to minimize impact.
• Updating the DNS if the domain changes servers, keeping in mind that it takes time to propagate.
• Freezing changes on the old site right before the cutover so you don't lose content.
• Verifying on the spot: home, key pages, forms, payment if it's ecommerce.

And, above all, don't shut down the old site abruptly: it's your plan B if something goes wrong.

After launch: watch, fix and monitor

Watch and fix in the first weeks

The migration doesn't end when the new site is in production. A monitoring phase of at least two or three weeks begins:

• Recrawl: ask Google to re-crawl your site with Search Console.
• Monitor the 404s: check for broken links or failed redirects.
• Compare traffic: week over week, and act if there are drops.
• Review indexing: make sure the new pages get indexed and the old ones redirect.

A well-done migration shouldn't be noticeable in traffic. If you notice a drop, it almost always has a concrete cause that can be fixed in time.

The role of post-migration monitoring

We've talked about watching the first weeks, but it's worth detailing exactly what to watch and why. Beyond 404s and indexing, full monitoring adds three fronts:

• Week-by-week traffic: compare with the previous 3-month history. An isolated drop can be normal; a sustained drop has a cause to find.
• Performance: measure speed before and after; the migration should improve it, not make it worse.
• Conversions: if you have forms or sales, watch that they haven't broken silently.

Monitoring isn't optional: it's the phase that turns a risky migration into a controlled one. Those who skip it find out about the problems when they've already done damage.

The migration mistakes that cost the most

After seeing many migrations (good and bad), these are the mistakes that cost companies the most:

• Not doing a URL inventory: migrating without knowing what URLs exist is migrating blind. Then the 404s appear in a chain and traffic plummets.
• Redirecting everything to the home page: Google interprets "everything goes to the main page" as "there's no content", and discards practically everything.
• Migrating directly in production: without a test environment, every error is a fire with clients in the middle.
• Forgetting the integrations: the form that sent to your CRM, the newsletter, the payment: if something isn't migrated, it breaks silently and you take weeks to find out.
• Not communicating the change: users with saved links, old search results, other sites that link to yours: all of that needs the redirects.

If you avoid these five mistakes, you've already avoided 90% of the typical catastrophes. There's no magic: there's method.

Beyond the code: content, access and dependencies

Migrate content, not just files

There's a subtle difference between "moving files" and "migrating content", and that difference shows in the result. Moving files is technical; migrating content is curating what you have.

During the migration, this is the ideal moment to:

• Review and update content: obsolete pages, outdated texts, old data. It's easier to clean before than after.
• Remove what's leftover: orphan pages, duplicate content, junk files. Less content, more quality.
• Improve the structure: reorganize sections, improve internal links, bring metadata up to date.

Migrating is a unique opportunity to bring your site up to date. Those who only "move" also inherit the problems. Those who migrate and clean up come out with a better site.

The data you can't forget: access and dependencies

There's a category of data that gets forgotten almost always and paralyzes the new site: access and external dependencies. Before migrating, make a list of:

• Integrations: CRM, newsletter, analytics, payment gateways, shipping services. Each has its API keys that need to be regenerated or configured in the new environment.
• Domain and DNS: who manages the domain, how the DNS is updated and where the email lives. An error here leaves the new site without a name and the email without service.
• Email: if the email lives on the old hosting, you have to make sure it isn't lost in the change.
• Accounts and credentials: a centralized document with all the access, so you don't depend on one person who "has it on a Post-it".

Without this list, the site can be perfectly migrated and still "dead" because the email or the CRM don't work. The migration is a complete system, not just the HTML.

Is it worth migrating? And how we do it at TakeYourDesign

Is it worth migrating? The prior question

Before migrating, it's worth asking whether you really need it. Sometimes a migration is necessary (hosting change, domain change, platform change). Other times what's needed is an optimization, not a migration. If your WordPress site works well and the problem is speed, maybe the solution is a tune-up and not a migration. We tell you about it in our article on speeding up WordPress.

Migrating with a clear goal (more performance, more flexibility, less cost) makes sense. Migrating just "for a change" rarely does.

How we do it at TakeYourDesign

When we're commissioned a migration, the process is always the same and no step is skipped: inventory, redirect plan, tested backup, test environment, controlled cutover and post-launch monitoring. The client finds out about the migration because the new site is faster, not because they lose traffic.

If you're considering migrating your WordPress site (or from any other platform), let's talk. You can see what we do in our cloud and migration services or write to us directly through contact. We'll give you an honest opinion on whether the migration is worth it and how to do it without scares.