Clone & Push WordPress Multisites

WP STAGING PRO lets you clone regular WordPress single sites and entire WordPress multisite networks — both subfolder and subdomain configurations.

TL;DR: Yes, WP STAGING PRO clones and pushes WordPress Multisites. It supports subfolder multisites, subdomain multisites, and cross-host scenarios. You can clone a single network subsite (converting it to a standalone staging site) or clone the entire network in one operation. A Business or Developer license is required.

What Type of Multisite Can be Cloned?

WP STAGING PRO supports cloning any WordPress Multisite network, including the main network site and individual sub-sites. The multisite can use either a subfolder or subdomain structure.

The table below shows which operations are available per multisite configuration:

In our testing, subdomain multisites consistently require a DNS propagation step that subfolder setups skip — plan for this before pushing a subdomain-based clone to a new host.

Cloning the Main or Network Site Separately

WP STAGING PRO can create a staging site for the active website. This can be either the main network site or one of its child network sites. While it clones one of these sites, it converts a specific network site to a standalone single site. This lets you work on the staging site and then later push changes back to the production parent network site.

It works as follows:

• Install WP STAGING PRO network-wide or on a per-site basis. Then log in to the specific network site wp-admin > WP STAGING PRO > Staging Sites.
• From there, create a staging site, which clones the current network site.

The cloned staging sites are independent and cannot affect each other, which is strongly recommended for safe testing.

Pushing Changes Back to the Network Site

After completing your changes on the staging subsite, use the push wizard in WP STAGING PRO > Staging Sites to push selected files and database tables back to the parent production site. Choose which tables and directories to include so unrelated network subsites are not affected.

Cloning the Entire WordPress Multisite Network

To clone the whole network, activate the plugin on the main network site, then go to WP STAGING PRO > Staging Sites and click "Start Cloning":

Clone a WordPress Multisite on SiteGround Hosting

SiteGround and similar hosting providers may require extra steps to make the multisite clone work.

When cloning a multisite from example.com into a subdomain like staging.example.com, SiteGround does not allow changing the subdomain root path. Once you clone your entire multisite, the network subsites will not resolve until you create a matching subdomain for each.

Say your site structure is:

1. example.com
2. site1.example.com
3. site2.example.com
4. site3.example.com

After cloning to staging.example.com, the expected staging network structure is:

1. staging.example.com
2. site1.staging.example.com
3. site2.staging.example.com
4. site3.staging.example.com

Create each of those subdomains in the SiteGround hosting dashboard:

SiteGround creates a public_html folder for each new subdomain. Delete that folder, then create a symbolic link pointing to the public_html in your staging site folder:

Create the symbolic link over SSH:

ln -s ~/www/staging.example.com/public_html ~/www/site1.staging.example.com/public_html

If subsites still do not load, check the .htaccess file in the staging root and replace every occurrence of example.com with staging.example.com.

Troubleshooting Common Multisite Clone Issues

From WP STAGING support experience, the most frequent multisite-specific failures fall into four categories.

Permalink Flush Failures After Clone

After cloning, WordPress may return 404 errors on subsite pages until you flush permalinks. Go to Settings > Permalinks on each subsite and click Save Changes without modifying the structure. This rewrites the .htaccess rewrite rules for the cloned domain.

Network Admin vs. Site Admin Confusion

WP STAGING PRO’s staging controls live in the Network Admin panel when installed network-wide. If you log in to a subsite admin instead, the staging menu may not appear. Always navigate to staging.example.com/wp-admin/network/ to manage the cloned network.

Subdomain DNS Not Resolving on Staging

Subdomain multisites require each staging subdomain to resolve via DNS or a wildcard DNS entry (*.staging.example.com). Without this, browsers return a DNS resolution error when visiting subsite URLs on the staging domain. Add a wildcard A record in your DNS panel pointing to your staging server IP before testing.

Table-Prefix Conflicts Across Network Sites

Each subsite in a WordPress multisite uses a prefixed set of tables (e.g., wp_2_posts, wp_3_posts). If your staging and production databases share a MySQL instance and the prefix is identical, WP STAGING PRO uses a separate database or a distinct prefix for the staging clone to prevent conflicts. Verify the Database settings in the clone wizard match your intended isolation level.

Structured Data and Schema

TechArticle schema is already present on this page. To improve rich results coverage for the step-by-step workflows above, consider adding HowTo schema for the clone and push procedures. Do NOT use FAQPage schema — Google restricted FAQ rich results to government and health authorities in 2023.

External Resources

For deeper background on WordPress Multisite architecture, see:

• WordPress Multisite Network Administration — the official WordPress.org handbook covering network setup, subsite management, and common configuration options.
• Create a WordPress Network — the WordPress developer handbook on enabling multisite and choosing between subfolder and subdomain configurations.

What WP STAGING PRO License Do I Need?

For multisite support you need at least a Business or Developer license of WP STAGING PRO. To use the push and backup feature, choose a license that covers the number of network sites where you need the push feature simultaneously.

For example: two network sites require at least the Business plan. Four or more network sites require the Developer plan.