Publishing a Domain and Setting Up HTTPS with Plesk panel

To publish a domain through the Plesk panel, first create the domain record in the hosting account, then verify that the DNS records point to the correct server. After uploading the site files, enable an SSL/TLS certificate and test the same address again over HTTPS. Menu names and certificate options may vary depending on the account’s permissions and the hosting provider’s configuration.

What information should you prepare before using the Plesk panel?

This process can be performed both in shared hosting environments where you log in to Plesk with a customer account and on a server where you have administrator access; however, the available options are not the same. With a customer account, you can manage only your own subscription. On a server managed by an administrator, the availability of the service plan, DNS service, and certificate extensions is also determined separately.

First, note which DNS service the domain uses and the values currently serving the website. If the domain is already live, taking a copy of the existing DNS records and backing up the site files and database before making changes is a safe starting point. Change only one factor at a time; changing DNS, the file path, and SSL settings simultaneously makes it unclear which step caused a problem.

Two basic decisions are important: if the domain’s DNS service is provided by the hosting provider, the DNS management in Plesk can be used; if DNS is managed by another company, the records must be edited in that company’s panel. If the domain will be connected to a new site, create a new subscription or domain record; if it will point to an existing site, first check whether the same domain is already defined in Plesk. Instead of adding the same domain a second time, inspect the existing record’s document root and hosting settings.

Creating the domain and connecting the site files

1. Review the Domains screen. In Plesk, go to the list of domains in your account and search for the target domain. If no record exists, open the option to add a domain; if one exists, do not create a new record. The document root shown on the screen—the folder where the web files will be served—must match the existing site. If it does not, first note the current value and correct only that value. The result should be that the domain is connected to one site and the expected folder.
2. Verify the DNS routing. In the domain’s DNS panel, check that the A record or appropriate CNAME record used for web traffic points to the Plesk server. If Plesk’s DNS servers are being used, make the change through Plesk; if external DNS is being used, make it in the domain provider’s panel. If the record still points to the old server, save the new value and wait for propagation; the domain appearing as added in Plesk does not mean that the DNS response across the internet changes immediately.
3. Upload the files and perform the initial HTTP test. Place the files in the document root using the file manager, SFTP, or another secure transfer method offered by the provider. Confirm that the main file is in the expected folder and open the domain over HTTP. If the default Plesk page appears instead of the site, the file path or the domain’s document root is incorrect; if a 403 error appears, inspect the access permissions or the application’s entry file. Broadening the root folder with permissions that make it publicly accessible is not a safe correction.

Distinguish the file path from the DNS result

Suppose the default Plesk page appears when the domain is opened over HTTP, but a DNS query confirms that the domain points to the new server’s address. In this case, instead of changing DNS again, check the domain’s document root in Plesk and whether the files were actually uploaded to that folder. Conversely, if the domain displays the old server’s page, changing the file path will not help; first wait for the DNS record to reach the correct target. This is an example scenario that separates two different causes producing the same symptom, and it is entirely hypothetical.

Enabling the SSL/TLS certificate and verifying HTTPS

1. Check the certificate option. Open the domain’s security or SSL/TLS section. If the provider offers a certificate extension, select the domain and the www subdomain according to the forms you actually use. If the certificate request fails, first check whether the HTTP and HTTPS validation addresses can reach the server and whether DNS shows the new target. If the certificate service is not visible, do not force it; verify the method offered by the provider or the administrator’s configuration instead.
2. Enable HTTPS redirection in a controlled manner. After confirming that the certificate is valid and matches the domain, enable the HTTPS redirection option in Plesk. First test the HTTP and HTTPS addresses separately; enabling a permanent redirect before the HTTPS certificate is verified can cause an access loop. The site application’s own URL setting should also use HTTPS instead of HTTP, but change this setting after the initial test succeeds, not at the same time as the Plesk setting.
3. Run the same operation again and examine the new evidence. Reopen the address or login form that initially failed and check the new Plesk error records or web server logs created after the test time. If the new record shows a certificate name mismatch, correct whether the domain is included in the certificate; if there is a redirect loop, check whether the application URL and the Plesk redirect work together. Do not assume that a change succeeded by looking at old records.

How can you safely roll back if the problem continues?

If the site does not open after HTTPS is enabled but HTTP works, first separate the certificate status from the redirect setting. If the certificate is invalid, disable the redirect and correct the domain’s DNS result and the names included in the certificate; if the certificate is valid, inspect the application’s HTTPS address and mixed-content warnings. Restore the original value you recorded before the change, but do not try different targets repeatedly before DNS propagation is complete.

If you cannot change administrator-level service settings in a shared hosting account, use only the areas available to your account. When sharing the new log line that matches the time in the provider’s error log, do not send a password, key, or session information. If you need broader DNS and web server control on a VDS you manage yourself, you can review the environment options on the Turkey VDS server plans page; this link does not mean that the Plesk configuration will be resolved automatically.

The first next step is to compare the domain’s DNS result with the document root in Plesk at the same time. If these two values are consistent, proceed to checking the file path and then SSL/TLS; if they are not consistent, correct the DNS routing before changing the HTTPS settings.