A subdomain is a label added to the left of a root domain that creates a distinct, separately addressable section within the same domain. www.example.com has the subdomain www. blog.example.com has the subdomain blog. app.redirect.supply has the subdomain app. The subdomain extends the domain name leftward, adding specificity and creating a new addressable hostname that can point to different infrastructure, serve different content, or fulfil a different purpose than the root domain.

Subdomains are created by adding DNS records in the root domain’s DNS zone: no separate registration is required. Creating shop.example.com means adding a CNAME record or A record for shop in the example.com zone. The root domain registration covers all subdomains beneath it. Unlimited subdomains can be created from a single domain registration at no additional registration cost.

Subdomains are one of the most versatile tools in web infrastructure. They separate different functions, app.example.com for the web application, api.example.com for the API, docs.example.com for documentation, status.example.com for the status page. They enable different teams to manage different sections independently. They allow different subdomains to be hosted on completely different servers or platforms. And they provide a mechanism for organising large web properties into distinct, separately manageable units.

How subdomains work

A subdomain is simply a label in the DNS hierarchy, a node in the domain tree between the root domain and any further subdomain levels. The subdomain is resolved through DNS like any other hostname, a DNS lookup for shop.example.com follows the same resolution process as a lookup for example.com: querying root nameservers, TLD nameservers, and the authoritative nameserver for example.com, which returns the DNS record configured for the shop subdomain.

Creating a subdomain involves adding a DNS record in the root domain’s zone specifying what the subdomain resolves to.

CNAME subdomain: the most common subdomain configuration for connecting to third-party services. shop.example.com CNAME stores.platform.com creates a subdomain that resolves to whatever IP address stores.platform.com currently points to. CNAME records for subdomains automatically follow infrastructure changes at the target, if the platform updates its IP addresses the subdomain continues working without any DNS changes.

A record subdomain: blog.example.com A 203.0.113.42 creates a subdomain that resolves directly to a specific IP address. Used when the subdomain points to infrastructure with a known stable IP address or when a CNAME is not appropriate.

AAAA record subdomain: example.com AAAA 2001:db8::1: the IPv6 equivalent of an A record for the subdomain.

Multiple subdomains: a single zone can contain records for unlimited subdomains. Each subdomain has its own DNS record or set of records. Different subdomains can point to completely different servers, api.example.com pointing to API infrastructure, www.example.com pointing to web infrastructure, mail.example.com pointing to mail infrastructure, all managed from within the same example.com zone.

Levels of subdomains

Subdomains can be nested, adding multiple labels to the left of the root domain creates multi-level subdomain structures.

Single-level subdomain: one label added to the root domain. www.example.com, blog.example.com, api.example.com. The most common subdomain depth for most web applications.

Two-level subdomain: two labels added to the root domain. app.blog.example.com, v2.api.example.com, us-east.app.example.com. Used for more granular organisation, regional deployments, versioned APIs, nested service structures.

Deeper subdomain nesting: technically unlimited levels of subdomain nesting are possible, a.b.c.d.example.com is valid DNS. In practice more than three levels of subdomain nesting is unusual and can create DNS management complexity. Most real-world applications use one or two subdomain levels.

DNS zone delegation for deep subdomains: deeply nested subdomains that require separate management can be delegated to separate DNS zones using NS records. prod.api.example.com NS ns1.apiplatform.com delegates the entire prod.api.example.com subtree to the API platform’s nameservers. Everything under prod.api.example.com is managed by the delegated nameservers independently of the parent example.com zone.

Subdomains and redirect management

Subdomains interact with redirect management in multiple ways, as sources of redirects, as destinations for redirects, and as the primary mechanism for connecting domains to redirect infrastructure.

www subdomain redirect: redirecting between www.example.com and example.com is one of the most universal redirect configurations. Whichever form is non-canonical must permanently redirect to the canonical form. The non-canonical form serves only as a redirect trigger, visitors and crawlers are immediately sent to the canonical domain.

Connecting subdomains to redirect infrastructure: subdomains are the preferred connection point for redirect management services because they can use CNAME records: the most flexible DNS connection mechanism. www.example.com CNAME proxy.redirect.supply connects the www subdomain to Redirect Supply’s infrastructure. All traffic arriving at www.example.com reaches the redirect service which applies configured redirect rules.

The advantage of using subdomains over root domains for redirect infrastructure connection is the CNAME flexibility, subdomains are not subject to the CNAME restriction at the apex. Any subdomain can be connected to any redirect management hostname via CNAME without requiring A records, ALIAS records, or Cloudflare-specific solutions.

Subdomain redirects: redirecting retired subdomains to current URLs is a common redirect management task. old.example.com redirecting to example.com when a subdomain is retired. shop.example.com redirecting to example.com/shop when a subdomain is consolidated into the main domain. beta.example.com redirecting to app.example.com when a beta service becomes the main application.

Subdomain wildcard redirects: a wildcard redirect matching *.example.com catches all subdomains, including ones that may not have explicit DNS records, and redirects them to a default destination. Useful for domains where content previously existed across many subdomains and all those subdomains need to be redirected to a new domain structure.

Subdomains and SEO

The relationship between subdomains and SEO is nuanced, search engines treat subdomains differently from paths in some contexts while treating them as part of the same root domain in others. Understanding this nuance helps inform decisions about subdomain architecture.

Subdomain vs subdirectory debate: a long-standing SEO question is whether to host content, particularly blogs and documentation, on a subdomain (blog.example.com) or a subdirectory (example.com/blog). The subdirectory approach consolidates all content under the root domain’s authority, every page on example.com/blog contributes directly to the example.com authority profile. The subdomain approach puts blog content on a separate hostname that may develop its own authority profile separately from the root domain.

Google has stated that it treats subdomains and subdirectories equivalently in most cases, both can rank well and both contribute to the overall domain’s reputation. In practice subdirectories tend to show ranking benefits faster because the authority consolidation is more direct. Subdomains are appropriate when the content is genuinely different in nature or when technical requirements necessitate separation.

Subdomain authority transfer: link juice from backlinks pointing to a subdomain contributes to that subdomain’s authority and, through the domain authority relationship, to the root domain’s overall profile. Moving content from a subdomain to a subdirectory with 301 redirects consolidates the authority from both under the root domain path structure.

Duplicate content risk: serving the same content at both a subdomain and a subdirectory without a redirect between them creates duplicate content. If blog.example.com/post and example.com/blog/post serve identical content search engines must choose one as canonical, potentially splitting authority between the two. Always use canonical tags and permanent redirects to consolidate identical content to one URL.

Subdomain for staging and testing: staging.example.com, dev.example.com, test.example.com: subdomains used for development and testing should be blocked from search engine indexing through noindex meta tags or robots.txt disallow directives. Test content indexed by search engines creates duplicate content issues and may expose incomplete or incorrect information.

Subdomain security considerations

Subdomains introduce specific security considerations that root domains without subdomains do not face.

Subdomain takeover: when a CNAME record points to a third-party service and the service account associated with the target hostname is deleted or cancelled the CNAME continues to point to the now-unclaimed hostname. If an attacker registers the same hostname on the same platform they control what content is served at the subdomain, effectively taking it over.

Subdomain takeover is a significant risk for organisations with large numbers of subdomains connected to third-party services. Auditing CNAME records regularly and removing records for decommissioned services prevents unclaimed CNAME targets from being exploited. Monitoring services that check for subdomain takeover vulnerabilities provide ongoing protection.

SSL certificates for subdomains: each subdomain needs a valid SSL certificate to serve HTTPS correctly. A wildcard certificate for *.example.com covers all single-level subdomains, www.example.com, blog.example.com, api.example.com: with a single certificate. Deeper subdomain nesting, app.blog.example.com: requires an additional wildcard for *.blog.example.com or a specific SAN certificate entry.

DNS hijacking of subdomains: compromised DNS management credentials allow attackers to modify subdomain DNS records, redirecting subdomains to malicious servers. Strong DNS management account security, multi-factor authentication, access controls, protects subdomain DNS records from unauthorised modification.

Creating and managing subdomains

Subdomain creation and management happens entirely through DNS record management, no registrar involvement is required.

Creating a subdomain: log into the DNS provider’s management interface for the root domain. Add a DNS record for the new subdomain. Specify the subdomain label, shop, blog, api: and the record type and value. A CNAME pointing to a service hostname for third-party-hosted subdomains. An A record pointing to a server IP for self-hosted subdomains. Save the record. DNS propagation begins.

Deleting a subdomain: remove the DNS records for the subdomain from the zone. The subdomain immediately stops resolving after the TTL expires on cached records. Ensure any services that depended on the subdomain are updated or decommissioned before deletion. Check for external links or bookmarks pointing to the subdomain that may need redirect rules.

Managing subdomain records: DNS providers offer control panels or APIs for managing subdomain records. Changes take effect after DNS propagation. Record types can be changed, updating a CNAME to point to new infrastructure or changing an A record IP address, without deleting and recreating the subdomain.

Subdomain delegation: for subdomains requiring independent DNS management add NS records to the root domain zone delegating the subdomain to separate nameservers. api.example.com NS ns1.apiplatform.com delegates the api subdomain. The delegated nameservers must have the subdomain zone configured. All records under the delegated subdomain are managed on the delegated nameservers independently of the parent zone.