August 13, 2026
11 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
Managing dozens of separate WordPress installations creates an unsustainable maintenance burden for agencies and legal-tech platforms. This WordPress Multisite Setup and Migration Guide provides the exact configuration steps, server prerequisites, and safety checks required to consolidate sites into a single network in 2026. Before touching production files, review my notes on hiring a WordPress developer in Nepal or assessing whether your current hosting infrastructure can actually support a network architecture without performance degradation.
Quick answer: The WordPress Multisite Setup and Migration Guide requires adding
define('WP_ALLOW_MULTISITE', true); to wp-config.php, running the Network Setup wizard, then configuring DNS and web server rewrites for subdomain or subdirectory routing. Always backup databases first and test on staging before migrating live production sites.How do you configure WordPress Multisite Setup and Migration Guide prerequisites?
Multisite is not a plugin; it is a core architectural mode that changes how WordPress handles database tables, file uploads, and URL routing. Before enabling it, your server environment must meet specific criteria that differ from standard single-site WordPress hosting. In my experience maintaining legal-tech portals and directory networks, skipping these prerequisites is the primary cause of post-migration failures.
Server and software requirements
As of 2026, WordPress 6.7+ requires PHP 8.2 or higher for optimal security and performance within a Multisite network. While PHP 8.1 may technically function, it no longer receives active support and introduces unnecessary risk for business-critical systems. Your database layer should be MySQL 8.0/8.4 LTS or MariaDB 10.11+. PostgreSQL is not natively supported for Multisite without significant custom workarounds that I cannot recommend for production use.
- PHP Memory Limit: Minimum 256M, preferably 512M. Each site in the network consumes additional memory during admin operations and plugin initialization.
- Max Execution Time: Set to at least 300 seconds. Network activation of plugins and bulk updates frequently timeout at default 30-second limits.
- Upload Max Filesize: Match your largest expected media upload plus overhead. 64M is a practical minimum for networks handling document uploads.
- Wildcard DNS (Subdomain only): If using subdomain routing, you must configure a wildcard A record (
*.yourdomain.com) pointing to your server IP before installation. Without this, new subsites will return 404 errors immediately after creation. - SSL Certificates: For subdomain networks, obtain a wildcard SSL certificate via Let's Encrypt or your provider. Individual certificates per subsite are operationally unfeasible beyond five or six sites.
Backup and staging verification
Never enable Multisite directly on a live production database. Create a complete dump of your existing site(s) using mysqldump or WP-CLI, deploy to an isolated staging environment, and validate the conversion there first. On client projects involving legal service directories or multi-location businesses, I have seen data corruption occur when administrators skipped this step during peak traffic periods. The cost of recovery far exceeds the time invested in proper staging validation.
Should you choose subdomain or subdirectory routing for WordPress Multisite?
This decision is irreversible after installation without complex database manipulation and SEO risk. Choose based on your actual operational needs, not aesthetic preference. For Nepal-based legal-tech platforms where each practice area or district office needs distinct branding but shared resources, subdirectories often simplify SSL management and DNS overhead. Subdomains suit truly independent brands sharing backend infrastructure.
| Criteria | Subdirectory (/site-name/) | Subdomain (site.domain.com) |
|---|---|---|
| DNS Configuration | No additional DNS records needed | Requires wildcard A record + wildcard SSL |
| SEO Treatment | Inherits root domain authority more directly | Treated as separate entities by search engines |
| SSL Complexity | Single certificate covers all paths | Wildcard cert mandatory for HTTPS |
| Cookie Sharing | Shared authentication cookies by default | Cross-domain cookie issues possible |
| Use Case Fit | Regional offices, language variants, product lines | Distinct brands, franchise locations, white-label clients |
| Migration Difficulty | Easier to convert existing single sites | Requires full DNS propagation planning |
In practice, I default to subdirectory routing unless the client explicitly requires brand separation. The operational savings on certificate renewal, DNS troubleshooting, and cross-site authentication issues compound significantly over years of maintenance. For detailed cost implications of different architectures, see my breakdown of website development costs in Nepal, which factors in long-term Multisite overhead versus individual installations.
How do you execute the WordPress Multisite Setup and Migration Guide installation?
The installation process modifies core configuration files and database structure. Follow these steps precisely on your staging environment first. Deviating from this sequence or attempting shortcuts has caused failed conversions on multiple projects I have debugged.
Step 1: Enable Multisite in wp-config.php
Add the following constant above the "That's all, stop editing!" comment line:
<?php
/* Enable Multisite */
define( 'WP_ALLOW_MULTISITE', true );
/* That's all, stop editing! Happy publishing. */Save the file and reload your WordPress admin. Navigate to Tools → Network Setup. You will now see the option to configure your network.
Step 2: Configure network settings
Select your routing type (subdomain or subdirectory). Enter the network title and administrator email. Click "Install." WordPress will generate two code blocks that must be added to your configuration files exactly as shown. Do not modify these values unless you understand the implications.
Step 3: Update wp-config.php with network constants
Add the generated constants to wp-config.php, typically including:
<?php
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); // true for subdomain, false for subdirectory
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );Step 4: Update .htaccess or Nginx configuration
For Apache servers, replace your existing rewrite rules with the block WordPress provides. For Nginx—which I prefer for production Multisite deployments due to superior performance under load—add the appropriate location blocks. Here is a tested Nginx configuration for subdirectory Multisite on Ubuntu 24.04 with PHP 8.4-FPM:
server {
listen 443 ssl http2;
server_name example.com;
root /var/www/example.com/current/public;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
# Multisite subdirectory rewrite rules
if (!-e $request_filename) {
rewrite ^/(wp-(content|admin|includes).*) /$1 last;
rewrite ^/(.*\.php)$ /$1 last;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~* /files/(.+) {
try_files /wp-content/blogs.dir/$blogid/files/$1 /wp-includes/ms-files.php?file=$1;
expires max;
log_not_found off;
}
}After updating configuration, restart PHP-FPM and Nginx. Verify that both the main site and newly created subsites load correctly before proceeding. If you encounter 404 errors on subsite admin pages, check that your permalink structure is set to Post Name and flush rewrite rules via WP-CLI: wp rewrite flush --network.
How do you safely migrate existing sites into a WordPress Multisite network?
Migrating standalone WordPress installations into an established Multisite network is where most practitioners encounter serious problems. The database schema differs fundamentally: Multisite uses numbered table prefixes (wp_2_posts, wp_3_options) rather than a single wp_ prefix. Direct SQL imports without transformation will corrupt your network.
Recommended migration workflow
- Audit source site: Document active plugins, theme, custom post types, and media library size. Deactivate caching and security plugins before export.
- Create destination subsite: Establish the new site within your network first. Note its assigned blog ID from the Sites list.
- Export content via WP-CLI: Use
wp export --dir=/tmp/exporton the source site for XML content. For media, copy the uploads directory preserving year/month structure. - Import with namespace awareness: Use WP-CLI's import command targeting the specific subsite:
wp site create --slug=newsitefollowed bywp import /tmp/export/file.xml --authors=create --url=example.com/newsite/. - Migrate users carefully: Multisite shares user tables across the network. Map existing users by email address rather than creating duplicates. Assign appropriate roles per subsite.
- Search-replace URLs: Run
wp search-replace 'old-domain.com' 'example.com/newsite' --all-tables --precise --dry-runfirst. Review output, then execute without dry-run flag. - Validate thoroughly: Check internal links, media attachments, custom fields, and serialized data. Test forms, payment integrations, and any third-party API connections.
For complex migrations involving WooCommerce stores or custom legal-tech portals with document management systems, I strongly recommend using dedicated migration tools like WP Migrate DB Pro or Duplicator Pro rather than manual exports. These handle serialized data replacement correctly—a common failure point when moving between single-site and Multisite schemas. If your project involves significant technical debt or legacy customizations, consider whether a migration to Laravel might offer better long-term maintainability than forcing incompatible architectures into Multisite.
Post-migration optimization
After successful migration, implement network-wide object caching using Redis 7.x. Configure persistent object cache drop-ins to reduce database queries across subsites. Monitor slow query logs for the first two weeks; migrated sites often reveal indexing gaps that were tolerable on isolated installations but become bottlenecks under shared resource contention. For deeper performance tuning strategies applicable to high-traffic networks, review my guide on caching strategies for web performance.
What are the ongoing maintenance considerations for WordPress Multisite networks?
Operating a Multisite network introduces administrative complexity that single-site WordPress does not present. Understanding these trade-offs prevents costly surprises months after deployment. Based on maintaining networks ranging from three to forty-plus subsites for Nepali businesses and international clients, these patterns recur consistently.
Plugin and theme management
Plugins activate either network-wide or per-site. Network activation simplifies management but increases attack surface and memory consumption. Audit every plugin for Multisite compatibility before network activation; many popular plugins assume single-site contexts and fail silently or cause conflicts. Maintain a documented allowlist of approved plugins. For custom functionality needed across multiple subsites, develop as a mu-plugin (must-use plugin) in /wp-content/mu-plugins/ to ensure consistent loading without activation dependencies.
Database growth and cleanup
Each subsite adds tables. A network with 30 sites generates 300+ tables in a single database. Implement automated cleanup for deleted sites: orphaned tables persist indefinitely unless explicitly removed. Schedule monthly reviews of inactive sites and establish decommissioning procedures. For large networks exceeding 50 sites, consider database sharding or external object caching to prevent query performance degradation. Regular optimization of wp_options autoloaded data across all subsites prevents cumulative slowdowns that manifest only under concurrent load.
Security and access control
Super Admin privileges grant unrestricted access to every subsite. Limit this role to one or two trusted operators. Use role management plugins to create custom network-level roles for content managers who need multi-site editing without full administrative access. Monitor login attempts across the entire network centrally; brute-force attacks against one subsite consume resources affecting all others. Implement rate limiting at the Nginx level rather than relying solely on application-layer security plugins.
Implementing WordPress Multisite Setup and Migration Guide for Production Success
Successful Multisite deployment depends on methodical preparation, correct routing selection, and disciplined migration practices. This WordPress Multisite Setup and Migration Guide covers the technical foundation, but real-world outcomes depend on understanding your specific operational constraints and growth trajectory. If you are evaluating whether Multisite fits your Nepal-based business or need hands-on assistance with migration, contact me to discuss your architecture before committing to a path that may be difficult to reverse.
Frequently Asked Questions
WordPress Multisite allows managing multiple websites from a single WordPress installation, sharing plugins, themes, and users. Use it for networks of similar sites like regional branches or franchise locations. Avoid it if sites require completely different server configurations or have unrelated security compliance needs.
Add define('WP_ALLOW_MULTISITE', true); to wp-config.php above the "That's all" line. Then visit Tools > Network Setup in the dashboard to configure subdomain or subdirectory structure. After configuration, add the generated code snippets to both wp-config.php and .htaccess exactly as instructed, then re-login to access network admin.
Subdirectories (example.com/site1) inherit domain authority immediately and are generally better for SEO when launching new content sites under one brand. Subdomains (site1.example.com) function as separate entities in search engines, requiring individual authority building. Choose subdirectories unless you need distinct branding or technical isolation per site. In my experience with Nepal-based business networks, subdirectories simplify local SEO targeting significantly.
Yes, but backup everything first. Enable WP_ALLOW_MULTISITE in wp-config.php, run Network Setup, then add the provided constants and rewrite rules. Existing content becomes the main site. Note that some plugins may not be multisite-compatible and will need replacement or reconfiguration. Test thoroughly on staging before converting production environments, especially for eCommerce sites running WooCommerce where order data integrity is critical.
Basic multisite setup on existing hosting costs Rs 15,000–25,000 (~USD 110–185). Full migration of multiple standalone sites into a network ranges Rs 40,000–80,000 (~USD 300–600) depending on site count, content complexity, and plugin compatibility issues. Ongoing maintenance typically runs Rs 5,000–10,000/month (~USD 37–75). Pricing varies based on whether sites need custom theme adaptation or database restructuring during consolidation.
Plugin incompatibility is the most frequent issue; many plugins aren't network-aware and break individual site functionality. Media upload paths can misconfigure, causing broken images. Permalink structures often need flushing via Network Admin > Settings. SSL certificates must cover all subdomains if using that structure. File permissions on wp-content/uploads/sites/ frequently cause upload failures on Linux servers. Always verify these areas immediately after activation.
Multisite introduces shared risk: one compromised plugin or theme affects the entire network. However, centralized updates make patching faster. Security depends on strict plugin vetting, network-only activation of trusted security tools, and regular audits. I recommend limiting super-admin accounts, enforcing strong passwords, and using fail2ban on the server. For legal-tech portals handling sensitive client documents, I've implemented additional file-access restrictions at the Nginx level to isolate tenant data beyond WordPress defaults.
Export content via Tools > Export on the source site. Create a new site in Network Admin, then import the XML file. Manually migrate media files to wp-content/uploads/sites/{ID}/, update attachment URLs in the database using WP-CLI search-replace, and reassign featured images. Migrate widget settings and customizer options separately. This process is tedious; for production migrations involving WooCommerce orders or custom post types, I use serialized-data-safe migration scripts rather than relying solely on the built-in exporter.
WP-CLI is indispensable for bulk operations across sites. User Role Editor manages permissions network-wide. Blog Copier or NS Cloner duplicates site templates efficiently. WP Multi Network handles domain mapping for complex setups. For performance, Redis Object Cache Pro works network-wide when configured correctly. Avoid activating heavy plugins network-wide unless necessary; activate per-site instead. On client projects, I've found that keeping the network-level plugin list minimal prevents cascading failures during updates.
It works but requires careful planning. Each store needs its own product catalog, payment gateway credentials, and shipping zones. Plugins like WooCommerce Multistore or custom code handle shared inventory scenarios. Performance degrades with many active stores due to shared database tables. For more than five high-traffic stores, consider separate installations. On a Nepal grocery delivery project, we used multisite successfully for three regional storefronts sharing core products but maintaining distinct delivery zones and local payment methods like eSewa and Khalti.
All sites share PHP-FPM workers, database connections, and memory. Traffic spikes on one site impact others. Database queries slow as wp_posts and wp_options grow across hundreds of sites. Implement object caching with Redis 7.x, use Nginx fastcgi_cache for static pages, and monitor with New Relic or similar. On Ubuntu servers, I configure separate PHP-FPM pools for high-traffic multisite networks to prevent resource starvation. Budget hosting rarely supports production multisite adequately; plan for dedicated VPS or managed WordPress hosting.
Yes. Themes and plugins can be activated individually per site through their respective dashboards. Network activation makes them available everywhere but doesn't force activation. This flexibility lets you maintain brand consistency on some sites while allowing customization elsewhere. However, excessive unique plugins increase maintenance burden and security surface. I typically standardize on a base theme with child-theme variations per site, reducing update overhead while preserving visual distinction where clients need it.
Wildcard SSL certificates (*.example.com) cover unlimited subdomains and are required for subdomain multisite. Let's Encrypt supports wildcards via DNS validation with Certbot. Subdirectory multisite uses standard single-domain certificates. Ensure your web server config includes the wildcard cert for all virtual hosts. On Ubuntu with Apache, I configure this in the main vhost rather than per-site. Certificate renewal automation via cron is mandatory; expired SSL on one subdomain breaks trust signals across the network.
The entire network fails because all sites share the same database, PHP processes, and file system. There is no automatic failover within multisite itself. Mitigate risk with redundant hosting, automated backups stored off-server, and health monitoring that alerts before complete failure. Database replication helps but adds complexity. In practice, I treat multisite as a single point of failure architecturally and ensure disaster recovery plans account for full-network restoration, not just individual sites.
Avoid multisite when sites serve different businesses with separate compliance requirements, need independent server scaling, or use incompatible plugin stacks. Don't use it just to manage multiple client sites; separate installs with management tools like MainWP are safer. High-traffic eCommerce stores often perform better independently. If you anticipate selling individual sites later, multisite complicates separation significantly. I've seen agencies regret consolidating unrelated client sites into one network when ownership transfers became legally and technically messy.
