How to Convert a WordPress Multisite into a Single Site

Dissolving a WordPress Multisite: Safely converting a network back into a single installation

A WordPress Multisite allows you to manage multiple websites within a single WordPress installation. This can be useful when several projects, language versions, customer websites or subpages need to be managed centrally. In some cases, however, a Multisite network later becomes too complex again: perhaps only one website is still needed, administration should be simplified or individual sites should continue as independent WordPress installations.

Dissolving a Multisite is an advanced technical process. It is not enough to simply deactivate a plugin. Multisite functions affect the WordPress configuration, server rules, database tables, upload structure, user management and, in some cases, plugin and theme settings.

Important preliminary decision: What should be retained?

Before making technical changes, you need to decide what goal you are pursuing. This decision affects the entire process.

This guide focuses on the most common case: the main site should continue running as a normal single installation. If several subsites are to be retained, you should export, migrate and test each website individually.

Why dissolving a Multisite is risky

WordPress Multisite changes several technical areas. When a Multisite is activated, additional entries in wp-config.php, special rewrite rules in .htaccess and additional database tables are used. When creating a network, WordPress describes exactly these necessary adjustments to wp-config.php and server rules.

During the rollback, these adjustments must be removed or modified in a controlled way. Mistakes can cause the website to become unreachable, images to be missing, login problems to occur or content from subsites to be lost.

Preparation: Create a complete backup

A complete backup is mandatory before any Multisite change. A file backup alone is not sufficient, because a large part of WordPress content is stored in the database.

Your backup should include:

• all WordPress files: including wp-content, themes, plugins and uploads,
• the complete database: including Multisite tables and subsite tables,
• wp-config.php: back up separately before every change,
• .htaccess: back up separately before every change,
• uploads from all sites: especially for subsites under wp-content/uploads/sites/,
• notes on domains and URLs: main domain, subdomains, subdirectories and redirects.

Do not store the backup only in the same hosting directory. Also download a copy locally or to secure external storage.

1. Document the current Multisite structure

Before removing anything, document the current state. This helps in case of errors and is especially important if subsites are still needed later.

Check in the network administration:

• Which sites exist in the network?
• Which site is the main site?
• Which domains or paths are used?
• Which themes are network-enabled?
• Which plugins are network-enabled?
• Which users have access to which sites?
• Where are the uploads of the individual sites located?

Pay particular attention to the IDs of the individual sites. In Multisite installations, subsites often have their own database tables such as wp_2_posts, wp_3_posts or similar prefixes.

2. Do not accidentally lose subsites

An important warning: content from subsites is not automatically stored in the normal tables of the main site. The main site often uses tables such as wp_posts and wp_options. Subsites, on the other hand, use their own tables, for example wp_2_posts, wp_2_options or wp_3_posts.

If you convert the Multisite back into a single installation, normally only the main site remains directly usable. Content from subsites must be exported beforehand or migrated into separate installations.

3. Check network-enabled plugins

In Multisite networks, plugins can be activated network-wide. After converting back to a single installation, these plugins must again be available and activatable normally in the main installation.

Before the rollback, check:

• Which plugins are active network-wide?
• Which plugins are needed on the main site?
• Which plugins are used only by subsites?
• Are there any Multisite-specific plugins?
• Are there domain mapping, role or network plugins?
• Are there security or cache plugins with Multisite configuration?

After the rollback, you should check important plugins individually and reactivate or configure them again if necessary.

4. Back up wp-config.php and remove Multisite constants

Connect to your hosting account via FTP, SFTP or the cPanel File Manager. In the root directory of your WordPress installation, open the wp-config.php file.

First save the file under a name such as wp-config-backup-multisite.php. Then remove the Multisite constants. Typical entries look like this, for example:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'your-domain.ch' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

This line was also often used to activate network setup:

define( 'WP_ALLOW_MULTISITE', true );

You can remove this line or set it to false:

define( 'WP_ALLOW_MULTISITE', false );

It is important that you do not accidentally delete other important settings, such as database access data, security keys, table prefix, debug settings or memory limits.

5. Reset .htaccess rules to a single installation

With Apache or LiteSpeed setups, WordPress often uses the .htaccess file for permalinks and rewrite rules. Multisite networks use special rules that can vary depending on the subdomain or subdirectory structure.

First back up the existing .htaccess separately. You can then replace the Multisite rules with the standard rules of a single installation.

# 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]
</IfModule>
# END WordPress

If your WordPress installation is not located in the root directory but in a subfolder, RewriteBase and paths must be adjusted accordingly. With Nginx setups, rewrite rules are not controlled via .htaccess, but via the server configuration.

6. Save permalinks again

After adjusting wp-config.php and .htaccess, you should log in to the WordPress dashboard again. Then open:

Settings > Permalinks

Click Save Changes there without necessarily changing anything. This causes WordPress to rewrite the permalink rules. This can fix many 404 issues after technical changes.

Then check:

• home page,
• pages,
• posts,
• categories,
• media URLs,
• login and dashboard,
• contact forms.

7. Clean up database tables only after checking

A Multisite uses additional network tables. Common Multisite tables include, for example:

• wp_blogs
• wp_blogmeta
• wp_blog_versions
• wp_registration_log
• wp_signups
• wp_site
• wp_sitemeta

There are also tables for subsites, for example wp_2_posts, wp_2_options, wp_3_posts and others. These contain the content of the respective subsites.

Do not delete tables immediately. Proceed safely:

1. Export the database completely.
2. Check the table prefix, for example wp_ or a custom prefix.
3. Identify main site tables.
4. Identify subsite tables.
5. Check whether content from subsites is still needed.
6. Only remove unnecessary network tables after successful testing.

8. Check upload paths and images

In Multisite installations, media can be located in different directories depending on the site. The main site often uses the normal upload path wp-content/uploads/. Subsites often use paths such as:

wp-content/uploads/sites/2/
wp-content/uploads/sites/3/

If you keep only the main site, its media normally remains available. If you migrate content from subsites, their media must also be transferred correctly and paths adjusted.

After the rollback, check:

• Are featured images visible?
• Do images work in pages and posts?
• Are PDF files and downloads accessible?
• Do image URLs still point to old Multisite paths?
• Are media files from subsites missing?

9. Check user roles and administrator rights

Multisite distinguishes between network administrators and site administrators. After converting back to a single installation, you should check which users still exist and which permissions they have.

Check:

• Is the correct administrator still present?
• Do former network administrators have appropriate roles?
• Are there unnecessary user accounts?
• Are editors, authors and staff correctly assigned?
• Are strong passwords set?
• Should two-factor authentication be enabled?

Especially after network changes, it is worth cleaning up user management.

10. Activate plugins and themes after the rollback

After removing the Multisite function, network-enabled plugins may appear differently or need to be checked again. Go to Plugins and check the status.

Check:

• Are important plugins active?
• Are there Multisite-specific plugins that are no longer needed?
• Do security, cache and SEO plugins work?
• Is the active theme correct?
• Are there theme settings that came from the network administration?
• Do licenses need to be reactivated?

Remove plugins that were only needed for Multisite functions only after a successful functional test.

11. Check domain mapping and redirects

Many Multisite networks use subdomains, subdirectories or domain mapping. When dissolving the network, these domains and redirects must be checked cleanly.

Typical cases:

• site1.example.ch
• example.ch/site1/
• customer-domain.ch mapped to a network site

If these domains are no longer used, DNS, redirects, SSL certificates and cPanel domain assignments should be cleaned up. If content is retained, appropriate 301 redirects must be set up.

12. SEO risks when dissolving a Multisite

If Multisite subsites were publicly indexed, dissolving the network can have significant SEO effects. Search engines may know URLs from the main site and the subsites. If these URLs suddenly disappear, 404 errors occur.

Therefore check:

• Which network sites were publicly accessible?
• Which URLs are indexed by Google?
• Which pages have backlinks?
• Which content should remain accessible?
• Which old URLs need 301 redirects?
• Which sitemaps need to be removed or updated?

After the changeover, you should check Google Search Console and monitor 404 errors.

13. Final check after the changeover

Once the Multisite configuration has been removed, you should test the website systematically. The My Sites menu item or the network administration should have disappeared.

Then check:

• Does login work?
• Is the dashboard normally accessible?
• Do pages and posts work?
• Are images visible in the media library?
• Do permalinks work?
• Do contact forms work?
• Are plugins active?
• Is the theme correct?
• Do menus and widgets work?
• Are there 404 errors?
• Does SSL work?
• Is the website displayed correctly on mobile?

Then clear all caches: WordPress cache, plugin cache, server cache, CDN cache and browser cache.

14. When professional support makes sense

A simple Multisite with only one main site can be converted back relatively cleanly with experience. Complex networks, however, should be migrated professionally.

Technical support is especially useful if:

• several subsites should be retained,
• domain mapping was used,
• WooCommerce shops are affected,
• member areas or user portals exist,
• multilingual websites are part of the network,
• many media paths need to be adjusted,
• SEO rankings should be retained,
• you are unsure about database tables.

Common mistakes when dissolving a Multisite

• No complete backup: errors cannot be cleanly undone.
• Subsite tables deleted: content from other sites is lost.
• Uploads not checked: images from subsites are missing after the migration.
• .htaccess replaced incorrectly: website or subsites return 404 errors.
• wp-config.php damaged: website is no longer reachable.
• Plugins not checked: network-enabled plugins are missing or behave differently.
• No redirects: old URLs lose visitors and SEO signals.
• Domain mapping ignored: external domains point nowhere.

Recommended procedure

1. Define the goal: keep only the main site or migrate subsites separately?
2. Create a complete backup: files, database, wp-config.php, .htaccess and uploads.
3. Document the network: record sites, domains, tables, plugins, themes and users.
4. Export subsites: if content is to be retained.
5. Back up and adjust wp-config.php: remove or deactivate Multisite constants.
6. Back up and replace .htaccess: use standard rules for a single installation.
7. Save permalinks again: under Settings > Permalinks.
8. Test the website: check frontend, backend, media, plugins, menus and forms.
9. Clean up the database later: remove unneeded tables only after successful testing.
10. Check SEO and redirects: review old URLs, sitemaps and Search Console.

Frequently asked questions about dissolving a WordPress Multisite

Can I simply deactivate a WordPress Multisite?

Not like a normal plugin. Multisite uses settings in wp-config.php, server rules, database tables and special upload structures. The rollback must be carried out carefully.

Will my subsites be retained?

Not automatically as normal single installations. Subsites have their own tables and upload directories. If they are to continue existing, they must be exported or migrated separately.

Which files do I need to edit?

Typically wp-config.php and, with Apache or LiteSpeed setups, .htaccess. With Nginx, server rules may be located elsewhere.

Which database tables can I delete?

Only after a complete backup and successful testing. Network tables such as wp_blogs, wp_site or wp_sitemeta can later become unnecessary, but subsite tables must not be deleted if their content is still needed.

Why are images missing after the rollback?

Media from subsites is often located under wp-content/uploads/sites/ID/. If content from subsites was migrated, media paths must also be transferred or adjusted correctly.

What should I do about 404 errors?

First save the permalinks again under Settings > Permalinks. Then check .htaccess, cache, redirects and old Multisite URLs.

Is dissolving a Multisite bad for SEO?

It can be problematic if URLs disappear or no redirects are set up. With proper planning, 301 redirects and sitemap updates, the risk can be reduced.

Should I carry out the rollback myself?

Only if you are confident working with files, databases and WordPress configuration. For several subsites, domain mapping or important rankings, professional support is recommended.

More helpful articles:

• What is phpMyAdmin and how do I use it?
• Insert and optimise WordPress images
• Manage files in the cPanel File Manager