Uploading sounds like the easy step — until the live site shows a blank page, a 404, or yesterday’s design after you “replaced” everything. Most of those failures come from how the zip was built, not from magic inside the host. This article walks through macOS and Windows zip pitfalls, nested folders, first-upload 404s, and how replacing a publish should feel when deploy history has your back.
What you are uploading
SiteHost expects website files: HTML, CSS, JavaScript, images, fonts, maybe a PDF. You deliver them as a .zip, or you connect GitHub so the host pulls from a repository. Either way, the published result is a tree of files with a clear root. There is no cPanel file manager maze and no website builder pretending to invent pages for you.
Skip this guide if you do not have files yet. Get an export from your designer first; hosting cannot upload a conversation or a Figma tab.
Build the zip on purpose (not by accident)
macOS habits that bite
- Zipping the wrong selection. In Finder, if you compress the outer folder that merely contains your site folder, you nest an extra directory. Compress the folder that *directly* contains
index.html, or select the files inside and compress the selection — then verify. - Hidden
__MACOSXfolders. Finder zips sometimes include resource-fork metadata. Harmless clutter usually, but confusing when you inspect archives. Prefer selecting the real site files. - Quarantine and iCloud placeholders. If a file shows a cloud icon and has not fully downloaded, your zip may omit it. Open large images once to force download before zipping.
Windows habits that bite
- “Send to compressed folder” from the parent. Same nested-folder risk as macOS. Open the site folder, select contents, then compress — or compress the site folder and confirm the archive’s top level.
- Explorer hiding extensions. You might think you have
index.htmlwhen you haveindex.html.txt. Enable file name extensions in File Explorer View options. - OneDrive-only files. Like iCloud, cloud-only placeholders can produce incomplete archives. Keep a local copy of the project.
The verification ritual (two minutes)
- Move your new zip into an empty temporary folder.
- Extract it.
- Confirm you immediately see
index.html(or a single site folder you *intended* — and if so, re-zip that inner folder’s *contents*). - Open
index.htmlin a browser from the extracted copy.
If that local extract fails, stop. Do not upload yet.
First upload: what a 404 usually means
You publish, open the HTTPS preview, and get “not found” or an empty shell. Common causes:
| Symptom | Likely cause | Fix |
|---|---|---|
| 404 on homepage | index.html not at publish root | Re-zip without extra nesting; ensure exact filename |
| CSS missing | Wrong relative paths or case mismatch | Fix href/src locally; re-upload |
| Only one folder name visible in errors | Nested zip | Zip inner contents |
| Old page still showing | Browser cache or wrong site selected | Hard refresh; confirm you published the site you think you did |
Works on /index.html but not / | Missing or misnamed index | Rename home file to index.html |
Preview URLs on SiteHost are HTTPS immediately, so you can test on your phone without a custom domain. Domain certificates wait until DNS verifies — that is unrelated to a first-upload 404. Keep those problems separate. Broader context: how to put a website online.
Replacing a publish without losing your nerve
A second upload should replace the files that make up the site. Before you overwrite:
- Keep the previous zip on your computer with a dated filename (
bakery-2026-03-12.zip). - Note what changed: one image, a whole redesign, or a typo.
- Publish, then click the same paths you care about (
/,/menu,/contact). - If the new version is worse, use deploy history / rollback to restore the prior file set, then try again.
Rollback is for file publishes — it will not fix a DNS mistake at your registrar. Different layer, different tool.
GitHub instead of zip
If the project already lives in GitHub and the repo contains the *publishable* files at a known root (or a static export folder you designate in your workflow), connecting GitHub can replace manual zips. Do not point the host at a repo full of design sources and build tooling without an export step. Upload the built site, whether the vehicle is zip or git.
Storage and plan reality while you upload
Starter is $9/mo for one site and 2 GB. That fits most HTML brochure sites. A wedding photographer dumping unresized RAWs into /gallery will blow storage and slow pages — compress first. Pro ($30, 3 sites, 10 GB, staging), Scale ($65, 10 sites, 30 GB), and Business ($130, 30 sites, 100 GB, teams) exist when you outgrow one small site. Trial is about a day; then you pay. No forever-free plan.
SiteHost does not include email hosting or a built-in CDN. Optional Cloudflare in front is a later performance choice, not a requirement for a successful upload. See fast-loading website hosting.
A campaign landing page story
A freelancer builds a single landing page for a product launch: index.html, a CSS file, three WebP images, and a form that posts to a third-party form service. They zip on Windows from the parent directory by mistake. Preview 404s. They extract, see one nested folder, re-zip contents, publish again. Form works; hero image is 4 MB. They replace the image, publish a third time, dislike the crop, roll back to the second publish, then fix the crop locally and publish once more. The custom domain still is not pointed — and that is fine until creative sign-off. Order of operations kept the public name clean. More on one-job pages: host a landing page online.
Checklist before every upload
- [ ] Local extract shows
index.htmlat the level you expect - [ ] Relative CSS/image paths work from that extract
- [ ] Oversized images resized
- [ ] Zip named so you can find it next month
- [ ] You know whether this publish should be rolled back to if it fails
Upload is a packaging skill. Treat it that way and the host looks “easy” because you stopped feeding it broken archives.
Questions people actually ask
Can I upload individual files without zipping?
The SiteHost path described here centers on zip upload or GitHub. Use a zip for a coherent full-site publish unless your workflow documentation says otherwise.
Why did my friend see the old site after I uploaded?
They may be caching the old assets, or you rolled forward on a different preview than the domain they use. Confirm which URL they open and try a private/incognito window.
Does a failed upload delete my previous site?
Rely on deploy history. If a publish is bad, roll back to the last good file set rather than assuming the host emptied everything.
What file types are appropriate?
Website assets: HTML, CSS, JS, images, fonts, PDF. This is not a general-purpose file locker for videos of every shoot at full resolution.
Should I upload before or after buying a domain?
Before is fine — better, even. Get the preview right, then point DNS. How to make a website live clarifies that “live” can mean preview HTTPS.