WordPress Multisite Hosting Requirements: What You Need Before You Start

Overview

WordPress multisite is a feature built into WordPress core that lets you run a network of sites from one installation. Instead of managing separate WordPress installs for each site, you manage them all from a single dashboard. It’s commonly used by agencies managing client sites, universities running department sites, and media publishers running regional editions.

The network can operate in one of two modes: subdomain (e.g. site1.yourdomain.com) or subdirectory (e.g. yourdomain.com/site1). Which mode you choose affects DNS, server configuration, and whether your host supports it at all. Most hosting-related issues with multisite come down to the environment not being configured correctly before the network is activated.

If you’ve already enabled multisite and something’s broken, skip to the troubleshooting section. If you’re planning a new network, read this front to back — the prerequisites matter more here than in almost any other WordPress setup.

Prerequisites

• WordPress 5.0 or later installed (multisite has been stable since 3.x, but don’t run anything older than 5.x in 2026)
• Root or sudo access to the server, or a hosting plan that allows .htaccess and wp-config.php editing
• PHP 8.1 or later — PHP 8.0 reached end-of-life in November 2023
• MySQL 8.0+ or MariaDB 10.6+
• Apache with mod_rewrite enabled, or Nginx with a correctly configured server block
• If using subdomain mode: wildcard DNS set up for your domain (e.g. *.yourdomain.com pointing to your server IP)
• If on shared hosting: confirm your host permits multisite — many shared plans block it
• SSL certificate that covers your domain (wildcard SSL recommended for subdomain networks)
• No existing multisite plugins already active that might conflict during setup

Hosting Environment Requirements

Shared Hosting

Multisite technically works on shared hosting, but with real limitations. Subdomain mode almost always requires wildcard DNS, which most shared hosts won’t configure for you. Subdirectory mode is more manageable on shared, but you’re still at the mercy of PHP memory limits and .htaccess restrictions.

If you’re on a shared plan and want to run more than two or three subsites with any real traffic, you’ll hit resource walls fast. I’d recommend looking at our Managed WordPress Hosting plans instead — they’re purpose-built for this kind of setup and include the server-level configuration multisite needs without you having to touch a config file.

VPS and Dedicated Servers

These are the natural fit for multisite networks, especially if you’re managing sites for multiple clients or running high-traffic subsites. You have full control over PHP settings, Nginx/Apache config, and DNS. Host & Tech VPS plans give you that control from day one.

Required PHP Settings

These are the minimum recommended values. Set them in your php.ini, a .user.ini in your webroot, or through your control panel’s PHP configuration:

memory_limit = 256M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 3000

📝 Note: max_input_vars is one people miss. WordPress multisite admin pages pass a lot of form fields simultaneously, and the default value of 1000 causes silent failures on plugin and settings pages in the network admin.

Step-by-Step: Enabling WordPress Multisite

Step 1 — Allow multisite in wp-config.php

Open /var/www/html/wp-config.php (or wherever your WordPress root lives) and add the following line above the line that reads /* That's all, stop editing! */:

define( 'WP_ALLOW_MULTISITE', true );

⚠ Warning: Do not add this below the stop-editing line. WordPress won’t read it there, and you’ll spend time wondering why the menu option isn’t appearing.

Step 2 — Run the network setup wizard

1. Log into your WordPress admin panel.
2. Go to Tools > Network Setup. If you don’t see this menu item, the constant in Step 1 wasn’t saved correctly.
3. Choose either Sub-domains or Sub-directories.
4. Enter a network title and confirm the admin email address.
5. Click Install.

📝 Note: If WordPress detects that your install already has posts, it will disable subdirectory mode as an option. This is a known limitation — subdirectory multisite can only be activated on a fresh install or one with no published posts. Subdomain mode doesn’t have this restriction.

Step 3 — Update wp-config.php with network constants

After clicking Install, WordPress gives you two blocks of code to add. The first goes in wp-config.php above the stop-editing line:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); /* true for subdomain, false for subdirectory */
define( 'DOMAIN_CURRENT_SITE', 'yourdomain.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Copy the exact values WordPress generates — don’t use the example above verbatim. The values are specific to your install.

Step 4 — Update .htaccess (Apache) or nginx.conf (Nginx)

WordPress will also show you updated rewrite rules. Replace the existing WordPress block in your .htaccess with what it provides. For a subdirectory network on Apache, it looks roughly like this:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*.php)$ $2 [L]
RewriteRule . index.php [L]

If you’re on Nginx, you won’t have an .htaccess file — you’ll need to update your server block manually. This is one area where having root access really matters. If you’re on managed hosting, open a support ticket and we’ll handle it.

Step 5 — Log back in and verify

After saving both files, you’ll be logged out. Log back in and you should see My Sites in the admin bar and a new Network Admin menu. If those appear, the network is active.

Common Issues & Troubleshooting

“The site you have requested does not exist”

This usually means the rewrite rules aren’t working. On Apache, check that mod_rewrite is enabled (sudo a2enmod rewrite) and that AllowOverride All is set for your document root in your virtual host config. On Nginx, confirm your server block has the multisite rewrite rules — Nginx ignores .htaccess entirely.

Subdomain sites return a blank page or 404

Wildcard DNS isn’t set up, or hasn’t propagated yet. Log into your DNS provider and confirm a wildcard A record exists: *.yourdomain.com pointing to your server IP. DNS changes can take up to 24 hours to propagate, though most resolve within an hour. You can check propagation with:

dig +short sitename.yourdomain.com

If the IP comes back correctly but the site still 404s, the issue is server-side — check your virtual host or server block for wildcard handling.

Network Admin menu is missing after setup

This happens when wp-config.php constants weren’t saved properly, or the file has a syntax error. Open it directly via SSH or your file manager and verify the block from Step 3 is present and has no extra characters. Even a stray space before <?php will break it.

Plugins showing as “Network Activated” but not working on subsites

Some plugins aren’t multisite-compatible. Network activation makes a plugin available across all sites, but if the plugin stores options in wp_options instead of the per-site table (wp_2_options, wp_3_options, etc.), it won’t work correctly on subsites. Check the plugin’s documentation for multisite support before deploying it network-wide.

Upload directory errors on subsites

In a multisite network, WordPress stores uploads in /wp-content/uploads/sites/[site-id]/ rather than the default location. If that directory doesn’t exist or has wrong permissions, uploads will fail. Fix it with:

mkdir -p /var/www/html/wp-content/uploads/sites
chown -R www-data:www-data /var/www/html/wp-content/uploads/
chmod -R 755 /var/www/html/wp-content/uploads/

Replace www-data with your web server user if you’re on a different distro (e.g. apache on CentOS/AlmaLinux).

Frequently Asked Questions