WordPress Multisite Network Recovery: Complete Restoration Guide

WordPress Multisite network crashes create exponentially more damage than single-site failures. A single database corruption event, hosting migration error, or security breach doesn't affect one website but dozens, hundreds, or even thousands of interconnected sites simultaneously. Network administrators face catastrophic scenarios where entire organizations lose their web presence overnight when shared hosting infrastructure fails. Educational institutions managing hundreds of department sites, media companies operating multiple publication properties, and agencies hosting client networks on shared multisite installations experience devastating consequences when network-level failures cascade across every connected site, destroying months or years of distributed content creation simultaneously.

WordPress Multisite recovery demands fundamentally different approaches than single-site restoration. The interconnected database structure with network-wide tables, site-specific tables, and complex relationships between blogs_id, user roles, and plugin activations creates restoration complexity far exceeding individual WordPress installations. Subdomain versus subdirectory configurations complicate URL structure preservation. Network-activated plugins require different restoration procedures than site-specific plugins. Super admin access recovery when admin credentials are lost becomes urgent as network-wide administrative control disappears completely. This comprehensive guide provides professional WordPress Multisite network recovery procedures covering architectural understanding, database reconstruction, site-specific restoration, network administration recovery, and prevention strategies for protecting complex multisite environments from catastrophic failures.

Understanding WordPress Multisite Architecture

WordPress Multisite transforms standard WordPress from single-site content management into sophisticated network infrastructure supporting thousands of interconnected sites sharing user databases, plugin installations, and theme libraries while maintaining separate content and configuration. Understanding multisite architectural complexity is essential for successful network recovery.

Multisite Database Structure Complexity

Network-wide versus site-specific tables: Standard WordPress uses wp_posts, wp_options, wp_users, and other tables storing all site data. WordPress Multisite creates this entire table set for each site in the network. The main site uses standard wp_ prefix while additional sites use wp_2_, wp_3_, wp_4_ prefixes corresponding to their blog_id numbers. A 100-site network generates over 1,100 database tables creating extraordinary restoration complexity.

Network-wide tables shared across all sites include wp_users storing all user accounts regardless of which sites they access, wp_usermeta containing user profile data and cross-site capabilities, wp_sitemeta storing network-level configuration options, wp_site containing network domain configuration, wp_blogs listing all sites in the network with their IDs, domains, and paths. These shared tables create dependencies requiring careful restoration sequencing.

Site-specific tables replicated for each site include wp_N_posts containing that site's content, wp_N_postmeta storing custom fields, wp_N_options holding site configuration, wp_N_terms and taxonomy tables managing categories and tags, wp_N_comments storing discussion data. Corrupted site-specific tables affect individual sites while network table corruption impacts the entire multisite installation simultaneously.

User role mapping across network: WordPress Multisite uses complex user role mapping where single user accounts have different capabilities on different sites. User ID 5 might have administrator privileges on site 1, editor privileges on site 3, and no access to site 7. This capability mapping stores in wp_usermeta with meta_keys like wp_capabilities for the main site, wp_2_capabilities for site 2, wp_3_capabilities for site 3, creating sprawling metadata requiring preservation during recovery.

User role corruption creates bizarre scenarios where users cannot access sites they previously administered or gain unintended access to sites outside their authorization. Recovering proper user role mapping requires understanding these meta_key naming patterns and reconstructing capabilities matching original network permissions.

Subdomain versus Subdirectory Configuration

Subdomain multisite structure: Subdomain configurations create sites like site1.example.com, site2.example.com, site3.example.com where each site uses unique subdomain. This configuration requires wildcard DNS records pointing all subdomains to the same server IP address. Recovery must preserve these subdomain mappings or users accessing site URLs encounter DNS resolution failures and connection errors.

Subdomain networks store domain information in wp_blogs table's domain column. Migrating subdomain networks to different primary domains requires updating every domain entry, changing example.com references to newdomain.com across potentially thousands of site records. Search-and-replace operations across network tables become mandatory for successful subdomain network migrations.

Subdirectory multisite configuration: Subdirectory networks create sites like example.com/site1/, example.com/site2/, example.com/site3/ where sites exist as paths under main domain. This configuration simplifies DNS management requiring only single domain but creates .htaccess or nginx rewrite complexity managing path-based routing to correct site installations.

Subdirectory network recovery must preserve .htaccess rewrite rules or nginx configuration enabling path-based site routing. Missing or corrupted rewrite rules cause all site requests to load the main network site, breaking access to every individual site in the network. Proper .htaccess restoration is critical for subdirectory network functionality.

Domain mapping additional complexity: Many multisite networks use domain mapping plugins allowing individual sites to use completely custom domains like clientsite.com instead of clientsite.example.com or example.com/clientsite/. Domain mapping creates additional database tables storing custom domain relationships and requires server configuration accepting requests for these mapped domains.

Domain mapping recovery requires restoring domain mapping tables, configuring DNS for mapped domains, and ensuring server configurations accept requests for custom domains. Without proper domain mapping restoration, sites using custom domains become completely inaccessible while their subdomain or subdirectory URLs work fine, creating confusing partial network failures.

Network Plugin and Theme Architecture

Network-activated versus site-activated plugins: WordPress Multisite supports network activation where super admins activate plugins across all sites simultaneously, and site activation where individual site administrators control plugin activation for their sites. Network-activated plugins store activation data in wp_sitemeta while site-activated plugins store activation in individual wp_N_options tables.

Recovery must distinguish between these activation levels. Restoring network activation requires wp_sitemeta table data while site-specific activation requires individual wp_N_options restoration. Mixing these during recovery creates scenarios where plugins appear activated network-wide but don't function on individual sites or vice versa.

Network-only plugins like domain mapping plugins or network administration tools require network activation to function. Attempting site-level activation of network-only plugins fails, creating restoration errors requiring troubleshooting. Understanding plugin network requirements prevents activation restoration mistakes.

Shared theme library management: All sites in multisite network share wp-content/themes directory. Individual site administrators select themes from this shared library unless theme access is restricted by network administrators. Theme availability configuration stores in wp_sitemeta's allowedthemes option controlling which themes individual sites can activate.

Recovering theme configurations requires restoring both theme files to shared directory and allowedthemes configuration enabling sites to access their themes. Missing theme files with intact configuration references creates errors across sites trying to load unavailable themes. Missing configuration with intact theme files prevents sites from activating themes even though files exist.

Assessing Multisite Network Damage

Before beginning multisite recovery, thoroughly assess damage extent determining whether issues affect entire network, specific sites, particular functionality, or administrative access. Proper damage assessment guides restoration strategy and prevents incomplete recovery attempts.

Network-Wide Failure Indicators

Complete network unavailability: When accessing any site in network including main site produces database connection errors, white screens, or HTTP 500 errors, network-wide infrastructure failure occurred. Database server crashes, corrupted network tables, or destroyed wp-config.php files cause total network failures affecting every connected site simultaneously.

Network-wide failures typically originate from hosting infrastructure problems like server crashes, database corruption, file system failures, or improper migration attempts. These catastrophic failures require complete network restoration rather than incremental site recovery.

Network admin dashboard inaccessible: Inability to access Network Admin dashboard at /wp-admin/network/ while individual sites load normally indicates network administration-specific problems. Corrupted wp_sitemeta table, missing network admin user capabilities, or plugin conflicts affecting network administration specifically create this scenario.

Network admin access loss prevents network-wide plugin activation, theme management, site creation, and user administration across the network. Restoring network admin access becomes highest priority enabling network management even if individual site issues persist.

Site-Specific Versus Network Problems

Individual site failures within functioning network: When specific sites return errors while other network sites and network dashboard function normally, site-specific table corruption occurred. Individual wp_N_posts, wp_N_options, or other site tables experienced corruption without affecting network infrastructure or other sites.

Site-specific failures enable surgical restoration focusing on affected sites without full network recovery. Export affected site's database tables from backup, restore site-specific tables, and verify site functionality while leaving functioning sites untouched. This targeted approach minimizes restoration time and reduces risk of damaging working sites during recovery attempts.

Plugin or theme conflicts affecting multiple sites: Network-activated plugins causing conflicts create simultaneous problems across all sites. Symptoms appearing identically on every site suggest network-activated plugin or theme conflicts rather than database corruption. Deactivating network plugins through database manipulation or wp-config.php constants isolates whether problems originate from plugins versus database corruption.

Add define('WPMU_PLUGIN_DIR', ''); to wp-config.php temporarily disabling mu-plugins. Set active_sitewide_plugins option in wp_sitemeta to empty array deactivating network plugins. Test if sites function with plugins disabled, confirming plugin conflicts versus deeper infrastructure corruption.

User and Permission Issues

Lost super admin access: Super admin capabilities enable network administration controlling all sites, users, plugins, and themes across the entire network. Losing super admin access through corrupted wp_users table, deleted admin accounts, or capability corruption prevents network management while sites continue functioning normally under existing configuration.

Super admin restoration requires direct database access. Identify existing admin user or create new admin account through phpMyAdmin. Add wp_capabilities meta entry with administrator role for main site. Add wp_super_admin entry to wp_usermeta table with meta_value '1'. Update wp_sitemeta site_admins option including admin username in serialized array.

Cross-site access permission corruption: Users reporting inability to access sites they previously administered or unexpected access to unauthorized sites indicates wp_usermeta corruption affecting site-specific capability assignments. Corrupted serialized capability data or incorrect meta_key naming creates permission chaos where user roles bear no relationship to intended access levels.

Restoring user capabilities from backup wp_usermeta tables provides quickest resolution. Alternatively, manually reconstruct capabilities understanding wp_N_capabilities meta_key naming corresponds to site blog_id numbers. Site with blog_id 5 uses wp_5_capabilities meta_key for user role assignments.

Network-Wide Database Restoration

Network-wide restoration addresses catastrophic failures affecting entire multisite installation requiring comprehensive database recovery, file restoration, and configuration reconstruction across all network infrastructure components.

Identifying Critical Network Tables

Essential network infrastructure tables: WordPress Multisite network functionality depends absolutely on specific network tables. The wp_site table contains network-wide configuration including network domain and path. Without intact wp_site table, WordPress cannot determine network configuration causing complete network failure.

The wp_blogs table lists all sites in network with their blog_id, site_id, domain, path, registration dates, and status. Corrupted or missing wp_blogs table makes WordPress unaware of network sites, effectively deleting every site except the main site from network perspective. Restoring wp_blogs from backup instantly restores network awareness of all sites enabling access.

The wp_sitemeta table stores network-wide options including site_admins listing super admins, allowedthemes controlling theme availability, and various network configuration options. Corrupted wp_sitemeta destroys network-level settings requiring manual reconstruction or backup restoration.

Shared user database tables: The wp_users and wp_usermeta tables store all user accounts and metadata across entire network. Unlike site-specific tables duplicated per site, user tables remain singular storing every network user regardless of site affiliations. Corrupted user tables prevent login across all network sites simultaneously creating network-wide access catastrophe.

Restoring user tables from backup immediately restores login functionality network-wide. However, user table restoration must match compatible wp_usermeta capabilities or users cannot access appropriate sites despite successful login. Restore wp_users and wp_usermeta together maintaining relationship integrity.

Database Backup Restoration Procedures

Full database restoration approach: For catastrophic corruption affecting multiple tables or unknown damage extent, full database restoration provides safest recovery path. Access phpMyAdmin or command-line mysql tools. Drop all existing database tables clearing corrupted data. Import complete database backup restoring all tables simultaneously including network tables and all site-specific tables.

Full restoration command using mysql: mysql -u username -p database_name < backup_file.sql replaces entire database with backup contents. This approach eliminates selective restoration complexity but requires accepting data loss for any content created after backup date. Balance recovery speed against potential data loss when choosing full restoration.

Selective network table restoration: When only network tables corrupted while site-specific tables remain functional, selective restoration preserves recent site content while repairing network infrastructure. Export network tables wp_site, wp_blogs, wp_sitemeta, wp_users, wp_usermeta from backup. Drop corresponding corrupted tables from live database. Import backup versions of network tables only.

Selective restoration preserves recent content in site-specific tables like wp_2_posts, wp_3_posts created after backup date while restoring corrupted network infrastructure. This approach minimizes data loss but requires careful identification of which tables need restoration versus preservation.

Handling table prefix variations: Multisite networks sometimes use custom table prefixes instead of standard wp_ prefix. Backup restoration requires matching table prefixes or search-replace operations updating prefix references. Database backup from network using wpms_ prefix cannot directly import to database expecting wp_ prefix without prefix conversion.

Use search-replace tools modifying SQL backup file before import. Replace wpms_ with wp_ throughout SQL file ensuring table names, user meta keys, and capability references use correct prefix matching new database configuration. Test prefix replacement on staging environment before production restoration.

wp-config.php Multisite Configuration

Essential multisite constants: WordPress Multisite requires specific wp-config.php constants distinguishing multisite from standard WordPress. Missing or incorrect multisite configuration prevents network functionality even with intact database. Essential constants include define('WP_ALLOW_MULTISITE', true) enabling multisite features, define('MULTISITE', true) activating multisite mode, define('SUBDOMAIN_INSTALL', true) or false specifying subdomain versus subdirectory configuration.

Additional required constants include define('DOMAIN_CURRENT_SITE', 'example.com') specifying network primary domain, define('PATH_CURRENT_SITE', '/') indicating network installation path, define('SITE_ID_CURRENT_SITE', 1) identifying network site ID, define('BLOG_ID_CURRENT_SITE', 1) specifying main site blog ID. Missing any constant creates partial network functionality or complete failures.

Sunrise.php for domain mapping: Networks using domain mapping require wp-content/sunrise.php file handling domain mapping resolution and define('SUNRISE', true) constant in wp-config.php before require_once ABSPATH . 'wp-settings.php' line. Missing sunrise configuration breaks domain mapping making custom domains inaccessible while subdomain/subdirectory URLs function normally.

Restore sunrise.php from backup or domain mapping plugin. Verify SUNRISE constant appears correctly positioned in wp-config.php. Improper sunrise placement causes errors or non-functional domain mapping requiring precise configuration placement.

Site-Specific Recovery Within Multisite Network

Individual site failures within functioning networks require targeted restoration preserving network infrastructure while repairing specific site damage. Understanding site-specific recovery procedures enables surgical site repair without network-wide restoration overhead.

Identifying Site-Specific Tables

Determining blog_id for target site: Each site in multisite network has unique blog_id determining its database table numbering. Query wp_blogs table identifying blog_id corresponding to domain or path of site requiring recovery. SELECT blog_id, domain, path FROM wp_blogs WHERE domain LIKE '%targetsite%' returns blog_id associated with specific site.

Main network site always uses blog_id 1 with standard wp_ prefix tables. Site with blog_id 5 uses wp_5_posts, wp_5_options, wp_5_postmeta and other wp_5_ prefixed tables. Knowing correct blog_id ensures targeting correct tables during site-specific restoration.

Site table set completeness: Standard WordPress site includes approximately 12 core tables: posts, postmeta, options, comments, commentmeta, terms, term_taxonomy, term_relationships, termmeta, links, and potentially additional tables from plugins. Site-specific restoration requires restoring complete table set maintaining referential integrity between related tables.

Restoring wp_5_posts without corresponding wp_5_postmeta creates scenario where posts exist but custom fields, featured images, and metadata disappear. Restore complete table sets together preventing partial recovery leaving sites functional but missing critical data components.

Exporting and Importing Site Tables

Selective table export from backup: Access backup database through phpMyAdmin or database client. Select all tables matching target site's blog_id prefix. For site with blog_id 7, select all wp_7_* tables. Export selected tables as SQL file containing only target site data without entire network database.

Selective export creates manageable restoration file containing only affected site's tables. Importing this selective backup overwrites corrupted site tables while leaving network tables and other site tables completely untouched, minimizing restoration impact and risk.

Import site tables to live database: Drop existing corrupted site-specific tables from live database. Import site table backup SQL file restoring clean versions. Verify imported tables contain expected data by querying wp_N_posts or wp_N_options confirming content presence.

After import, access target site verifying frontend loads correctly, content appears, and administrative functions work properly. Test creating new post, editing existing content, and accessing media library confirming complete site functionality restoration.

URL and Domain Configuration for Individual Sites

Site-specific URL settings in wp_N_options: Each site stores its URL configuration in its wp_N_options table with siteurl and home option names. Corrupted or incorrect URLs create redirect loops, 404 errors, or complete site inaccessibility. Query SELECT option_value FROM wp_5_options WHERE option_name IN ('siteurl', 'home') checking site URL configuration.

Incorrect URLs require manual correction through database updates. UPDATE wp_5_options SET option_value = 'https://correcturl.example.com' WHERE option_name = 'siteurl' corrects site URL. Update both siteurl and home options ensuring consistency preventing redirect loops.

Upload path configuration variations: Multisite sites store uploads in subdirectories under wp-content/uploads/sites/N/ where N matches blog_id. Site-specific upload_path and upload_url_path options in wp_N_options control upload directory locations. Incorrect upload paths prevent media library access and image display.

Verify upload configuration matches actual file system structure. Check wp-content/uploads/sites/5/ directory exists for site with blog_id 5. Update upload configuration options if mismatch exists ensuring WordPress locates site media correctly.

Network Admin and Super Admin Recovery

Super admin access loss creates critical situations where network cannot be managed despite sites functioning normally. Recovering network administrative access requires direct database manipulation understanding WordPress multisite user capability architecture.

Restoring Super Admin Capabilities

Identifying or creating admin user: Query wp_users table finding existing administrator user. SELECT ID, user_login FROM wp_users WHERE ID = 1 typically returns main admin account. If no suitable admin exists, create new user directly in database. INSERT INTO wp_users (user_login, user_pass, user_email, user_registered) VALUES ('newadmin', MD5('temporarypassword'), 'admin@example.com', NOW()) creates basic user account.

After creating user, retrieve new user's ID from wp_users for subsequent capability assignments. New user requires both site-level administrator role and network-level super admin privileges functioning as network administrator.

Site administrator role assignment: Insert wp_capabilities meta entry granting administrator role on main site. INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (1, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}') grants administrator capabilities on main site using blog_id 1 default wp_ prefix.

Administrator role on main site enables accessing standard WordPress dashboard but doesn't automatically provide network administration access. Network admin requires additional super admin assignment independent of site-level roles.

Super admin privilege elevation: Update wp_sitemeta site_admins option including target username in super admin list. First, retrieve current site_admins value: SELECT meta_value FROM wp_sitemeta WHERE meta_key = 'site_admins'. Existing value shows serialized array like a:1:{i:0;s:5:"admin";} listing current super admins.

Add username to serialized array. For single super admin named newadmin: UPDATE wp_sitemeta SET meta_value = 'a:1:{i:0;s:8:"newadmin";}' WHERE meta_key = 'site_admins'. Serialized array format critically important. String length numbers like s:8 must match username character count exactly or serialization breaks causing errors.

Network Dashboard Access Restoration

Verifying network admin capability: After granting super admin privileges through site_admins option, verify user can access /wp-admin/network/ dashboard. Login using administrator account and navigate to Network Admin. If access denied appears despite site_admins inclusion, check wp_usermeta for conflicting or missing metadata.

Some networks use wp_user_level meta entries affecting access permissions. Verify wp_user_level set to 10 for administrator users. INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (1, 'wp_user_level', '10') ensures maximum user level access.

Plugin interference with network access: Security plugins, membership plugins, or custom authentication plugins sometimes interfere with network admin access even for legitimate super admins. Temporarily deactivate all network plugins testing if access restores with plugins disabled.

Set active_sitewide_plugins option in wp_sitemeta to empty serialized array temporarily: UPDATE wp_sitemeta SET meta_value = 'a:0:{}' WHERE meta_key = 'active_sitewide_plugins'. Test network admin access with plugins disabled. If successful, reactivate plugins individually identifying problematic plugin.

Bulk User Role Management

Auditing cross-site user capabilities: Large networks with hundreds of users across dozens of sites develop complex capability assignments where individual users have different roles on multiple sites. Capability corruption creates scenarios requiring systematic audit and correction across entire user base.

Export wp_usermeta table filtering for capability meta_keys: SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE meta_key LIKE '%capabilities'. Review exported data identifying incorrect or corrupted capability assignments. Serialization errors, incorrect role names, or inappropriate privilege levels require correction.

Systematic capability restoration from backup: For widespread capability corruption, restore entire wp_usermeta table from backup. Export wp_usermeta from backup database. Drop wp_usermeta from live database. Import backup wp_usermeta restoring all user metadata including capabilities, user levels, and profile information simultaneously.

Complete wp_usermeta restoration resets all user metadata to backup state. Users who joined network or changed roles after backup date lose recent changes. Balance data currency against correction effort when choosing bulk restoration versus individual role correction.

Plugin and Theme Restoration for Networks

WordPress Multisite plugin and theme management differs fundamentally from single-site installations. Network activation, theme restrictions, and must-use plugins create unique restoration requirements beyond standard WordPress plugin recovery.

Network-Activated Plugin Recovery

Restoring plugin files to network: All plugins install in shared wp-content/plugins directory regardless of activation scope. Restore plugin directory completely from backup or reinstall plugins from WordPress repository and premium sources. Shared plugin directory serves all sites simultaneously, requiring single restoration providing plugin access network-wide.

After restoring plugin files, verify permissions allow web server reading plugin code. Set plugin directory permissions to 755 and plugin files to 644 ensuring WordPress can load plugins properly across all sites.

Network activation status restoration: Network-activated plugins store activation data in wp_sitemeta table's active_sitewide_plugins option. This serialized array contains activated plugin basenames as keys. Query SELECT meta_value FROM wp_sitemeta WHERE meta_key = 'active_sitewide_plugins' viewing current network activation status.

Restore network activations from backup by updating active_sitewide_plugins option with backup value. Alternatively, network activate plugins manually through Network Admin Plugins page after restoring network admin access. Manual activation ensures plugins activate properly and don't cause conflicts potentially present in backup activation state.

Must-use plugin restoration: Must-use plugins in wp-content/mu-plugins directory load automatically on every site regardless of activation settings. MU plugins often control critical network functionality like domain mapping, custom authentication, or network-wide customizations. Missing MU plugins can break entire network despite appearing as simple plugin issues.

Restore mu-plugins directory completely from backup including all PHP files and subdirectories. MU plugins load from main mu-plugins directory files only, not subdirectories, unless explicitly included. Verify MU plugin file placement matches original configuration ensuring proper loading.

Site-Specific Plugin Activation

Individual site plugin status: Sites can independently activate plugins from shared plugin library when plugins aren't network-activated. Site-specific activation stores in wp_N_options table's active_plugins option. Each site maintains separate activation list enabling different plugin configurations across network sites.

Restore site-specific activations by updating individual site active_plugins options. Query SELECT option_value FROM wp_5_options WHERE option_name = 'active_plugins' retrieves site 5's activated plugins. Import backup values restoring original activation states or manually activate through individual site dashboards.

Plugin dependency and network compatibility: Some plugins designed exclusively for multisite networks require network activation functioning properly. Others operate only at site level despite network-activated status. Understanding plugin network requirements prevents activation configuration mistakes during restoration.

Review plugin documentation determining proper activation scope. Domain mapping plugins, network admin enhancements, and cross-site functionality plugins typically require network activation. Content management plugins, site-specific functionality plugins, and individual site tools work at site activation level.

Theme Configuration and Restrictions

Restoring theme files and activation: Themes install in shared wp-content/themes directory serving all network sites. Restore entire themes directory from backup including parent themes, child themes, and custom theme developments. Missing theme files with active theme references create widespread errors across sites using those themes.

Individual site active theme settings store in wp_N_options with template and stylesheet option names. The template option specifies parent theme while stylesheet specifies active theme or child theme. Mismatched template and stylesheet values create theme loading errors requiring correction.

Network theme access restrictions: Super admins control which themes individual sites can activate through allowedthemes network option. This security feature prevents sites from activating potentially problematic themes while allowing controlled theme library access.

Restore allowedthemes configuration from wp_sitemeta backup or enable all themes network-wide. UPDATE wp_sitemeta SET meta_value = 'a:0:{}' WHERE meta_key = 'allowedthemes' disables theme restrictions allowing all sites to access all installed themes. Alternatively, reconstruct allowed themes list through Network Admin Themes page enabling specific themes for network use.

Domain Mapping and URL Structure Recovery

Networks using domain mapping for custom site domains require additional restoration procedures beyond standard multisite recovery. Domain mapping tables, DNS configuration, and server settings all require proper restoration enabling custom domain access.

Domain Mapping Database Restoration

Domain mapping plugin data structures: Popular domain mapping plugins like WordPress MU Domain Mapping or Mercator create custom database tables storing domain-to-site relationships. These tables typically named wp_domain_mapping or similar contain domain names, blog_id associations, and primary domain flags.

Restore domain mapping tables from backup along with network tables. Missing domain mapping table makes custom domains inaccessible while subdomain or subdirectory URLs continue functioning. Users accessing custom domains receive connection errors or DNS failures despite site existing and functioning under network URLs.

Verifying domain mapping relationships: Query domain mapping table confirming all expected domain associations exist. SELECT domain, blog_id FROM wp_domain_mapping displays mapped domains and their corresponding sites. Cross-reference with wp_blogs table ensuring blog_id values match actual network sites.

Missing or incorrect domain mapping entries require recreation. Insert new mapping records: INSERT INTO wp_domain_mapping (blog_id, domain, active) VALUES (5, 'customdomain.com', 1) creates mapping between site 5 and customdomain.com enabling custom domain access.

DNS Configuration for Mapped Domains

DNS record requirements for domain mapping: Each custom domain requires DNS A record pointing to hosting server IP address. Missing or incorrect DNS records prevent domain mapping functionality regardless of database configuration correctness. Verify all mapped domains have proper DNS records targeting hosting server.

Access DNS management for each mapped domain creating or verifying A records. Typical configuration includes A record for domain.com pointing to server IP and A record for www.domain.com pointing to same IP. Some configurations use CNAME record for www pointing to non-www version.

SSL certificate coverage for mapped domains: HTTPS-enabled sites using custom domains require SSL certificates covering those domains. Missing SSL coverage causes browser security warnings when accessing custom domains through HTTPS. Wildcard certificates covering *.example.com don't cover mapped custom domains requiring separate certificates or multi-domain certificates.

Obtain SSL certificates for all mapped domains either through individual certificates, multi-domain certificates listing all custom domains, or server-side SSL supporting multiple independent certificates. Configure web server to serve appropriate certificate for each domain enabling secure HTTPS access across all mapped sites.

Server Configuration for Domain Acceptance

Apache virtual host or server alias configuration: Apache servers require ServerAlias directives or separate VirtualHost blocks accepting requests for mapped custom domains. Without proper ServerAlias configuration, Apache rejects requests for domains not explicitly configured causing domain mapping failures.

Add ServerAlias directives to Apache configuration: ServerAlias customdomain1.com customdomain2.com customdomain3.com listing all mapped domains. For large networks with many domains, some administrators use ServerAlias * accepting all domains though this creates security considerations requiring careful evaluation.

Nginx server_name configuration: Nginx requires server_name directive listing accepted domains. Configure server_name example.com *.example.com customdomain1.com customdomain2.com; listing network primary domain, wildcard subdomains, and all custom mapped domains. Reload nginx configuration applying changes: nginx -s reload.

Verify server configuration accepts domain requests by testing DNS and server response. Tools like curl or browser developer consoles show whether servers accept and process requests for custom domains versus returning server-level errors before WordPress processes requests.

Multisite Network Migration Procedures

Migrating multisite networks to different domains, hosting providers, or directory structures requires additional procedures beyond single-site migrations. URL references throughout network database and cross-site dependencies create migration complexity requiring systematic search-replace operations.

Database Search and Replace for Networks

Network-wide URL pattern replacement: Changing network primary domain from olddomain.com to newdomain.com requires replacing domain references throughout entire database including network tables and all site-specific tables. Standard WordPress search-replace affects only site-specific tables missing critical network table references.

Use WP-CLI search-replace command with network flag: wp search-replace 'olddomain.com' 'newdomain.com' --network --all-tables processes all network tables and site tables simultaneously. This comprehensive replacement updates domain references in wp_site, wp_blogs, wp_sitemeta, and every site's wp_N_options tables maintaining network consistency.

Subdomain network domain changes: Subdomain networks using site1.olddomain.com, site2.olddomain.com URLs require replacing subdomain base domain across all site domains. This affects wp_blogs table domain column containing complete subdomain for each site.

Execute UPDATE query replacing domain portions: UPDATE wp_blogs SET domain = REPLACE(domain, '.olddomain.com', '.newdomain.com') modifies all site domains simultaneously changing site1.olddomain.com to site1.newdomain.com, site2.olddomain.com to site2.newdomain.com maintaining subdomain structure under new base domain.

Serialized data and character count adjustments: WordPress stores URLs in serialized arrays requiring special handling during replacements. Direct string replacement breaks serialization when new string length differs from original. String s:17:"olddomain.com" replacing with newdomain.com requires updating length counter to s:17:"newdomain.com" or serialization corrupts.

Search-replace tools like Better Search Replace plugin or WP-CLI search-replace automatically handle serialization updates. Avoid manual SQL REPLACE() queries on serialized data as these corrupt serialization structure causing widespread errors across network.

File Path and Upload Directory Updates

Updating file system paths in database: Networks migrating to different server directory structures require updating absolute file paths stored in database. Upload paths, plugin configurations, and cached file references contain absolute paths like /home/olduser/public_html/wp-content/uploads requiring replacement with new server paths.

Search and replace absolute paths: wp search-replace '/home/olduser/public_html' '/var/www/html' --network --all-tables updates file path references throughout database matching new server directory structure.

Site-specific upload directory migration: Multisite uploads store in wp-content/uploads/sites/N/ subdirectories where N matches blog_id. Verify uploads directories migrate correctly with proper permissions and directory structure. Missing upload directories prevent media library access and image display despite database references remaining intact.

Restore entire wp-content/uploads directory from backup including sites subdirectory and all numbered site folders. Verify directory permissions allow web server writing uploaded files: chmod 755 wp-content/uploads/sites and chmod 755 on individual site upload directories.

wp-config.php Updates for New Environment

Updating network domain constants: Multisite constants in wp-config.php specify network domain and configuration. DOMAIN_CURRENT_SITE constant must match new primary domain after migration. Update define('DOMAIN_CURRENT_SITE', 'newdomain.com') replacing old domain with new network primary domain.

PATH_CURRENT_SITE constant specifies installation path, typically '/' for root installations. Update if network migrated to subdirectory installation: define('PATH_CURRENT_SITE', '/wordpress/') for installation in /wordpress/ subdirectory.

Database connection updates: Update database connection constants DB_NAME, DB_USER, DB_PASSWORD, DB_HOST matching new hosting environment database credentials. Incorrect database credentials prevent WordPress from connecting to database causing complete network failure despite successful file migration.

Verify database host value correctly specifies new database server. Some hosts use 'localhost' while others require specific hostnames like 'mysql.example.com' or IP addresses. Incorrect DB_HOST prevents database connections even with correct credentials.

Testing and Verifying Multisite Network Recovery

After completing restoration procedures, systematic testing verifies network functionality across all sites, user access, administrative capabilities, and content delivery. Thorough testing identifies remaining issues before declaring recovery complete.

Network Infrastructure Testing

Verifying network admin functionality: Access Network Admin dashboard confirming all administrative sections load properly. Test Sites screen displaying all network sites, Users screen showing all network users, Themes interface presenting installed themes, Plugins listing available plugins. Missing sections or loading errors indicate incomplete network recovery.

Create test site through Network Admin verifying site creation functionality works. Add new user and assign to multiple sites testing user management. Network activate test plugin confirming network activation propagates across sites. These functional tests verify network administration operates correctly post-recovery.

Cross-site user access testing: Login as user with access to multiple sites. Switch between sites using site switcher in admin bar confirming cross-site access functions properly. Verify appropriate administrative capabilities on each site matching intended user roles. Test creating content on different sites ensuring user can perform assigned roles across all authorized sites.

Test user without cross-site access confirming site isolation works correctly. Users should only access authorized sites, not entire network. Proper isolation indicates user capability restoration succeeded without granting unintended access.

Individual Site Functionality Checks

Content accessibility across all sites: Visit every site in network or sample of sites for large networks verifying frontend loads properly displaying content. Check multiple pages per site including homepage, posts, pages, archives confirming content displays correctly without missing images, broken layouts, or error messages.

Test site-specific functionality like contact forms, search features, custom post types, or specialized plugins. Verify media libraries load showing uploaded images and files. Test creating new content ensuring database writes function properly and new content appears on frontend immediately.

Domain and URL consistency testing: For subdomain networks, access several sites via their subdomains confirming subdomain routing works correctly. For subdirectory networks, test subdirectory URLs ensuring proper site routing. For networks with domain mapping, verify custom domains load correct sites without redirecting to network primary domain.

Test HTTPS functionality across sites if SSL enabled. All sites should load over HTTPS without certificate warnings. Mixed SSL coverage indicates incomplete SSL configuration requiring attention.

Plugin and Theme Verification

Network plugin activation status: Review Network Admin Plugins page confirming network-activated plugins show proper activation status. Deactivate and reactivate test plugin verifying activation controls work correctly. Check plugin settings pages ensuring configurations preserved during recovery.

Test critical network plugins thoroughly. Domain mapping plugins should resolve custom domains correctly. Caching plugins should generate and serve cached content. Security plugins should enforce configured rules. Broken plugin functionality indicates incomplete plugin restoration or configuration loss.

Theme appearance across sites: Visit sites using different themes confirming each theme displays correctly with proper styling, layouts, and functionality. Check theme customizer settings persist showing configured colors, logos, widgets. Test switching themes on test site verifying theme activation works properly.

Review sites using child themes confirming parent theme and child theme relationships intact. Child theme customizations should display correctly. Missing child theme customizations while parent theme loads indicates child theme file restoration issues.

Preventing Future Multisite Network Disasters

WordPress Multisite network complexity creates numerous failure points requiring comprehensive backup strategies, monitoring, and maintenance procedures preventing catastrophic failures. Proactive prevention reduces disaster frequency and impact.

Comprehensive Backup Strategies for Networks

Network-wide database backup procedures: Standard WordPress backup plugins often overlook network tables or site-specific tables backing up only main site. Configure backups explicitly including all network tables wp_site, wp_blogs, wp_sitemeta, wp_users, wp_usermeta and all site-specific wp_N_* tables across entire network.

Use specialized multisite backup plugins like BlogVault, BackupBuddy multisite edition, or UpdraftPlus multisite with network backup functionality. These plugins understand network architecture ensuring complete backup coverage. Alternatively, use server-level database dumps backing up entire database including all tables: mysqldump -u username -p database_name > backup.sql.

Incremental backup scheduling for large networks: Large networks with hundreds of sites and massive databases cannot feasibly backup completely every few hours. Implement tiered backup strategy with daily incremental backups capturing database changes and weekly full backups including complete file and database snapshots.

Store backups off-server using cloud storage, remote servers, or backup service providers. On-server backups provide no protection against server failures, hosting account suspensions, or ransomware encrypting all server data including backups. Off-site backup storage ensures recovery capability even with complete primary server loss.

Testing backup restoration regularly: Untested backups frequently fail during actual disaster recovery due to corruption, incomplete backup coverage, or configuration mismatches. Test backup restoration quarterly by restoring to staging environment verifying complete network functionality including all sites, users, plugins, and themes.

Backup testing identifies gaps before disasters strike. Discovering network tables missing from backups during quarterly testing enables correcting backup configuration immediately. Discovering during actual disaster after data loss creates unrecoverable situations.

Network Monitoring and Maintenance

Uptime monitoring for all network sites: Implement uptime monitoring checking network primary site and sample of individual sites. Services like UptimeRobot, Pingdom, or StatusCake send alerts when sites become inaccessible enabling rapid response before users report problems.

Configure monitoring testing actual site functionality beyond simple ping tests. Check for specific content strings, working logins, or functional site elements ensuring sites truly function rather than simply returning HTTP responses. Functional monitoring detects partial failures where sites load but display errors or broken content.

Database size and performance monitoring: Multisite databases grow rapidly with hundreds of sites creating content. Monitor database size detecting unusual growth indicating spam, malware, or runaway processes. Track database query performance identifying slow queries affecting network performance.

Implement database optimization procedures including clearing spam comments, removing post revisions, optimizing database tables reducing size and improving performance. Large network databases benefit from professional database administration addressing indexing, query optimization, and structure improvements.

Security monitoring for network integrity: Install security plugins monitoring for malware, unauthorized file changes, suspicious login attempts, and security vulnerabilities. Wordfence, Sucuri, or iThemes Security provide multisite-compatible security monitoring alerting network administrators to security issues before they escalate into major compromises.

Enable login attempt limiting preventing brute force attacks across all network sites. Implement two-factor authentication for super admins and site administrators. Regular security scanning across all sites identifies malware or security issues requiring remediation.

Documentation and Access Management

Network configuration documentation: Document complete network configuration including subdomain versus subdirectory setup, primary domain, network site count, super admin accounts, network-activated plugins, domain mappings, custom configurations. Detailed documentation enables rapid recovery understanding network requirements without researching configurations during crisis.

Include wp-config.php multisite constants, DNS configurations for network domain and mapped domains, server configurations for domain acceptance, SSL certificate information, hosting provider details, database credentials stored securely. Complete documentation provides recovery roadmap during disasters.

Access credential security and redundancy: Store super admin credentials, hosting control panel access, database admin credentials, DNS management access securely using password managers like 1Password, LastPass, or Bitwarden. Multiple administrators should have access preventing single point of failure if primary administrator unavailable during disaster.

Create recovery documentation accessible to authorized administrators including backup locations, restoration procedures, emergency contacts, critical configuration details. Store documentation separately from network servers ensuring access during complete server failures requiring recovery from external information.

Conclusion: Mastering Multisite Network Recovery

WordPress Multisite network recovery requires understanding architectural complexity far exceeding single-site WordPress restoration. Interconnected database structures with network-wide tables serving all sites and site-specific tables for individual sites create restoration challenges requiring systematic approaches addressing both network infrastructure and individual site integrity.

Successful multisite recovery begins with proper damage assessment determining whether failures affect entire network, specific sites, administrative access, or particular functionality. Network-wide failures require comprehensive database restoration including critical wp_site, wp_blogs, wp_sitemeta, wp_users, and wp_usermeta tables maintaining network infrastructure. Site-specific failures enable surgical restoration targeting affected site tables without risking functioning sites or network-wide configurations.

Super admin access recovery through database manipulation enables network administration when credentials lost or capabilities corrupted. Understanding serialized capability storage, site_admins configuration, and user role architecture enables reconstructing administrative access providing network control essential for comprehensive recovery procedures.

Network plugin and theme restoration requires distinguishing between network-activated functionality affecting all sites and site-specific configurations. Domain mapping restoration reunites custom domains with their associated sites through database table restoration, DNS configuration, and server setup accepting mapped domain requests.

Network migrations require comprehensive search-replace operations updating domains and paths throughout interconnected database structures. Proper serialization handling ensures data integrity during replacement operations preventing corrupted serialized arrays creating widespread functionality failures.

Prevention through comprehensive backup strategies, regular monitoring, security implementations, and detailed documentation reduces disaster frequency and accelerates recovery when failures occur. Multisite networks represent substantial organizational investments deserving professional-grade protection through systematic maintenance and emergency preparedness.

Testing backup restoration, monitoring network health continuously, maintaining current software versions, securing administrative access, and documenting configurations creates resilient multisite infrastructure capable of weathering and recovering from disasters affecting complex interconnected WordPress installations.

WordPress Multisite network recovery is challenging but entirely manageable through understanding network architecture, following systematic restoration procedures, and maintaining comprehensive backups enabling recovery from even catastrophic network failures. The complexity inherent in multisite installations rewards careful management with powerful capabilities serving hundreds or thousands of sites from single centralized infrastructure.