Subdomains: Creating and Configuring via cPanel and DNS

A subdomain is the part of the URL before the main domain: blog.example.com, shop.example.com. Subdomains let you separate different sections of a site or create independent projects without buying a new domain.

What Subdomains Are Used For

Creating a Subdomain in cPanel

1. Go to cPanel → Domains → Subdomains
2. In the "Subdomain" field enter: blog
3. Select the main domain from the list
4. Set the folder (Document Root): public_html/blog
5. Click Create

cPanel automatically creates a DNS A record for the subdomain.

Creating a Subdomain Manually via DNS

If you manage DNS yourself (Cloudflare and similar services):

# A record (direct IP)
blog    IN    A    192.168.1.100

# CNAME (alias of the main domain)
shop    IN    CNAME    example.com.

# Wildcard — all subdomains
*       IN    A    192.168.1.100

Wildcard Subdomains

A wildcard (*.example.com) lets you create an unlimited number of subdomains without adding separate DNS records. Handy for SaaS platforms where every user gets username.example.com.

Subdomains and SEO

Google indexes subdomains as separate sites. If the blog matters for the main site's SEO, it is better to put it in a subfolder (example.com/blog/) rather than on a subdomain. Subdomains lose the authority passed down from the main domain.

Creating a subdomain in DNS

Add an A record in your DNS control panel:

Configuring Nginx for a subdomain

server {
    listen 80;
    server_name blog.yourdomain.com;
    root /var/www/blog;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

SSL for a subdomain

# A separate certificate
certbot --nginx -d blog.yourdomain.com

# A wildcard certificate (for every subdomain)
certbot certonly --dns-cloudflare   -d yourdomain.com   -d "*.yourdomain.com"

Common mistakes when setting up subdomains

Nearly every subdomain problem traces back to one of three causes: the wrong DNS zone, the wrong SSL certificate, or a web server config conflict.

NXDOMAIN

This dig response for a subdomain query almost always means the record was added in the wrong DNS zone — for example, in the hosting's DNS panel while the domain is actually managed through the registrar's or Cloudflare's name servers. Check who currently holds the domain's authoritative NS records: dig example.com NS +short, and add the record there instead.

NET::ERR_CERT_COMMON_NAME_INVALID

The certificate was issued for example.com, and the blog.example.com subdomain isn't covered by it. A regular Let's Encrypt certificate only covers the names listed explicitly at issue time — a new subdomain needs either a separate certificate, a reissue that adds the name, or a Wildcard certificate.

nginx: [emerg] duplicate default server for 0.0.0.0:80

The new config for the subdomain accidentally duplicates the default_server parameter already set in the main site's config. Only one default_server is allowed per IP and port — remove the directive from every block except one.

Subdomain vs subfolder compared

For a blog meant to boost the main site's rankings, a subfolder is usually the right choice. For a functionally independent project (a customer portal, a store on a different engine), a subdomain makes sense despite the loss of some SEO authority.

When subdomains don't fit

Some shared hosting plans cap the number of subdomains — check the plan's limit in hosting limits and resources before designing an architecture around dozens of subdomains. Wildcard subdomains (*.example.com) for SaaS products with per-user names need a Wildcard SSL certificate and careful handling at the application level — if you only expect 2-3 subdomains, a Wildcard is overkill; it's simpler to issue regular certificates for each one.

How to verify the result

Check DNS and the web server separately — it immediately shows you which side the problem is on:

# Confirm the subdomain resolves to the right IP
dig blog.example.com A +short

# Check that Nginx serves the correct config for this name
curl -I -H "Host: blog.example.com" http://YOUR_SERVER_IP/

# Check the certificate for the specific subdomain
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject

The second command, with an explicit Host header, tests Nginx's routing directly by IP, bypassing DNS — that separates a DNS problem from a web server config problem. If content from the wrong site comes back over the IP, the issue is server_name, not the DNS record.