You already have a website sitting on your computer — a folder of pages, photos, and styles — and you want other people to open it in a browser. That gap between “files on my laptop” and “a link I can send a customer” is what hosting closes. This walkthrough stays on that path: no servers to rent by the hour, no Linux homework, no rebuilding the site from scratch.
What “online” actually means
A website is a set of files. When someone types an address, their browser asks a computer somewhere on the internet for those files and draws the page. Hosting is the service that keeps those files ready to answer that request around the clock.
You do not need to own that computer. You need a place that accepts your files, gives you a working address, and stays up while you bake bread, shoot a wedding, or sleep. SiteHost is built for that: you upload what you have, get a secure preview link, then attach your own domain when you are ready.
Skip this guide if you are shopping for a full server you can log into with a terminal. Renting a VPS (a virtual private server) is a different product. You patch the operating system, configure web software, and recover from your own mistakes. Fine for engineers. Unnecessary if you only want a brochure site, portfolio, or landing page live.
Gather the files before you touch hosting
Open the folder you think is “the website.” You should see something like index.html near the top — that is the home page most hosts look for. Nearby you might find css, images, js, or similarly named folders. Click a few pages in a regular browser by double-opening index.html locally. Broken images and missing styles are cheaper to fix now than after a publish.
Checklist before you zip anything:
- Home page is named
index.html(notHome.htmlorpage1.htmlalone) - Links between pages use relative paths (
about.html,css/style.css) rather thanC:\Users\...orfile:/// - Large photo exports are resized for the web if you can; multi-megabyte hero images eat storage and load slowly
- You know which folder is the *root* of the site — the folder that contains
index.html, not a parent folder that only contains another folder
If a designer built the site, ask them for “a zip of the finished export” and whether the home file is at the root. One sentence of clarity here saves an afternoon of 404 pages later. More detail lives in how to upload website files and how to host an HTML website.
Zip, upload, get a preview URL
On SiteHost you create an account, start a new website, and upload a .zip of those files (or connect GitHub if that is how you already keep the project). After publish, you receive a preview address over HTTPS immediately. That link is real: share it with a friend, open it on your phone, click every menu item.
Typical failure modes on the first try:
- Nested zip. You zipped the parent folder, so the live site’s root contains only one folder and no
index.html. Visitors see a blank or a directory-style miss. Fix: unzip locally, zip the inner folder that actually holdsindex.html, upload again. - Wrong home filename. The server looks for
index.html.index.HTMorhome.htmlalone will not behave as the front door. - Broken asset paths. Absolute paths that worked on one machine fail on the host. Relative paths travel cleanly.
Treat the preview as your dress rehearsal. Custom domains come after the site looks right — not before. See how to make a website live if you are stuck on what “live” means before a domain is attached.
Domain last — DNS is not step one
A domain (like yourbakery.com) is a name you rent from a registrar. Hosting is where the files live. They are separate bills and separate dashboards on purpose.
When the preview looks good:
- In SiteHost, add your custom domain to the website.
- At the registrar, create the DNS records SiteHost shows you (often an A record or CNAME — follow the on-screen values exactly).
- Wait for DNS to verify. Propagation can take minutes or, occasionally, longer depending on TTL and prior settings.
- After DNS checks out, the certificate for your custom domain is issued. Until then, keep using the HTTPS preview.
Do not transfer the domain unless you specifically want a new registrar. Pointing DNS is enough. Walkthroughs: connect a domain to your website and how to point DNS to website hosting.
Contrast: this path vs renting a VPS
| Task | Site hosting (SiteHost) | VPS you manage |
|---|---|---|
| Put files on the internet | Upload zip / connect GitHub | Install web server, permissions, firewall |
| HTTPS | Preview cert right away; custom domain after DNS | You obtain and renew certificates |
| Undo a bad upload | Publish history / rollback of files | Restore from your own backups if you made them |
| OS security patches | Platform handles the machine | You schedule and apply them |
| Best for | Sites you already built as files | Apps, custom stacks, full control |
If your goal is “customers can open the menu page,” the left column is the honest match. If your goal is “I need root access,” buy a VPS elsewhere and expect a learning curve.
What SiteHost does not include (so you plan ahead)
SiteHost is website hosting, not a builder and not a control panel suite. There is no drag-and-drop site creator, no cPanel, no email inboxes bundled with the plan, and no built-in CDN. Many people put Cloudflare in front later if they want that layer; it is optional, not required to go live.
Plans scale by how many sites and how much storage you need: Starter at $9/mo for one site and 2 GB, Pro at $30 for three sites and 10 GB with staging, Scale at $65 for ten sites and 30 GB, Business at $130 for thirty sites, 100 GB, and teams. There is a short trial of about a day, then paid — no forever-free tier. If you need a WordPress CMS with themes and plugins, that is a different kind of hosting; this guide assumes you already have (or can get) website files.
After you are live: small habits that prevent panic
- Keep a local copy of the exact zip you published.
- Use publish history to roll back files if a new upload breaks layout.
- Change content in batches you can test on preview before you announce a redesign.
- Separate “site is up” from “email works.” Mail is usually at your registrar or a mail provider, not inside website hosting.
When something fails, name the layer: files (upload), name (DNS), or certificate (waits on DNS). Mixing those three into one vague “the website is broken” message slows every fix.
A bakery-sized example
You hired a student to design a three-page site: home, menu, contact. They hand you a Drive folder. You download it, confirm index.html opens locally, zip that folder, upload to SiteHost, and send the HTTPS preview to your partner. She notices the logo is stretched. You fix the image locally, zip again, publish, and roll back if the second try is worse. Only when both of you like the preview do you point yourbakery.com at the host. Customers never saw the broken logo version on the public domain.
That order — files, preview, domain last — is the whole method.
Questions people actually ask
Do I need to buy a domain before I can put the site online?
No. Get the HTTPS preview working first. Buy or point a domain when you are ready for the public name.
Is uploading a zip “real” hosting?
Yes. Visitors receive the same HTML, CSS, images, and scripts you uploaded. The zip is only the delivery package.
What if I only have a design in Figma or Canva?
You need exported website files (HTML and assets), not a design file alone. Ask whoever built it for a web export, or hire that last step. Hosting does not turn a mockup into pages by itself — SiteHost is not a website builder.
Can I undo a publish that went wrong?
Yes. SiteHost keeps deploy history so you can roll back to a previous set of files when a bad upload ships.
How is this different from social profiles and link-in-bio tools?
Those are profiles on someone else’s product. Hosting puts *your* files at *your* address. For a longer comparison, see website hosting for a personal brand.