WordPress Multisite runs many websites from one WordPress installation: one codebase, one database (with per-site tables), shared plugins and themes, and a network admin who manages everything. Universities, agencies, franchises and publishers use it to run dozens or hundreds of similar sites.

Should you use Multisite?

Good fit:

  • Many sites sharing the same theme and plugins (e.g. regional or departmental sites).
  • Central control: you update plugins once for all sites.
  • Users who need access to several sites with one login.

Poor fit:

  • Unrelated client sites — one bad plugin or a security issue affects all sites, and moving a site out of a network later is work.
  • Sites needing different plugin versions or PHP settings.
  • Sites with different owners who need full admin rights.

For separate client sites, several normal WordPress installs (one per site, with isolated PHP-FPM pools) is usually better — see hosting multiple websites.

Subdirectories or subdomains?

  • Subdirectories: example.com/shop/, example.com/blog/. Simple DNS and SSL.
  • Subdomains: shop.example.com, blog.example.com. Needs wildcard DNS and a wildcard certificate.

Either type can additionally map custom domains (shop-brand.com) to individual sites.

You choose once, at setup. Subdirectory networks aren’t available on installs older than a month with existing content (to avoid URL clashes) without extra work.

1. Enable Multisite

Start with a working WordPress install (see installing WordPress with Nginx). Deactivate all plugins, then add to wp-config.php:

define( 'WP_ALLOW_MULTISITE', true );

Go to Tools → Network Setup, choose subdomains or subdirectories, and install. WordPress then shows lines to add to wp-config.php, similar to:

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 );

It also shows Apache .htaccess rules — on Nginx, use the config below instead. Log in again afterwards.

With WP-CLI, convert an existing install in one step:

sudo -u www-data wp core multisite-convert --title="My Network"            # subdirectories
sudo -u www-data wp core multisite-convert --title="My Network" --subdomains

2. Nginx configuration

Subdirectory network

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com;
    index index.php;

    # Rewrite /site/wp-admin, /site/wp-includes etc. to the real files
    if (!-e $request_filename) {
        rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
        rewrite ^(/[^/]+)?(/wp-.*) $2 last;
        rewrite ^(/[^/]+)?(/.*\.php) $2 last;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Subdomain network

server {
    listen 80;
    server_name example.com *.example.com;
    root /var/www/example.com;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Plus a wildcard DNS record: *.example.com A 203.0.113.10.

Reload Nginx after changes. Uploads for each site live in wp-content/uploads/sites/<id>/.

3. SSL

  • Subdirectories: a normal certificate for example.com.
  • Subdomains: a wildcard certificate for *.example.com via the DNS-01 challenge — see wildcard certificates with Certbot.
  • Mapped custom domains: each domain needs its own certificate (Certbot --nginx -d shop-brand.com), or use a reverse proxy that issues certificates on demand (Caddy).

4. Map custom domains

Since WordPress 4.5, domain mapping is built in:

  1. Point the domain’s DNS to the server.
  2. Add it to Nginx’s server_name (or a dedicated server block) and issue a certificate.
  3. Network Admin → Sites → Edit the site, set Site Address (URL) to https://shop-brand.com.

Add define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); to wp-config.php if logins fail on mapped domains. See Multisite domain mapping.

5. Managing the network

  • Network-activate plugins that every site needs; let site admins activate others individually (Network Admin → Settings → “Enable administration menus → Plugins”).
  • Themes must be network-enabled before sites can use them.
  • Upload limits per site: Network Admin → Settings.
  • WP-CLI targets a site with --url: wp --url=shop.example.com plugin list; loop over wp site list --field=url for network-wide tasks.
  • Cron runs per site — see WordPress real cron for the multisite loop.

Performance

All sites share PHP workers, database and cache. Use a persistent object cache (Redis, with one prefix for the network — see Redis object cache) and page caching. Large networks benefit from more RAM and a tuned database.

A multisite network concentrates many sites on one server — a WordPress VPS with enough RAM keeps them all fast, and you can move to a larger plan as the network grows.

  • WordPress
  • Multisite
  • Nginx