The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →There are two different ways to turn a WordPress Multisite setup into a standalone site. To split out one subsite while keeping the network running, create a fresh single-site installation, import that subsite’s WXR export, copy its media, and repair URLs and custom data. To end Multisite altogether, first migrate every subsite you need, then remove the network configuration and tables while preserving the original main site.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Back up both the files and database before either operation. Keep the source untouched until the new site has passed content, login, media, permalink, form, redirect, and plugin tests.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Choose the conversion you actually need
The procedure depends on the scope of the change. Extracting one site is a migration into a new WordPress installation. Reverting the network changes the existing installation back to single-site mode and retains its original main site.
| Decision point | Extract one subsite | Revert the whole network |
|---|---|---|
| Scope | One subsite becomes a separate installation; other network sites remain online. | The existing installation stops being a network and keeps the original main site. |
| What transfers automatically | Posts, pages, comments, taxonomies and other WXR-exportable content. | The main site’s existing database and files remain in place after network configuration is removed. |
| What needs separate attention | Media files, themes, plugins, custom tables, plugin settings, URLs and users. | Every subsite that must survive, network tables, configuration constants, rewrite rules and any domain mapping. |
| Operational risk | Moderate: a new site must be assembled and validated, but the network can remain as a rollback copy. | High: configuration and database changes affect the live installation; deleting a subsite or table is irreversible without a backup. |
| URL change | Usually yes, unless the subsite already uses the same mapped top-level domain. | Usually no for the main site, although old network paths, mapped domains and rewrite rules still require testing. |
| Downtime and rollback | Cutover can be scheduled after validation; the original subsite remains available until DNS or routing is changed. | Use a maintenance window and retain a complete pre-change copy so the network can be restored if the single-site conversion fails. |
| When outside help is justified | When plugins store important data outside normal WordPress content tables or the site has complex domain mapping. | When several subsites, custom tables or unfamiliar database/configuration work must be handled at once. |
Prepare a rollback before touching the network
Do not begin by deleting a site, changing wp-config.php, or editing SQL. Build a recovery point first.
- Take a database dump and a complete copy of the WordPress files, including
wp-content/uploads, themes, plugins and any server-level rewrite configuration. - Store the backup outside the web root and verify that it can be downloaded or restored. A backup that has never been tested is not a reliable rollback.
- Record the network URL, the target subsite URL, the subsite ID, the database table prefix, mapped domains, active themes and plugins, and the PHP/web-server environment.
- List forms, membership features, stores, search indexes, scheduled jobs and integrations that may keep data in plugin-owned tables.
- Pause content changes during the export and final cutover. New comments, orders, form submissions or edits made after the export will not appear in the standalone copy unless you migrate them again.
- Keep the original network online and unchanged until the destination has been checked on a staging URL or hosts-file entry.
Path A: extract one subsite into a standalone installation
Learn WordPress describes this as possible but requiring manual steps. The WordPress Exporter gives you portable content, not a complete clone of every plugin and file.
1. Back up the network and identify the subsite
Complete the rollback preparation above. In Network Admin, note the subsite’s numeric ID and whether it is configured as a subdomain, subdirectory or mapped top-level domain. The ID is needed to find its media directory and to distinguish its tables from those of other sites.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall2. Export the subsite as WXR
- Log in to the subsite’s own dashboard, not Network Admin.
- Open Tools > Export.
- Choose All content unless you have a documented reason to export only a content type, then download the WordPress eXtended RSS (WXR) file.
- Keep the original XML file with the backup and note the time at which it was generated.
The WXR file contains WordPress content and references to attachments, but it does not reproduce the entire network environment. It will not automatically recreate every plugin’s custom table, setting, license state, scheduled task or external integration.
3. Build a clean single-site WordPress installation
Install standalone WordPress in a new directory, virtual host or server account. Use a new database or a separately prefixed set of tables so the source network remains untouched. Set the final site URL provisionally if you are testing on staging.
Create the users that should own imported content before importing. You can create matching usernames and email addresses, or plan to map each exported author to an existing account during import. Give administrative access only to the people who need it.
4. Install the required theme and plugins
Install the same active theme and the plugins that provide the subsite’s functionality. Configure them only enough for the importer and initial tests; do not assume that copying plugin files copies their data. Record versions and settings from the source so you can reproduce forms, custom post types, shortcodes, widgets and rewrite rules.
5. Import the WXR file and map authors
- In the new dashboard, open Tools > Import.
- Install or activate the WordPress Importer when prompted.
- Upload the WXR file.
- When the importer asks how to handle authors, map each author to an existing user or create the required users.
- Enable attachment downloading if the source URLs are reachable, but do not treat that option as a substitute for copying the media directory manually.
- Wait for the import to finish and save the completion report.
Check representative posts, pages, comments, categories, tags, custom post types and menus immediately after import. An apparently successful import can still omit content generated by a plugin.
6. Copy the subsite’s media files
Multisite stores a subsite’s uploads under wp-content/uploads/sites/{subsite ID}. Copy the contents of that directory into the standalone site’s normal wp-content/uploads directory while preserving the year/month folders and filenames. Copy rather than move until validation is complete.
Make sure the web server user can read the files and that the destination permissions match the rest of the standalone installation. Open images, downloadable files, PDF links and media embedded in older posts; a successful file copy does not guarantee that the database points to the new paths.
7. Recreate custom data instead of assuming WXR is a full migration
Inspect every active plugin for tables or records outside the normal WordPress content tables. Examples include form entries, directory listings, event registrations, memberships, search indexes and bespoke settings. Export or copy that data using the plugin’s documented migration method, then verify that the standalone plugin version can read it.
Do not copy an entire network database over the new site simply to obtain one plugin’s tables. That can overwrite the destination’s users, options and site identity. If the data is business-critical and no supported export exists, have someone experienced with MySQL and WordPress table relationships extract only the required tables after a backup.
8. Replace URLs without corrupting serialized data
After the files and content are in place, update references from the old subdomain or subdirectory to the standalone URL. Use a serialization-aware tool, such as WP-CLI’s search-replace, or a migration plugin that explicitly preserves serialized PHP arrays and objects. A plain SQL replacement can change string lengths without updating the stored length value, breaking widgets, theme options and other settings.
Run a dry run first, then perform the replacement across the destination tables. A typical WP-CLI sequence is:
wp search-replace 'https://old.example.com/subsite' 'https://new.example.com' --all-tables-with-prefix --skip-columns=guid --dry-runReview the dry-run report, then run the same command without --dry-run. Adjust the old and new values for a subdirectory path, HTTP-to-HTTPS change or alternate hostname. Include custom tables when they contain serialized URLs, but do not alter columns that are not meant to hold site URLs.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesIf the subsite already uses a mapped top-level domain and the standalone site will keep exactly that domain, a global replacement may be unnecessary. Still inspect the options and content for network paths, staging URLs and hard-coded asset links.
9. Set the site identity and test before cutover
Check the destination’s home and siteurl values, then visit Settings > Permalinks and click Save Changes once the final URL is active. This regenerates rewrite rules for the standalone installation.
- Open the front page, several old and new posts, archives, search results and pagination.
- Load images and downloads from old content and newly uploaded media.
- Sign in and out with each important role; test password resets and any membership or customer account flow.
- Submit every form and confirm that entries arrive in the intended destination.
- Check menus, widgets, shortcodes, blocks, custom post types, feeds, XML sitemaps and scheduled jobs.
- Test redirects from the former subsite URL and decide whether old links should redirect, remain available or return a deliberate 404.
- Inspect browser developer tools and server logs for mixed-content errors, missing assets, redirect loops and 404 responses.
Only after these checks should you change DNS, reverse-proxy routing or web-server configuration. Leave the source subsite intact until traffic and data have been observed on the standalone site.
Path B: revert the entire network to single-site mode
This path keeps the original main site and changes the existing installation. It is not a shortcut for extracting one subsite.
Rank #3
1. Migrate every subsite that must survive
Export or independently migrate each subsite you need before changing network configuration. Deleting a subsite removes its content and tables and cannot be undone without a backup. If a subsite is being abandoned, archive its export and files anyway so you can answer later requests for records or media.
2. Take a second backup immediately before the change
Use a fresh database dump and file copy after the final subsite export. Label this copy with the change date and keep it separate from the earlier working backup. This is the point to which you will restore if the main site fails after the configuration edit.
3. Remove the active Multisite constants
Edit wp-config.php and remove every constant that defines the network. A typical configuration contains entries like these, although the exact set varies by installation:
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 );Remove the network-specific block generated when Multisite was enabled, not unrelated database credentials or security settings. If your installation has additional network constants, remove those as well. The official Learn WordPress guidance is direct: to revert to a single site, first remove all Multisite-related constants from wp-config.php.
4. Regenerate single-site rewrite rules
Log in through the normal single-site /wp-admin/ path when it becomes available. Open Settings > Permalinks and click Save Changes without necessarily changing the selected structure. WordPress then regenerates the original single-site .htaccess behavior. If the dashboard is not reachable, restore the pre-network rewrite file from your backup and correct server rules before making database changes.
5. Remove the network-only tables only after the main site works
After the main site loads and you have confirmed the backup, remove the Multisite-only tables using your database tool. With the default wp_ prefix, the tables are:
wp_blogmetawp_blogswp_registration_logwp_signupswp_sitewp_site_meta
Your prefix may not be wp_; substitute the actual prefix consistently. Confirm the table names in the database before issuing a drop command. Do not remove per-subsite content tables until all required migrations and retention decisions are complete. Keep the pre-change database so the dropped network tables can be restored if needed.
6. Validate the resulting single site
- Use the ordinary
/wp-admin/login and confirm that the expected administrators can sign in. - Check the front end, media library, uploads, menus, widgets, comments and search.
- Open representative old URLs and confirm that permalink rules and redirects behave as intended.
- Submit forms and exercise plugin features that write data.
- Review scheduled tasks, cron jobs, caching, security rules and external integrations.
- Check the server and PHP logs for database errors, missing tables, redirect loops and permission failures.
URL, database and domain cautions
Never use a blind SQL URL replacement
WordPress stores URLs inside serialized options, widgets and theme settings. Replacing text with a generic SQL command can leave serialized lengths wrong and make those values unreadable. Use WP-CLI search-replace, a serialization-aware plugin or a purpose-built replacement script. Test on a copy, review the dry-run result and include the destination’s custom tables only when you know they contain site URLs.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Leave wp_posts.guid values alone
The guid column identifies a post for feeds and synchronization; it is not the setting that controls the address visitors use. Do not rewrite it merely to change the site URL. The WP-CLI example above excludes that column. Update actual site settings, content links and rewrite rules instead.
Review the URL-bearing options
Check home and siteurl in the destination database and inspect fileupload_url where that option exists. Search custom rewrite rules, plugin settings, CSS, JavaScript and email templates for the old hostname or network path. A mapped-domain subsite may have fewer replacements because visitors already see a top-level domain, but internal references can still point to the network address.
Handle mapped-domain cookies carefully
WordPress supports mapping both subdomain and subdirectory subsites to a non-network top-level domain. If the standalone site repeatedly logs users out or sends them back to the login screen after mapping, the WordPress handbook documents this possible configuration:
define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );Use it only when the cookie scope is the cause and test across the exact hostname, HTTPS scheme and proxy setup. A cookie change will not fix an incorrect URL, mixed content or a redirect loop.
Common failure symptoms and targeted fixes
Posts imported but images are missing
Confirm that the contents of wp-content/uploads/sites/{subsite ID} were copied into the standalone uploads directory, with year/month folders intact. Check file permissions, then run a serialization-aware URL replacement for attachment URLs. Review a post’s source HTML to determine whether the problem is a missing file, an old hostname or a blocked remote download.
The front page works but inner URLs return 404
Save the permalink settings on the destination, verify that the web server allows the WordPress rewrite rules, and remove old network-specific rewrite directives. Test both pretty permalinks and direct query-string URLs to separate a rewrite problem from missing content.
Users are trapped in a login loop
Confirm that home, siteurl, HTTPS termination and cookie scope all use the same public hostname. Clear old browser cookies, inspect redirects, and consider the documented COOKIE_DOMAIN setting only after the URL values and proxy headers are correct.
A plugin appears active but its data is gone
WXR does not export arbitrary plugin tables. Identify the plugin’s tables and settings in the source, use its supported export/import process if available, and restore or migrate only the required data. Do not overwrite the destination database with the whole network dump.
Recommended Free Tools
Authors changed or content is owned by the wrong account
Repeat the import on a clean destination or correct authorship through the importer’s mapping option and WordPress’s user tools. Create the intended users before importing so the mapping is explicit rather than relying on automatic name matching.
The main site fails after the network is disabled
Stop further edits, restore the pre-change files and database, and bring the network back online. Compare the failing request, PHP error and database error with the backup before attempting another conversion. A rollback copy is safer than trying to reconstruct deleted network tables manually.
When a migration tool or professional help is worth the cost
A manual extraction is reasonable when the subsite uses standard WordPress content, ordinary media and well-documented plugins. Consider a paid migration tool or an experienced WordPress professional when plugins create custom tables or opaque serialized data, when many subsites must be separated, when mapped domains and redirects are business-critical, or when there is no tested restore process.
Commercial tools and services change their Multisite compatibility, supported WordPress versions and pricing. Verify those details for your exact environment before purchasing, and still keep an independent database and file backup. A tool can automate copying; it cannot decide which custom records, users, redirects or legal-retention requirements your site needs.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Final go/no-go check
- The source files and database have been backed up and the restore path is understood.
- Every subsite that must survive has a WXR export or a validated standalone copy.
- Required themes, plugins, users, media and custom data exist on the destination.
- URL replacement was performed with serialization awareness and excluded
wp_posts.guid. - Permalinks, login cookies, forms, media, redirects and plugin features pass tests.
- The original network remains available until production traffic and new submissions are confirmed on the standalone site, or the whole-network rollback window has closed.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
