Migrate WordPress without losing SEO: a practical checklist.

Why a migration can cost you traffic

Google ranks URLs, not websites. When a page moves without warning, the search engine treats it as gone. Links pointing to it end in a 404 error, and the history it had built up is lost.

Most post-migration traffic drops come down to three mistakes: URLs left without redirects, SEO tags that were not carried over, and an indexing block that was never removed. The good news is that a simple method prevents all three. Whether you are leaving WordPress for Plumixia or for any other CMS, the checklist is the same.

1. Build a complete inventory of your URLs

You cannot redirect a page you do not know about. Combine several sources, because none of them is complete on its own:

• The WordPress XML sitemap (often /sitemap.xml or /wp-sitemap.xml).
• A site crawl with a crawling tool, which follows internal links the way a search bot does.
• Google Search Console: the Performance report lists pages that get clicks, including ones that have dropped out of your menus.
• Pages with backlinks, meaning links from other websites. Search Console lists them in its Links report.

Remember category and tag archives, author pages, PDF files and any image URLs that rank well.

2. Draw up a redirect map

In a spreadsheet, list each old URL in one column and its new URL in the next. This is the core document of the whole project. Every row needs a destination: the equivalent page, or failing that, the closest page on the same topic.

The best redirect is the one you never need. Keep your existing URLs wherever you can. If the new CMS lets you set each page's address freely, reuse the current paths, down to whether or not they end with a trailing slash.

3. Set up 301 redirects, one by one

For every URL that changes, create a 301 redirect. This status code means the page has moved permanently, so Google passes the old page's signals on to the new one. A 302 redirect is temporary and does not send that clear message.

• Redirect page to page, to the exact equivalent, not to the home page. Google often treats bulk redirects to the home page as "soft 404" errors.
• Avoid redirect chains (A to B, then B to C). Point straight at the final destination, and update any old redirects inherited from WordPress.
• Return a 404 or 410 for pages that are genuinely gone and have no equivalent, rather than redirecting them somewhere random.

Depending on your platform, redirects live in the server configuration or in the CMS itself. In Plumixia, for instance, they are created as redirect pages, so you do not depend on a server file. Our SEO features page covers the other relevant settings.

4. Carry over each page's SEO elements

Copying the content is not enough. For each page, keep these exactly as they were:

• the title tag and meta description;
• the H1 heading and the structure of subheadings;
• structured data (the JSON-LD code describing an article, an FAQ or your organisation);
• image alt text;
• the canonical tag and, on a multilingual site, the hreflang tags.

On a large site, this is slow work. An AI agent connected to the CMS can speed it up: with the Plumixia MCP server, it recreates pages as drafts, which you review before anything goes live.

5. Move your media and update internal links

Transfer images and documents, keeping descriptive file names where possible. If their URLs change, add them to your redirect map, especially images that bring in traffic.

Then update internal links so they point straight to the new URLs. A redirect will catch an outdated link, but a direct link is faster for visitors and clearer for search bots.

6. Keep staging out of the index

Build the new site on a staging address protected by a noindex tag, a password, or both. That way, Google does not index a duplicate copy of your site.

The classic trap is forgetting to remove that noindex on launch day. Put it at the top of your go-live list.

7. Compare old and new, page by page

Before launch, work through your redirect map. For each URL, check that the redirect returns a 301 to the right page, then compare the title, description, H1, content and structured data. Crawl the staging site to catch broken links.

8. Switch the DNS

Pick a quiet moment. A few days beforehand, lower the DNS cache duration (the TTL) so the change spreads quickly. On the day, point the domain at the new hosting, check the HTTPS certificate, remove the noindex and test a sample of old URLs.

9. After launch: monitor closely

1. Submit the new sitemap in Search Console.
2. Watch the page indexing report: 404 errors, excluded pages and failing redirects.
3. Fix every 404 that matches a useful old URL by adding the missing redirect.
4. Track traffic and rankings for several weeks. Some early fluctuation is normal while Google recrawls the site.

Keep your redirects in place for the long term: external links will keep pointing at the old addresses for years.

In short

A successful migration rests on a full inventory, a rigorous redirect map and careful checks before and after launch. If you are thinking of leaving WordPress, our WordPress alternative page explains how Plumixia differs. And if you would like help planning your move, get in touch.

Frequently asked questions