Learning how to deploy a website is the moment a side project becomes something real. You have built the pages, everything looks right on your own screen, and now you want the world to type in an address and see it. The gap between “it works on my laptop” and “it is live” feels enormous the first time, but it is really a short series of steps: choose a host, move your files there, point a domain at the host, and turn on HTTPS.
My first deployment was a tiny portfolio and a folder of HTML and CSS. I uploaded the files, refreshed, and nothing happened — I had pointed the domain at the wrong place and had no idea how to check. The fix took ten minutes once someone explained DNS in plain language. That is what this guide does: no unexplained jargon, just a clear path from your local folder to a live URL. Whether your site is a static portfolio or a small project built in one of the best code editors, the process below will get it online.
What Does “Deploy a Website” Actually Mean?
Deploying a website means copying your site’s files to a computer that is always on, always connected to the internet, and configured to serve those files to visitors. That always-on computer is a server, and the company renting you space on one is a hosting provider.
Right now your site probably lives at localhost:3000 — your own machine talking to itself. A deployed site lives at a public address: an IP address like 203.0.113.42 or, far more usefully, a domain name like yoursite.com.
Every deployment has three moving parts:
- Files — your HTML, CSS, JavaScript, and images, as they sit in your project folder.
- A server — rented space where those files will live permanently.
- A domain name — the human-friendly address pointing visitors to that server.
Everything else — DNS records, FTP logins, SSL certificates — is plumbing connecting these three: pack the boxes (files), rent the new place (server), tell the post office your new address (domain).
Before You Deploy: The Pre-Launch Checklist
Run through this list before touching any hosting dashboard — it dodges the mistakes that send most beginners back to square one.
Confirm the site works locally. Open every page and click every link. If something is broken on your laptop, deployment will not fix it — it will just make the broken thing public.
Name your homepage index.html. When a visitor requests a folder, the server automatically serves the index.html inside it. Any other name gives visitors an error or a bare directory listing.
Use lowercase, no-space filenames. Servers (usually Linux) treat About.html and about.html as different files, while your laptop may not. Stick to lowercase names with hyphens: about-me.html. Case mismatches are a classic “works locally, broken online” bug.
Make links relative. Links to C:\Users\you\my-site\style.css or http://localhost:3000/images/logo.png die the moment files leave your machine. Use relative paths like style.css and images/logo.png.
Know whether your site is static. No database, no form backend, no server-side code? Then you have a static site — just HTML, CSS, JavaScript, and images — and your hosting choice gets much simpler.
Choosing Where to Host Your Site
Hosting marketing is loud, but there are only three broad categories. Pick based on what your site needs.
Static hosting platforms
Services built for static sites — plain HTML, CSS, and JavaScript with no server-side code. You usually connect your project through Git and the platform publishes it to a public URL within minutes. Many offer a genuinely useful free tier, and custom domains are standard.
Best for: portfolios, landing pages, documentation, static-site-generator blogs. If your checklist said “no database, no server code,” start here — the fastest path from folder to live URL.
Shared hosting
The classic option: your site shares one server with many other customers, managed through a control panel with a file manager, email accounts, and one-click installers for software like WordPress. It supports server-side languages like PHP, which matters if you need a form backend or a database-driven CMS.
Best for: WordPress sites, small business sites, and PHP projects where you want a control panel instead of a command line.
Virtual private servers (VPS)
You rent a whole virtual machine and configure everything yourself: the operating system, web server software, database, and security updates. Maximum power and flexibility — and maximum responsibility. You will live in the command line.
Best for: web apps with backends and databases, and learning how servers actually work. Our beginner guides to how APIs work and Docker become relevant here — but not for deploy number one.
Which should a beginner pick?
Match the host to the site: static site → static platform; WordPress/PHP → shared hosting; custom app with a database → VPS. The classic beginner mistake is renting the most powerful option “to be safe” and drowning in server configuration. Start small — your first deploy should teach you the process, not server administration.
Connecting a Domain Name: DNS Without the Headache
Your hosting gives you a server; now you need a memorable address — a domain name like yourname.com instead of an IP address like 203.0.113.42.
Buying the domain. You purchase domains from a registrar. Search for the name you want and register it, usually one year at a time. Shorter is better; avoid hyphens and tricky spellings, and double-check the spelling before paying. Some hosts also sell domains, but you are never required to buy domain and hosting from the same company.
Understanding DNS. The Domain Name System is the internet’s phone book: it translates yourname.com into your server’s IP address. You manage it with DNS records. The two beginners meet most:
- A record — points your domain at an IP address. Example:
yourname.com → 203.0.113.42. - CNAME record — points one name at another. Example:
www.yourname.com → yourname.com.
Many static platforms ask you to add the specific records shown in their docs — follow those character for character.
Propagation takes time. Changed records must spread across servers worldwide, a process called propagation that takes minutes to 48 hours. During that window, the site may load for some people and not others. That is normal. Do not keep editing the records every ten minutes “to fix it” — you will only restart the clock.
Pick one canonical address. Decide whether your main address is yourname.com or www.yourname.com, then redirect the other to it. Most platforms handle this with a single toggle.
Uploading Your Files: File Manager, FTP, and SFTP
Three common ways to move your files onto the server.
The browser file manager. Shared hosting control panels include a web file manager: open the website root folder (often public_html, htdocs, or www) and upload your files. Fine for a small first deploy; tedious for hundreds of files.
FTP and SFTP. FTP moves files to a server; SFTP is its encrypted sibling — always prefer SFTP when offered. In a free FTP client you enter the server address, username, and password from your hosting account and get a two-pane window: your computer on the left, the server on the right. Drag files across. The key skill is knowing where they go: the website root (public_html or equivalent). Files placed anywhere else are invisible to visitors.
Git-based deploys. Many modern platforms skip manual uploads: push your code to a Git repository and the platform publishes it automatically. If you already track your project in Git — and if the two still blur together, our Git vs GitHub explainer clears it up — this is the smoothest workflow of all. Full walkthrough below.
The golden rule: your local project folder and the server’s website folder should mirror each other. Identical structure eliminates an entire category of deployment bugs.
Turning On HTTPS: Why SSL Matters
HTTPS is the padlock in the address bar. It encrypts the connection between visitors and your server, and in 2026 it is not optional: browsers warn visitors away from plain-HTTP sites.
The good news: HTTPS is now effectively free and often automatic. Most reputable hosts offer one-click certificates, and many static platforms enable HTTPS by default once your domain is connected. After enabling it, check three things:
- The padlock appears on your domain — try both the
http://andhttps://versions. - HTTP redirects to HTTPS. Turn on your host’s “force HTTPS” toggle so the old address bounces visitors to the secure one.
- No mixed content. If the page loads over HTTPS but pulls an image or script over HTTP, browsers block or warn about it. Use
https://(or relative paths) for every resource.
If the padlock will not appear, the usual culprits are DNS still propagating or the domain not showing as connected in the hosting dashboard. Wait, confirm, then retry the SSL toggle.
How to Deploy a Website with Git: A Simple Workflow
Once manual uploads get old — and they get old fast — Git-based deployment is the upgrade. Your code lives in a Git repository, and every push automatically rebuilds and republishes your site.
1. Turn your project into a Git repository:
git init
git add .
git commit -m "First version of my site"
A code editor with built-in Git support makes these steps clickable instead of typed.
2. Push the code to a Git hosting service:
git remote add origin <your-repository-url>
git push -u origin main
3. Connect the repository to your hosting platform. In the platform’s dashboard choose “import from Git,” select your repository, and confirm the settings.
4. Push to deploy. From now on, deploying is:
git add .
git commit -m "Update the about page"
git push
A minute or two later the live site updates, and the platform’s deploy log shows you exactly what happened.
The underrated bonus: every deploy is a snapshot you can roll back. Pushed something broken? Revert the commit, push again, and the site returns to the working version. FTP uploads cannot do that.
You do not need branching, rebasing, or any advanced Git for this. add, commit, and push are the entire deployment vocabulary at this stage.
8 Common First-Deploy Mistakes (and How to Fix Them)
Almost every beginner hits at least two of these — all fixable in minutes once you know where to look.
1. A directory listing or “Index of /” page. Files are in the wrong folder, or the homepage is not named index.html. Confirm index.html sits directly inside the website root, not a subfolder.
2. Text loads but images and styles are broken. Wrong paths — usually absolute local paths or case mismatches. Open developer tools (F12), check the Network tab for 404s, and fix each path.
3. “This site can’t be reached” right after DNS changes. Propagation. Verify the records are correct, then wait — check again in an hour instead of changing things.
4. The domain works without www but not with it (or vice versa). Missing record: you set an A record for the bare domain but no CNAME for www. Add the missing record or use the platform’s domain settings.
5. HTTPS warnings or no padlock. The certificate is not issued yet (usually a propagation timing issue), or you have mixed content. Fix the URLs, force HTTPS, and reissue if needed.
6. New files uploaded, but the site looks unchanged. Caching. Hard-refresh with Ctrl+Shift+R (Cmd+Shift+R on Mac). Some hosts also cache server-side — look for a “purge cache” option in the dashboard.
7. A 403 Forbidden error. The server refuses to serve the files: almost always permissions or a missing index.html. Folders generally need 755 and files 644 — your FTP client can set these.
8. A 500 Internal Server Error. A server configuration problem — often a bad .htaccess on shared hosting. Rename it temporarily; if the site recovers, fix the offending lines. On static platforms, read the deploy log instead.
See the pattern? Nearly every first-deploy failure is files in the wrong place, names that do not match, unfinished DNS propagation, or caching.
After Go-Live: What to Do Once Your Site Is Live
The site is online. A little follow-through now turns a “deployed” site into a maintained one.
Test like a visitor. Open the live URL in a private/incognito window and on your phone. Click everything and submit every form, hunting for anything that behaves differently in production — hardcoded localhost URLs in JavaScript are the classic catch.
Add basic analytics. A lightweight, privacy-friendly snippet tells you whether anyone visits and which pages they read.
Back up your work. With Git-based deploys, your repository is the backup. With FTP uploads, keep a dated zip of the project folder. Store your hosting login, registrar login, and DNS notes somewhere secure.
Tell search engines you exist. Create a sitemap.xml, add a robots.txt permitting crawling, and submit the sitemap in Google Search Console. That guarantees discovery, not rankings — but discovery comes first.
Document your update workflow. Write down how future changes go live: Git push, FTP upload, or file manager. Sites stagnate after launch largely because the owner forgot how they deployed it.
Do monthly basics. Check the domain has not expired (enable auto-renew), the SSL certificate is valid, and the site still loads.
Keep learning the stack. Deployment is the doorway, not the destination. When projects outgrow static files, you will meet SQL databases, server-side Python, and eventually containers — each building on the model you just formed: files, a server, and an address.
Key Takeaways
- Deploying a website means arranging three things: your files, a rented server, and a domain name pointing at it.
- Before deploying: verify the site works locally, name the homepage
index.html, and use lowercase relative paths. - Match hosting to the project: static platforms for static sites, shared hosting for WordPress/PHP, a VPS for full control.
- DNS connects domain to server with A and CNAME records; propagation takes time, so set records once and wait.
- Upload via file manager, SFTP, or — best of all — a Git workflow where every push redeploys automatically.
- Enable HTTPS, force all traffic to it, and fix mixed-content warnings.
- Almost every first-deploy failure is wrong folder, wrong filename case, unfinished DNS propagation, or caching.
- After go-live: test in incognito, add analytics, back up, submit a sitemap, and document your update workflow.
Frequently Asked Questions
How long does it take to deploy a website the first time?
The hands-on work takes under an hour: signing up for hosting, uploading files, and pointing the domain. The wildcard is DNS propagation — minutes to 48 hours.
Do I need to know how to code to deploy a website?
You need a website to deploy, but that can be a single index.html from a tutorial. Deployment itself is mostly configuration, not programming.
How much does it cost to deploy a website?
A domain costs a small annual fee; hosting ranges from free tiers (enough for many static sites) to a few dollars a month for shared hosting. Start on the cheapest option that fits your site and upgrade only when it outgrows it.
What is the difference between a registrar, a host, and DNS?
The registrar sells you the domain name. The host’s server stores your files. DNS connects the two by translating your domain into your server’s address.
Can I deploy a website for free?
Yes, for static sites — several platforms offer free tiers with HTTPS and custom domains that suit portfolios and personal projects. If your site needs a database or server-side code, expect to pay at least a small amount.
Why does my site work on localhost but not after deploying?
The four usual suspects: absolute file paths from your machine, filename case mismatches, localhost hardcoded in code, or files in the wrong folder. Open developer tools, check the Network tab for 404s, and work through the mistakes section above.
Conclusion
Knowing how to deploy a website turns you from someone who builds pages into someone who publishes them. The process is the same every time: prepare your files, rent the right hosting, connect your domain with DNS, upload the files, switch on HTTPS, and fix the small mistakes every beginner meets. Do it once with a simple static site, and the second deploy — with Git doing the heavy lifting — feels routine.
Type your first live URL into a browser, watch your own work load from a server somewhere in the world, and send the link to someone. Then keep the rhythm: update, push, and let deployment fade from an event into a habit. Now go ship it.