How to Move a Site from WordPress Multisite to Single Install

At some point, many site owners outgrow a shared network environment and need to extract one site from a WordPress Multisite installation into its own standalone instance. Whether you are restructuring hosting, handing off a project to another team, or simplifying maintenance, understanding how to safely move from a network to a single install is essential.

Reasons to Separate a Site from a Multisite Network

Before you begin, it helps to understand why this migration is worth the effort and what to expect from the process.

Performance and resource isolation: A busy site can consume more server resources than other subsites. Moving it to its own installation helps isolate performance issues.
Independent updates and maintenance: In a network, core, theme, and plugin updates are shared. A standalone setup allows you to manage versions and deployments separately.
Simplified access and management: Clients or internal teams may not need access to the entire network, only to one site. A single install gives them a cleaner, narrower admin experience.
Hosting changes and migrations: Sometimes only one subsite needs to move to a new server, data center, or provider, leaving the rest of the network untouched.
Security and compliance: Regulatory or organizational requirements may demand data separation between business units or projects.

Whatever your motivation, the key is to handle the migration methodically so that content, media, URLs, and SEO signals remain intact.

Understanding the Multisite Structure

A WordPress Multisite network stores each site’s data in a way that looks unified at first glance but is actually segmented by database tables and paths. Understanding this structure makes the move to a single installation much smoother.

How subsites are stored in the database

In a typical network database, you will see:

Global tables: These include tables like wp_users and wp_usermeta that are shared across all sites in the network.
Site-specific tables: Each subsite has its own set of tables, usually following the pattern wp_<blog_id>_posts, wp_<blog_id>_postmeta, wp_<blog_id>_options, and so on.

If you are moving subsite ID 3, for example, that site’s content will live in tables like wp_3_posts, wp_3_postmeta, wp_3_terms, and wp_3_options. Part of this migration involves converting those tables into the standard single-site equivalents: wp_posts, wp_postmeta, wp_terms, etc.

How URLs and media paths are handled

Depending on your configuration, subsites may use one of two patterns:

Subdirectories: example.com/site1/
Subdomains: site1.example.com

Media uploads are typically stored under wp-content/uploads/sites/<blog_id>/ or wp-content/uploads/<year>/<month>, depending on the network age and configuration. During the migration, you must align these paths with the standard uploads structure for a standalone install and update any embedded URLs in your content.

Planning the Migration

A successful move from Multisite to a single install starts with careful preparation. Rushing this step leads to broken media, missing users, and damaged SEO.

Clarify what needs to move

Determine the scope of the migration in advance:

Post types and taxonomies: Are you moving only posts and pages, or also custom post types, taxonomies, and custom fields?
Media library: Do you need all historical media, or can you archive old assets?
Users and roles: Will user accounts be recreated manually, or do you need to preserve logins, roles, and passwords?
SEO data: Are there SEO plugins whose metadata must be preserved (titles, descriptions, redirects, schema, sitemaps)?

Choose your destination environment

Decide where the new single installation will live:

Same server vs. new server: Staying on the same server simplifies file transfers. Moving to a different host may offer performance or support advantages.
Temporary staging domain: It is often best to migrate to a staging domain or subdomain, validate everything, then switch the production DNS later.
PHP and database versions: Ensure the destination environment’s versions are compatible with the current WordPress core, themes, and plugins.

Full backups and version control

Before making any changes, create comprehensive backups:

Database backup: Export the entire Multisite database so you can roll back if needed.
File backup: Archive wp-content, including themes, plugins, and uploads.
Configuration backup: Copy your wp-config.php and .htaccess (or Nginx config) files for reference.

If you use version control for custom themes or plugins, ensure your repository is up to date before proceeding with the migration.

Step 1: Identify the Subsite and Its Data

The first technical step is to identify the site you want to extract and map its data to the corresponding tables and paths.

Find the site’s blog ID

Inside the network admin, navigate to the list of sites. Each entry has a unique ID that appears in the browser’s address bar when editing that site’s settings. This ID determines the table prefix used for that subsite.

For example, if the site has ID 5, its tables will typically be named with wp_5_ prefixes. If a custom table prefix is used in your installation, the pattern will be similar but with your custom prefix instead of wp_.

List the required tables

For the subsite you are moving, you will need at minimum:

wp_X_posts
wp_X_postmeta
wp_X_terms
wp_X_term_taxonomy
wp_X_term_relationships
wp_X_options
wp_X_comments and wp_X_commentmeta (if comments are in use)

You may also have additional subsite-specific tables created by plugins, which need to be considered if their data is critical.

Step 2: Set Up the New Single Installation

Next, prepare a clean, single WordPress installation that will receive the data from the network.

Create a fresh WordPress instance

On your destination environment, perform a standard WordPress install:

Upload the latest WordPress core files.
Create a new, empty database and user with appropriate privileges.
Run the WordPress installation wizard and complete the initial setup.

Use the domain or temporary URL that will eventually host the standalone site. You can adjust the URL later if you are using a temporary domain during migration.

Match themes and plugins

To avoid compatibility issues, ensure the new installation has the same theme and plugins as the subsite you are extracting:

Copy the active theme folder from the network’s wp-content/themes directory to the same path on the new installation.
Copy any must-use plugins and regular plugins that the subsite depends on.
Install or update any premium themes or plugins from their official sources when necessary.

Do not activate everything yet. You will activate the theme and plugins once the data has been imported.

Step 3: Export the Subsite’s Database Tables

With the new site ready, you can export the relevant tables from the Multisite database.

Export via database tools

Using a tool such as phpMyAdmin, Adminer, or the command line, export only the subsite’s tables. This keeps the migration focused and avoids clutter in the target database.

Select all tables prefixed with wp_X_, where X is your site’s ID.
Export them as SQL, ensuring you include both structure and data.

If your database is large, you may want to export in smaller chunks or use the command line with compression to manage file sizes efficiently.

Adjust the table names in the SQL file

In the exported SQL file, the table names will still use the subsite prefix. For the standalone installation, you need them to match the default table names (or the new table prefix you configured).

This typically involves a search-and-replace:

Replace wp_X_posts with wp_posts.
Replace wp_X_postmeta with wp_postmeta.
Repeat for each relevant table: options, terms, term_taxonomy, term_relationships, comments, and commentmeta.

If your single installation uses a custom prefix (e.g., wp_single_), adjust the replacements accordingly. Be careful not to replace references anywhere in the data where prefixes might appear in serialized values without verifying them.

Step 4: Import the Data into the Single Site

With your SQL file prepared, it is time to import the subsite data into the standalone database.

Ensure the destination database is clean

On a brand-new WordPress install, the default tables will already exist with some initial data. You have two options:

Drop the default content: Delete posts, pages, and other demo content from the new site before import.
Drop the tables: If you prefer, drop the existing tables and allow the import to recreate them entirely, as long as your SQL includes the table structure.

Dropping and recreating tables is cleaner but requires careful attention if any additional plugins or data were installed after the initial setup.

Run the import

Use your preferred database tool to import the modified SQL file into the destination database. After the import completes, you should see the familiar set of WordPress tables containing the content and settings from the original subsite.

Update the site URL and home URL

In the options table of the new database, confirm that:

siteurl is set to the standalone site’s URL.
home matches the public URL visitors will use.

If necessary, update these values to reflect the new domain or path. This ensures WordPress generates correct URLs for internal links and assets.

Step 5: Move the Media Library

Content without media looks broken and unprofessional. The next step is to migrate your Media Library and fix any path differences.

Copy the uploads directory

On the original server, locate the uploads directory that belongs to the subsite. In many Multisite setups, this will be under:

wp-content/uploads/sites/<blog_id>/ for newer installs.
wp-content/blogs.dir/<blog_id>/files/ for older installs.

Copy all the relevant folders and files into the uploads directory of the single install, usually wp-content/uploads/. Preserve the year/month structure to keep references intact.

Update media URLs in content

If the media URLs in your posts and pages still reference the original network domain or path, you must update them to the new standalone URL. This includes:

Image src attributes within posts and pages.
Background images and other media embedded via shortcodes or page builders.

Use a search-and-replace tool at the database level that safely handles serialized data to replace the old uploads URL with the new one. Take care to test thoroughly, as broken replacements can corrupt serialized values used by themes and plugins.

Step 6: Handle Users and Roles

In a Multisite environment, users are shared across the network, but their roles and capabilities are stored per site. When moving to a single installation, you need to decide how to recreate or import these users.

Import users directly from the network database

One approach is to copy the relevant user rows from the global users and usermeta tables into the single install. This preserves passwords and login credentials but requires careful mapping to avoid conflicts.

Identify all users assigned to the subsite in the original network.
Export their rows from wp_users and the associated rows from wp_usermeta.
Import them into the standalone installation’s users and usermeta tables, adjusting prefixes as needed.

Be cautious about duplicate user IDs or usernames if the destination site is not entirely fresh.

Recreate users manually or via plugins

If the number of users is small, or you want to start clean, you can recreate accounts manually in the new site’s admin. Alternatively, use a user migration plugin that supports exports from Multisite networks and imports into standalone WordPress installations.

After migrating or recreating accounts, ensure each user has the correct role and capabilities, especially for editors, authors, and administrators.

Step 7: Fix URLs, Internal Links, and Permalinks

Once the content, media, and users are in place, you must clean up URLs and link structures to align with the new environment and preserve SEO value.

Search-and-replace the domain and path

Within the standalone database, search for references to the old domain or subdirectory and update them to the new URL. This includes:

Links inside post content.
Custom fields, widget settings, and theme options.
Shortcodes that include hardcoded URLs.

Use a tool designed for WordPress databases that can handle serialized values safely, and make a backup before making large-scale replacements.

Update permalinks and flush rewrite rules

In the new site’s admin, visit the permalink settings page and save changes, even if you keep the same structure. This rebuilds rewrite rules to match the new environment and ensures your URLs resolve correctly.

If you were using a specific permalink structure on the subsite, replicate it in the standalone installation to avoid unnecessary URL changes.

Step 8: Preserve SEO and Redirects

A migration from a Multisite network to a single installation can have a significant impact on organic traffic if not handled carefully. Preserving SEO involves minimizing URL changes and managing redirects properly.

Maintain URL parity wherever possible

The ideal scenario is that visitors and search engines see the same URLs before and after the migration, only with the underlying infrastructure changed. If you are keeping the same domain and path, this is straightforward as long as permalinks are consistent.

If the domain or structure is changing, document the old and new URL patterns to set up systematic redirects.

Set up 301 redirects for changed URLs

When URLs change, permanent 301 redirects help search engines and users find the new destination while transferring as much link equity as possible. Implement redirects at the server level or via a robust redirect management plugin.

Map old subdomain or subdirectory URLs to the new standalone domain.
Handle edge cases for attachment pages, archives, and custom post types.
Preserve query parameters where necessary.

After setting up redirects, test them in batches to confirm they behave as expected and do not create redirect loops.

Reconfigure SEO plugins and sitemaps

If the original subsite used an SEO plugin for meta tags, sitemaps, or schema, ensure the same configuration is applied in the new environment:

Install and activate the same SEO plugin in the standalone site.
Import or manually replicate key settings, including title templates and meta descriptions.