When a WordPress Multisite Subdomain Dashboard Returned 404 but the Main Site Worked and the Domain Mapping Fix That Finally Restored Access

If you’ve ever managed a WordPress Multisite Network, you’re already aware of the power it brings in handling multiple websites under one core installation. However, when issues arise—especially ones that affect subdomains—it can be a challenge to isolate the problem. One particularly troubling scenario is when a subdomain site’s dashboard suddenly returns a 404 error, even though the main site and front-end of the subdomain still work perfectly. This is a real-world troubleshooting journey into restoring dashboard access using domain mapping fixes and a bit of persistence.

TL;DR

A WordPress Multisite with subdomains was working fine on the surface, but the dashboard of one subdomain returned a 404 error. The main site and the front-end of the subdomain were unaffected, compounding the mystery. The root cause lay in broken or misconfigured domain mapping settings. Once corrected, the dashboard access was fully restored, offering key insights into how domain mapping intricacies can affect Multisite performance.

Understanding the Problem: A 404 in the Wrong Place

Everything seemed smooth—until it wasn’t. After a routine deployment, we noticed that one of our subdomain sites, shop.example.com, refused to allow access to its WordPress admin area. Navigating to shop.example.com/wp-admin returned a 404 Not Found error. However, the front-end of the subdomain was functioning correctly, displaying the custom-designed WooCommerce storefront as expected. The main site, example.com, was completely unaffected.

This unusual behavior raised more than a few eyebrows. If there were a hosting or DNS problem, we would expect the entire subdomain to fail. But only the dashboard was broken—clearly pointing to something more subtle.

Initial Investigation: Checking the Usual Suspects

When troubleshooting anything on WordPress Multisite, it’s good practice to start with basics:

• DNS Resolution: Confirmed that shop.example.com was pointing to the correct A record and resolving properly across various networks.
• Server Configuration: Verified Apache’s configuration to make sure ServerAlias entries allowed subdomain traffic properly.
• .htaccess and wp-config.php: Double-checked rewrites and Multisite-specific constants like DOMAIN_CURRENT_SITE and SUBDOMAIN_INSTALL.

All checked out. Nothing looked amiss. The .htaccess file had the correct Multisite rewrite rules, and wp-config.php showed consistent data with the rest of the working environment.

The Turning Point: Domain Mapping Considerations

This was a WordPress Multisite with subdomain installation, as opposed to folders, and domain mapping was also in play—although that was an earlier choice when using an external plugin on legacy builds. It’s worth noting that domain mapping used to require a plugin, but since WordPress 4.5, it’s managed natively to a great extent when correctly configured.

We inspected the database in the wp_blogs and wp_sites tables and found that:

• The subdomain entries had inconsistencies in the domain fields.
• Some entries used non-www versus www versions, or mapped custom domains to subdomains that no longer existed.

Additionally, a look at the siteurl and home options in the relevant sub-site’s options table revealed a mismatch. The siteurl was pointing to the original mapped domain, which had expired and was no longer in DNS!

This was a big “Aha!” moment. No wonder the frontend worked (because the content was still being rendered), but the backend tried to redirect dashboard requests through a defunct mapped domain. WordPress was obeying its configuration—blindly, and predictably—resulting in a 404 error.

The Solution: Correcting Domain Mapping

Here’s a breakdown of the steps that we followed to restore dashboard access:

1. Correct the siteurl and home in the database

Using phpMyAdmin or WP-CLI, we navigated to the affected site’s options table (e.g., wp_3_options) and updated the URLs:

UPDATE wp_3_options 
SET option_value = 'https://shop.example.com' 
WHERE option_name IN ('siteurl', 'home');

This removed the dependence on the defunct custom domain and aligned the backend URL to a valid, accessible subdomain.

2. Clear any domain mapping plugins or inconsistent data

Legacy plugins like WordPress MU Domain Mapping were no longer necessary. We deactivated and removed those, then searched the database for leftover mapped domains using:

SELECT * FROM wp_domain_mapping;

Entries referencing inactive domains were deleted.

3. Validate DNS and SSL Certificate

Though not directly causing the issue, we made sure that shop.example.com had valid SSL coverage via Let’s Encrypt. Sometimes, an insecure redirect can cause a status 404 post-redirect due to HSTS policies.

4. Flush Rewrite Rules

Finally, we triggered a rewrite rule flush by visiting the Settings > Permalinks page in the WordPress admin—or used WP-CLI command:

wp rewrite flush --network

This ensures the web server is following the correct URL structure site-wide.

The Result: Dashboard Repaired, Lesson Learned

After applying the fixes, browser navigation to shop.example.com/wp-admin loaded the dashboard with no further errors. That familiar blue-and-white backend never looked so good.

This issue was a lesson in how WordPress Multisite setups can seem functional while hiding subtle configuration errors that affect only particular areas. Because the frontend wasn’t broken, it was easy to overlook deeper domain mapping configurations.

Words of Advice for Other Multisite Admins

To avoid similar headaches down the line, here are a few best practices that may help:

• Audit your DNS and domain mapping regularly—especially if external domains are being mapped to subsites.
• Keep sub-site configurations consistent, including home and siteurl options.
• Avoid unnecessary domain mapping plugins on recent WordPress versions. Use native tools where possible.
• Back up your database before performing any manual edits.
• Document your Multisite architecture. Having a map of domain relationships can speed up problem diagnosis.

Conclusion

WordPress Multisite is a powerful tool when set up correctly, but it introduces layers of complexity—especially in sites using subdomains and legacy domain mapping techniques. Our journey through a mysterious 404 error ultimately led us to abandoned domain mappings that quietly redirected admin access into oblivion. With some careful sleuthing, database surgery, and a bit of DNS validation, we were able to bring everything back under control.

Let this serve as a reminder: when your dashboard mysteriously vanishes, always follow the trail of breadcrumbs left in your domain mappings.