Subdomain created automatically when setting up a new domain

Understanding the problem

When you add a domain, some cPanel configurations also create an associated technical subdomain. Check the names and document roots in Domains before changing anything: deleting an associated item can affect the domain you want to keep.

If both names show the same content, a page can have several public URLs. Not having linked the subdomain does not guarantee that nobody knows about it or that a search engine will not discover it. Check the actual response and the Search Console data before deciding what to do.

Where the document root sits depends on how the account was created. A folder inside public_html could also be reachable through the primary domain; do not assume every older installation was created outside that root.

Domains in the same account can have their own content, but they share that account's resources and permissions: they are not fully isolated the way separate accounts are.

Choose the behaviour

• If the subdomain shows the same content and has visits or links, use a permanent redirect to the equivalent domain and path.
• If a URL should not exist and has no relevant replacement, it can return 404 or 410.
• If it is a test environment with private data, protect it with authentication; hiding it from search engines does not restrict access.

Do not redirect a subdomain with useful content to an unrelated home page just to clear a warning. Check traffic, links and relevant paths first.

Fixing the problem

Keep a copy of the .htaccess file in the affected root. Add only one of the alternatives before the application's rules and replace the example domains. The condition limits the action to the exact technical host.

To return 404:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^subdominio\.tudominio\.com(?::[0-9]+)?$ [NC]
RewriteRule ^ - [R=404,L]

To redirect to the public domain, keeping the path when the same content exists there:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^subdominio\.tudominio\.com(?::[0-9]+)?$ [NC]
RewriteCond %{THE_REQUEST} \s/+([^?\s]*)
RewriteRule ^ https://dominio-publico.example/%1 [R=301,L,NE]

The second condition takes the original request path so that its encoded characters are preserved; the query string is kept because no other one is defined in the destination. The destination is a fixed name you must replace; do not build it from the host sent by the visitor. A ! in front of the condition would invert its scope and could affect the wrong domain.

These rules belong in that website's document root. If you are dealing with alternative access through a subfolder, it needs a rule specific to that path; do not copy the host condition expecting it to solve it.

Check without affecting the public domain

Test the home page and an inner path of the subdomain, and confirm that the public domain still loads directly. Check status codes, destination, parameters and that there are no loops. A permanent redirect can stay in the browser cache: use a fresh session when checking.

Keep the old name's certificate valid while it serves HTTPS requests; the TLS handshake happens before the redirect. Update internal links and canonical tags so they point to the public URL, and keep the redirects for addresses with useful signals.

If a 500 error appears, restore the saved file and check the log before trying new rules.