WordPress Multisite Subdomain: A Complete Guide

A WordPress multisite subdomain setup looks simple until the first new site opens a host 404 page, a certificate warning, or a different WordPress install. That usually means WordPress was ready, but DNS, server routing, or SSL was not.

TL;DR: Enable multisite, choose subdomains in Network Setup, add your first subsite from Network Admin, and back up the site before you touch config files. The setup only works when WordPress, DNS, server routing, and SSL all point to the same network install.

This guide walks you through the safe order: confirm the structure, prepare the site, set up the outside routing, enable multisite, add a test subdomain, and fix the common failures without guessing.

What a WordPress multisite subdomain means

A subdomain multisite network is one WordPress installation that runs several sites with addresses such as example.com, news.example.com, shop.example.com, and members.example.com.

These are not separate WordPress installs in separate hosting folders. You create the subsites inside Network Admin. Themes and plugins are installed once at the network level, then made available to the sites that need them. If you are still deciding whether the network model fits, start with the broader WordPress multisite tradeoffs before choosing subdomains.

The mistake I see most often is treating a hosting-panel subdomain as the same thing as a multisite subsite. It is not. The hosting panel routes a hostname. WordPress creates the site record. A working setup needs both.

Layer	Job
WordPress	Creates and manages the subsite
DNS	Points the subdomain to the right host
Server routing	Sends the request to the multisite install
SSL	Makes HTTPS valid for that hostname

If one layer is wrong, the site can look broken even when the other layers are fine.

Choose the right URL structure first

Choose subdomains because they fit the sites, not because they sound better for SEO. Google can work with subdomains and subdirectories. The real difference is operational.

Structure	Use it when	Main catch
Subdomains	Sites need stronger identity, like regional, department, brand, or member sites	DNS, routing, and SSL need more care
Subdirectories	Sites are closely related and simplicity matters	URLs feel less separate
Mapped domains	Each site will use its own custom domain later	DNS, SSL, redirects, and mapping still need testing

Use subdomains when separation is worth the extra setup. Use subdirectories when you want fewer moving parts. If the sites are unrelated businesses with different owners, separate WordPress installs may be easier to maintain. If you want to rehearse the choice away from production, build a local test network first.

Prepare the site before changing files

Multisite changes affect how WordPress routes every request. On a fresh test site, that is low risk. On a live site, it is the kind of change you do slowly.

Before you start, confirm:

BlogVault fits this stage because the risk is not theoretical. A small config mistake can lock you out or break routing. Use BlogVault to create an offsite backup and staging copy before you change network structure. It does not configure multisite for you, but it gives you a clean way back.

Set up DNS, server routing, and SSL

WordPress can create shop.example.com as a subsite. It cannot make the internet route that hostname to your server by itself. Set up these three pieces before you add a full network of sites:

Layer	What to set up	Good result
DNS	Wildcard DNS for *.example.com, or records for each planned subdomain	The subdomain resolves to your host
Server routing	A server alias, app mapping, virtual host, or reverse-proxy rule	The request reaches the same WordPress install
SSL	A wildcard certificate or a certificate for each subdomain	HTTPS loads without warnings

This is the part to verify outside WordPress before assuming the dashboard setup is wrong.

Wildcard DNS is best when you will create many subsites or allow open-ended site creation. Individual records are fine when you only need a few fixed sites, such as news.example.com and members.example.com.

⚠️ Where this goes wrong: DNS points to the server, but the server sends the request to a default page, a different folder, or a different app. That is not a WordPress dashboard problem. It is a host routing problem.

If you use managed hosting, ask this exact question: Can this account route wildcard subdomains to the same WordPress multisite installation and issue SSL for them? A general “we support WordPress” answer is not enough, especially if you plan to change a multisite subsite domain or map custom domains later.

Enable WordPress multisite

Once the backup, WordPress multisite staging plan, DNS, routing, and SSL plan are ready, enable the network from the main WordPress install.

Use the snippets from your own Network Setup screen. Do not copy config blocks from a tutorial and assume they match your site.

Add one subdomain site

Create one test subsite before you build the rest of the network. A single failing subdomain is easier to diagnose than ten.

Be careful with network-activated plugins. One update can affect every site in the network. That is useful when you manage shared code well, and painful when one plugin behaves badly.

Verify before adding more sites

A homepage loading once is a good sign. It is not enough proof.

Check the first subsite for:

Success looks plain: you can visit the subdomain, log in, publish content, upload media, and browse normal URLs without warnings or odd redirects.

Troubleshooting common issues

When a subdomain fails, diagnose the layer that failed. Random edits usually make this worse.

Symptom	Likely cause	First check
Host 404 page	DNS or host routing	DNS target and app mapping
Default page or separate install	Wrong virtual host or folder	Server alias and subdomain target
HTTPS warning	Certificate missing	Wildcard or subdomain SSL
Wrong URL redirect	Site URL, mapping, cache, or redirect rule	Network Admin site settings and redirect rule
Login or cookie error	Mixed HTTP/HTTPS or domain mismatch	SSL and site URLs
Broken CSS, images, or 502 errors	Stored URLs, cache, PHP, or proxy issue	Cache, logs, and app status
Nginx ignores rules	Apache rules were used	Host-specific Nginx config

Use this order: DNS first, server routing second, SSL third, WordPress settings fourth. WordPress cannot fix a subdomain that never reaches WordPress.

If the failure includes suspicious redirects, unknown admin users, or files changing again after repair, scan the site before restoring traffic. If a failed change happened on production, stop making live edits. Restore the last known good state or move the fix to staging. This is why the backup step matters.

Changing structure later

You can switch a multisite network from subdirectories to subdomains later, but treat it as a migration. It is not a casual dashboard preference.

A proper switch may require:

Do not do this live as your first attempt. Build the plan on staging, keep a complete backup, and involve a developer for large networks. If the change moves a whole network between hosts or URL structures, use a dedicated multisite migration plan.

Domain mapping and mixed structures

WordPress multisite supports domain mapping without extra plugins, but DNS, SSL, routing, and redirects still need to be set up correctly. Standard multisite uses one site structure—either subdomains or subdirectories—while mixed setups like example.com/shop and members.example.com usually need a separate install, mapped domain, or custom routing.

When to avoid a WordPress multisite subdomain

Subdomain multisite is the wrong choice when shared management becomes shared risk. Skip it if:

Use a WordPress multisite subdomain when the shared codebase is the advantage. Avoid it when every site needs its own rules.

Final recommendation

If you are starting fresh and your host supports subdomain routing and SSL, follow the setup flow and create one test subsite first.

If the site is live, back it up, stage it, test the network there, then move carefully. BlogVault is useful here because multisite gives one change a wider reach, and a WordPress multisite backup plugin should cover the full network, not just one visible subsite.

If your host cannot route subdomains to the same WordPress install, choose subdirectories, mapped domains on better hosting, or separate installs.

FAQs