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.
To add a second domain to a WordPress server, complete three separate jobs: point the domain’s DNS records at the server, configure Apache or Nginx to route that hostname to the intended WordPress directory, and install HTTPS for the new name. If the domain should be a separate site, use a separate document root and database; if it should be another site in one WordPress installation, use Multisite and map the domain after the server and TLS configuration are working.
The correct procedure depends on whether the new hostname is an alias for the existing site, an independent WordPress installation, or a mapped Multisite site. Decide that architecture first; changing it after DNS and URLs are live can create redirect, cookie, and database problems.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →
Choose what the second domain is supposed to do
“Add another domain” can mean three different configurations. They are not interchangeable, and each requires a different WordPress setup.
Use the same site (an alias)
If example.net should show exactly the same content as example.com, configure the web server to accept both hostnames and send them to the same document root. This is appropriate for a defensive domain, a country-code variant, or a temporary migration address. WordPress should normally have one preferred, canonical URL; otherwise search engines and visitors can see duplicate URLs and login or redirect behavior can become confusing.
#1 Best Overall
Use a separate WordPress installation
For an independent site, create a new document root, a separate database and database user, and its own virtual host or server block. The two sites may run on the same server, but their files, uploads, configuration, updates and failure domains remain separate. This is the simplest model when the sites have different owners, plugins, themes or maintenance schedules.
Use WordPress Multisite
Multisite creates virtual sites that share WordPress core files while keeping separate site data structures, tables and upload directories. It is useful when one administrator manages a group of related sites. You must choose subdomain or subfolder mode when creating the network, then use domain mapping for a different public domain. WordPress documents the network creation process at Create A Network.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Requirement | Same-site alias | Separate installation | Multisite with mapped domain |
|---|---|---|---|
| Document root | Existing root | New root for the second site | Network’s existing root |
| Database | Existing database | Separate database recommended | Network database with separate site tables |
| Web-server routing | Additional hostname on the existing host | New virtual host/server block | Hostname routed to the network root plus Multisite rewrite rules |
| WordPress URL change | Keep one canonical URL and redirect the alias | Set the new installation’s own URLs | Edit the site’s full Site Address in Network Admin |
| Best fit | One site reachable through more than one name | Truly independent sites | Several related sites sharing core files and administration |
Check prerequisites before changing anything
- Administrative access to the DNS zone for the new domain.
- Root or equivalent privileges to edit Apache or Nginx configuration, reload the service and install certificates, unless your host provides these operations through a control panel.
- A confirmed document-root path for the existing site, a new site, or the Multisite network.
- A database and database user for an independent installation.
- A backup of WordPress files, the database and the current web-server configuration.
- A certificate that covers the added hostname. WordPress recommends SSL for the primary and other mapped domains, using SNI for additional domains; see WordPress Multisite Domain Mapping.
Shared hosting may not permit virtual-host edits at all. In that case, use the host’s “add domain” or “addon domain” workflow, or move to a plan that exposes DNS and web-server configuration. Do not edit files that your provider regenerates automatically without following its documented procedure.
Point DNS at the server
Create the records required by your DNS provider so the new hostname resolves to the server’s public address. WordPress states that DNS must map the domain to the server IP and that the server must map the hostname to the WordPress installation directory; the full preparation guidance is at Before You Create A Network.
Choose the records
- Use an
Arecord for an IPv4 address. - Use an
AAAArecord when the server accepts IPv6. - If your DNS provider supports an equivalent alias record, use it only as that provider documents; the end result must be a hostname resolving to the server that runs WordPress.
- Add records for every hostname you intend to serve, such as the bare domain and
www, rather than assuming one automatically covers the other.
DNS changes are cached according to the zone’s TTL, so a resolver may continue returning the previous address for a while. Test with your DNS provider’s tools or a command such as dig from a machine that can query the public DNS system. Do not proceed on the assumption that an edited DNS panel means the change is already visible everywhere.
Configure Apache virtual hosts
Apache selects a VirtualHost by the requested IP address and hostname. Each independent site should have its own host definition. An alias can use the existing host with an additional ServerAlias; a separate installation needs its own DocumentRoot. WordPress’s preparation documentation calls out virtual hosts, mod_rewrite and AllowOverride requirements.
Rank #2
- Used Book in Good Condition
Same site through a second hostname
Add the new hostname to the existing site’s host definition. A minimal pattern is:
<VirtualHost *:80>
ServerName example.com
ServerAlias example.net www.example.net
DocumentRoot /var/www/example.com
<Directory /var/www/example.com>
AllowOverride All
Require all granted
</Directory>
</VirtualHost>Use the real canonical name, aliases and document-root path. If the second domain is intended only as a redirect, do not leave it serving duplicate content; create a host that redirects it to the canonical HTTPS URL instead.
Separate WordPress installation
Create a new host definition whose ServerName and optional ServerAlias identify only the second site:
<VirtualHost *:80>
ServerName example.net
ServerAlias www.example.net
DocumentRoot /var/www/example.net
<Directory /var/www/example.net>
AllowOverride All
Require all granted
</Directory>
</VirtualHost>Install the second WordPress copy in /var/www/example.net, create its database, and complete the WordPress installer only after the host routes correctly. Keeping a distinct root prevents Apache from accidentally serving the first site’s wp-config.php and uploads.
Make WordPress permalinks work
Pretty permalinks require Apache’s rewrite support and permission for WordPress rules in .htaccess. Enable the rewrite module using your operating system’s normal Apache tooling, and ensure the relevant directory permits the overrides WordPress needs. A typical WordPress .htaccess file contains:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPressDo not copy this file into an unrelated directory or assume that AllowOverride All is acceptable for every security policy. If your server uses a narrower policy, permit the specific override classes required by the WordPress rules. WordPress’s Nginx documentation also explains the difference between Apache rewrite handling and Nginx configuration.
Rank #3
Enable the host and reload Apache
Use the site-enable and service-reload commands supplied by your Linux distribution, hosting panel or container image. Command names differ between operating systems, so do not paste a Debian-specific command into a Red Hat-based system or a managed panel. Validate the configuration before reloading; a syntax error can leave Apache unable to restart. After the reload, request the hostname with both HTTP and HTTPS and verify that the intended virtual host, not the default host, answers.
Configure Nginx server blocks
Nginx uses server blocks rather than Apache VirtualHost sections. It does not read .htaccess, and WordPress cannot generate Nginx configuration automatically, so rewrite and PHP-FPM behavior must be written in the Nginx configuration. The official references are Nginx and Multisite Network Administration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Basic server block for an independent site
server {
listen 80;
listen [::]:80;
server_name example.net www.example.net;
root /var/www/example.net;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}Replace the PHP-FPM socket or upstream with the one configured on your server. Distribution packages commonly use a versioned socket or a named upstream, so the example path is not universal. The important behavior is that existing files are served directly, other requests fall through to index.php, and PHP requests reach the configured FPM service.
Route a second hostname to the existing site
For an alias, add the second name to the same server_name directive and keep the existing root and PHP-FPM settings. If the alias should redirect, use a separate server block that returns a permanent redirect to the canonical HTTPS hostname instead of serving the same pages twice.
Apply Multisite rules deliberately
Subdomain and subfolder Multisite networks have different rewrite requirements. Use the Nginx rules for the network type you selected, and make sure the block that receives the mapped domain has the same root and PHP-FPM upstream as the network. Test an ordinary page, a nonexistent path, an uploaded image and wp-admin; a block that works for the home page but omits the network rewrites will fail on these other requests.
Test and reload safely
Run Nginx’s configuration test command supplied by your installation, correct every reported error, and reload through the service manager or hosting control panel. A reload applies the new block without needlessly terminating existing connections. Check which block is selected when multiple blocks listen on the same address; an unmatched hostname can be answered by the default server.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchInstall HTTPS for the added domain
HTTP routing alone is not enough. Obtain a certificate whose names include the new domain and any hostname you serve, such as www.example.net. Configure the certificate and private key in the TLS virtual host or server block, then redirect HTTP to HTTPS once the secure endpoint works.
For multiple domains, Server Name Indication (SNI) allows the server to select the correct certificate for each hostname. WordPress specifically recommends SSL for the primary domain and SNI for other domains in its domain-mapping guidance. Confirm that the certificate’s subject or SAN list contains the exact hostname; a certificate for example.com does not automatically cover example.net.
After installing TLS, test:
https://example.net/andhttps://www.example.net/, if both are configured.- A permalink below the home page.
- An image or other uploaded media URL.
/wp-admin/and the login form.- HTTP requests, which should follow the intended redirect without a loop.
Set the WordPress address
Independent installation
During installation, set WordPress Address (URL) and Site Address (URL) to the new site’s final HTTPS URL. If the installer was run with a temporary hostname, correct both values before publishing links. A mismatch between the database URL, the server hostname and the certificate commonly produces redirect loops, mixed-content warnings or links that return to the first site.
Multisite domain mapping
Complete DNS, web-server routing and TLS first. Then open Network Admin → Sites, edit the target site, and enter its complete mapped address, for example https://example.net, in the site’s Site Address (URL). Native domain mapping is available in WordPress 4.5 and later; older WordPress versions required a domain-mapping plugin.
WordPress’s mapping guidance is at WordPress Multisite Domain Mapping. The mapped value must include the scheme (https://) and the hostname, not merely the bare domain. Save the change only after the new host reaches the network’s WordPress root, otherwise Network Admin may become difficult to reach.
Cookie and login issues
If the mapped site reports that cookies are blocked or login repeatedly returns to the login screen, first check that every redirect ends at the same HTTPS hostname and that no proxy is stripping the forwarded protocol. The official mapping guide documents define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); as a possible configuration adjustment. Treat it as a targeted compatibility fix, not a substitute for correcting DNS, TLS or URL mismatches.
Best Value
Verify the complete request path
Verification should follow the request from DNS through the web server and WordPress rather than checking only the home page.
- Resolve the new hostname and confirm its A and, if used, AAAA records point to the intended server.
- Request the hostname over HTTP and HTTPS. Confirm that HTTPS presents a certificate covering that exact name.
- Check the response body or headers to ensure the intended virtual host/server block answered, not a default site.
- Open a pretty permalink, a deliberately nonexistent URL and a media file. All should be handled by the intended WordPress installation or network.
- Inspect canonical redirects and generated links. They should use the chosen canonical domain and HTTPS scheme.
- Log in to
wp-admin, save a test post or page, and verify that the editor and logout flow stay on the mapped hostname. - For Multisite, revisit Network Admin → Sites and confirm that the target site’s Site Address is the full mapped URL.
Troubleshoot the failures that matter most
The old site or a default page appears
DNS may still point to the old server, or the new hostname may not match ServerName, ServerAlias or Nginx’s server_name. Check both the public DNS answer and the server’s host-selection order. An unmatched hostname is commonly handled by the first or default host.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute404 errors occur only on inner pages
Apache may lack rewrite support or the directory may disallow the required overrides. On Nginx, the block may be missing the WordPress try_files fallback or the Multisite-specific rules. Remember that Nginx will never read an Apache .htaccess file.
PHP downloads or returns a gateway error
The Nginx PHP location may point to the wrong PHP-FPM socket or upstream, or the FPM service may not be running. Verify the configured socket, permissions and service status for the PHP version used by that site. Apache installations should likewise verify that PHP handling is enabled for the selected virtual host.
HTTPS loops or shows mixed content
Check that the certificate is installed on the host that answers the new name, that WordPress URLs use https://, and that a reverse proxy communicates the original scheme correctly. Update hard-coded HTTP asset URLs only after confirming the canonical URL; indiscriminate database replacements can corrupt serialized WordPress data.
Multisite login fails after mapping
Confirm the mapped URL in Network Admin, clear old browser cookies for the domain, and test in a private window. Then inspect redirects and proxy headers before considering the documented COOKIE_DOMAIN adjustment. A cookie fix cannot make a hostname that still routes to the wrong site work.
Changes appear inconsistent
Resolver, browser and proxy caches can retain old DNS or redirect responses. Compare results from more than one network, check the authoritative DNS zone, and wait for the record’s TTL to expire before treating a cached answer as proof that the server configuration failed.
Operational and security details after it works
- Use least-privilege ownership and permissions for each document root, and keep one site’s writable uploads directory from being shared accidentally with another.
- Back up each database and its files independently, including the Multisite network database and uploads.
- Keep the canonical-domain decision documented so future plugin, SEO and redirect changes do not reintroduce duplicate hostnames.
- Renew every certificate that covers the added domain and test renewal before expiry.
- Monitor Apache or Nginx access and error logs for requests reaching the wrong host, repeated redirects, PHP-FPM failures or unexpected paths.
- When removing the domain, remove or redirect its DNS record only after deciding what should happen to existing links, certificates and search-engine references.
Which setup should you use?
Choose an alias when the added domain is merely another entrance to one site and you can enforce one canonical URL. Choose a separate installation when the site needs independent databases, plugins, themes, users or maintenance. Choose Multisite when related sites should share WordPress core and central administration, and you are prepared to manage network-level rewrites, mapped URLs and shared operational risk. In every case, the order is the same: DNS, web-server routing, TLS, WordPress URL configuration, then end-to-end verification.
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.
