Frequently Asked Questions

“Test connection” fails with “Not Found”

Your site’s REST API isn’t reachable at the pretty URL WPMove uses (/wp-json/...). This usually means the site’s permalink rewrite rules aren’t active — common right after installing a plugin, changing themes, or on a fresh install. Fix: go to Settings → Permalinks on that site and click Save Changes (even without changing anything), then test the connection again.

“The target user does not have sufficient permissions”

The target account needs the upload_files and edit_posts capabilities — in practice an Author, Editor or Administrator. A Subscriber or Contributor account won’t work. With the free Connector installed on a site, use an Administrator there: the plugin only accepts writes from an admin.

The application password is rejected or seems ignored

“Sorry, you are not logged in” — or “You are not currently logged in” — means WordPress authenticated nobody, not that the password is wrong. When it happens, the connection test tells you which of three cases it is, whenever that can be known. Check in this order:

• The password still exists. On that site, Users → Profile → Application Passwords: if it is no longer listed (revoked, or the user was recreated), create a new one. Copy it in full — spaces are cosmetic, keep or remove them — and use the WordPress username, not the email. A saved profile keeps the password it was given: after creating a new one, type it in again.
• Application passwords are turned on. Some security plugins switch them off (look for “application passwords” in their settings), and WordPress refuses them on a site not served over HTTPS — enter the site’s address with https://.
• The host passes the credentials on. On some Apache setups (CGI / FastCGI) the Authorization header is removed before WordPress sees it, and any password then looks like no password at all. Make sure the site’s .htaccess still holds the line WordPress adds for this, just after RewriteEngine On:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

If the site sits behind another login prompt (HTTP Basic Auth or “Directory Privacy” on some hosts) or a firewall that blocks the REST API, WPMove is rejected before WordPress even sees the request: exempt the /wp-json/ path from that protection. Some security plugins (Solid Security, for one) answer “not logged in” to any wrong password, which makes a revoked password and a lost header look alike — that is why the first point comes first.

SSL / certificate errors — or my site is local

wpmove.app must reach both sites over HTTPS with a valid, trusted certificate. A local site (.local, .test, a self-signed certificate…) cannot be reached from the internet, whatever the credentials — WPMove never disables certificate checks. Two ways out: a staging domain with a real certificate (Let’s Encrypt is fine), or the Connector Premium installed on the local site, which imports or exports from the inside.

“The request was blocked by a security firewall”

Some hosts place a firewall in front of WordPress that blocks repeated automated requests before WordPress sees them. Your credentials are not the problem — the site never received the request. Ask your host to allow requests from wpmove.app, or wait a few minutes and try again. Smaller runs (fewer items per migration) usually stay under the threshold.

What does “Analyze before migrating” check?

It reads both sites without writing anything and tells you how many items of each type would move, what your plan allows (items per migration, media quota), whether sync mode applies and since when, and what needs your attention: reusable blocks, comments, post types or taxonomies hidden from the REST API, and — when you ticked them — every site setting that would change on the target, before and after. With the free Connector installed, it goes further — page builders in use, addresses already taken on the target. Whatever it could not check is listed as such. It is available on every plan and never guesses a duration.

Custom post types (CPT) don’t appear in the content step

The list is read live from your source once its connection test succeeds. A missing type was almost certainly registered without REST API support (show_in_rest) by the plugin or theme that declares it — WPMove only sees types exposed by the REST API of the site it reads (the source for wpmove.app or an import from another site, the target for an export to another site). Fix: install the free WPMove Migration Connector on that site and tick the type in its REST API visibility section — type by type, with one caveat shown there: an exposed type becomes readable through that site’s public REST API. Then test the connection again. If no plugin can be installed, the must-use plugin from the next entry works the same way with register_post_type_args.

A custom taxonomy never migrates

Same cause as above: the taxonomy was registered without show_in_rest — which can happen even when its post type migrates fine, since the two are declared separately. With the Connector installed on the affected site, tick the taxonomy in its REST API visibility section. Otherwise, ask whoever manages that site to drop this file into wp-content/mu-plugins/ (create the folder if needed — no activation required):

<?php
/**
 * Plugin Name: Force show_in_rest on a custom taxonomy
 * Description: Exposes a specific taxonomy through the REST API so tools
 *              like WPMove can read its terms. Replace 'your_taxonomy_slug'
 *              with the actual taxonomy name.
 */
add_filter( 'register_taxonomy_args', function ( $args, $taxonomy ) {
	if ( 'your_taxonomy_slug' === $taxonomy ) {
		$args['show_in_rest'] = true;
	}
	return $args;
}, 10, 2 );

Media isn’t migrating even though “Import media” is ticked

On the Free plan, media is never migrated — it is a plan limit, not a bug. Media migration comes with the Starter, Pro and Unlimited plans, each with a yearly quota you can top up with credit packs (see Pricing).

“Please wait N days before your next migration”

That is the Free plan’s cooldown between two migrations. Paid plans have no cooldown and unlimited migrations.

A migration seems stuck — no progress for a while

Migrations run through a queue, so pauses of a few minutes between two pages are normal. If one stops progressing for more than 30 minutes, you automatically receive an email (at most one per hour). On the migration screen, Restart resumes where it stopped, Reset clears it to start over.

Are my site settings migrated — homepage, logo, title, menus, widgets?

On request. In the Options step, “Homepage and identity” sets the target’s homepage, posts page, site icon and logo to the pages and files the migration brought over; “General settings” adds the title, tagline, language, timezone and date formats. Both are off by default, because they change the target itself: right when you copy a site to a fresh one, wrong when you merge content into a site that already has its own. The analysis shows each change before you start, and a page or file that is not part of the migration is skipped and named — never pointed at by mistake. Never copied: the site address, the admin email, the active theme and plugins, and plugin settings (they often hold licence keys). Menus follow on request too (“Menus”, same step): navigation and classic menus, links pointed at the migrated pages. The target’s header shows them only when it has no menu of its own; otherwise pick one in Appearance → Editor → Navigation. Widgets follow on request as well (“Widgets”, same step), into the widget areas the target’s theme shares with the source and that are still empty there; a widget whose plugin keeps it closed to the REST API is copied by the WPMove Connector when the target has it (free plugin, 2.1.24+), and a widget whose plugin is missing on the target is named in the analysis and the log.

Migrating to or from a multisite network

Each site of a network is its own WordPress for WPMove: enter the full address of the one you mean — https://example.com/shop/ for a subsite, not the network’s root. A subsite and its network’s root are two different sites, so migrating between them is allowed. Three things are specific to networks. Account: on a network, only a super admin may publish unfiltered HTML — written by a site administrator, contents lose their iframes, scripts and on… attributes; WPMove flags every content it happens to, and a super admin’s application password avoids it. File size: the network caps every upload (Network Admin → Settings → Max upload file size, 1,500 KB by default) — raise it before migrating large media; the log names this setting when a file is refused. Root as source: links and files of the other sites of the network are left as they are, never redirected to the target; with the free Connector on the root, every subsite is recognised, without it only their media files are.

Migrating a WooCommerce shop

Products move with everything WooCommerce knows about them: type (simple, variable, grouped, external, downloadable), prices and sales, SKU, stock, featured and catalogue visibility, attributes — global ones are created on the target with their values — variations with their own prices, stock and images, gallery, downloadable files, upsells and cross-sells, category images, and reviews with their rating. WooCommerce itself writes them, so its price filters and sorting work straight away. Needed: WooCommerce active on both sites, and an administrator’s application password. Reviews follow “Import comments”; with the free Connector on the target they are added without emailing the product author. Running it again updates products and variations instead of duplicating them. File export / import carries all of it except the files themselves: images and downloadable files are used when the target’s media library already holds them, and the import log names any that are missing. Not migrated: orders, customers, coupons and the shop’s settings — personal and payment data stay where they are. The analysis report lists the products, variable and grouped ones, and reviews before you start.

Can I run migrations from the command line?

Yes, with WP-CLI on the site where the Connector is installed: wp wpmove export and import are free; pull, push and saved profiles come with Premium — sync mode included, for a cron job or a deployment pipeline. Run them as an administrator (--user=), and never put the application password in the command. All commands and examples.

Can I save several pairs of sites — one per client or per project?

Yes. In the Sites step, the Profile bar saves the two sites, their credentials and every option as a named profile; My migrations in the sidebar lists them with their last migration and the action that fits — sync, retry what failed, or analyze a pair never run. Switching from one profile to another keeps each pair’s memory of what was already migrated, so a sync stays incremental. Application passwords are stored encrypted and never shown again — leave the field empty to keep the saved one. One migration runs at a time per account. The Free plan keeps one profile; paid plans, as many as you like. An account back on the Free plan keeps the profiles it has, but cannot add new ones.

Where do I find past migrations and their logs?

Under History in the app’s sidebar: every run with its date, counts and status, and its full log. During a run, the log can be filtered to show errors only and downloaded. From My migrations, “View its history” shows the runs of one profile only.

Elementor layouts, ACF fields or SEO metadata are missing

WordPress’ REST API only carries the custom fields a plugin has explicitly opened to it — most do not, so Elementor layouts, ACF fields and some SEO metadata stay behind without a warning. Install the free WPMove Migration Connector on both sites, then run the migration again: every custom field travels, including the images an ACF field points to. The plugin is free, needs no account, and only answers requests authenticated with the application password you already use here.

Media re-imported with a -1 suffix on the filename

This happens when “Skip already imported media” is unticked (replace mode) and a file with the same name already exists on the target. WPMove’s replace mode deletes the existing file first precisely to avoid it; suffixed files you still see were most likely uploaded outside WPMove before the migration.

Sync mode migrated everything — or nothing

Sync mode carries only what changed since your last successful migration between the same two sites, so a run that finds nothing to do is usually right: nothing changed. It deliberately falls back to a full migration in four cases, and the log always says which: no previous successful migration to this target; the previous run stopped at your plan’s limit; you added a content type the previous run did not cover; or your earlier migrations predate sync mode and never recorded what they covered. One full migration records the scope, and every sync after it is incremental. Content deleted on the source is never removed from the target: sync mode adds and updates, it is not a mirror.

Comments are missing — or arrived awaiting moderation

Comments only travel when “Import comments” is ticked; it is off by default. Comments awaiting moderation come across too, and stay awaiting moderation. Spam and trash are left behind on purpose. Threads are rebuilt; a reply whose parent was not migrated is attached at top level rather than to the wrong comment, and the log says so. Commenters arrive as guests (name and email), and re-running a migration never duplicates comments already on the target.

The post author received one email per migrated comment

That email comes from the target site: WordPress notifies a post’s author for every approved comment, and a comment created through the core REST API is treated like a new one. Install the free WPMove Migration Connector on the target and migrated comments are written directly — no email, no moderation, no reply rejected as a duplicate. Without it, untick “Email me whenever anyone posts a comment” in Settings → Discussion on the target for the duration of the migration.

What does installing the free Connector on the target change?

Several things, all silent otherwise. Custom fields: Elementor layouts, ACF fields, SEO meta and page templates travel (the plugin is needed on both sites). Comments and reviews: written directly, without moderation or notification emails. Widgets: plugin widgets closed to the REST API are copied too. Analysis: the report can check addresses already taken on the target. Installing it: once a site passes its connection test, the Sites step shows an “Install the connector” button under it — it installs and activates the plugin from wordpress.org with the credentials you entered, and a “Remove it” link undoes it after the migration. The Premium plugin does the same for the other site, from its import/export screen or with wp wpmove connector install. One requirement: the application password used on that site must belong to an Administrator (or an account allowed to install plugins); a host that forbids installing plugins from outside is named, and you can then install it from the site’s Plugins page. The plugin is free, needs no account, and is the same one used for file export and import.