You moved a WordPress multisite network to a new host, the main site loads fine, and every single subdomain in the network throws a persistent 404 error. Not one subdomain, not a small handful, every single one, without exception. That specific pattern, every subdomain failing at once right after a migration, is actually good news, because it almost always rules out plugin conflicts, theme problems, and content issues entirely. When every subsite breaks identically and simultaneously, the cause lives in the server configuration itself, not in WordPress. This guide walks through the exact chain of dependencies a multisite subdomain network relies on, in the order to check them, so you can find the specific broken link instead of guessing.
This is one of the more disorienting errors in WordPress hosting because the WordPress admin dashboard itself often looks completely normal. You can log in, you can see every subsite listed under My Sites, network admin functions correctly, and yet every single subdomain URL returns a 404 the moment you visit it. That disconnect, a functioning dashboard alongside completely broken frontend URLs, is the signature of a server level problem rather than a WordPress level one, and it is exactly why generic 404 troubleshooting guides written for single site WordPress installs do not solve this particular version of the problem.
Why this points to the server, not wordpress
A standard WordPress 404 error, on a single site install, usually comes down to permalink rewrite rules getting corrupted, which is fixed by resaving permalinks in Settings. On a multisite network, subdomain sites depend on several additional layers that a single site install does not need at all, and a host migration is exactly the kind of event that breaks those extra layers while leaving the core WordPress install and database completely intact. The main site working while every subsite fails tells you WordPress itself migrated correctly, the database is connected, and the core files are in place. The problem sits specifically in the parts of the stack that are unique to serving multiple subdomains from one WordPress install, which is a much smaller and more specific list of things to check than a general 404 troubleshooting guide would have you believe.
The four things multisite subdomains depend on
A WordPress multisite network configured for subdomains, rather than subdirectories, depends on four things working together correctly. First, wildcard DNS, meaning a DNS record that routes any subdomain of your root domain, not just specific ones you have manually created, to your server’s IP address. Second, a wildcard SSL certificate, or an equivalent that covers every possible subdomain rather than a handful of manually issued certificates, assuming the site is served over HTTPS, which nearly every site is by default in 2026. Third, a wildcard virtual host entry on the web server itself, whether that server runs Apache, Nginx, or LiteSpeed, telling the web server software to route requests for any subdomain to the same WordPress installation rather than only responding to domains it has an explicit entry for. Fourth, the correct values inside wp-config.php and the wp_site and wp_blogs database tables, which tell WordPress itself which domain the network is running on. A migration to a new host can break any single one of these four independently, and because they depend on each other in sequence, a break early in the chain, like a missing wildcard vhost, produces the exact same 404 symptom as a break later in the chain, like a stale database entry, which is why guessing rather than checking each layer in order wastes a lot of time.
Step 1: confirm wildcard dns actually points to the new server
Before touching anything inside WordPress, confirm the most basic layer first. A wildcard DNS record, typically written as an A record for the host value asterisk, pointing to your new server’s IP address, needs to exist at whichever DNS provider currently manages your domain, whether that is your new host’s own nameservers or a separate DNS provider like Cloudflare. If your previous host had this wildcard record configured but your new host’s default DNS setup does not include one automatically, which is common since many hosts only auto-create records for the root domain and www, every subdomain will fail to resolve at all, and browsers will typically show a DNS error rather than a 404, though some browsers and CDNs will render this as a generic 404 style page depending on configuration. Checking a specific subdomain against a DNS lookup tool confirms within seconds whether this specific layer is the problem, and if the wildcard record is missing entirely, adding it and waiting for propagation, which can take anywhere from a few minutes to several hours depending on your previous TTL settings, is the first and simplest fix to rule out.
Step 2: confirm a wildcard ssl certificate covers every subdomain
If wildcard DNS is confirmed working, the next layer is SSL. A certificate issued for your root domain and www does not automatically cover arbitrary subdomains, you specifically need a wildcard certificate, typically shown as an asterisk followed by a dot and your domain, or your host needs to be issuing individual certificates automatically for each subdomain as it is created through an integration with Let’s Encrypt or a similar automated certificate authority. Many hosts handle this automatically for subdomains created through their own control panel interface but do not extend that automation to subdomains created through WordPress multisite’s own network admin interface, since from the server’s perspective those subdomains were never explicitly registered anywhere outside of the WordPress database itself. This mismatch, where WordPress considers a subdomain fully created and functional while the web server has no certificate and no explicit configuration for it, is one of the most common single causes of this exact error appearing specifically after a host migration, since the previous host may have had a wildcard certificate configured that simply was not part of what got migrated to the new environment.
Step 3: the missing piece most migrations get wrong, a wildcard virtual host
This is the layer that causes the most confusion because it is invisible from inside WordPress entirely. Even with correct DNS and a valid SSL certificate, your web server software still needs an explicit configuration telling it what to do when a request arrives for a subdomain it has never seen an explicit entry for. Without this, the server has nowhere to route the request, and depending on the server’s default behavior, this shows up as a 404, a 403, or in some configurations a default placeholder page rather than your WordPress site. Many hosting control panels automatically create a specific virtual host entry only for domains and subdomains added explicitly through that control panel’s own interface, and have no awareness of subdomains that WordPress created internally through its own network admin screen. This is precisely the layer where a working migration, one where the files copied correctly and the database imported without errors, can still produce a completely broken multisite network, because the missing piece exists entirely at the web server configuration level, several steps removed from anything a typical WordPress migration plugin or manual file transfer would think to touch.
Adding a wildcard virtual host on apache
On an Apache server, a wildcard virtual host uses ServerAlias with an asterisk wildcard pattern inside the virtual host block for your domain, for example ServerAlias asterisk.yourdomain.com alongside the existing ServerName directive for your root domain. This single line tells Apache to route any subdomain matching that pattern to the same document root as your main WordPress installation, which is exactly the behavior a subdomain based multisite network needs. After adding this line, a full Apache restart, not just a reload, is typically required for the change to take effect, and testing against a subdomain that was not previously working is the fastest way to confirm the fix worked before moving on to the next layer.
Adding a wildcard virtual host on nginx
Nginx uses a slightly different syntax inside the server block, where the server_name directive accepts a wildcard pattern directly, for example server_name yourdomain.com asterisk.yourdomain.com. Unlike Apache, Nginx requires a full reload rather than always needing a full restart, though a restart works as well if you are unsure. One detail that trips people up specifically on Nginx is that the wildcard pattern needs to appear in the same server block that has the correct root and PHP-FPM handling configuration for WordPress, since Nginx will match the most specific server_name it can find first, and a separate default server block elsewhere in your configuration can silently intercept subdomain requests before they ever reach the block you actually configured for WordPress.
Adding a wildcard virtual host on litespeed
LiteSpeed, increasingly common on shared and managed WordPress hosting because of its speed advantages, handles this through its own virtual host configuration rather than raw Apache or Nginx config files in most managed environments. The concept that trips people up on LiteSpeed specifically is the need for what LiteSpeed calls a catch-all virtual host, meaning a virtual host entry configured to accept any hostname that does not match a more specific existing entry, rather than a wildcard pattern written directly the way Apache and Nginx handle it. Without an explicit catch-all virtual host configured, LiteSpeed will return a 404 for any subdomain it does not have an exact matching entry for, which matches exactly the symptom described by multiple site owners troubleshooting this specific combination of LiteSpeed and multisite after a migration. Most managed hosts running LiteSpeed provide this setting somewhere in their own control panel rather than through a raw config file, so checking your specific host’s documentation for the phrase catch-all or wildcard virtual host is the fastest path to the correct setting.
Related reading on wordpress migrations and hosting troubleshooting:
1. Hosting account exceeded inode limit: full technical guide
2. Hostinger hpanel shows resource usage limit exceeded: what it means
3. WordPress REST API returns 401 error after host migration
4. SiteGround staging site accidentally showing on the live URL
5. Cloudways vs RunCloud: managing a DigitalOcean VPS
When a cdn or reverse proxy sits between visitors and your server
If your domain routes through Cloudflare or a similar CDN and reverse proxy service, an additional layer needs checking before assuming the origin server itself is misconfigured. Cloudflare’s own DNS needs the same wildcard A or CNAME record pointing at your origin server that a non-proxied setup would need, and critically, that wildcard record needs the orange cloud proxy status enabled consistently with how your other records are configured, since a mismatch, where your root domain is proxied through Cloudflare but a newly created wildcard record was accidentally left in DNS-only grey cloud mode, produces exactly this kind of inconsistent subdomain behavior. Cloudflare’s own SSL mode setting matters here too, since Full or Full Strict mode requires your origin server to present a valid certificate for whatever hostname Cloudflare is forwarding, meaning a missing wildcard certificate at the origin server level will still break subdomains even when Cloudflare’s own edge certificate, which covers wildcard subdomains automatically on most Cloudflare plans, looks completely correct from the visitor’s side. This is a subtle but common cause specifically for sites that added Cloudflare or a similar service as part of the same migration that moved hosting providers, since two changes happening simultaneously make it harder to isolate which one introduced the problem.
More hosting intelligence
Diagnosing with curl and direct server ip testing
A reliable way to isolate whether the problem sits at DNS, at a CDN layer, or at the origin server’s virtual host configuration is to bypass DNS entirely and test directly against the server’s IP address using curl with a manually specified Host header, for example curl with the dash capital H flag setting Host to the specific subdomain, sent directly to the server’s IP rather than through the domain name. If this direct test against the IP address returns the WordPress site correctly, the problem is confirmed to live somewhere between DNS and the server, whether that is a missing wildcard DNS record, a CDN configuration issue, or DNS propagation still in progress. If the same direct IP test still returns a 404 or a connection refused, the problem is confirmed to live at the server’s virtual host configuration itself, regardless of what DNS or any CDN in front of it is doing, which immediately rules out an entire category of things to check and focuses the remaining troubleshooting time on Apache, Nginx, or LiteSpeed configuration specifically.
What to expect from your host's support team on this issue
Shared hosting support teams are generally fast at confirming DNS and SSL status, since those checks are quick and well documented in their own internal tools, but wildcard virtual host configuration is a less common request and support agents on a first tier support queue may not immediately recognize the specific fix needed, particularly on hosts where multisite is not a heavily marketed feature. Being specific in a support ticket, naming the exact symptom as a wildcard or catch-all virtual host missing for a subdomain multisite network, rather than describing it generically as a 404 error, tends to route the ticket to someone with server level access faster than a general description would. On VPS and cloud plans where you manage the server configuration yourself rather than relying on a shared hosting support team, this entire fix is in your own hands and does not require waiting on a support queue at all, which is one practical reason some agencies managing multiple multisite networks prefer a VPS specifically for the direct control it gives over virtual host configuration.
Step 4: checking wp-config.php after the move
With DNS, SSL, and the virtual host layer confirmed, the remaining checks live inside WordPress itself. Open wp-config.php on the new server and confirm the DOMAIN_CURRENT_SITE constant matches your actual root domain exactly, including whether it includes www or not, since a mismatch here, even a subtle one like www.yourdomain.com defined where the network was actually set up without www, will cause every subdomain to fail even though the root site itself continues working normally. Confirm PATH is still set correctly, typically a single forward slash for a standard install, and confirm SUBDOMAIN_INSTALL is defined as true, since a migration process that partially preserved the old wp-config.php but merged in new database credentials incorrectly can occasionally leave this constant missing or set incorrectly, which silently changes how WordPress expects subdomain URLs to be structured.
Step 5: checking the wp_blogs and wp_site tables directly
If wp-config.php looks correct and the previous three layers are confirmed working, the final place to check is the database itself, specifically the wp_site and wp_blogs tables, which store the domain and path for the network and for every individual subsite respectively. A migration that involved a search and replace across the database, which is standard practice when moving a domain or moving hosts, can sometimes miss serialized data or leave stale entries in these specific tables if the search and replace tool used was not multisite aware. Checking the domain column in wp_blogs for a handful of subsites and confirming it matches your actual current domain exactly is usually enough to confirm whether this is the issue, and if entries are stale, a multisite aware search and replace tool, rather than a generic one, is necessary because these tables reference domains in ways that a naive text replacement can corrupt rather than fix.
Flushing permalinks and object cache after fixing the root cause
Once the actual root cause, whether DNS, SSL, the virtual host, wp-config, or the database tables, has been corrected, one additional step resolves the vast majority of remaining edge cases. Visiting Settings then Permalinks on the network’s main site and clicking save, without changing any setting, forces WordPress to regenerate its internal rewrite rules against the now correct configuration. If an object caching layer like Redis or Memcached is active, which is common on managed WordPress hosting for performance, flushing that cache afterward prevents WordPress from continuing to serve a cached version of the broken state even after the underlying fix is in place, which is a common reason a fix appears not to have worked immediately after being applied.
A migration checklist to do this correctly the next time
For anyone about to migrate a multisite network rather than already troubleshooting a broken one, confirming these same five layers before the migration, rather than after, prevents the entire situation. Before initiating the move, document your current wildcard DNS record exactly as configured, confirm whether your current SSL setup uses a true wildcard certificate or automated per-subdomain issuance, and export the exact virtual host configuration from your current server rather than assuming the new host’s default setup will replicate it. During the migration itself, request explicitly, in writing if working with a migration service, that wildcard DNS and a wildcard virtual host be configured on the destination server before DNS is pointed at it, rather than after, since testing subdomains against the new server’s IP directly, before changing DNS, catches virtual host and SSL problems while the live site is still safely running on the old server. After the migration completes, testing at least three subdomains, not just the main site, before considering the migration finished catches this exact class of error while it is still trivial to fix rather than after client complaints start arriving, and keeping a written record of which specific subdomains were checked gives you something concrete to point to later if a client ever questions whether the migration was actually verified properly.
Common mistakes that make this worse
The most common mistake is assuming the problem is a plugin or theme issue because that is what a general web search for WordPress 404 error suggests, and spending hours deactivating plugins one at a time on a network where every subsite is affected identically, which as covered earlier almost never points to a plugin. A second common mistake is fixing DNS and SSL, confirming the domain resolves and shows a valid certificate in a browser, and stopping there, without checking that a wildcard virtual host actually exists, since a browser showing a valid SSL padlock does not confirm the web server has a matching virtual host configured, it only confirms the certificate itself is valid for that hostname. A third mistake specific to agencies managing client migrations is testing only the main domain before considering a migration successful and handing the site back to the client, when the entire value of a multisite network is in its subsites, meaning the main domain working correctly tells you almost nothing about whether the migration actually succeeded for the client’s real use case.
Real world scenario: an agency migrating twelve client subsites
A marketing agency running a multisite network with twelve client subsites, each on its own subdomain, migrated the entire network to a new host over a weekend to take advantage of better VPS pricing. The main agency site loaded correctly Monday morning, and the agency began reporting the migration as complete to clients, until the first client called reporting a 404 on their own subdomain within an hour. Checking DNS confirmed the wildcard record had in fact been recreated correctly on the new host. Checking SSL in the browser showed a valid certificate. The actual cause, found only after checking the server’s virtual host configuration directly, was that the new VPS’s control panel had created a specific virtual host entry only for the root domain during the initial server setup wizard, with no wildcard or catch-all entry for anything else, meaning the SSL certificate itself was a wildcard certificate correctly issued through Let’s Encrypt’s DNS validation method, valid for any subdomain, while the web server simply had nowhere to route the request once DNS and SSL correctly delivered it to the server. Adding a single ServerAlias wildcard line to the existing Apache virtual host block resolved all twelve client subsites simultaneously within minutes of the restart, without touching WordPress, the database, or any plugin at all.
Why this specific combination catches even experienced teams off guard
Teams that migrate single site WordPress installs regularly, and do it well, often assume the same migration checklist applies equally to a multisite network, since the files and database steps look identical on the surface. The difference only becomes visible at the exact moment a subsite is tested, and if a team’s standard process only verifies the main domain before marking a migration complete, this gap can persist for days or weeks until a client happens to visit their own subdomain and reports it directly. Building a specific verification step for multisite networks, separate from the standard single site migration checklist, into a team’s own internal process is the most reliable way to prevent this specific failure from reaching a client at all, rather than relying on remembering to check it manually every time a multisite migration happens to come up.
The bottom line on multisite 404 errors after a host change
Every subdomain in a network failing identically right after a migration, on any host, is a server configuration signature, not a WordPress problem, and checking the four dependencies subdomain multisite relies on, wildcard DNS, wildcard SSL, a wildcard or catch-all virtual host, and correct values in wp-config.php and the database, in that specific order, finds the actual break far faster than troubleshooting plugins or themes ever will. The virtual host layer specifically is the one most migrations get wrong because it is invisible from inside WordPress and is rarely covered by generic hosting migration checklists written with single site installs in mind rather than multisite networks, which is exactly why this specific error keeps appearing across different hosts, different server software, and different agencies year after year.
Sources and references consulted: the official WordPress multisite network documentation, WordPress.org’s multisite glossary reference, how wildcard DNS records work, a DNS propagation checking tool, Let’s Encrypt’s wildcard certificate documentation, Apache’s official virtual host documentation, Nginx’s server block configuration guide, LiteSpeed’s virtual host configuration documentation, the WordPress Network Setup codex page, WP-CLI’s search-replace command for multisite, Redis object caching documentation, the WordPress support forums thread on this exact error, phpMyAdmin’s official documentation, WordPress.org’s common errors reference article, Cloudflare’s SSL and TLS documentation, WPMU DEV’s domain mapping plugin documentation, the WP-CLI command line tool for WordPress, cPanel’s official documentation on wildcard subdomains, the WordPress multisite network admin handbook, Google’s guidance on migrating a website without losing SEO.
