You open File Manager and next to public_html you see several other folders you never created: mail, logs, tmp, etc, ssl. You delete one of them because it looks redundant to you, and half an hour later the site won't come up or outgoing emails stop being delivered. This article is exactly for that moment: what's inside each folder, which ones the user can change, and which ones you should leave untouched.
The host folder structure from the user's perspective, not the server's
When you log into your account via FTP or SSH, you land in a folder named after yourself. Its real path is something like this:
/home/USERNAME/This folder is the root of your account and is known in cPanel as the Home Directory. Everything beneath it belongs to that same account and has no effect on other accounts on the server. But not all folders beneath it are on the same level. We have three categories: folders that the web server serves directly, folders that other services (Mail, DNS, Cron) use, and folders that only the hosting engine touches.
What exactly does public_html serve
The account's main domain is mapped to public_html. That means a request to https://example.com/wp-login.php reaches the file /home/USER/public_html/wp-login.php. If you create an Addon Domain, cPanel by default creates a folder with the same name as the domain and registers it as the Document Root; for example public_html/shop. This mapping is written in the web server's configuration file, not in the folder itself, so moving the folder without changing the Document Root will send the site to a 404.
A point many people don't know: if both index.php and index.html exist, the web server's priority order determines which one runs, and this order is not the same in Apache and LiteSpeed. If after uploading an old HTML version of the site the new PHP version isn't displayed, check this first.
Folders that should not be touched
Don't delete these, don't rename them, don't change their permissions:
| Folder | Its function | If you break it |
|---|---|---|
mail | Mailboxes, filters, and Maildir configuration | Existing emails disappear or sending is cut off |
etc | Configuration of domains, Cron, SSL, and user files | The domain gets detached from the account, Crons fall apart |
logs | Web server access and error logs | Troubleshooting goes blind; it usually rebuilds itself |
ssl | Keys and certificate chains for domains | HTTPS breaks and the browser shows a warning |
tmp | Temporary PHP files and incomplete uploads | Upload errors and strange sessions |
.trash | File Manager's recycle bin | Space is freed but recovery is no longer possible |
The logs folder is the biggest victim, because its size grows and it's the first thing users delete to free up space. Deleting the files inside it is harmless; deleting the folder itself is not. If the web server can't write logs, depending on the configuration it may reject requests with a 500 error.
See hidden folders with ls -la
File Manager doesn't show dotfiles by default. With SSH, view them like this:
ls -la ~/
du -sh ~/* ~/.[!.]* 2>/dev/null | sort -hThe output of the second command is usually surprising: a folder like .cagefs or .wp-cli or a Composer cache can be several hundred megabytes. You can also see the exact usage number from inside cPanel in the Disk Usage section, but that report is cached for up to 24 hours; for a real-time number, trust du.
File permissions and ownership: the 500 error comes from right here
The rule that works in practice: folders 755, files 644. Set sensitive configuration files like wp-config.php to 600. Fix them all at once with this command:
find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;Don't touch ownership. On shared hosting, files must belong to the account owner; if you give them to another user with chown, PHP no longer has write permission and WordPress shows the "Could not create directory" message when uploading or updating. Here's where people make a mistake: to fix a permission error, the user sets the entire folder to 777. The site comes up, but from that moment any script on the server can overwrite your files, and usually a few weeks later you're faced with an uploaded shell in public_html/uploads.
Host folder structure and inode consumption
Every file and every folder consumes one inode. A disorganized folder structure will hit your ceiling faster than your disk space does. A WordPress installation with average plugins usually takes between 15,000 and 40,000 inodes; if you keep page cache or backup versions inside public_html, this number multiplies. For an exact count and to figure out which folder is responsible, see inode limit on hosting: what consumes it and how to count it. The practical solution is simple: move cache, log, and backup folders outside public_html.
Which folders should be outside public_html
- Backup versions and
.sqlor.tar.gzfiles - Plugin cache folders and
wp-content/cacheif the plugin allows relocation - Configuration files containing the database password
- Projects under development that aren't ready for release yet
Any file inside public_html can be requested from the internet, even if you haven't linked to it anywhere. A backup.sql in the site root will be found with a simple Google search.
Addon domains, subdomains, and their folders
Subdomains are by default created under public_html, like public_html/blog for blog.example.com. This means a vulnerability in the blog site can also reach the main site's files, because both are under one root Document Root. If security matters to you, create the subdomain outside public_html, for example /home/USER/blog, and point the Document Root to it manually.
Let me also mention the cost: some plugins and file management tools assume relative paths based on public_html and break with a non-standard structure. If you have a simple site and no dedicated technical admin, the default cPanel structure is less of a headache. For projects with multiple sites having different security needs, separating the paths is worth it.
When you migrate the site from shared hosting to a dedicated server, this same structure changes: instead of /home/USER you're dealing with /var/www and independent VirtualHosts. Before migrating, write down the list of folders and the Document Root path of each domain; after the transfer, the only thing that usually gets left behind is files outside public_html.
Frequently asked questions
Can I rename public_html?
No, neither from File Manager nor from FTP. The name of this folder is registered in the web server configuration as the main domain's Document Root. If you change it, the site comes up with a 404 error or the host's default page. If you really need a different path, you must request the Document Root be changed from inside cPanel or from support.
Where is the .htaccess folder and why isn't it visible?
It's located in the root of public_html, and because it starts with a dot, File Manager shows it as hidden. Enable the Show Hidden Files option in File Manager settings or view it with ls -la. This file holds URL rewrite rules, redirects, and access restrictions; a single wrong character in it will take the whole site to a 500 error.
Why has the mail folder taken up so much space?
Because unread emails and attachments are stored on the same account, not in separate space. If you have a POP3 mailbox and don't download the emails, this folder grows until it fills the disk quota. Use du -sh ~/mail/* to see which domain is responsible and empty the mailbox or limit its quota from inside cPanel.
When are cache and session files in tmp cleared?
On most shared hosts, the tmp folder is cleaned periodically and automatically; usually every few hours to a day. So don't keep any data you need there. If you write PHP sessions to tmp and users get logged out for no reason, move the session path to a more stable folder.
Before making any change to the folder structure, take a full backup and write down the Document Root path of each domain. If you're not sure what a folder does, don't touch it; deleting it is never urgent, but restoring it always is.