How to add client websites in cPanel correctly

Adding a client website to cPanel requires the correct account, domain configuration, files and application data. Start by deciding the administrative boundary. Unrelated clients are generally easier to manage appropriately in separate cPanel accounts created through your reseller tools.

Adding another domain inside a single cPanel account does not create independent account isolation. It can be suitable for related sites under common administration, but it should not expose one customer’s files or databases to another. The workflow below covers the domain and deployment after that choice is made.

1. Confirm the account and authorised domain

Identify the client, domain holder, intended account and package. Check the available resources and domain allowance. A domain must be owned or used with appropriate authority; creating a hosting entry does not register an available name.

For a new independent client account, use the enabled WHM account-creation process and select the correct package. For an additional related site, use the existing account only after confirming the shared administrative arrangement.

Back up an existing service and record the active DNS, mail and application configuration before changing it. Keep the migration decision and authorised contact with the client record.

2. Open the current Domains interface

Use the provider’s secure cPanel access route and open Domains if enabled. Current cPanel documentation uses Domains and Create a New Domain; the exact interface depends on version and provider features.

Enter the intended hostname carefully. Do not assume an older tutorial’s separate Addon Domains screen or button exists in the installed version. Follow any provider ownership-verification requirements.

DNS is a separate layer. You can often retain the current authoritative provider and change relevant website records. A nameserver migration is not automatically required merely because the domain is registered elsewhere.

3. Choose the correct document root

The document root is the directory served for the website. For an independent additional site, select its intended directory rather than unintentionally sharing another website’s root. Read any share-document-root option carefully.

Record the mapping from hostname to directory. Avoid nesting unrelated client work under a public directory simply because an old example uses that structure. The account and provider determine which paths are permitted.

Check that existing files will not be overwritten. A new directory and a saved domain entry do not copy an old website; files and databases need a separate, controlled deployment.

4. Arrange appropriate file access

Use File Manager over the secure panel connection or an encrypted file-transfer method supported by the provider. Restrict access to what the authorised person needs and keep credentials separate from general project notes.

If using FTP accounts, configure encrypted FTPS where supported rather than sending credentials over plain FTP. SFTP is a different SSH-based service; an FTP subaccount is not automatically an SFTP login.

A directory-scoped transfer login can limit routine file access, but it does not turn websites in one cPanel account into separate security tenants. Do not share the main account login among unrelated clients.

5. Deploy the website and application data

Upload the correct files into the recorded document root. If using an archive, inspect its directory structure and extract into the intended location. Remove temporary archives from public web paths after the deployment is verified.

Create the required database and a separate application user through the available cPanel database tools. Use the full names shown by the panel, including any account prefix. Assign the permissions the application requires for its own database.

Configure the application’s connection settings securely and import data through an appropriate method. A static site may not need a database at all. A framework may require a particular public directory rather than serving every project file.

Use File Manager deliberately

Check the directory before uploading, moving or deleting. A similar-looking folder name can belong to another site. Confirm hidden configuration files and application-specific paths according to the deployment instructions.

Do not fix an access error by making every file world-writable. Investigate ownership, permissions and the runtime requirement. Keep database exports, private backups and secrets outside publicly served paths with appropriate access controls.

Connect DNS and HTTPS

Obtain the web destination from the hosting provider. Update the relevant A, AAAA or platform alias records at the active authoritative DNS service. Check old IPv6 records as well as IPv4 so visitors do not reach inconsistent destinations.

Preserve MX, authentication and verification records for services that are staying in place. If nameservers move, copy the whole required zone and coordinate DNSSEC. Arrange a certificate covering the actual hostnames visitors use.

Test the complete website

Visit the main name and www where used over HTTPS. Test key pages, navigation, forms, login and application-specific transactions in a controlled way. Verify scheduled tasks and external integrations rather than checking only the homepage.

If mail is included, test external sending and receiving and the provider’s authentication checks. If it remains elsewhere, confirm the web deployment did not disturb its records. Document the result and the time of the cutover.

Investigate errors at the right layer

A default page can indicate a domain or document-root mapping problem. A database error needs connection, user, permission and data checks. An HTTPS warning needs certificate and hostname investigation.

If DNS is wrong, compare authoritative answers with the provider’s intended values. If authoritative data is correct but one resolver shows an old answer, caching may explain the difference. Do not change several unrelated settings before identifying the fault.

Plan the cutover for changing data

A website that receives orders, uploads or form submissions can change while you are copying it. Agree how new writes will be handled during migration and how the final data copy is verified. Otherwise the old and new services can contain different customer records.

Use a recovery point and a clearly defined cutover window. Keep the old service available for the planned transition, while avoiding two independent live copies accepting conflicting transactions. The appropriate method depends on the application and business workflow, so document it before changing DNS.

Remove temporary deployment material

After verification, review uploaded archives, installation files, test pages and database dumps. Remove material that is no longer needed from public paths, and retain required recovery copies in a suitably controlled location. Do not leave credentials in a publicly reachable text file for convenience.

Review temporary access granted to a supplier or contractor. Disable or rotate it when the agreed work ends, keeping the ongoing administrators’ recovery methods intact. Record the clean final state so a future operator can distinguish active application files from abandoned migration material.

Finish the client handover

Record the account, document root, database, DNS operator, service period and support route. Keep secrets in the appropriate secure system. Confirm who can approve future changes and which access the client receives.

Use telaHosting’s reseller allocations when separate client accounts are required, and follow the features enabled for the actual plan. A clean deployment includes ownership, isolation and recovery information as well as visible pages.