Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
WordPress 4.5 and later can map a custom domain to a Multisite subsite without a domain-mapping plugin. The reliable order is: make DNS resolve to the network server, route the hostname to the same WordPress document root, provision HTTPS for that hostname, and then enter the complete HTTPS address in Network Admin.
This guide covers the native workflow for both subdomain and subdirectory networks, explains when legacy or specialist plugins are relevant, and gives recovery steps for the common “cookies are blocked” and “site not found” failures.
Recommended Free Tools
What domain mapping does
A Multisite network normally gives each site an address derived from the network’s base domain. In a subdomain network, a site might use store.example.net; in a subdirectory network, it might use example.net/store. Domain mapping changes the public address of one of those sites to another hostname, such as store.example.com, while the site remains in the same WordPress installation.
Mapping is not only a setting in the WordPress dashboard. Every request passes through several layers:
#1 Best Overall
- DNS must resolve the custom hostname to the server that hosts the network.
- The web server or hosting panel must accept that hostname and send it to the WordPress document root.
- TLS/HTTPS must have a certificate covering the hostname.
- WordPress must associate the hostname with the intended site.
If any earlier layer is missing, changing the Site Address (URL) field cannot make the domain work. WordPress 4.5+ includes the mapping feature natively; the old WordPress MU Domain Mapping approach is mainly for networks running before 4.5 or for a specialized workflow that needs behavior beyond the core feature.
Check the network before changing a domain
Confirm that Multisite itself is healthy
The official domain-mapping guidance assumes the network is already correctly configured. Before touching DNS, sign in to Network Admin and create a test subsite, visit its existing network URL, and confirm that its front end and dashboard work. Resolve broken network creation or permalink problems first. Mapping a hostname adds another variable and makes an unhealthy network harder to diagnose.
Identify subdomain or subdirectory mode
Open the network configuration and determine whether sites are created as subdomains or as paths. WordPress documents SUBDOMAIN_INSTALL set to true for subdomain networks and false for subdirectory networks. The native mapping procedure works with either mode, but the original network address and rewrite rules differ, so record the current mode before making changes.
Collect the values you will need
- The exact hostname to map, including whether you will use the apex name (for example,
example.com) or a host such aswww.example.com. - The existing network URL and the target subsite’s current address.
- The server or hosting account that serves the network’s document root.
- Access to the domain’s DNS management, the hosting control panel or web-server configuration, and Network Admin.
- A current backup of the database and
wp-config.phpbefore changing advanced settings.
Native mapping versus a plugin
For a normal WordPress 4.5 or newer network, start with the feature built into WordPress. A plugin is not a prerequisite for assigning one custom hostname to one subsite.
| Consideration | Native WordPress mapping | Legacy or specialist plugin |
|---|---|---|
| WordPress version | Built into WordPress 4.5 and later. | Historically required before 4.5; current plugins may target additional workflows. |
| Basic custom domain | Enter the complete URL in Network Admin → Sites → Edit. | Usually adds its own mapping screens or configuration. |
| Aliases and redirects | Core handles the mapped site address; unusual alias or redirect schemes may need extra tooling. | May offer alias, redirect, or automation features, depending on the product. |
| Server and HTTPS work | Still requires DNS, web-server routing, and a certificate for every hostname. | Does not remove those infrastructure requirements. |
sunrise.php |
Not normally needed for a straightforward modern setup. | Some Multisite plugins require a custom sunrise.php loader and additional configuration. |
| Maintenance | Fewer moving parts and no separate mapping plugin to update. | Adds compatibility, update, and vendor-support considerations. |
A current third-party option called Domain Mapping System advertises Multisite support, but its documentation describes server configuration, plugin installation, and mapping as separate tasks and requires custom sunrise.php configuration for that mode. Treat that path as an intentional compatibility or customization choice, not as the default setup for WordPress 4.5+.
Step 1: Point the custom domain in DNS
Use the DNS zone for the mapped hostname
Create or update the DNS record for the hostname so it resolves to the server hosting the Multisite network. Depending on the hosting design, that can be an address record or an alias record supplied by the host. Use the exact target and record type your provider specifies; do not point the name at a different server merely because it is the same registrar account.
Rank #2
The domain-mapping guidance says that all domains you intend to use should already be mapped to the DNS server and parked on the master domain. In practical terms, the custom hostname must resolve before WordPress is told that it is the site’s address.
Decide how the apex and “www” names behave
Choose one canonical hostname. If both the apex domain and a www hostname are intended to work, configure both at the DNS and web-server layers and decide which one should redirect to the other. Map the hostname you want WordPress to generate in links. Leaving one variant unconfigured often produces a redirect loop, a certificate warning, or a host that reaches the wrong site.
Allow for DNS propagation
After saving a DNS change, test resolution from more than one network or resolver. A result from your local computer can be cached, so a successful lookup does not prove that every visitor sees the new destination. Do not change the WordPress URL until the hostname consistently resolves to the network server you intend to use.
Step 2: Route the hostname to WordPress
DNS only chooses a server. The server must also recognize the hostname and select the Multisite document root. Configure this in the hosting panel or web-server virtual-host configuration.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsCommon routing arrangements
- Shared document root: Add the hostname as an additional domain or alias that uses the same directory as the network’s primary site.
- Virtual hosts: Add a host entry whose document root is the existing WordPress installation, not a new empty directory.
- Wildcard subdomains: A wildcard host can support a subdomain-style network, provided the wildcard DNS and server rule both point to the network’s document root.
- Hosting-panel addon domains: Add the custom domain as an addon or parked domain only when the panel lets it use the network’s existing document root.
WordPress’s network-preparation guidance lists wildcard subdomains, virtual hosts that share one document root, and addon domains as possible arrangements. The labels differ by host, but the requirement is the same: a request whose Host header is the mapped domain must reach the existing WordPress files and rewrite rules.
Verify routing before changing WordPress
Request the hostname over HTTP and HTTPS while it is still using the network’s current URL settings. You should reach the same WordPress installation rather than a hosting placeholder, a default virtual-host page, or an unrelated site. If you see the wrong content, fix the server mapping first; changing Site Address will not correct a virtual-host mismatch.
Step 3: Provision HTTPS for every mapped hostname
Install a valid SSL/TLS certificate for the primary domain and for each additional mapped domain. The official guidance specifically calls for SNI (Server Name Indication) for other domains on the same server. SNI lets one server present the certificate that matches the hostname requested by the visitor.
Test the secure origin first
- Install or attach the certificate in the hosting panel or web-server configuration.
- Ensure the HTTPS virtual host uses the same WordPress document root as the HTTP host.
- Open the exact mapped hostname with
https://and verify that the certificate name matches it. - Confirm that the request reaches the intended network site and that there is no certificate warning or immediate redirect to another host.
Do this before changing the Site Address field. WordPress administrative cookies are tied to the origin and security settings; changing the URL first can leave you locked out if HTTPS is not ready.
Cover alternate names deliberately
If the site will answer on both the apex and www forms, the certificate and server configuration must cover both. A certificate for only one name does not make the other secure. Pick one canonical form for WordPress and redirect the alternate form at the server layer after both are valid.
Step 4: Enter the mapped address in Network Admin
Once DNS, routing, and HTTPS work independently, make the WordPress change:
- Sign in as a network administrator.
- Open Network Admin → Sites.
- Locate the subsite and choose Edit.
- On the site settings screen, find Site Address (URL).
- Replace the existing network address with the complete mapped URL, including the scheme, for example
https://example.com. - Save the changes.
Use the full HTTPS URL, not only a hostname and not a path fragment. The native workflow applies whether the original subsite was created as a subdomain or as a subdirectory. After saving, open the front end in a private browser window and then open the subsite dashboard through the new address.
Check generated links and administrative access
- Follow a few internal links and confirm they stay on the mapped hostname.
- Open the login page and sign in without being sent back to the old network address.
- Visit the media library and a page containing an image to catch links that still use the old origin.
- Check that the browser shows a secure connection on both the front end and the dashboard.
Do not edit database URL fields manually for a standard mapping. The network site setting is the supported place to assign the mapped address; direct search-and-replace changes can alter serialized data or affect other subsites.
Rank #4
Fix login and cookie errors
Symptoms
A mapped site may display a message that cookies are blocked, return to the login form without authenticating, or appear to log in and then immediately forget the session. These failures usually mean that the browser is receiving cookies for a different host or that the secure origin is not configured consistently.
First checks
- Use one canonical hostname and remove conflicting browser cookies for both the old and new addresses.
- Confirm that the mapped URL and the certificate both use HTTPS.
- Check that HTTP-to-HTTPS and apex-to-
wwwredirects do not bounce between hosts. - Temporarily test in a private window to rule out stale cookies.
- Verify that the web server sends the mapped host to the same WordPress installation on every request.
Apply the documented cookie-domain setting when necessary
If the problem persists, the official Multisite domain-mapping guidance documents defining the cookie domain from the incoming host. Add this line to wp-config.php after the other network-creation code:
define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );Save the file, clear old cookies, and test the mapped dashboard again. Edit wp-config.php carefully: a syntax error can take down the entire network. Keep a backup so you can remove the line and restore the previous configuration if it does not fit your hosting arrangement.
Diagnose “site not found” and routing failures
DNS resolves, but the browser shows a hosting page
The hostname is reaching a server, but not the WordPress virtual host or document root. Recheck the addon-domain, parked-domain, or virtual-host target and make sure it is the same directory used by the network’s primary site.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →WordPress reports that the site cannot be found
The ms_site_not_found hook runs when WordPress has identified a network but cannot find a matching site. Check the saved Site Address value for spelling, scheme, and an accidental trailing path. Then verify that the request’s hostname is exactly the one stored for the subsite, including whether www is present.
The old network URL keeps returning
Inspect redirects at the web server, hosting panel, caching layer, and WordPress plugins. A redirect that forces every request to the old network domain can override the mapped address. Disable or adjust that rule only after confirming the new HTTPS host is valid.
Only some assets fail
Images, stylesheets, or scripts that still reference the old hostname can create mixed-content warnings or broken requests. Identify the exact URL in the browser’s network or page-source tools, then correct the setting that generated it. Do not perform a blind database replacement across the whole network; one replacement can unintentionally modify other subsites.
When a plugin or sunrise.php is justified
Networks created before WordPress 4.5 historically needed a plugin such as WordPress MU Domain Mapping. A plugin can also be appropriate when you intentionally need custom aliases, automated mapping workflows, or compatibility with an established installation that already depends on an early-loading domain resolver.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The sunrise.php mechanism is an advanced path. The ms_site_not_found reference notes that the mechanism can load wp-content/sunrise.php when WordPress is resolving a network and site. Some plugins require enabling that loader and adding their own configuration. Because it runs early in request handling, a mistake can prevent site resolution across the network.
Safeguards for an advanced migration
- Back up the database and the complete WordPress files, including
wp-config.phpand any existingsunrise.php. - Document the current network and site URLs and the server’s virtual-host rules.
- Read the plugin’s Multisite instructions for its required constant, loader, and mapping table; do not copy settings from an unrelated single-site installation.
- Test one non-critical subsite first and keep an administrator session on the original network address until the mapped host is confirmed.
- Have a rollback plan that removes the new early-loading configuration and restores the previous file and database state.
Do not install a plugin merely to compensate for missing DNS, server routing, or HTTPS. Those requirements remain even when a plugin is present.
Operational checklist
- Network Admin can create and open subsites normally.
- The network mode, subdomain or subdirectory, is recorded.
- The mapped hostname resolves to the network server.
- The web server or hosting panel routes that hostname to the existing WordPress document root.
- An HTTPS certificate covers every hostname visitors will use, with SNI configured where needed.
- The secure hostname works before the WordPress URL is changed.
- Network Admin → Sites → Edit → Site Address (URL) contains the complete HTTPS URL.
- Front-end links, login, dashboard, media, and redirects stay on the chosen canonical hostname.
- Cookie errors have been tested in a clean browser session and addressed with the documented
COOKIE_DOMAINdefinition only if required. - Any plugin or
sunrise.phpchange is backed up and has a tested rollback.
What to expect after mapping
Domain mapping changes how visitors and administrators reach the subsite; it does not create a separate WordPress installation. The subsite continues to share the network’s core files and Multisite administration. DNS, server routing, certificates, and WordPress’s saved site address must remain aligned whenever the hostname changes. If you later move the network to another server, repeat the DNS, virtual-host, and certificate checks before updating the mapped URL again.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
