A domain alias is a configuration that makes one domain name serve identical content to another domain name, the same website, the same pages, the same everything, under a different address. When a visitor navigates to either domain they see the same content without being redirected to the other domain. The address bar shows whichever domain they arrived at. Both domains are active and serving content simultaneously.

The alias relationship means one domain is treated as an alternative name for another, an alias, in the dictionary sense of the word. The primary domain is the canonical domain where content is authoritative. The alias domain is an additional name through which the same content is accessible. Both names resolve to the same web infrastructure and serve the same content but they remain two distinct addresses in the browser’s address bar.

Domain aliases are sometimes called domain aliases, parked domains in the hosting sense, addon domains, or mirror domains depending on the hosting platform or configuration context. The specific terminology varies by platform but the concept is consistent, multiple domain names serving identical content from the same hosting infrastructure.

Understanding domain aliases clearly, and particularly how they differ from domain redirects: is important because choosing the wrong approach has significant SEO consequences. Domain aliases and domain redirects achieve superficially similar outcomes, both make two domain names reach the same content, but they accomplish this in fundamentally different ways with very different implications.

How domain aliases work technically

A domain alias is implemented at the web server or hosting platform level, the server is configured to respond to requests for multiple domain names with the same content.

DNS configuration: both the primary domain and the alias domain have DNS records pointing to the same web server infrastructure. The primary domain, example.com: has A records or CNAME records pointing to the server. The alias domain, example.net: has its own DNS records pointing to the same server.

Server configuration: the web server, Apache, Nginx, or a hosting platform, is configured to accept requests from both domain names and serve the same content for both. In Apache this is done through ServerAlias directives in virtual host configuration. In Nginx by listing multiple server_name values. On hosting platforms through a domain management interface that allows adding additional domains to serve the same site.

Content serving: when a visitor requests example.net the server receives the request, recognises example.net as an alias for the primary site, and serves the same content as it would for example.com. The HTTP response is a 200 OK: the content is delivered directly without any redirect. The visitor’s address bar shows example.net throughout their visit.

SSL certificates: for the alias domain to serve content over HTTPS correctly it needs SSL certificate coverage. A multi-domain SAN certificate covering both example.com and example.net allows both domains to serve HTTPS without certificate errors. A wildcard certificate covering *.example.com covers subdomains of the primary domain but not the alias domain, separate certificate coverage is needed for the alias.

Domain alias vs domain redirect

Domain aliases and domain redirects are the two fundamentally different approaches to making multiple domain names reach the same content. Understanding the distinction is critical, choosing the wrong approach has significant SEO consequences.

Domain alias: both domains serve content. No redirect occurs. The visitor’s address bar shows whichever domain they arrived at. Both domains are indexable by search engines. Requires SSL on both domains. Both domains appear as separate addresses in web analytics.

Domain redirect: one domain redirects to the other. The redirecting domain serves no content, only a redirect response. The visitor’s address bar changes to the destination domain. Only the destination domain is indexed, the redirecting domain passes visitors and equity to the destination. Requires SSL on the redirecting domain to handle HTTPS connections before the redirect fires.

The key difference is what happens to the visitor’s address bar and what search engines see. A redirect sends the visitor to the destination, they end up at the destination domain. An alias serves the content directly, the visitor stays at whatever domain they arrived at.

Which to use when: the choice between alias and redirect depends on the desired outcome.

Use a domain redirect when one domain is the canonical address and the other should funnel all traffic and SEO equity to it. Brand protection domains, old domains after rebranding, www to non-www canonicalisation, all should use permanent redirects. The redirecting domain has one purpose, sending visitors and link equity to the canonical destination.

Use a domain alias when content genuinely needs to be accessible under multiple domain names simultaneously, typically for specific technical or business reasons where both names must remain active as independent addresses. True alias use cases are less common than redirect use cases.

The SEO problem with domain aliases

Domain aliases create a fundamental SEO problem, the same content accessible at two different URLs creates duplicate content. Search engines see identical pages at example.com/page and example.net/page: two separate URLs with the same content. This splits SEO equity between the two addresses and creates ranking confusion.

Duplicate content consequences: when the same content appears at two URLs search engines must decide which URL to index and rank. They cannot rank both equally because they are identical, showing the same result twice would be unhelpful to searchers. Google typically selects one URL to treat as canonical and filters the other from prominent search results. This selection may not favour the URL the domain owner intended.

Split link juice: backlinks pointing to example.com contribute their equity to example.com. Backlinks pointing to example.net contribute their equity to example.net. The two domains accumulate separate authority profiles rather than consolidating under one canonical domain. The total authority across both domains is less than the combined authority would be if concentrated on one domain through redirects.

Canonical tags as partial mitigation: adding <link rel="canonical" href="https://example.com/page"> to pages served under the alias domain instructs search engines that the primary domain is the canonical version. This reduces, but does not eliminate, the duplicate content problem. Canonical tags are hints that search engines generally respect but are not required to follow. The alias domain still serves content and still attracts crawling, consuming crawl budget even if the canonical tag reduces indexation of the alias pages.

Permanent redirect is almost always better for SEO: for virtually every situation where a domain alias might be considered a permanent redirect from the non-canonical domain to the canonical domain is the better SEO choice. The redirect eliminates duplicate content, consolidates all link juice at the canonical domain, and provides unambiguous canonical signals to search engines.

Legitimate use cases for domain aliases

Despite the SEO disadvantages there are specific situations where domain aliases are used, typically for technical or business reasons where the SEO trade-off is accepted.

Multi-region content serving with geographic routing: serving content from the same infrastructure under region-specific domain names, example.co.uk serving UK-localised content, example.de serving German-localised content, where the localised content is genuinely different. When the content differs meaningfully by region the duplicate content problem is reduced, the domains serve related but distinct content rather than identical content. Hreflang annotations signal the regional relationship to search engines.

Platform or SaaS multi-tenant hosting: SaaS platforms where each customer has their own domain name, customer1.com, customer2.com: pointing to the same platform infrastructure. Each customer’s domain serves their specific account content, which may be built from the same templates but contains different customer-specific data. These are not true content aliases, the content differs by customer, but the infrastructure setup resembles domain aliasing.

Staging and preview environments: development environments where a staging domain, staging.example.com: serves the same codebase as the production domain, example.com: for testing purposes. The staging domain should be blocked from search engine indexing through noindex directives or password protection, preventing the staging content from creating duplicate content issues in search indexes.

Legacy system compatibility: technical systems or integrations that are hardcoded to reference specific domain names may require those domains to remain active and serving content rather than redirecting. When changing the domain would require updating complex integrations an alias may be a temporary solution during a migration period, with the intention of eventually redirecting once integrations are updated.

Email and application authentication: some authentication systems, particularly older SAML or OAuth implementations, validate that the domain in the authentication flow matches a registered domain. If the application is accessible under multiple domains the authentication may need to work for all of them, which can require content aliases rather than redirects that would change the domain in the authentication flow.

Domain aliases in hosting platforms

Major hosting platforms implement domain aliases through their own terminology and interfaces, though the underlying concept is consistent.

cPanel hosting: traditional shared hosting using cPanel distinguishes between addon domains, separate domains with separate content, and domain aliases or parked domains, additional domains serving the same content as the primary domain. The Parked Domains or Domain Aliases section in cPanel allows adding alias domains that map to the primary domain’s content.

WordPress hosting: some WordPress hosting platforms support domain mapping, configuring multiple domains to display the same WordPress installation. WordPress Multisite supports domain mapping at the network level. Some managed WordPress hosts support single-site domain mapping as a feature.

Cloudflare: at the DNS level Cloudflare can be configured to point multiple domains to the same origin server. The alias behaviour is implemented at the origin server level, Cloudflare routes traffic from both domains to the same server which responds with the same content.

Vercel, Netlify, and modern platforms: modern hosting platforms typically support adding multiple custom domains to the same deployment or site. The platform serves the same deployed content for all configured domains. These platforms also support redirects, directing one domain to another, and the choice between alias and redirect is typically exposed through the platform’s domain management interface.

Domain alias vs subdomain alias

Domain aliases involve separate registered domain names serving the same content. Subdomain aliases involve subdomains of the same domain serving the same content, a related but distinct configuration.

Subdomain alias: www.example.com and example.com both serving the same content without a redirect between them is a subdomain alias situation, the www subdomain is an alias for the root domain. This is a common misconfiguration, both should be configured so that one redirects to the other rather than both serving content.

Cross-domain alias: example.com and example.net both serving the same content, different registered domains. This is the domain alias scenario described throughout this article.

Both subdomain aliases and cross-domain aliases create duplicate content problems with similar SEO consequences. In both cases the correct solution for most situations is to choose a canonical address and redirect all others to it rather than serving content at multiple addresses simultaneously.

Migrating from domain alias to domain redirect

Organisations that have been using domain aliases, serving identical content at multiple domains, may want to migrate to a redirect configuration for SEO benefits. This migration requires careful handling to avoid disrupting the authority that has accumulated under the alias domain.

Audit the alias domain’s authority: before migrating check the alias domain’s backlink profile and indexed pages. If the alias domain has accumulated backlinks and indexed pages those are assets that the redirect will capture, the permanent redirect will transfer their equity to the canonical domain.

Implement permanent redirects: configure 301 redirects from the alias domain to the canonical domain. Path-preserving redirects, forwarding each path on the alias domain to the equivalent path on the canonical domain, preserve path-level link equity from backlinks pointing to specific pages.

Update canonical tags: ensure all pages on the canonical domain include canonical tags pointing to themselves. Remove any canonical tags on the alias domain that were previously pointing to the canonical domain, they are no longer needed once the redirect is in place.

Monitor post-migration: after implementing the redirect monitor the canonical domain’s authority scores and rankings. The authority that was split between the canonical and alias domains should consolidate on the canonical domain over time, typically over several weeks as search engines process the redirect signals.