Retire a subdomain when a staging environment, campaign or application is no longer needed. Plan the hostname’s public behaviour before removing it so visitors, integrations and bookmarked links do not point to an abandoned service.
IN THIS ARTICLE
01 Prepare for the change
Back up any data to retain and note the subdomain’s document root. Check whether a scheduled task, API callback, email configuration or another domain depends on it. Do not delete a folder merely because its name resembles the subdomain.
02 Retire a subdomain from cPanel
- Open Domains and select Manage beside the complete subdomain hostname. Verify the name and document root.
- Use the domain removal action and confirm the intended hostname. Review any associated files separately rather than assuming the panel removed or preserved every dependency.
- Remove or repoint the public DNS record at its authoritative provider. If users need an ongoing replacement, arrange a valid redirect before discarding the old hosting endpoint.
- Review databases, application schedules, certificates and FTP access created specifically for this subdomain. Remove only the items proven unused.
- Record the retirement and keep the backup for the required retention period.
03 Confirm the expected result
Check the remaining primary site and any sibling subdomains. Verify that the retired hostname does not point to a third-party service that could be claimed by someone else.
04 Example: close a staging subdomain after a project finishes
Before retiring a staging subdomain, confirm that its files and database are separate from production. Check deployment jobs, redirects and application settings that may still refer to it.
Remove or disable the staging site through the appropriate hosting and application controls, then review the public DNS record at the authoritative provider. If the subdomain remains in certificates, monitoring or access lists, update those records deliberately rather than assuming they disappear with the hosting entry.
Should I leave the staging files online as a backup?
A publicly reachable old site is not a suitable backup. It may contain outdated code, copied customer data or forgotten credentials. Preserve a protected backup using the intended backup system, then remove unnecessary public access.
Test the main website after cleanup and confirm the old subdomain behaves according to your retirement plan. Do not remove a shared parent directory or wildcard record without checking what else depends on it. Send us the hostname, associated path and desired final behaviour if you need help separating the staging resources from the live service.
What if retiring a subdomain affects another website?
If another site stops working, restore the affected association and check whether document roots or databases were shared. A DNS result may remain cached temporarily. For an accidentally removed production subdomain, stop further cleanup and ask support to help restore the correct configuration.