Quick answer
Preview the complete static website on your computer, then upload its public files to the document root for your domain. Use SFTP or File Manager only when that method is available on your account. Keep a copy of the existing site and verify the published HTTPS pages, assets, and forms afterward.
Apply this guidance to your website task
Applies to
Use this guide for ordinary HTML, CSS, browser JavaScript, images, fonts, and a framework’s completed static output. PHP applications, databases, server-rendered Node apps, logins, and payment handling need their own supported runtime and setup. Check whether your export needs a server runtime.
1. Identify the public output
A simple website might contain index.html, about.html, contact.html, styles.css, and an assets folder. An Astro static build normally has a generated dist folder. Upload the contents of the public output, so index.html lands directly in the chosen domain folder. Keep source repositories, .env files, private keys, database dumps, backups, and node_modules out of public web access.
website/
index.html
about.html
contact.html
styles.css
assets/
logo.svg2. Preview on your computer
For plain HTML, you can inspect the pages in a browser. A local web server is more reliable when the site uses scripts or relative URLs. If Python is installed, open a terminal in the public-output folder and use the appropriate command below.
Windows commonly uses py or python; macOS commonly uses python3. Check your installed command with its --version option. Run the preview only from a folder that contains public website files.
# Windows, with the Python launcher installed
py -m http.server 8000 --bind 127.0.0.1
# macOS, with Python 3 installed
python3 -m http.server 8000 --bind 127.0.0.13. Check the preview
Open http://127.0.0.1:8000/. Follow every navigation link, refresh a nested page directly, check filename case, and narrow the browser window. Replace placeholders and confirm you can use every image and font. Stop the preview with Ctrl+C when finished.
A contact form needs a real handler. A success message written in browser JavaScript is not evidence that an email was sent. Decide how submissions will reach you before publishing. Check the form’s authorized mail path.
4. Confirm the destination and preserve the old site
- Sign in to the Client Area and open the exact hosting service. In cPanel > Domains, find the document root for the domain or subdomain. Locate the correct folder.
- Download the files you will replace and include the relevant database if you are changing a CMS application. Keep the recovery copy outside the public document root.
- Compare the live site with your working copy immediately before upload. Preserve newer live edits. If the destination already contains WordPress or another application, do not mix a new static site into it without a replacement plan.
5. Upload with a supported method
- For SFTP, connect with the assigned server, SSH port, cPanel username, and authorized key. Use the SFTP connection guide. Verify the server identity and open the exact document root.
- Upload the public output contents and retain their folder structure. Transfer CSS, scripts, images, and fonts as well as HTML. A folder named website inside public_html can make the new site appear only at /website/.
- If your account offers File Manager, use its Upload action in the correct domain folder. Review any archive before extracting it, and remove the public upload archive after verifying extraction. Limited dashboards may not offer this method.
- Keep a record of the version and files replaced. Uploading files does not change DNS or create a missing backend service.
6. Verify the published website
Open the real HTTPS domain and each important page directly. Check root and www behavior, navigation, images, fonts, downloads, and browser network errors. Test the actual form handler with a controlled message and confirm receipt. Check the intended changes after refreshing relevant caches.
Troubleshooting
- Old site appears: confirm DNS, document root, index-file priority, and the relevant browser/CDN/application cache.
- Styles or images are missing: check uploaded paths, filename case, and local-machine URLs left in the HTML.
- A nested page fails on refresh: check whether the export contains that route or needs an application-specific rewrite.
- A form shows success but no message arrives: check the backend request, authenticated sender, mail logs, and destination mailbox.
- The new version is unusable: restore the changed files from the preserved copy and retest. Database recovery needs a separate plan that preserves newer business data.
Ask support
Provide the domain, document root you used, publishing method, affected URL, timestamp/time zone, and a redacted error. Keep credentials and session URLs private.
Choose the smallest fix after publication
For a failed transfer or ZIP extraction, use the File Manager troubleshooting guide. For an unchanged public page after a successful upload, use the domain and document-root checks. A 403 Forbidden response needs the access-error checks; repeated uploads alone do not resolve an access rule. Preserve the previous files and use a selective rollback when a specific new file caused the failure.
Related help
- Upload website files with SFTP: settings and secure connection
- Find the correct document root before an AI tool uploads files
- Upload a reviewed file with cPanel File Manager
- Check whether an exported website needs a server runtime before upload
- Make website form notifications use an authorized mail path
- Site shows 403 FORBIDDEN message.
- Send a website support request with useful troubleshooting details
Official references
Last content review: October 31, 2026. Check the version and features available in your own account.
Customer troubleshooting and related-help review: November 1, 2026. Earlier review notes retain their original scope.
AI editing guidance and linked workflow documentation reviewed November 2, 2026. Existing video and earlier review history retained.
