When a WordPress multisite network has more sites in it than you need, you can choose to separate any number of those sites out and give them WordPress installations of their own. WordPress has no built-in tool for this, because a network keeps every site’s content in its own set of database tables and every site’s images in its own folder, all inside one shared installation. Converting a WordPress multisite to a single site means copying the right pieces into a fresh installation, renaming them so the new site can find them, and turning off the settings that made it a network. The steps below assume the site you’re moving, runs on the Kadence theme, though everything except the design checks works the same way on any WordPress theme.
Before you start the conversion
Before you start the conversion, back up the whole network and set up a copy of it to practice on. Parts of this job touch pieces of the database that every site in the network shares, so a mistake can affect sites you were not moving, and running it through once on a copy shows you what to expect.
Four things to have ready:
- A full backup of every file and the whole database, covering the network not only your site.
- A staging copy of that backup to do the work on.
- Your site’s ID number, listed next to it in Network Admin > Sites. Almost everything you need to find is named after this number.
- A list of which plugins were switched on for the whole network and which were switched on for your site alone. The network ones will not come across and need installing again.
Export your Kadence settings on their own as well. With the Kadence Starter Templates plugin active, go to Appearance > Customize > Import/Export and download the .dat file, which you can load straight back in if the design does not survive the move.
What belongs to your site
What belongs to your site is everything named after that ID number. If your site is number 4, its database tables are called wp_4_posts, wp_4_options and so on, and its images sit in a folder called wp-content/uploads/sites/4/.
The main site of a network works differently. It is number 1, its tables have no number in them, its permission entries don’t have a number either, and its images are already in wp-content/uploads/.
Some things stay behind. Three tables called wp_blogs, wp_site and wp_sitemeta exist only to run the network, and a single site has no use for them. Accounts are the other way around, because everyone with a login anywhere on the network is stored together in wp_users and wp_usermeta, so you take only the people who had access to your site.
Move your site into a new WordPress install
Moving your site into a new WordPress install is more reliable than stripping the network out of the installation you already have, because you start from a copy of WordPress you know is working. Install WordPress, then install the Kadence theme and each of your plugins from their own sources before you import anything. Downloading fresh copies avoids bringing across files that were modified or left out of date, and having the theme in place first gives your imported design settings something to attach to when the database arrives.
Then move the site itself:
- Export your site’s tables from the network database.
- Rename each one, changing the wp_4_ at the start to wp_.
- Delete the default tables in the new install, then import your renamed ones.
- Copy the contents of wp-content/uploads/sites/4/ into wp-content/uploads/ on the new site.
- Change the old web address to the new one everywhere it appears in the database, using WP-CLI’s search-replace command or a WordPress plugin built for this. Theme settings and widget layouts are saved in a format that an ordinary find and replace will damage.
- In the wp_usermeta table, rename the entries called wp_4_capabilities and wp_4_user_level to wp_capabilities and wp_user_level.
Skipping the last step locks you out of your own site. WordPress records what each person is allowed to do separately for every site in a network and puts the site number in the name, so if those names keep the number, your new site has no administrator.
Turn off the network settings
Turning off the network settings is what stops WordPress behaving like a network. Until you do it, WordPress keeps loading its multisite code and sending web addresses through the network’s routing rules, and those instructions sit in two files.
In wp-config.php, delete or comment out
MULTISITE, SUBDOMAIN_INSTALL, DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE, SITE_ID_CURRENT_SITE, BLOG_ID_CURRENT_SITE and WP_ALLOW_MULTISITE.
That last one is what switched the network on originally, so it goes with the others.
In .htaccess, delete everything between the lines marked # BEGIN WordPress and # END WordPress. Then open Settings > Permalinks on the new site and click save, and WordPress writes the correct rules back in for you.
Check the design and redirect the old addresses
Checking the design and redirecting the old addresses is the last step. Open the Kadence Customizer and look at your color palette, your fonts, and the header and footer. If the site loads with no styling at all, import the .dat file you saved at the start.
Then set your site address under Settings > General, and put 301 redirects in place sending each old address to the one that replaces it. This is important, because if you point everything at the homepage instead you will lose the search value each page had built up prior to the conversion. Leave the old site working until you have clicked through the new one and checked that the images load.
Frequently asked questions
Where to start
Start by finding your site’s ID number in Network Admin > Sites, then build a staging copy of the network and run the whole conversion on that before you touch the live one.
When you’re moving a site out of a multisite network, it helps to have a safe place to test changes before going live. With Liquid Web’s Managed WordPress Hosting, you get staging environments, direct database access, and automatic backups, so you can handle even complex migrations with confidence.


Kamila Thompson