How to Set Up WordPress Multisite Without Breaking Your Hosting

Whether your host supports WordPress Multisite comes down to two things: whether the web server will answer on the hostnames or paths the network needs, and whether you can reach the database and filesystem to configure it. Almost every modern host running Apache, Nginx, or LiteSpeed with PHP and MySQL or MariaDB can run a network, but the wordpress multisite hosting requirements that actually trip people up are the ones written down nowhere: wildcard DNS, wildcard TLS, and a server config that passes arbitrary subdomains to one PHP entry point. Check those three before you install anything.

Multisite is not a plugin. It is a mode the WordPress core enters when wp-config.php defines MULTISITE and the network tables exist in the database. The core then routes every request through index.php and resolves the site from the request host or path. That resolution is the whole game. If the server never delivers the request to index.php, nothing else matters.

What WordPress multisite hosting requirements actually mean at the server layer

Start with the rewrite. In subdirectory mode, every site lives under one domain, so the existing rewrite rules mostly work. In subdomain mode, the network must accept anything.example.com and send it to the same document root. Apache needs a ServerAlias or a wildcard vhost. Nginx needs a server_name with a wildcard and a catch all block.

server {
    listen 443 ssl;
    server_name example.com *.example.com;
    root /var/www/example.com;
    index index.php;
    location / { try_files $uri $uri/ /index.php?$args; }
}

The wildcard in server_name only matches one label deep, so a.example.com matches and a.b.example.com does not. If you plan to nest subdomains, you need a separate rule. On Apache, confirm the vhost is not the default catch all, because the first matching vhost wins and a stray default will swallow the subdomain before WordPress ever sees it.

Then check DNS. A wildcard A record, written as *.example.com, points every unlisted subdomain at the same address. Verify it resolves before you blame WordPress.

dig +short test.example.com A
# expect the same address as example.com

If that returns nothing, the network will still create sites in the database, but visitors will get a DNS failure. Fix DNS first. Everything downstream depends on it.

Configuring the network so subdomains or subdirectories resolve

Enable the network from wp-config.php before you run the installer. Add the constant above the line that says the absolute path, and give the network a base path or domain.

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Set SUBDOMAIN_INSTALL to false for subdirectory mode. You cannot switch between the two after the fact without rebuilding the network, so decide now. Subdirectory mode is easier to serve because it needs no wildcard DNS and no wildcard certificate. Subdomain mode is cleaner for sites that must look independent, and it is the mode that forces you to solve TLS.

TLS is the requirement people forget. A certificate that covers only example.com produces a browser warning on every subdomain. You need a wildcard certificate, or a certificate that lists each hostname, or a proxy that terminates TLS and issues per host certificates. On a host where you cannot install a certificate, subdomain mode is not viable no matter how good the PHP is.

The database needs the network tables. The installer creates wp_site, wp_blogs, wp_blogmeta, wp_sitemeta, and wp_registration_log. If you clone a single site into a network, those tables must exist and the wp_blogs and wp_site rows must match the domain you serve. A mismatch between the stored domain and the requested host is the most common cause of a redirect loop.

Diagnosing the errors you will actually see

A redirect loop usually means the stored site domain does not match the host the browser sent. Check the Host header the server received and compare it to the domain column in wp_blogs. The two must agree exactly, including any www prefix.

A 404 on every subdomain means the wildcard vhost is not matched, or the rewrite is not reaching index.php. Test the rewrite directly with curl and look at the status line.

curl -sI https://test.example.com/ | head -n 1
# HTTP/2 200

If that returns a redirect to the main domain, the subdomain is being resolved but WordPress is rejecting the host. If it returns a connection error, DNS or the vhost is wrong. If it returns the main site content, the wildcard is working but the network lookup is failing.

Cookie problems are the next layer. Multisite sets cookies scoped to the network domain. A reverse proxy that rewrites the host, or a CDN that strips it, will break login for every site at once. Confirm the proxy passes the original Host header through unchanged.

Object caching deserves a mention because it changes behavior. A persistent object cache shared across the network is fine, but the cache key must include the site ID, or one site will serve another site's data. Most well written cache backends handle this, but verify it after you enable the network rather than before.

What to check before you commit

Ask your host three concrete questions. Can I point a wildcard DNS record at this account? Can I serve a wildcard certificate, or add hostnames individually? Does the server pass unknown subdomains to my document root with the original host header intact? If the answer to any of those is no, subdomain mode is off the table and you should build the network in subdirectory mode instead.

Once you have the answers, set up a staging copy of the site, enable the network there, and create one test site. Watch the server access log while you load it. The log tells you instantly whether the request arrived, which vhost answered, and what status came back. Only after the test site loads cleanly should you enable the network in production.