WordPress 4.5 and later can map a custom domain to a Multisite subsite without a domain-mapping plugin. The reliable sequence 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. If the server or certificate is not ready first, changing the Site Address (URL) can produce redirects, site-not-found errors, or failed logins.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What domain mapping does in Multisite
A Multisite network has one WordPress installation serving multiple sites. Depending on how the network was created, a subsite normally appears under a subdomain such as site.example.com or a subdirectory such as example.com/site. Domain mapping changes the public hostname for one of those subsites to a separate domain, for example https://example.com or https://brand.example, while the site continues to run from the same Multisite installation.
As an Amazon Associate I earn from qualifying purchases.
The mapping is not a DNS-only alias. DNS tells browsers where to send a request, and the web server must then accept that hostname and select the WordPress document root. WordPress finally uses the requested hostname to identify the mapped site. All three layers must agree before the dashboard setting can work.
Since WordPress 4.5, domain mapping is a native feature. A plugin is generally unnecessary for a normal current installation. Older networks running before 4.5 may still use WordPress MU Domain Mapping, and specialized workflows may justify a plugin, but adding one to a current network merely to map a domain introduces another configuration and maintenance layer.
#1 Best Overall
Requirements and decisions before you start
Confirm the network is healthy
Do not begin mapping on a network that already has broken logins, unreliable subsite creation, or incorrect URLs. Create a test subsite from Network Admin and confirm it loads using the network’s existing subdomain or subdirectory format. Domain mapping depends on the network bootstrap working correctly; it does not repair an unhealthy installation.
Identify the network’s URL model
Multisite networks use either subdomains or subdirectories. In a subdomain network, the creation configuration uses SUBDOMAIN_INSTALL set to true. In a subdirectory network it is set to false. Native mapping works with either model, so you do not need to rebuild the network simply because your subsites use directories. Record the primary network URL and the exact subsite you intend to map.
Prepare access and a rollback plan
- Have access to the mapped domain’s DNS management.
- Have access to the hosting panel or web-server configuration that controls the WordPress document root.
- Have permission to issue a certificate for every hostname you will use.
- Ensure you can reach Network Admin and edit the target site.
- Back up the database and
wp-config.phpbefore changing URLs or any advanced sunrise configuration.
Keep the original network address documented. If the mapped hostname is misconfigured, you may need the original address to regain administrative access and undo the change.
Step 1: Point the custom domain’s DNS to the network
Create or update the DNS records for the hostname you want to map so it resolves to the server hosting the Multisite installation. The authoritative WordPress guidance says that all domains you intend to use should already be mapped to your DNS server; in hosting environments, an additional domain may also need to be parked on the primary domain.
The exact record type and value depend on your hosting provider and network design. Use the destination supplied by the host rather than guessing an IP address. If you are mapping the bare domain and a www hostname separately, decide which one is canonical and configure the other to follow your redirect policy. Do not change the WordPress Site Address until the hostname resolves to the intended server.
DNS resolution and web-server routing are separate checks. A lookup can show the correct destination while the server still returns a default site, a hosting-panel placeholder, or an unrelated virtual host. Test the hostname in a browser and inspect the response before proceeding.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Rank #2
Step 2: Route the hostname to the WordPress document root
Configure the web server or hosting panel so the mapped hostname uses the same document root as the Multisite installation. WordPress’s preparation guidance describes several common arrangements:
- Wildcard subdomains: useful when the network’s normal sites use subdomains and the server is configured to send those hostnames to one document root.
- Virtual hosts sharing one document root: each hostname is accepted by the server, but requests are handled by the same WordPress files.
- Addon domains in a hosting control panel: the addon domain is created and pointed at the existing Multisite directory instead of a separate empty directory.
Choose the arrangement supported by your host. The essential result is that an HTTPS request for the custom hostname reaches the same WordPress installation that serves the network’s primary domain. If the server presents a different site, WordPress cannot identify the mapped subsite regardless of what you enter in Network Admin.
Verify routing before changing WordPress
Open the mapped hostname over HTTP and HTTPS, if available, and confirm that the response comes from your WordPress installation. A temporary maintenance page or a normal WordPress response is useful; a generic “domain not configured” page means the virtual host or addon-domain step is incomplete. Resolve this at the hosting layer first.
Step 3: Provision HTTPS for every mapped hostname
Install an SSL certificate for the primary domain and for each additional mapped domain. The WordPress documentation specifically recommends Server Name Indication (SNI) for additional domains. SNI allows one server to present the correct certificate for multiple HTTPS hostnames.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Test the final HTTPS hostname before changing the site’s URL. The certificate must match the hostname the browser will use, and the server must complete the TLS handshake without a warning. This order matters because WordPress administrative cookies are tied to the secure origin. If you map the site first and add HTTPS later, you can lock yourself out or create redirect and cookie symptoms that obscure the real problem.
Include every public hostname you plan to serve, such as the chosen canonical name and any hostname that will redirect to it. Certificate issuance, renewal, and hostname limits vary by provider and hosting environment, so follow the certificate provider’s current process rather than assuming that a certificate for the primary network domain covers every mapped domain.
Step 4: Enter the mapping in Network Admin
Once DNS, server routing, and HTTPS are working, apply the native mapping:
- Sign in as a network administrator.
- Open Network Admin → Sites.
- Locate the subsite and select Edit.
- On the site settings screen, find Site Address (URL).
- Replace the existing subdomain or subdirectory address with the complete mapped address, including the scheme. For example, enter
https://example.com, not justexample.com. - Save the changes.
The native workflow applies to subsites that originated in either a subdomain or a subdirectory network. You do not need to alter the network’s SUBDOMAIN_INSTALL value for an individual mapping. That constant describes the network’s site-creation model; the Site Address field identifies the public URL for this specific site.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Check the result immediately
- Open the mapped HTTPS address in a private browser window.
- Confirm that the front page, an internal page, media URLs, and the login URL use the intended hostname.
- Sign in to the subsite dashboard and verify that administrative links stay on the mapped domain.
- Visit the original subsite address and observe whether it follows the network’s intended canonical redirect behavior.
Do not test only the home page. A mapping can appear successful while media, login, or deep links still reveal a server or URL mismatch.
Fixing cookie and login errors
Symptoms
After mapping, WordPress may report that cookies are blocked or unsupported, repeatedly return you to the login form, or appear to log you in and then immediately forget the session. These symptoms often occur when the browser is using the new hostname but the server or WordPress configuration is still treating another host as authoritative.
Documented COOKIE_DOMAIN setting
The official 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'] );Make a backup before editing the file, preserve the existing PHP syntax, and clear the browser’s cookies for the affected domain before testing again. Apply the change only when the request is actually arriving with the mapped hostname; if a reverse proxy or security layer rewrites host headers, have that layer checked first.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
If the error continues
- Confirm you are visiting the exact HTTPS hostname entered in Site Address (URL), including whether you chose the bare domain or a
wwwvariant. - Verify that the certificate is valid for that hostname and that no HTTP-to-HTTPS redirect sends you to a different host.
- Check that the web server passes the original host to PHP and routes the request to the Multisite document root.
- Remove stale cookies for both the old subsite address and the new mapped address, then retry in a private window.
- Temporarily disable caching or proxy rules that might be serving a login response generated for another hostname.
Diagnosing common mapping failures
The custom domain shows another site or a hosting placeholder
This is a web-server routing problem, not a WordPress Site Address problem. Recheck the virtual host, addon-domain target, or shared document-root setting. DNS can be correct while the server still selects the wrong site.
WordPress says the site cannot be found
The ms_site_not_found path is used when WordPress has identified a network but cannot find a site for the request. Check the hostname saved in Site Address (URL), including the scheme and spelling, and confirm that the request reaches the correct network. If you have introduced custom sunrise logic, inspect that configuration only after the basic DNS, routing, and URL checks pass.
The browser reports a certificate warning
The mapped hostname does not have a valid certificate, the certificate does not include that name, or the server is presenting the wrong certificate. Fix SNI and certificate coverage before troubleshooting WordPress redirects or cookies.
Redirects loop between HTTP and HTTPS or between hostnames
Compare the canonical hostname configured at the web server, hosting panel, proxy, and WordPress Site Address. A redirect rule that forces one host while WordPress forces another can loop indefinitely. Keep one canonical HTTPS address and make every alternate hostname redirect toward it.
Recommended Free Tools
Only some pages use the old domain
Inspect the affected links and media references. The Site Address change controls the mapped site’s public URL, but hard-coded links, cached markup, or separately configured services can retain an earlier hostname. Correct the source that generated the old link rather than repeatedly changing the network URL.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Do you need a domain-mapping plugin?
For a current WordPress installation, start with the native feature. A plugin is relevant mainly when you are supporting a pre-4.5 network, need behavior not provided by the native Site Address field, or have an established compatibility workflow that depends on one.
| Consideration | Native WordPress mapping | Plugin-based mapping |
|---|---|---|
| WordPress version | Built into WordPress 4.5 and later. | Historically required for versions before 4.5; compatibility depends on the plugin and WordPress version. |
| Basic custom hostname | Enter the full HTTPS URL in Network Admin → Sites → Edit → Site Address (URL). | Usually involves plugin settings in addition to the site’s URL and server setup. |
| DNS and web-server work | Still required; a plugin cannot replace DNS, virtual-host, addon-domain, or document-root configuration. | Still required. Some products document server configuration as a separate step. |
| HTTPS and multiple domains | Use a certificate for each mapped hostname; SNI handles additional domains. | Use the same certificate and SNI requirements; the plugin does not remove TLS configuration. |
| Custom aliases or redirects | May require your own web-server or WordPress rules beyond the basic mapping field. | Some plugins add alias, redirect, or workflow controls; verify that behavior against your network. |
| sunrise.php complexity | Not normally needed for the standard native workflow. | Some current plugin options require a custom sunrise.php configuration for Multisite mode. |
| Maintenance burden | Fewer moving parts and updates are tied to WordPress core. | Adds another component to test during WordPress, PHP, theme, and hosting changes. |
| Vendor support | Use WordPress documentation and your hosting provider for infrastructure issues. | Plugin support may cover its own settings, but it cannot control your DNS provider or server. |
WordPress MU Domain Mapping remains a legacy option for networks created before native mapping. A current third-party product called Domain Mapping System advertises Multisite support but describes a custom sunrise.php setup alongside separate server and plugin configuration. Treat such a setup as an intentional compatibility choice, not as a prerequisite for ordinary WordPress 4.5+ mapping.
Understanding sunrise.php and advanced compatibility paths
The sunrise.php mechanism is loaded early in the Multisite request process. The ms_site_not_found reference documents that the hook runs when WordPress has recognized a network but cannot locate a matching site, and its notes show the SUNRISE mechanism loading wp-content/sunrise.php.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
This makes sunrise useful for advanced domain-resolution or legacy plugin workflows, but it also means a mistake can prevent WordPress from selecting the correct site before normal page loading begins. Back up the network before changing it, document the previous file and constants, and make one controlled change at a time. If native mapping meets your requirements, leaving sunrise disabled or untouched keeps the request path simpler.
Operating a network with mapped domains
Adding another mapped site
Repeat the same order for each new hostname: prepare DNS, route the hostname to the existing document root, issue and test its certificate, then edit the target subsite’s Site Address (URL). Treat every hostname as a separate TLS and server-routing responsibility even when all sites share one WordPress installation.
Changing a mapped domain later
Prepare and test the replacement hostname before editing the Site Address. Keep the old hostname available long enough to recover administration, then update redirects and external integrations deliberately. Changing the field without preparing the replacement host creates the same failure modes as an initial mapping, including a server placeholder, certificate warning, or lost login session.
Quick Recap
Keeping renewals and configuration documented
- Maintain a list of every mapped hostname and its certificate renewal method.
- Record which DNS zone, virtual host, addon domain, and document root serve each hostname.
- Document the network’s subdomain or subdirectory model and the location of any
COOKIE_DOMAINor sunrise configuration. - After WordPress, hosting, proxy, or certificate changes, test a front page, deep link, media URL, and administrator login for each important mapped site.
A concise pre-launch checklist
- The Multisite network creates and serves normal subsites correctly.
- You know whether the network uses subdomains or subdirectories.
- The mapped domain resolves to the server hosting the network.
- The web server accepts the hostname and points it to the same WordPress document root.
- An HTTPS certificate covers the mapped hostname, with SNI configured where additional domains share the server.
- Network Admin → Sites → Edit contains the complete HTTPS URL.
- The mapped front page, internal links, media, and dashboard load on that hostname.
- If login cookies fail, the documented
COOKIE_DOMAINdefinition has been considered and added after a backup. - No custom plugin or
sunrise.phpcode is being used unless a specific compatibility requirement justifies it.
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.
