Getting a site onto the server is one decision and one rule. The decision is which method suits the amount you are moving. The rule is that everything the public sees goes in public_html, and anything above it is not served.
That rule explains most of the confusion people have here: a file uploaded to the home directory is correct, present, and invisible.
Upload an archive, not files
For anything beyond a couple of files, compress the site into a ZIP, upload the one file, and extract it on the server.
This is dramatically faster than sending thousands of small files individually, and it avoids the transfers that silently drop one or two, which produces a site that is almost working and a fault that is very hard to find.
In cPanel's File Manager, navigate into public_html first, then Upload. Right-click the archive and choose Extract, then delete the archive.
Watch the structure after extraction. If your ZIP contained a folder rather than the files themselves, everything is now one level too deep and the site loads a directory listing instead of a homepage. Move the contents up and remove the empty folder.
Delete what you uploaded to get there
The archive and any database export are now sitting inside your public directory, where anyone who guesses the filename can download them.
A .sql file in public_html contains your entire database including user records. Remove both as soon as the extraction is done, and keep intermediate files above public_html in future.
What actually needs uploading
For a site built from files, everything. For an application, less than people assume.
WordPress core can be downloaded again, and plugins can be reinstalled. What cannot be replaced is wp-content (your uploads, your customised theme) and wp-config.php. If you are moving a WordPress site instead of starting one, the migration route carries the database as well and is a different job: moving an existing WordPress site deals with it.
Permissions after upload
Files should be 644 and directories 755. That is correct for a normal site, and a fresh extraction usually produces it.
If something fails with a permissions error, the cause is nearly always ownership rather than permissions. A file uploaded by one process and read by another. The right move is a support ticket.
Never set anything to 777. It appears constantly in old forum advice as a fix for upload problems, and it makes the file writable by anyone on the server. It converts an inconvenience into a compromise.
When an upload fails on size
The limit is a PHP setting rather than anything about File Manager. Two values control it and they must move together: upload_max_filesize, and post_max_size, which has to be at least as large because an upload arrives inside a form submission.
Raising only the first is the most common mistake, and it produces the confusing outcome where the limit says 64M and a 20M file still fails. There is more in configuring PHP settings in cPanel.
For genuinely large files, FTP has no such limit and resumes if the connection drops. Connecting via FTP sets out setting that up.
After uploading
Load the site. Three failures are common enough to recognise immediately.
A directory listing instead of the homepage. There is no index.html or index.php at that level: usually the one-level-too-deep problem.
The old site still showing. Browser cache. Check in a private window.
Nothing at all. The domain does not point here yet. That is DNS instead of the upload, and the files are fine.
Check the upload arrived intact
An extraction that reports success can still be missing files, particularly on a large archive uploaded over a poor connection.
find . -type f | wc -l du -sh .
Compare both against the source. A count that is short by a few files means a partial transfer, and the site will work until somebody reaches the page that needed the missing one.
Where the archive tool offers it, verifying the archive before extracting is better than counting afterwards. A truncated ZIP frequently extracts what it can without reporting a problem.
Hidden files are the ones that get left behind
File Manager hides files beginning with a dot by default, and those are frequently the important ones: .htaccess, .env, and the configuration a framework needs.
A site copied without its .htaccess loses its rewrite rules, which on WordPress means every page except the homepage returns a 404: a symptom that looks like a broken installation and is a missing file.
Turn on hidden files in the File Manager settings before comparing anything, and check specifically for that one after any manual copy. Directory indexes and hidden files explains the setting.
Ownership after a panel upload
Files uploaded through File Manager are owned correctly, which is one of its advantages over other routes.
Files extracted from an archive created elsewhere can carry unexpected permissions, particularly an archive built on a different system, where an executable bit or an unusual mode survives the transfer.
find . -type f -perm /o+w find . -type d ! -perm 755 | head
The first finds files writable by anyone, which should return nothing. Correct those before the site is reachable rather than after. For the values, see understanding file permissions and ownership.
What to do about the archive afterwards
Beyond deleting it, there is a habit worth forming: keep the archive somewhere above the web root rather than removing it entirely.
It is the state the site was in at upload, which is the only copy you have before anything was changed. Moving it up rather than deleting costs nothing and has rescued more than one site from a change made in the first hour.
mv ~/public_html/site.zip ~/uploads-archive/
Then delete it when the site has been running for a week, and note that this is not a backup, because it captures nothing since. Restoring a website sets out what one needs to contain.