A hostname under a parent domain, such as docs.example.com, that can serve a distinct technical or content purpose within the wider site architecture.
A hostname under a parent domain, such as docs.example.com, that can serve a distinct technical or content purpose and must be planned as part of the wider site architecture.
The decision and its boundary
A subdomain is a hostname below another domain name, for example docs.example.com beneath example.com. Technically it can have its own application, routing, cookies, DNS configuration, and search presence. That flexibility does not decide the information-architecture question. The choice between a subdomain and a subdirectory should follow operational ownership, product boundaries, localization or platform needs, and the user journey—not an assumed SEO bonus.
What to inspect
Map every hostname, its purpose, owner, canonical host, TLS state, robots rules, sitemap, analytics identity, and internal-link paths. Crawl representative pages across the boundary and check that links point directly to intended canonical routes. During a migration, retain a URL-level map and test each destination rather than assuming that host-wide routing is enough.
A practical implementation path
Use a subdomain when it creates a stable, understandable boundary such as documentation, an app, or a regionally separate platform. Give it its own clear navigation and indexation policy while preserving contextual links to the parent experience. If moving content between hostnames, configure direct permanent redirects where appropriate, update canonical and sitemap references, and validate rendering and tracking on both sides.
Mistakes and measurement limits
The risky shortcut is creating a subdomain merely to isolate SEO work or duplicate content. It can fragment ownership and make sitewide fixes harder. Do not state that a subdomain automatically inherits or loses authority; evaluate the actual links, content, accessibility, and migration implementation.
Worked architecture example. A company may place product documentation on docs.example.com because a separate documentation platform and team own it, while a customer-facing application lives on app.example.com. That can be a coherent boundary if navigation, account expectations, search policy, and ownership are clear. Moving a marketing folder to a subdomain merely because it has a different template is a much weaker reason. Document the user journey across hosts before choosing the hostname.
Check criteria. Maintain a host inventory with purpose, primary owner, canonical public host, sitemap, robots policy, TLS coverage, analytics scope, and key entry routes. Crawl representative pages from the parent to the subdomain and back, checking direct internal links, redirect behaviour, and footer or navigation paths. For a move, test the old and new URL pairs, not only the hostname root. Check browser and mobile journeys if cookies, login, or application hand-off is involved.
Common errors. Do not duplicate the same content across a root host and subdomain without an explicit canonical or migration decision. Do not assume that search systems treat all hostnames as one site or as totally unrelated; verify the real link and URL structure. A hostname change affects operations, analytics, and user trust as well as SEO, so it needs a route-level rollback plan.