Website migration SEO checklist: leaving WordPress without losing your rankings
The short answer
You keep your Google rankings through a website move when four things hold: every old address still answers, every page keeps its title, description and other search details, every form still delivers, and nothing goes live until it has been checked against the old site, with a way to switch back. When rankings drop after a move, a missed redirect is the usual suspect: Google ties a page's history to its address, so an address that stops answering takes that history with it.
- Decide first. Some sites should stay on WordPress. Stores, member areas and sites built around one plugin feature are the usual reasons to wait.
- Record everything before anything changes. Every URL, what each page ranks for, and what each form does. This list becomes the test the new site has to pass.
- Match the new site to the old one, page by page. Same addresses or a one-to-one redirect, same search details, working forms, all checked on a private preview.
- Launch in a way you can undo. Keep the old site ready, switch the domain last, and know the rollback before you need it.
- Watch for 90 days, then keep checking. Google says rankings can move for a few weeks or more. Redirects stay for at least a year.
You do not have to run any of this yourself. You do have to know what to ask for, and what proof looks like. That is what the tables below are for.
1. Decide whether your site should move at all
Move when WordPress costs you time, money or worry and the site is mostly pages and posts. Stay when the site's main job runs on WordPress itself: a store, a members-only area, an online course, or a directory or booking system built on one plugin. Moving those means rebuilding the feature, not just moving the site.
Use this as a quick filter:
Your site | Good candidate to move? | Why |
|---|---|---|
Brochure or marketing site, 5 to 250 pages, a contact form | Yes | Mostly content. The risks are URLs, search details and forms, and all three can be checked |
A blog or content site that earns money | Yes, carefully | More URLs to keep, but the same checks apply |
A WooCommerce or other online store | Not yet | Checkout, stock and payments are an application, not pages |
A members area, course or anything people log into | Not yet | Logins and private content need their own rebuild |
A directory, complex booking system or page builder logic at the core | Usually not | The plugin is the site |
Any site, together with a full redesign | Split them | Change the platform first and the design later, so you can tell which change moved your rankings. Keeping your current look or redesigning is your call; both are listed under pricing |
If the site works, costs you little and nobody touches it, staying is a fine answer. The rest of this checklist is for the owners who already know the current setup is not working.
2. Before anything changes: record every page and what it earns
Before anyone builds anything, capture the old site as it is today: every public URL, the title and description on each page, which pages bring in search traffic and leads, and every form with where its messages go. This snapshot is the contract. Later, the new site is checked against it line by line.
Check | What has to be true | Proof to ask for |
|---|---|---|
Full URL list | Every public address, from a crawl of the live site plus your sitemap and Google Search Console, not just the menu | A spreadsheet or file with one row per URL and its status |
Search details per page | Title, meta description, canonical address and structured data recorded for each URL | The same file, with those columns filled |
Pages that matter | The pages that bring search visits and leads are marked, so they get checked first | A short list pulled from Search Console, with clicks for the last 3 to 12 months |
Forms | Every form, its fields, and the email address or system each one sends to | A list of form pages and a test message received from each |
Backups | A full backup of the database and the uploads folder, stored somewhere other than the server | Where it is, and the date |
Hidden pages | Drafts, private pages and scheduled posts are listed separately, so none of them goes public by accident | A count by status |
One WordPress detail catches people out here. The standard WordPress export file is not a backup. EmDash's own migration guide says a WordPress export "points to media on the WordPress origin; it does not contain the attachment bytes" (EmDash docs). Your images live in the uploads folder, so back that up too.
3. On the new site: match every page, checked against the old one
Every old URL either exists at the same address on the new site or redirects to its closest match with a permanent (301) redirect, every page carries the same search details, and every form delivers a real test message. All of this is checked on a private preview, while the live site stays untouched.
Check | What has to be true | Proof to ask for |
|---|---|---|
Every URL answers | Each address on the old list returns the page, or a single 301 to the closest matching page. Never a blanket redirect to the home page | A report with one line per old URL and its result |
Search details carried over | Titles, descriptions, canonical addresses and structured data match the old site, or are better on purpose | The same report, comparing old against new |
Forms deliver | A test submission from every form arrives where it should | The test messages, with times |
Content complete | Text, images and embedded items show up on every page. Nothing renders empty | Side-by-side screenshots of the pages that matter |
Hidden stays hidden | Drafts and private pages are not reachable by a logged-out visitor | A check from a logged-out browser |
Preview not indexed | The preview address carries `noindex`, so Google never finds the copy | The preview's response headers |
These are the checks a WordPress move most often skips, because the import tools say so themselves. EmDash's importer does not move redirects; its guide tells you to "crawl old public URLs and prepare redirects for every changed route" (EmDash docs). It does not move forms either – its theme-porting guide says to keep WordPress available until "forms, and plugin-dependent pages have been verified" (EmDash docs) – so form pages need their own check. A few more traps from the same documentation:
- SEO plugin data needs a template that prints it. Yoast and Rank Math titles and descriptions can be copied across, but they arrive as "regular content fields, separate from the SEO panel, so the page template has to render them" (EmDash docs). If nobody checks the live
<title>on each page, they can be imported and still be missing. - Private and scheduled posts change status. Anything that is not published in WordPress, including private and scheduled posts, arrives as a draft (EmDash docs).
- Some blocks arrive empty. Server-rendered blocks such as Latest Posts "show no content on the site" after import (EmDash docs).
- Page builders need a rebuild. Builder shortcodes and layouts "usually require a deliberate" conversion or a new template (EmDash docs).
None of this is a reason to avoid moving. It is the reason each page gets checked rather than spot-checked.
4. At launch: switch in a way you can undo
A safe launch changes one thing, where your domain points, and only after the preview has passed every check above. The old site stays running and ready, the redirects go live at the same moment, and everyone knows the exact steps to switch back. If anything looks wrong, you point the domain back and nothing is lost.
Check | What has to be true | Proof to ask for |
|---|---|---|
Preview approved | You have seen the preview and the check report, and said yes | Your written approval |
Old site kept | The WordPress site stays intact and reachable for rollback | Where it is and how long it stays |
Named rollback | The steps to switch back are written down before launch, with who does them | The rollback steps, in writing |
Domain switch last | DNS (where the domain points) changes only after everything else is ready | The planned time |
Redirects live at launch | The redirect list works on the real domain, not just the preview | The URL report re-run on the live domain |
Indexing open | The `noindex` from the preview is gone on the live site, and the sitemap is submitted | A live check and the Search Console submission |
Analytics working | Your analytics and Search Console still record visits | A test visit showing up |
EmDash's guide says the same about keeping the old site: "Keep the backup and WordPress deployment until the new site has run successfully in production and rollback is no longer required" (EmDash docs). A move with no way back is a bet.
5. After launch: watch for 90 days, then keep checking
For the first weeks, re-check every old URL, watch Search Console for errors and pages that drop out, and fix any 404 the moment it appears. Expect some movement: Google says that "for medium-sized websites, it can take a few weeks or more" to show the new URLs, and to keep redirects "generally at least 1 year" (Google Search Central).
When | Check |
|---|---|
Launch day | Re-run the URL and forms checks on the live domain. Submit the sitemap |
Daily, first 2 weeks | Search Console coverage and 404s. Fix each missing URL with a redirect |
Weekly, to day 90 | Clicks and impressions for the pages that matter, against the baseline from step 2 |
Monthly, after that | URLs still answering, redirects still resolving, forms still delivering, search details still present |
For at least a year | Keep every redirect in place |
The monthly line is the one most moves drop. Sites change after launch: pages get edited, the platform updates, a setting gets switched. A redirect that worked in March can break in June, and nobody notices until leads go quiet. EmDash keeps a log of 404s, up to 10,000 paths, so missing pages can be found and redirected (EmDash docs). Someone still has to read it.
How we run this checklist
This is what we check on every move from WordPress to EmDash, the open-source CMS from Cloudflare built on Astro. A free, read-only check of your public pages tells you whether your site is a good fit and gives you the exact price before you ask. If it is a fit, we build a private preview, check every URL, redirect, form and search detail against your live site, and only switch the domain once you have approved it, with the rollback written down. With Looked after hosting, which we recommend, we host the site after launch and email you a monthly certificate listing the checks we ran and what changed. Prefer to host it yourself? Download your finished site instead and run it on your own Cloudflare account.
If you would rather see where your own site stands first, check your site for free.
Frequently asked questions
Will I lose my Google rankings if I move my WordPress site?
Not if every old URL still answers and every page keeps its search details. Rankings attach to addresses and content, not to WordPress. Google does say rankings can fluctuate for a few weeks or more while it recrawls, so judge the move after 90 days, against a baseline you recorded before launch.
What is a 301 redirect, and why does it matter?
A 301 is a permanent redirect from an old address to a new one. It tells Google the page moved and passes its history to the new URL. Without one, the old address returns "page not found", and the ranking it earned is gone. Google advises keeping redirects for at least a year.
Can I keep the same URLs when I leave WordPress?
Usually, yes. Most page and post addresses can stay exactly as they are, which is the safest option. Where an address has to change, it gets a one-to-one 301 redirect to its closest new page. Check the full URL list afterward, not just the menu.
What happens to my Yoast or Rank Math titles and descriptions?
They can be carried across, but they have to show up on the live pages. On EmDash, imported Yoast and Rank Math values land in content fields that the page template must print. Ask for a page-by-page comparison of the live title and description against the old site.
Will my contact form still work after the move?
Only if it is rebuilt and tested. WordPress form plugins do not move with the content, so each form needs rebuilding on the new site and a real test message sent from it before launch. Ask to see the test messages arrive.
How long should I keep my old WordPress site after launch?
Keep it intact until the new site has run in production without problems and you no longer need a way back. EmDash's own guide says the same. Keep the full backup longer, and keep the redirects for at least a year.