Every so often we need to work on a WordPress website that has a complicated history. One recent project involved a WordPress Multisite installation that only contained a single active website. At some point in its life, the platform had hosted multiple sites, but over time those sites had been retired, leaving behind a network configuration that was no longer serving a purpose. The challenge was to simplify the platform without losing any content, functionality, SEO value or historical data.
Why Simplify?
WordPress Multisite is an excellent solution when you genuinely need to manage multiple websites from a single installation. Schools, franchises, membership organisations and multi-location businesses often benefit from it. However, if a network eventually shrinks down to a single site, Multisite can introduce unnecessary complexity:
- Additional administration overhead
- More complicated plugin management
- Additional database structures
- More complex backups and migrations
- Increased troubleshooting complexity
In this case, the goal was to return the website to a standard single-site WordPress installation.
Understanding the Existing Platform
Before making any changes, we performed a full audit of the site structure. Although only one website remained active, the database still contained evidence of numerous historical sites that had existed within the network over the years. The challenge wasn’t simply removing the Multisite configuration. It was identifying:
- Which data belonged to the active website
- Which data belonged to retired sites
- Which plugin tables were still required
- Which records could safely be removed
This is the kind of work that can’t be rushed. Making assumptions in a WordPress database can quickly lead to lost content or broken functionality.
Creating a Safe Testing Environment
Rather than making changes directly on the live website, the entire platform was replicated onto a staging server. This allowed us to:
- Test the conversion process safely
- Verify plugin compatibility
- Validate database changes
- Confirm that media, forms and integrations continued to function correctly
Staging environments are one of the most valuable tools in modern website development. They allow significant structural changes to be tested without introducing risk to the live site.
Converting the Site
The conversion process involved:
- Removing Multisite-specific configuration settings
- Replacing Multisite rewrite rules
- Rebuilding plugin registrations
- Verifying permalink structures
- Testing all front-end and back-end functionality
Note that your plugins will probably require reactivation from when the network configuration was removed. For us, the plugin settings remained intact, but the activation state needed to be refreshed. Because this was identified during staging, the process for the live deployment became straightforward and predictable.
Cleaning Up Years of Historical Data
The database audit revealed remnants of numerous retired websites that had existed within the network. These were no longer active websites, but many had left behind plugin-specific tables containing historical data. After verifying that no active sites depended on these records, the unused tables were removed, reducing database complexity and leaving behind a much cleaner platform.
The Result
The final outcome was:
- A standard WordPress installation
- Simplified administration
- Cleaner database structure
- Easier future migrations
- Reduced maintenance overhead
- No loss of content or functionality
Most importantly, the website owners now have a platform that is easier to maintain and easier to grow.
Why This Matters
One of the biggest misconceptions about web development is that success comes from building ever more complex systems. In reality, good development often means reducing complexity.
A simpler platform is usually:
- Easier to maintain
- Easier to secure
- Easier to back up
- Easier to migrate
- Easier to troubleshoot
Sometimes the most valuable technical work isn’t adding features. It’s carefully removing complexity while preserving everything that matters. If your WordPress site has evolved over many years, inherited multiple developers, or contains legacy infrastructure that nobody fully understands anymore, a technical audit can often uncover opportunities to simplify, improve performance and reduce long-term maintenance costs.
Technical Notes for Developers
For WordPress developers researching a similar migration, the actual conversion process was surprisingly straightforward. The difficult part was understanding the history of the installation and identifying which data was still relevant.
1. Create a Staging Environment
Clone the entire site to a staging server before making any changes.
This should include:
- Database
- Themes
- Plugins
- Media uploads
- Configuration files
Never attempt this conversion on a live site first.
2. Verify Only One Active Site Exists
Check the Multisite network tables and confirm that only the root site remains active. If additional sites still exist within the network, stop and plan a proper migration strategy before proceeding.
3. Remove Multisite Configuration
In wp-config.php, remove the Multisite configuration block:
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
You may also remove:
define('WP_ALLOW_MULTISITE', true);
4. Replace Multisite Rewrite Rules
Replace the existing Multisite rules in .htaccess with standard WordPress rules:
# 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
5. Clear Cookies and Log Back In
Delete browser cookies for the site and log back into WordPress. This avoids authentication and redirect issues caused by old Multisite session data.
6. Reactivate Plugins
In our case, plugin settings remained intact but plugin activation states did not. After conversion we reactivated all required plugins and verified that:
- Forms worked correctly
- SMTP and email delivery worked
- Redirects functioned correctly
- Maps loaded correctly
- Security plugins initialised correctly
7. Rebuild Permalinks
Navigate to:
Settings → Permalinks
Then click:
Save Changes
without altering any settings.
8. Verify Site Functionality
Before removing any database tables, test:
- Homepage
- Internal pages
- Media uploads
- Forms
- Email delivery
- Plugin functionality
- SEO settings
Confirm that My Sites and Network Admin no longer appear.
9. Remove Multisite Infrastructure
Once the site is confirmed working as a standard WordPress installation, remove any remaining Multisite infrastructure tables.
Typical examples include:
wp_blogs wp_blogmeta wp_site wp_sitemeta wp_signups wp_registration_log
10. Remove Orphaned Subsite Tables
Many Multisite installations accumulate historical plugin tables from retired sites. Before removing these tables, verify that no corresponding site tables still exist and that the site itself has been removed from the network. Only then should the orphaned plugin tables be deleted.
11. Final Validation
Once the cleanup is complete, verify:
- Website functionality
- Plugin functionality
- Media uploads
- Form submissions
- Email delivery
- Redirects
- SEO configuration
The final result should be a standard WordPress installation with all unnecessary Multisite infrastructure removed.
Technical takeaway: Converting a WordPress Multisite back to a standard WordPress installation is often the easy part. The real challenge is understanding the site’s history, identifying what still matters, and removing years of accumulated complexity without affecting the live website.