Guide
WordPress migration checklist: what to check before you move.
Most WordPress migrations go wrong in the same place: the things that were never written down. This checklist is those things, in the order to capture them.
The four things that only exist on the current site
Everything else about a WordPress move is recoverable. These four are not, because they are generated by the platform or a plugin rather than stored in your page content, and they are invisible while you look at the site.
- Your full URL list, including the pages nothing links to.
- What the SEO plugin is generating on every page.
- Redirect rules that already exist.
- Where each form actually sends its submissions.
1. Capture the URL list first
Before you change a single setting, export the sitemap and the permalink structure. This list is the inventory for the whole move, and it is the only thing that tells you whether the move is complete.
Do it first because it is cheap now and impossible later. Once the old site is offline, the pages that were never linked from anywhere are simply gone, and nobody finds out until a customer searches for something and lands on nothing.
2. What the SEO plugin is doing is usually the whole SEO story
On most WordPress sites the search metadata is not in the content - it is in the SEO plugin's own tables, generated at render time. That means a content import brings the words across and leaves the metadata behind.
Record per page, before the move:
- Custom title tags, and which pages are using the default pattern instead.
- Custom meta descriptions.
- Canonical overrides.
- Noindex and nofollow rules, and the pages they apply to.
- Structured data settings - organization, article, product, breadcrumb.
- XML sitemap configuration, and any pages deliberately excluded from it.
The noindex list is the one people forget. It is a set of pages the previous owner deliberately kept out of search results, and a rebuild that drops those rules can publish pages that were hidden on purpose.
3. Redirects and forms
Redirects: export every existing rule. Sites accumulate them over years, and they usually represent old URLs that still receive links. If the new site does not carry them, those addresses start returning 404s.
Forms: each form needs its destination recorded, not just its fields. A WordPress form plugin typically writes submissions into the site's own database. Move the site without moving that behaviour and the form keeps looking correct while going nowhere.
4. Verify the new site against the old one
With the old site still live and the new one on a staging address, compare the two instead of trusting the import. Things to compare, per page:
- Title tag, meta description, canonical URL, Open Graph tags.
- Structured data.
- Heading structure.
- Text, headings, links and images.
- Links resolving, forms submitting, the mobile menu opening.
Fix what is missing and check again, then point the domain at the new site. The old site is your reference until the moment it goes away, which is why the check belongs before the switch rather than after.
Host moves are the easy case
If you are staying on WordPress and only changing hosts, the URL list should come out identical and most of this is reassurance. Rankings problems in a same-platform move almost always trace back to URLs changing, or to the new environment serving different metadata - not to the server itself.
If you are leaving WordPress for another platform, the metadata capture above is the part that decides whether traffic holds. More detail for specific destinations: Squarespace to WordPress, Wix to WordPress, WordPress to a headless build.
Find out what this move would break.
One address, 20 seconds, no account. You get the platform you are on and every part of it a move can silently break.