A WordPress Multisite subsite often starts with a network subdomain or path, but a client or brand site may need to appear under its own independent domain. WordPress Multisite domain mapping makes that possible, provided the change is handled across several configuration layers rather than treated as a single WordPress setting.
The practical sequence has three parts: DNS must direct the additional domain to the appropriate server, the web server or hosting panel must route that domain to the WordPress installation, and Network Admin must store the final Site Address for the selected subsite. Before changing a live site, create a full database and file backup, test on staging where possible, and confirm HTTPS coverage. Hosting-specific DNS and routing procedures vary, so the WordPress-side workflow should be separated from environment-dependent instructions.
What WordPress Multisite Domain Mapping Does
Domain mapping allows a subsite created under a network subdomain or subdirectory to be displayed under a separate top-level domain. For example, a subsite can retain its place inside the Multisite network while visitors use an independent client or brand domain as the site’s public address. Native domain mapping is documented as available in WordPress 4.5 and later.
Network URL, Subsite and Custom Domain
It helps to distinguish the original network URL from the mapped domain. The network URL may use a subdomain or path belonging to the main installation. The mapped domain is the address intended for visitors and administrators of that particular subsite. In Network Admin, the selected subsite’s Site Address (URL) is changed to the complete mapped URL.
This change does not automatically transfer domain registration, DNS management, email, or other services associated with the domain. It only forms part of the process that makes WordPress serve the selected subsite at that address. DNS and server routing must support the change before the WordPress URL is updated.
Pre-Configuration Checklist
Begin by confirming that the Multisite network and the target subsite work correctly through their existing network-based address. Identify the exact subsite that will receive the independent domain and decide which complete final URL should be used, including the HTTPS form intended for visitors.
Record the Current Access Paths
Write down the current network URL and the planned mapped URL before changing anything. This gives the agency, freelancer or site owner a clear recovery reference if the new address does not load as expected. Also note how access to Network Admin and file management will be retained during testing.
- Create a full database and file backup before changing DNS, server rules, the Site Address or
wp-config.php. - Use staging where possible to test the mapping sequence before applying it to a live client or brand site.
- Keep a recovery route through the network administrator or file access.
- Do not switch the public URL until DNS routing and HTTPS for the intended domain have been checked.
A wrong URL or server rule can make the subsite or its administration area inaccessible. Preparation is therefore part of the configuration, not an optional administrative task.
DNS and Server Routing
DNS and web-server routing solve different problems. Both must be correct before the mapped domain can reliably serve the intended Multisite subsite.
DNS Resolution Versus Web-Server Routing
The additional domain must already be mapped in DNS to the appropriate server. DNS directs the domain toward the infrastructure where the WordPress installation is hosted, but a successful DNS lookup alone does not establish that WordPress will serve the selected subsite.
The web server or hosting configuration must also route the domain to the WordPress installation directory. Depending on the environment, this may involve virtual hosts, an addon domain, a hosting-panel domain or another supported routing arrangement. The exact record names, target values and routing syntax depend on the hosting provider, control panel, reverse proxy or other infrastructure, so there is no single universal instruction to copy into every environment.
Verify that the domain reaches the intended WordPress installation before replacing the subsite’s Site Address. If the domain reaches a different directory or a default hosting page, changing the WordPress URL can make diagnosis more difficult.
When Wildcard DNS Is Relevant
Wildcard subdomains are relevant to a domain-based network that creates sites on demand. In that situation, wildcard DNS and corresponding server handling can allow newly created subdomains to reach the installation without configuring each one separately.
Wildcard DNS is not necessarily required for every manually assigned custom domain. A specific mapped domain may use another supported DNS and server-routing method, depending on the hosting environment. Do not apply a wildcard rule simply because the installation uses Multisite, and do not present one provider’s panel fields or server syntax as universal.
SSL and HTTPS for Mapped Domains
HTTPS must be planned for the primary network domain and for every additional domain mapped to a subsite. This is especially important because administrators use authenticated sessions on the mapped domain. A certificate covering only the main network domain is insufficient for independent mapped domains.
Certificate Coverage and SNI
WordPress documentation recommends installing SSL for the primary domain and using SNI for additional domains. The practical requirement is certificate coverage for each mapped domain that visitors or administrators will use. Certificate issuance and hosting-panel steps vary by environment and are not one universal procedure.
Before changing the Site Address, confirm that HTTPS works for the mapped domain itself. Check that the intended address loads consistently, that redirects do not alternate between HTTP and HTTPS, and that administrators can reach the login area through the final address. Do not direct users to the new URL while HTTPS is valid only for the main network domain.
Assigning the Domain in Network Admin
Once DNS, server routing and HTTPS preparation are complete, make the WordPress-side change in Network Admin. The documented workflow applies to the selected subsite, not to an unrelated general network setting.
The Network Admin Site Address Workflow
- Open Network Admin and navigate to Sites.
- Edit the subsite that should use the independent client or brand domain.
- Replace its Site Address (URL) with the complete mapped URL, using the final HTTPS form intended for visitors.
- Save the change only after confirming that DNS, server routing and HTTPS are ready.
- Check the front end, administration area, redirects, permalinks and front-end asset URLs.
The universal WordPress action is short, but the surrounding preparation is not. After saving, confirm that the selected subsite is being served rather than another site in the network. Retain the existing recovery route while checking the result, particularly when the change is applied to a live client site.
If the new address fails, avoid making several unrelated changes at once. Return to the three layers: confirm that DNS reaches the appropriate server, confirm that the server routes the domain to the WordPress installation, and confirm that the saved Site Address contains the intended complete URL.
Diagnosing Cookie Errors and Login Failures
Blocked-cookie messages, failed logins without a clear error and redirect loops can appear after domain mapping. These symptoms should be investigated methodically. A login problem does not prove that cookies are the original cause; an incorrect URL, incomplete HTTPS, inconsistent redirects, DNS error or stale cache can produce a similar experience.
A Layered Login Troubleshooting Sequence
Start with the least invasive checks and move toward configuration changes only when the basic layers are confirmed.
- Verify that the mapped domain resolves to the appropriate server and that the server routes it to the WordPress installation.
- Confirm that HTTPS is valid for the mapped domain and that redirects consistently lead to the intended HTTPS address.
- Check the subsite’s saved Site Address in Network Admin and confirm that it matches the public URL being tested.
- Test with cleared or private browser cookies to distinguish stale browser data from a persistent configuration issue.
- Review caching and proxy settings if an old redirect, session or page continues to appear.
- Only after these checks, investigate the cookie configuration area in
wp-config.php.
The official domain-mapping documentation identifies blocked-cookie errors or failed logins without an error as symptoms that may require checking wp-config.php and provides a COOKIE_DOMAIN configuration example. Treat that example as a conditional troubleshooting test, not as a guaranteed or universal fix. Cookie behavior can differ between mapped domains, network subdomains, the main site, caching layers and authentication plugins.
Back up wp-config.php and the site before testing a cookie-related change. Apply the change carefully, then test login on the affected mapped domain. If the result is worse, use the recovery route through file access or the network administrator rather than continuing to add unverified constants.
Post-Change Regression Checks
A change that appears to repair one login can affect another domain in the same network. After any cookie configuration test, verify both the mapped subsite and the rest of the network.
- Test login and logout on the mapped subsite.
- Check authentication on the network’s other domains and subdomains.
- Look for redirect loops, repeated login prompts or blocked-cookie messages.
- Review caching and proxy behavior when stale redirects or sessions persist.
- Confirm that the front end, administration area and HTTPS address remain accessible.
Do not treat COOKIE_DOMAIN as a solution that can be applied safely to every Multisite arrangement. Its effect should be tested in the affected environment, with a backup and a recovery path available.
WordPress Multisite domain mapping is best handled as a three-layer change: DNS points the domain to the appropriate server, server or hosting configuration routes it to the WordPress installation, and Network Admin assigns the final Site Address to the selected subsite. SSL must cover every mapped domain, including the domain used for administrative sessions. For agencies and freelancers, the practical handoff checklist is simple: back up the site, test on staging, configure DNS, verify routing, validate HTTPS, assign the URL, check the front end and administration area, and perform login regression testing. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.