Originally posted 1 Jan 2014. Updated multiple times since then. Most recently updated with info for editing web.config on Windows Server.

Our company website here at wpxpress.com (previously Fiddler.Online) had been a WordPress Multisite for some time. I decided it wasn’t really serving any good purpose to have it that way, partly because we’d simplified and only had 2 other sites running on the network. The other was a site we’d quit using and updating some time ago, but hadn’t yet removed. So I decided to roll it back to a single-site WordPress install. Here’s how it did it:

1. Backup Everything

I recommend a full cPanel backup to start with. Just go into your cPanel and click the “Backup Wizard” icon. Use the options for a full backup, then download the file when it’s completed. A separate backup of the database is also a good idea. From cPanel just go to phpMyAdmin, select the correct database, then the “Export” tab, and click the “Go” button. It’ll download the export.

NOTE: if you have or purchase BackupBuddy, you can actually use it to do all of this step, by backing up the entire Multisite in one neat package (assuming yours isn’t too large). You can also do the separate database-only backup quickly as well.

2. Export, Then Delete Sub-Sites

I did this the easy way. I used BackupBuddy (network installed) to export the sub-sites we wanted to keep. Then used the importbuddy.php script included with it, to setup this site as a standalone single-site from the exported backup. To do this, you have to enable BackupBuddy’s experimental Multisite features. Once you’ve added that line (see previously link) to your wp-config.php file, just navigate to the sub-site and select “BackupBuddy” in the sidebar. In the next step you’ll select any plugins you want to include with this sub-site.

Alternately, if you’re wanting to merge 1 or more sub-sites into the parent site, or other sites, you can just use WP’s export feature to export only posts, pages, and media. If you go this route, you’ll want to import them elsewhere before proceeding, otherwise the media will have to be manually added elsewhere, after the sub-site is deleted.

Once I exported this site, I used the importbuddy.php script and set it up separately first. That way I knew it was running just like it did on the Multisite, and all I cared about was wpxpress.com. But you don’t have to. It won’t affect this, so you can setup the sub-sites separately at any time.

Now you want to delete all the sub-sites in the network. Just go to the network admin, then Sites, and check all of them, then select Delete from the bulk actions, and apply it. Now confirm.

3. Disable Network Activated Plugins, Then Delete Multisite-Only Plugins

Obviously plugins like Domain Mapping, Network Plugins Auditor, and New Site Templates aren’t going to work on a standalone WordPress install, so disable, then delete them all. Also disable any network activated plugins, since there will soon be no network.

You’ll also want to delete the sunrise.php file from the /wp-content/ folder. Thanks to Julie for catching that.


It’s possible that your user can be a super-admin for the network, but not an Admin on the main site. If that’s the case, your user won’t have access to anything after the change to single site.

Before proceeding: Make sure that your user is an Admin user on the main site! To do this, go to “All Sites” in the Network Admin and click the “Edit” link under the main site. Now click the “Users” tab. You should see your user with Admin status. If not, edit your user and change to Administrator. Or if your user is not there at all, use the “Add Existing User” section below the uers list to add yourself as an Administrator.

4. Remove Multisite Markers From “wp-config.php”

Next you need remove all the Multisite stuff from wp-config.php. If you’re not sure what was added, navigate to the network admin at http://yoursite.com/wp-admin/network/. From there go to Settings > Network Setup. Under #1 you should see something like this:

define('MULTISITE', true);
define('WP_ALLOW_MULTISITE', true );
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'yoursite.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
define('SUNRISE', 'on' );

You’ll want to remove all of that and re-save the file. To do that go to cPanel, then the File Manager icon. Now navigate to your public_html folder and find the file wp-config.php. Right-click it and select “Code Edit”. Now you’ll be able to remove the above lines, and save it.

As Joseph points out in the comments, you could change the 1st two lines here, to “false” instead of deleting them. Julie reminded me that you should remove the sunrise line for domain mapping as well. I’ve added it to the list above.

5.a Linux Hosting: Remove Multisite Rules From “.htaccess”

If you’re not sure, you’re probably using Linux/APACHE based hosting. So on that same settings page in the Network Admin, under “2.” you’ll see the Multisite info for your .htaccess file.


Do the same thing here: right click the .htaccess file in File Manager (or your FTP client) and Code Edit it. You may need to tell it to show hidden files to see it. Once you’re able to edit it, remove all that stuff in the Network Setup under “2.” and replace it with the following:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress


5.b Windows Server: Remove Multisite Rules From “web.config”

Not many people are running WordPress on Windows Server. But if you happen to be one of those who are, you won’t have an .htaccess file since that’s a Linux thing. So you’ll need to edit the web.config file. Remove everything in there and replace it with:

<?xml version="1.0" encoding="UTF-8"?>
        <rule name="Main Rule" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          <action type="Rewrite" url="index.php" />

6. Delete Multisite Tables from the Database

Lastly, you’ll want to delete the Multisite tables from the database to keep things clean. To do this, open phpMyAdmin from cPanel, and click on your Multisite’s database. Next export the database again, so you can come back to this point, if you delete something you shouldn’t.

Next remove any tables that start with “wp_#_” such as “wp_8_comments”. Any that have the number after the table prefix (normally “wp_”), are for the sub-sites that you already deleted, so you want them gone. Additionally, delete these tables that are only used by Multisite:

  • wp_blogs
  • wp_blog_versions
  • wp_registration_log
  • wp_signups
  • wp_site
  • wp_sitemeta
  • wp_sitecategories (if it exists)

As Tom points out in the comments, there may be other tables you can remove as well. Such as those for specific plugins, like the domain mapping plugin:

  • wp_domain_mapping
  • wp_domain_maping_logins

If you’re not familiar with phpMyAdmin, to delete them just check the checkbox next to each one, then select the “With selected:” drop-down menu at the bottom and click “Drop”. You’ll confirm it in the next step. I also repaired and optimized my database at this point. To do that, use the “Check All” checkbox next to that same drop-down, then click “Repair”. After that’s completed. Click the “Structure” tab at the top to get back to the top level of the database, and repeat the process, only this time select “Optimize.

7. Delete the “blogs.dir” or “sites” and “mu-plugins” Folders

Back in the File Manager, navigate to /public_html/wp-content/. There you can delete the “blogs.dir” or “sites” folder, and maybe the “mu-plugins” folders. The “blogs.dir” or “sites” (depending on when your Multisite was 1st created) contains all the files uploaded to the sub-sites. The “mu-plugins” folder is the “must use” plugins. Meaning they can’t be ignored, disabled, etc. This is common on multisite, but can still be important on a single site. So you’ll have to determine if you still need any “must use” plugins on the single-site, or not. Thanks to Surbma for reminding me of this point, in the comments.

8.  Login to the New Single-Site & Re-Activate Plugins

Now just visit http://yoursite.com/wp-admin/ and login normally with the admin user you’ve always used. It may tell you that you need to upgrade your database. Go ahead and let it do that, then you’ll get to your admin (you may have to login a 2nd time). Now activate all the plugins that are supposed to be running and check the front-end of your website to make sure everything is working fine.

Also go to Settings > Permalinks and just click the save button. No need to change anything, just click save. This can fix some issues.

The only problem I had at this point was that some plugins that required additional info, needed to be setup again. For example BruteProtect (now merged into JetPack) required an API key. For some reason it was lost in the transition. So I found the email that contained the API key for our site, pasted it into the plugin’s settings, and saved. Other than that, everything worked great.

If Something Goes Wrong

If something goes wrong, feel free to comment, but I can’t guarantee a speedy reply. You can contact me directly and I can try and give some additional direction.

SPECIAL OFFER: if you’re interested in having my team and I here at wpXPRESS manage and support your WP site for you, sign up for our Boxcar membership and mention this post. If you do that, we’ll include changing your Multisite to a single site for FREE (1 site liberated from the multisite per site you signup), as part of your new member onboarding.

Tevya Washburn