A complete guide to every common subdomain convention — what each one is for, when to use it, and how to configure the DNS record.
Subdomains are prefixes added before your main domain name separated by a dot — like blog.example.com or api.example.com. They allow you to organize different sections or services of your web presence under one domain while pointing each to a different server, IP address, or cloud service. Each subdomain requires its own DNS record.
The www subdomain is the oldest and most recognized, originating from the early World Wide Web when servers were named by function (www for web, ftp for file transfers, mail for email, etc.). Today, www is optional — most modern websites work equally well at both example.com and www.example.com.
The main technical reason to still use www is the ability to configure a CNAME record (root domains can only use A records, limiting flexibility). For large sites using CDN, using www allows CNAME pointing to a CDN's hostname, enabling easier server migrations without DNS TTL delays. Most sites set up a redirect so that one version redirects to the other (301 redirect from www to root or vice versa) to avoid duplicate content issues.
A blog subdomain is used when a company or individual wants to host their blog on a different platform or server than their main website. For example, a company might run their corporate site on custom code at example.com and their blog on WordPress at blog.example.com.
From an SEO perspective, blog.example.com is treated by Google as a separate entity from example.com/blog. Most SEO experts recommend example.com/blog (subfolder) over a subdomain for SEO purposes, as it consolidates domain authority. However, technical or organizational constraints sometimes make the subdomain approach necessary.
The shop subdomain (sometimes store) is used to separate a company's e-commerce functionality from their main informational website. This is common when the shop runs on a different platform (Shopify, WooCommerce, Magento) than the main corporate site. Shopify, for example, allows custom domains like shop.yourdomain.com via CNAME.
The api subdomain is the standard convention for hosting API endpoints that serve data to mobile apps, third-party integrations, or the company's own frontend applications. By separating the API at its own subdomain, you gain several technical advantages: independent scaling (your API servers can scale separately from your web servers), separate SSL certificates and rate limiting, cleaner CORS (Cross-Origin Resource Sharing) configuration, and a clear developer-facing interface.
REST APIs at api.example.com/v1/users, GraphQL endpoints at api.example.com/graphql, and WebSocket services at ws.example.com are all common patterns in modern web architecture.
A cdn subdomain is used to serve static assets — images, CSS, JavaScript files, video, downloadable files — from a different server or CDN service than your main web application. By serving static assets from a subdomain (or third-party CDN), you enable several performance optimizations: parallel downloading (browsers limit connections per domain), cookie-less domain (static assets don't need to send session cookies on every request, reducing header size), and easy CDN integration.
The mail subdomain traditionally points to the company's mail server or webmail interface (e.g., Roundcube or Outlook Web App). Users access webmail at mail.example.com. Note that email sending/receiving is configured via MX records pointing to your mail server — the mail subdomain itself just provides a human-friendly address for the webmail login interface.
dev and staging subdomains are used to host non-production versions of a website or application. They allow developers and testers to preview changes before they go live on the main site. The typical environment chain is: dev.example.com (development builds, frequently changing) → staging.example.com (pre-production, mirrors production, for final QA testing) → example.com (production).
Best practice: protect dev and staging subdomains with HTTP basic authentication or IP allowlisting so they're not crawled by search engines and don't expose work-in-progress features to the public. Use a robots.txt with Disallow: / or the X-Robots-Tag: noindex HTTP header on all staging pages.
A status subdomain hosts a public status page showing the real-time operational status of a service's components. When example.com is down, users can still check status.example.com (typically hosted separately or via a third-party service like Atlassian Statuspage, Betterstack, or Freshstatus) to understand the outage. Major services like GitHub, Cloudflare, and AWS all maintain public status pages at dedicated subdomains.
The app subdomain separates the logged-in web application from the public marketing site. This is the standard pattern for SaaS products: the marketing site at example.com, and the actual product dashboard at app.example.com. This separation provides cleaner architecture, separate deployment pipelines, different caching strategies (the app needs no-cache for personalized content; the marketing site benefits from aggressive caching), and independent SSL/security policies.