Convert WordPress Multisite to Single Site: 3 Proven Methods

Converting a WordPress Multisite to a single site means extracting one sub-site from the network into its own WordPress installation, or disabling Multisite entirely and reverting the base site to standalone.

You have three proven paths: (1) manual export/import using WordPress’s built-in tools, (2) a migration plugin like Prime Mover or Duplicator Pro, or (3) a manual database extraction via phpMyAdmin. This guide walks through all three plus how to fully turn off Multisite, preserve SEO with 301 redirects, and troubleshoot the errors you’re likely to hit.

Use this table to pick the right path before you touch anything. Every method below is covered step-by-step later in this guide.

If you’re unsure, use Method 2 with the free Prime Mover plugin. It’s the fastest, safest path for most sites and handles the database, media, plugins, and themes in one package.

WordPress Multisite stores data differently from a standard install. Media for each sub-site lives in /wp-content/uploads/sites/[SITE_ID]/. Posts, options, and postmeta live in prefixed database tables (wp_XX_posts, wp_XX_options, etc.). Users are shared across the entire network in a single wp_users table. Themes and plugins are stored once at the network level and activated per-site.

That means a straight database export won’t work. You need to grab the right upload folder, rewrite table prefixes, extract only your sub-site’s users, and rebuild plugin/theme activation on the destination. This guide walks through exactly how to do that, with the code and commands you’ll actually paste into your server.

Multisite is a great architecture for tightly related sites, university departments, franchise locations, agency white-label client networks, or SaaS platforms. But the moment a single sub-site outgrows the network, Multisite starts working against you. Here are the six most common reasons operators pull a sub-site out:

• Autonomy — a sub-site owner wants their own hosting, plugins, backups, and admin control without a Super Admin above them.
• Performance — one busy sub-site slows down every site on the network. Splitting it out into dedicated hosting eliminates noisy-neighbor issues.
• Security — a compromised plugin on one Multisite sub-site can expose the entire network. Isolation limits the blast radius.
• Client handover — freelancers and agencies routinely build client sites inside their own Multisite for efficiency, then have to hand the client their own independent install when the project ships.
• Plugin compatibility — some plugins, particularly older WooCommerce extensions and single-tenant tools, simply don’t work on Multisite.
• Regulatory or compliance separation — certain frameworks require data isolation that Multisite’s shared user table makes hard to prove.

When You Should NOT Convert

If you manage 10+ tightly related sub-sites that share users, themes, and centralized admin, Multisite is still the right architecture. Only extract when the ongoing cost of staying networked exceeds the one-time cost of migrating.

Rushing this migration is how sites get bricked. Thirty minutes of prep saves thirty hours of recovery.

1. Take Two Backups

One via your hosting provider’s snapshot tool, one via a plugin like UpdraftPlus, BlogVault, or WP Time Capsule. Store both off-server. If you’re on Rocon Managed WordPress Hosting, automatic daily snapshots are enabled by default — grab an on-demand one before you start.

2. Find Your Sub-Site’s Site ID

In the Multisite dashboard, go to Network Admin > Sites > Edit on the sub-site you’re moving. The URL in your browser ends in ?id=XX — that number is your Site ID. You’ll need it to find the correct upload folder (/wp-content/uploads/sites/XX/) and database tables (wp_XX_posts, wp_XX_options, etc.).

3. Document Plugins, Themes, and Settings

Screenshot your Plugins and Themes screens. Export every plugin’s settings that supports export, Yoast SEO, Rank Math, WooCommerce, Contact Form 7, WPForms, etc. This is the single biggest time-saver when rebuilding on the destination.

4. Prepare the Destination

Provision a fresh WordPress install on your new host with a temporary domain or subdomain. Don’t point production DNS at the new site until you’ve fully verified the migration.

5. Confirm Access to

• FTP or SFTP credentials for both source and destination
• phpMyAdmin (or Adminer) on both servers
• DNS management for the final cutover
• WordPress admin passwords for both installations

This method uses only free, built-in WordPress tools plus two well-known plugins. It’s the safest option if you’re not comfortable editing databases, and it works on every host, managed, shared, VPS, or dedicated. Total time: 60–120 minutes for a small site; add 30 minutes per 1,000 posts.

Step 1: Export sub-site content

Log in to the sub-site’s dashboard (not Network Admin, the sub-site itself). Go to Tools > Export, select All Content, and click Download Export File. WordPress produces an XML file (WXR format) containing posts, pages, custom post types, taxonomies, and menu references, but not the media files themselves.

Save the XML file somewhere you won’t lose it. You’ll upload it to the new site in Step 5.

Step 2: Copy the sub-site’s media files

WordPress does not include media in the WXR export, you have to copy the files yourself. Connect via FTP/SFTP and navigate to:

/wp-content/uploads/sites/[YOUR_SITE_ID]/

Download the entire folder to your local machine. If your Multisite was created before WordPress 3.5, your media lives in /wp-content/blogs.dir/[SITE_ID]/files/ instead.

Step 3: Set up a fresh WordPress installation

On your destination server, install WordPress on a temporary domain or subdomain. Do not use the final production domain yet, you’ll switch DNS at the very end. Use PHP 8.1 or higher for compatibility with modern plugins.

Step 4: Install matching themes and plugins

Before importing content, install the same theme and plugins the sub-site was using. Some plugins register custom post types on activation if you import content before the plugin exists, WordPress silently drops those posts.

Activate everything but skip any setup wizards or first-run flows. You’ll configure them after the content lands.

Step 5: Import content via WordPress Importer

On the new site, go to Tools > Import > WordPress > Install Now. Once installed, click Run Importer and upload the XML file you exported in Step 1.

Assign posts to an existing user or create a new one. Then, critically check the ‘Download and import file attachments’ box. This tells WordPress to try to fetch media from the original URLs; some fetches will fail, which is why you also copy files manually in the next step.

Step 6: Upload media files via FTP

Upload the entire folder you downloaded in Step 2 into your new site’s /wp-content/uploads/ directory, preserving the year/month subfolder structure (e.g., /uploads/2024/03/). Once uploaded, install the Regenerate Thumbnails plugin and run it so WordPress rebuilds every image size.

If the Media Library still doesn’t show your images, use the Add From Server plugin to register the uploaded files with WordPress’s database.

Step 7: Migrate users

The WXR export includes only users who authored content. Every other user, subscribers, editors, customers, members is stored network-wide in wp_users and won’t come across.

Install Import Export WordPress Users on both the multisite and the new single site. Export a CSV from the multisite, then import it on the new site. Password hashes, roles, and user meta all come across. Users can log in with their existing passwords, never try to copy or reset hashes manually.

Step 8: Search-and-replace URLs

Your imported content still references the old Multisite URLs. Install Better Search Replace on the new site and run:

• Search for: https://subsite.example.com (or https://example.com/subsite for subdirectory installs)
• Replace with: your new domain (e.g., https://newsite.com)
• Tables: select all, or at minimum wp_posts, wp_postmeta, wp_options, wp_termmeta
• Run as dry-run first, review the count, then run for real

Better Search Replace safely handles PHP-serialized data (widget settings, theme options, plugin configs) that a naïve MySQL REPLACE would corrupt.

Step 9: Rebuild menus and widgets

Menus and widget assignments don’t survive the WXR export cleanly. Go to Appearance > Menus and reassign your menus to their theme locations.

For widgets, install Widget Importer & Exporter, export a .wie file from the old sub-site, and import it on the new site.

Step 10: Update permalinks and test

Go to Settings > Permalinks and click Save Changes without changing anything. This regenerates the rewrite rules for the new install.

Then run through this checklist:

• Every top-level page loads without 404s
• A random sample of blog posts opens with correct images
• Contact forms submit successfully
• Login and password reset both work
• Site search returns expected results
• Any WooCommerce checkout completes with a test order

Run the site through Screaming Frog SEO Spider or Sitebulb to catch every remaining 404 and broken image.

Step 11: Point the domain and set up 301 redirects

Once you’re satisfied the new site works, update DNS to point your production domain at the new host. Then, on the original Multisite, add 301 redirects from every old sub-site URL to the new URL. You can do this three ways:

• In .htaccess: Redirect 301 /old-path https://newsite.com/old-path
• Via the Redirection plugin (best for non-technical operators)
• At the CDN layer, Cloudflare Page Rules, Fastly, or your host’s edge

Redirects preserve your search rankings. Skipping this step is the #1 reason sites lose organic traffic after a migration.

If you’d rather not touch the database yourself, a migration plugin is the fastest and safest option. Prime Mover (free) is our top pick for most sites; Duplicator Pro is worth it if you migrate frequently or run large stores.

Option A: Prime Mover (Free — Recommended)

Prime Mover is one of the only free plugins that can package a single sub-site out of a Multisite network in one shot — database, media, plugins, and themes included.

1. Install Prime Mover on the Multisite via Network Admin > Plugins > Add New. Network-activate it.
2. Install Prime Mover on the destination single site and activate it.
3. In Network Admin > Sites, click ‘Export Blog ID’ for your sub-site.
4. Select ‘Export database, media files, plugins and themes’ and ‘Export to single-site format’, then click Export Now.
5. Download the resulting .wprime package.
6. On the destination site, go to Tools > Migration Tools > Restore under Import Package, upload the .wprime file, and confirm.
7. After the import completes, go to Settings > Permalinks and click Save Changes.

That’s the entire migration. What took 11 manual steps in Method 1 collapses into a single package export and restore. Prime Mover also handles serialized data correctly, so you don’t need Better Search Replace afterwards.

Option B: Duplicator Pro (Paid, $99+/yr)

Duplicator Pro’s Multisite feature lets you extract one sub-site from a network into its own standalone package. It’s more mature than Prime Mover for very large sites (10 GB+) and includes cloud storage integration.

Workflow:

1. Install Duplicator Pro on the Multisite (network-activate).
2. In the Duplicator dashboard, create a new Package. Under Archive > Multisite, choose ‘Single Sub-site Install’.
3. Select the sub-site by Site ID and build the package. Duplicator generates a .zip archive and an installer.php file.
4. Upload both files to the destination server via FTP.
5. Visit https://newsite.com/installer.php in your browser and follow the on-screen prompts. Duplicator handles database creation, table renaming, URL rewriting, and file placement.
6. Delete installer.php and installer-backup files after the migration completes for security.

Option C: All-in-One WP Migration (Paid Multisite Extension)

All-in-One WP Migration is popular for standard migrations, but the free version does not support extracting a sub-site from Multisite. The paid Multisite Extension does. It’s a viable alternative if you already own the plugin family.

This method gives you total control and works when plugins fail (PHP timeouts, memory limits, or hosts that block migration tools). It’s the fastest method for developers, but the riskiest for beginners — one wrong table drop and you’ll be restoring from backup.

Step 1: Copy files

Copy /wp-content/uploads/sites/[SITE_ID]/ to /wp-content/uploads/ on the destination server. Copy any Must-Use plugins from /wp-content/mu-plugins/. Install the sub-site’s themes and plugins fresh on the destination, copying them from Multisite works too, but a fresh install avoids license and update headaches.

Step 2: Export the sub-site’s database tables

Open phpMyAdmin on the Multisite server. Select all tables prefixed with wp_XX_ where XX is your Site ID (for example: wp_5_posts, wp_5_postmeta, wp_5_options, wp_5_users, wp_5_usermeta, wp_5_terms, wp_5_term_relationships, wp_5_term_taxonomy, wp_5_termmeta, wp_5_commentmeta, wp_5_comments, wp_5_links). Click Export, choose ‘Custom – display all possible options’, pick SQL format, and download.

Step 3: Rewrite the SQL file

Open the exported .sql file in a code editor and make two find-and-replace passes:

1. Replace every instance of wp_XX_ (e.g., wp_5_) with wp_ — this converts your Multisite-prefixed tables to single-site standard.
2. Replace every instance of the old sub-site URL (e.g., https://subsite.example.com) with your new single-site URL (e.g., https://newsite.com).

Warning: this URL replace only handles unserialized data. If your database has serialized options (widget settings, theme mods), use Better Search Replace after import instead.

Step 4: Import into the destination database

On the destination server, drop the default WordPress tables (except wp_users and wp_usermeta if you want to keep the admin account you created during install). Then use phpMyAdmin > Import to upload the edited .sql file. Large databases (>50 MB) may need to be uploaded via SSH and imported with the mysql CLI:

mysql -u USER -p DATABASE < edited-multisite-export.sql

Step 5: Update wp-config.php

Set the database name, user, password, and host to match the destination. Make sure the $table_prefix line reads wp_ (single underscore), not wp_XX_. Save and load the site.

Step 6: Regenerate permalinks and test

Log in, go to Settings > Permalinks, click Save Changes, and work through the same test checklist from Method 1, Step 10.

If you’ve already extracted or deleted every sub-site and only want the base site to remain, you can fully turn Multisite off. Take a full backup before you start — these edits are not reversible without one.

Step 1: Delete every sub-site except the base

In Network Admin > Sites, select every non-base sub-site and choose Bulk Actions > Delete > Apply. This deletes their upload folders and their site-specific database tables. If any of those sub-sites still have content you need, migrate them out first using Method 1 or 2 above.

Step 2: Uninstall unused plugins and themes

In Network Admin > Plugins, delete plugins the base site doesn’t use. Repeat for Themes. This step isn’t strictly required, but it cleans up your install.

Step 3: Remove network-only users

In Network Admin > Users, delete users who don’t have a role on the base site. The free Multisite Enhancements plugin shows a per-user site list to make this quicker.

Step 4: Edit wp-config.php

Open your site’s wp-config.php file and find this block, usually near the bottom:

define( ‘MULTISITE’, true );

define( ‘SUBDOMAIN_INSTALL’, false );$base = ‘/’;

define( ‘DOMAIN_CURRENT_SITE’, ‘example.com’ );

define( ‘PATH_CURRENT_SITE’, ‘/’ );

define( ‘SITE_ID_CURRENT_SITE’, 1 );

define( ‘BLOG_ID_CURRENT_SITE’, 1 );

Delete all seven lines. Then find:

define( ‘WP_ALLOW_MULTISITE’, true );

Change it to:

define( ‘WP_ALLOW_MULTISITE’, false );

Save the file.

Step 5: Edit .htaccess

Open .htaccess in the WordPress root. Delete every Multisite rewrite block (they contain references to wp-content/blogs.dir or ms-files.php) and replace with the standard WordPress single-site rules:

# BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteBase /RewriteRule ^index\.php$ – [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress

Step 6: Drop Multisite database tables

In phpMyAdmin or Adminer, select these tables and drop them:

• wp_blogs
• wp_blog_versions (older WordPress installs only)
• wp_registration_log
• wp_signups
• wp_site
• wp_sitemeta

Do NOT drop wp_users, wp_usermeta, wp_options, or any other core table. Those belong to your base site.

Step 7: Log back in and verify

Clear your browser cache and log in via /wp-admin/. You should land in a standard single-site dashboard with no ‘My Sites’ menu at the top. Multisite is fully disabled.

Broken image links after import

Almost always caused by media files not being uploaded, or uploaded to the wrong path. Confirm files exist at /wp-content/uploads/YEAR/MONTH/ and that URLs in post_content match. Run Better Search Replace to fix path references, then Regenerate Thumbnails to rebuild sizes.

‘Sorry, this file type is not permitted for security reasons’ during import

The WordPress Importer is being blocked from downloading attachments. Add this to wp-config.php to diagnose:

define( ‘IMPORT_DEBUG’, true );

If it’s an SSL verification error, add: add_filter(‘https_ssl_verify’, ‘__return_false’); to a small plugin or the theme’s functions.php. Remove it after the import.

Login redirects to the old domain

Your siteurl and home options still point to the Multisite. Fix in wp-config.php with the WP_HOME and WP_SITEURL constants, or run Better Search Replace on wp_options for the two rows named ‘siteurl’ and ‘home’.

Plugin conflicts after activation

Multisite-specific plugins (network admin tools, per-site theme switchers, etc.) can fatal-error on activation on a single-site install. Deactivate everything, then reactivate one plugin at a time to isolate the culprit.

500 Internal Server Error after wp-config edits

You’ve almost certainly left a typo or stray character in wp-config.php or .htaccess. Restore both files from your backup and redo the edits carefully. Watch for missing semicolons in PHP and stray characters in .htaccess.

Users can’t log in after migration

The wp_users table wasn’t migrated, or you’re on a different WordPress version that changed password hashing. Migrate users with the Import Export WordPress Users plugin (Method 1, Step 7) and ask affected users to use the ‘Forgot Password’ link if hashes fail.

• Always run the full migration on a staging site first. Fix everything there before touching production.
• Schedule the DNS cutover for your lowest-traffic window — usually 2–5 a.m. local for content sites, or Sunday morning for B2B.
• Lower your DNS TTL to 300 seconds 48 hours before the cutover so DNS changes propagate quickly.
• Put a temporary maintenance page on the old sub-site during the final content freeze, or use a database sync tool like WP Migrate DB Pro to catch last-minute changes.
• Monitor Search Console ‘Coverage’ and ‘Sitemaps’ reports daily for the first two weeks post-migration.
• Keep the old Multisite live for at least 30 days after cutover as a safety net, with redirects intact.

Converting a WordPress Multisite to a single site is a technical migration, but it’s absolutely doable with the right method and preparation. For most site owners, Method 2 with Prime Mover is the fastest, safest path. For developers who want total control, Method 3 via phpMyAdmin gives you it. And when you’re ready to shut Multisite off entirely, the network revert steps above take the guesswork out.

Whichever path you choose, three rules keep migrations from going sideways: back up twice, stage first, and 301 everything. Do those three things and you’ll come out the other side with a faster, simpler, more secure WordPress install, and your rankings intact.

Need help with a complex WordPress migration? Rocon offers free Multisite-to-single-site migrations with every hosting plan, handled end-to-end by our engineering team. Talk to a migration expert if you’d rather hand this off.

1. How do I revert a Multisite to a single site in WordPress?

To convert WordPress Multisite back to a single site, back up your site, remove multisite lines from wp-config.php and .htaccess, then clean up your database (wp_blogs, wp_site tables). Then keep only the main site’s data and delete others. Best to do this on a staging site first so you don’t lose data.

2. How do I turn off Multisite WordPress?

To disable WordPress Multisite, edit wp-config.php and remove the multisite lines (MULTISITE, SUBDOMAIN_INSTALL, etc.), then clean up related entries in .htaccess. Be careful—disabling it doesn’t remove the extra sites, so manual database cleanup is required. Always back up your site before making changes so you don’t break anything.

3. How to migrate a WordPress Multisite?

To move a WordPress Multisite, backup the files and database, move them to the new server and update the wp-config.php, .htaccess and database URLs. Use WP Migrate DB Pro or manually update settings. Test each subsite after migration to make sure everything is working and redirecting properly.

4. Is WordPress Multisite good for SEO?

Yes, WordPress Multisite can be good for SEO if each subsite is optimised properly. It allows you to manage multiple sites from one dashboard while having separate SEO settings, sitemaps and content. Just make sure to use domains or subdirectories, fast hosting and clean permalinks to keep SEO strong.