2026-07-27 · 6 min read

How to put your website online (a beginner’s guide)

You have your website’s files. They look right when you open them on your computer. What’s got you stuck isn’t publishing it: it’s that there are three different ways to do it, each asks something different of you, and no one explained how they differ.

Here’s the whole map — including the routes that don’t go through FluentOps — so you can choose on the merits instead of going with whatever showed up in a video first.

What “putting a website online” actually means

Your site needs three things. You already have one of them.

• The files — what you made, or what an AI generated for you. They’re already on your computer.
• A public place for them to live — a computer that stays on, connected to the internet, handing those files to whoever asks for them. That’s what hosting is.
• An address — something anyone can type or click. A URL, like yourbusiness.com.

That’s it. “Publishing” is getting the other two and putting your files there. The hard part was never the what — it’s the different ways of getting it done. There are three.

Before you choose: what’s actually in that folder?

This step gets skipped almost every time, and it’s the number-one cause of “I uploaded it and it doesn’t work.” Open your folder and look:

• If you see an index.html (maybe a style.css, some images): that already is your site. The browser reads it as-is. Nothing to prepare.
• If you see a package.json, a src/ folder, and names like React, Vue, Next or Vite: your page doesn’t exist yet.

In that second case what you have is the *project*, not the site. Browsers don’t understand React or TypeScript, so a tool translates all of it into plain HTML, CSS and JavaScript and drops the result into a new folder — usually called dist (as in *distribution*) or build (as in what was built). Same idea, different name depending on the tool. That step is called building.

Which is why the folder is sometimes there and sometimes not: dist or build only appears after you build. Never ran that step, never got the folder. And if it’s there but stale, it reflects the build from three changes ago — not your latest work.

Why does this decide how you publish? Because a traditional hosting panel builds nothing: it uploads exactly what you hand it. Hand it an unbuilt project and you publish raw code that won’t load. Modern platforms — FluentOps among them — detect the project and build it for you, so you hand over the project folder, not the output one.

The three ways to publish it, and what each one asks of you

All three work. The difference isn’t the result — it’s how much you need to know before you get there:

1. The hosting panel. The classic route: buy a plan, log into a panel, open the file manager or an FTP client, and drag in what you want published. It works, and it has worked for decades. The cost is that you are the process: every change means rebuilding on your machine and re-uploading by hand, the security padlock (SSL) is sometimes a separate setup, and pick the wrong folder and you publish code instead of a site.

2. From a Git repository. GitHub Pages, Vercel and Netlify do this very well: connect a repo and every change you push goes live on its own. If you already live in Git it’s an excellent workflow and there’s little to fault. The catch is different: they assume you already use Git. For someone who just built their first page, learning Git *in order to publish* is a detour — the wall isn’t the deploy, it’s everything that comes before it.

3. Dragging the folder. The third route drops that requirement: you drag the folder in and the platform does the rest — works out what kind of project it is, builds it, publishes it, adds SSL. That’s what FluentOps does, and the Git repository is still waiting whenever you want it: connect it later and every change publishes itself, without having had to start there.

How to publish it, step by step

1. Find your site’s folder. The whole project, exactly as it is. You don’t need to build anything first.
2. Drag it into FluentOps. No commands, no FTP credentials, no setup.
3. Wait a few seconds. It detects the project type, builds it if needed, and publishes it.
4. Share your URL. It’s public now: it opens from any phone or computer in the world, padlock included.

And it stays there. Your site won’t pause or expire after months without a visitor — worth checking on whatever platform you pick, because several switch off or throttle free sites once the month’s credits run out.

What none of the three routes tells you is missing

Publishing is the first step, not the last. Two things almost nobody mentions decide whether your page works for you or merely exists.

Your page may be leaking things you don’t know about

When an AI generates a project, it also generates files that should never reach the internet. The usual suspects:

• A .env file holding your passwords and service keys, published right next to the site — downloadable by anyone who knows where to look.
• API keys written straight into the code, in plain view of whoever opens the file.
• The entire .git folder, exposing your source and your full change history.
• Source maps: files that let anyone download your original, uncompressed code. Nobody told you they were there.

An FTP panel uploads whatever you give it and stays quiet. FluentOps checks on every publish, both your code and what actually went live, and audits the libraries your project uses against known vulnerabilities — not just the ones you installed, but the ones those pull in, which is where they usually hide. Free shows you the checklist and a score for your site; Pro shows exactly which file, what it exposes, and how to fix it.

And it’s born invisible to Google

AI-built pages ship, systematically, with the title Vite App, no sitemap.xml, no robots.txt and no preview image — which is why sharing the link in a chat shows an empty grey box. None of that is your fault: they’re technical details nobody told you existed, and they cost your page visitors.

FluentOps checks seven of them on every publish — title, description, share preview, icon, main heading, sitemap.xml and robots.txt — and generates whichever are missing, using a screenshot of your own site as the preview image. With one rule worth demanding of any platform: your files always win. If you already brought your own sitemap.xml or icon, they’re left alone.

You’re live. Now what?

• Put your own domain on it. yourbusiness.com instead of a generic address, SSL included, at no extra cost.
• Let people reach you. A form that works with no backend turns a good-looking page into one that brings you customers.
• Publish the rest. Up to 21 sites on the free plan, and none of them pause for lack of traffic.

If you landed here because your page only opens on localhost and you want to understand why, start with this guide.

And don’t take any of it on faith — see for yourself. Put your page up and time how long it takes to stand in front of your customers.

Publish your page free →