What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
To move one site out of a WordPress multisite network, create a separate WordPress installation, export the subsite’s content, copy its uploads, transfer any plugin-specific data, update URLs safely, and test the new site before retiring the source. This is different from converting the network’s existing main site back to single-site mode; choose the path that matches what you want to keep.
Choose the migration path
| Your goal | Use this path | What happens to the network |
|---|---|---|
| Make one subsite an independent website | Export that subsite into a fresh, separate WordPress installation. | The multisite network remains in place while you validate the new site. Other subsites are unaffected. |
| Stop using multisite for the network’s existing main site | Convert the retained main site to single-site mode. | This changes the existing installation’s configuration. Other subsites need to be migrated first if they must survive. |
WordPress Learn documents both approaches in Advanced Multisite Management. The steps below cover each separately.
Extract one subsite into a standalone installation
1. Back up the source and keep it available
Back up the network’s files and database before making changes. Keep the original network intact as a rollback option until the destination has passed your checks. WordPress’s migration guidance emphasizes keeping a database backup when moving a site.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Export the subsite’s content
Sign in to the dashboard for the subsite you intend to move, then open Tools > Export and create a WordPress eXtended RSS (WXR) export. WXR transfers content; it is not a complete copy of the site’s files, plugin settings, or every plugin’s database data.
3. Prepare the new WordPress site
Install WordPress as a separate, single-site installation at the destination address. Create or identify the user who should own the imported content. Install the theme and plugins the subsite relies on, and check that each plugin supports the standalone setup and version you plan to use.
4. Import the WXR file and map authors
In the new site, open Tools > Import, run the WordPress importer, and upload the WXR file. When prompted, map imported content to the intended destination user. Review the assignment rather than assuming source usernames will correspond to the right destination accounts.
Rank #2
5. Copy the subsite’s media
Multisite stores a subsite’s uploads under wp-content/uploads/sites/, in a directory named for that subsite’s ID. Copy the relevant media into the destination’s uploads tree. Then inspect representative posts, images, and attachment pages to confirm files load and references point to the right location.
6. Transfer plugin-specific data
Some plugins store information in custom database tables or other data that WXR does not include. Inventory the plugins used by the subsite and identify what each one must retain, such as form entries or other plugin-managed records. WordPress Learn notes that custom tables or custom data may require manual copying; copying tables without checking relationships can also associate content with the wrong user. Test plugin features on the destination instead of assuming an import covered them.
Rank #3
7. Replace the site address without damaging stored data
If the standalone site uses a different URL, update references from the old subsite address to the new one with a serialization-aware search-and-replace method. WordPress warns that a raw database-wide replacement can corrupt serialized values because their stored string lengths matter. See its URL migration guidance and the WP-CLI command reference, which documents database export and search-replace capabilities.
If the public address changes, also plan redirects from old URLs where appropriate. Check internal links, canonical URLs, and media paths as part of the move.
8. Validate the destination before retiring the source
Compare page and post counts, browse key pages, and check navigation, permalinks, media, and user access. Exercise forms, commerce, and other plugin-dependent features that matter to the site. Keep the source and its backup until those checks pass.
Convert the network’s retained main site to single-site mode
This route changes the existing installation rather than importing the main site into a fresh one. First export any other subsites that must remain independent; removing subsites can remove their content tables.
- Back up the files and database. Keep a rollback copy before changing configuration or database tables.
- Remove multisite configuration. Edit
wp-config.phpand remove the multisite-related constants used by the network configuration. - Restore ordinary rewrite rules. Replace the network-specific rewrite rules in
.htaccesswith the standard rules for a single WordPress site. - Reset permalinks and test. In the WordPress dashboard, open Settings > Permalinks and save the permalink settings. Check that the retained site loads and its pages work.
- Consider network-table cleanup only after validation. WordPress identifies network tables including
wp_blogmeta,wp_blogs,wp_registration_log,wp_signups,wp_site, andwp_site_meta. Table names can use a different database prefix. Do not remove network data until required subsites are safely migrated and the retained site has been validated.
For the network conversion procedure and its table considerations, see WordPress Learn’s Advanced Multisite Management.
What WXR does—and does not—move
The WordPress exporter and importer are useful for transferring content, but a standalone site may need additional work beyond that file. Plan separately for the theme and plugins, uploads, plugin settings, custom tables, user mapping, URL changes, and any site-specific behavior. The reverse-direction guidance in WordPress’s migration documentation also describes general WXR and resource-limit caveats; it is not a procedure for extracting a multisite subsite.
Quick Recap
Common migration failures to check
- Missing images: Confirm the files were copied from the correct subsite ID directory and that destination references resolve.
- Broken links or redirects: Check for old subsite URLs in content, canonical URLs, and public-facing links.
- Plugin features with missing records: Verify whether the plugin uses custom tables or separate data that the WXR export did not include.
- Unexpected content ownership: Review imported author assignments and test user permissions.
- Broken pages after network conversion: Recheck rewrite rules and permalink settings before considering network-table cleanup.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
