Web page hosting sites are not one product ranked by price. They split into a small number of categories, and picking the wrong one costs more than picking the wrong vendor inside the right one. A static site host serves files you built elsewhere. A website builder generates the page for you inside its own editor. A WordPress host runs a specific piece of software with its own database. An application platform runs code, not just pages. Match the category to what you are actually publishing before comparing a single price.
Most “best web hosting” roundups rank a mixed bag of these categories against each other on price and uptime, as if a website builder and a static-file host were competing for the same job. They usually are not. Here is what each category actually is, and what the free tier in each one quietly costs you.
Table of contents
- Static site hosts
- Website builders
- WordPress-specific hosts
- Application platforms
- Shared and cPanel hosting
- What “free” actually costs you
- Matching category to what you’re publishing
- How this fits the rest of the stack
- FAQ
Static site hosts
For a site built somewhere else, a generator like Astro, Hugo or Jekyll, or a plain HTML export, a static host’s job is narrow: build from a repository, serve the resulting files fast, and hand you a custom domain, headers and redirects. There is no server-side process running your code, which is exactly why this category is usually the cheapest one.
The build step is worth understanding before you pick a static host, because it is the part that actually varies between them. Some run your generator’s build command against the repository on every push and serve whatever comes out. Others expect you to upload a pre-built folder yourself, which works but reintroduces a manual step the first approach removes entirely. A missing environment variable at build time, a Node version mismatch, or a broken image path are the usual causes of a static deploy that succeeds but renders wrong, and the fix is almost always in the build log rather than in the hosting configuration itself.
Website builders
A drag-and-drop builder generates and hosts the page inside one closed product. You design in the browser, publish with a button, and never see or own the underlying code. That is genuinely useful if you are not writing code and want one bill and one login. It is also the category with the least portability: leaving usually means starting the page over somewhere else, not exporting it.
The failure case worth knowing about ahead of time: a builder-made site’s content, layout and any custom scripts live entirely inside that vendor’s system, so a plan lapsing, a policy violation, or a decision to switch providers years later can mean rebuilding from screenshots rather than migrating a file. That is a reasonable trade for someone who wants the least technical overhead possible. It is worth going in with eyes open about what you are trading away for it, particularly if the site is expected to outlive the current pricing tier or grow into something more custom later.
WordPress-specific hosts
WordPress needs a database and a place to run PHP, which a plain static host does not provide. WordPress-specific hosting bundles that database, handles core and plugin security updates, and often adds a file manager or staging environment tuned specifically for that software, at a cost separate from generic hosting because the maintenance is CMS-specific.
What to check before picking one: whether core updates apply automatically or wait for you to click a button, whether the plan includes a staging copy for testing a plugin update before it hits the live site, and whether database access is a browser-based table view or strictly phpMyAdmin over a separate login. Those three differences explain most of the price spread between WordPress hosting tiers that otherwise list similar vCPU and memory numbers, and none of them show up in a headline price comparison. A plan that looks identical to a cheaper one on paper is often earning its higher price through exactly these operational details.
Application platforms
Anything with server-side logic, a login form, a database-backed submission, an API, needs a running process, not just files. This is a different category from static hosting entirely, and the confusion between the two is where a lot of “my contact form doesn’t work” support tickets come from: a static host was never going to run that code.
A concrete example: a static export of a React site can render a contact form’s markup perfectly, but submitting it needs somewhere to receive the POST request, validate it, and either email it or write it to a database. That receiving end is an application platform’s job, deployed separately from the static frontend, even when both end up served under the same domain through routing rules. Treating the two as one category is exactly how a working-looking site ships with a form that quietly does nothing, since nothing in the build process would have caught the gap.
Shared and cPanel hosting
The old-school category: one physical server split among many customers, managed through a control panel, cheap by the month. It can run a small site fine. It can also mean noisy-neighbor performance when another customer’s site spikes, and tooling that still expects FTP uploads in an era where most publishing is a git push.
The practical failure mode is intermittent, not constant, which makes it hard to diagnose: the site is fast most of the time and inexplicably slow for twenty minutes on a Tuesday, because a neighboring account on the same physical server is doing something CPU-heavy. There is no fix available to you as the customer beyond asking support to move your account, since the resource contention is architectural, not something in your own configuration, and no amount of caching on your end changes it. It is a real category with a real place; it just does not resemble a modern deploy pipeline in any way.
What “free” actually costs you
- A subdomain or forced branding instead of your own domain name
- A bandwidth cap that throttles the site or bills you once crossed
- No server-side code allowed at all, even a simple form handler
- Ads inserted onto your page to fund the free tier
- Cold starts if the free tier is app-based and sleeps when idle
- Support limited to a community forum, with no ticket for a real outage
- A build minutes allowance that runs out mid-month on a site that deploys often
None of that makes free hosting bad. It makes it a trial of the paid product rather than a separate durable option, which is a fine trade for a test project and a bad surprise for anything real. Read the specific limits before launch, not after a bandwidth bill arrives or a client asks why the site has someone else’s logo on it.
Matching category to what you’re publishing
A landing page or a blog built from a static site generator belongs on a static host. A page you want to design visually without writing code belongs with a builder. A content site that needs a plugin ecosystem and a database belongs on WordPress hosting. Anything that needs to run your own server-side logic belongs on an application platform.
A real project sometimes spans more than one category at once: a marketing site as static pages, a blog on WordPress, and a signup flow as a small application, each hosted appropriately rather than forced onto one host that is only good at one of the three. Picking the wrong category for any one piece is a bigger mistake than picking the wrong vendor inside the right one, since no amount of vendor loyalty fixes a static host being asked to run server-side code it was never built to run.
How this fits the rest of the stack
If what you are publishing is a landing page built from a repository, that is a static site job: build from Git, a custom domain, 120GB of bandwidth included and $0.10 per gigabyte after. If the page needs to do something, such as submit a form to a database or handle a login, that is a service, not a static site, and a Node or Python service deploys from the same kind of repository push. See what a specific stack costs on the RunxBuild hosting calculator.
Useful related references:
- Photography Hosting: What Image-Heavy Sites Actually Need
- Buying Hosting: The Line Items Nobody Puts on the Pricing Page
- App Hosting: What It Is, How It Differs From Web Hosting, and What You Actually Pay For
- Services on RunxBuild
FAQ
What is the best site to host a web page?
It depends entirely on what the page is. A static export from a generator belongs on a static host that builds from a repository. A page built inside a drag-and-drop editor stays with that builder. A page with server-side logic needs an application platform, not a page host.
Can I host a web page for free?
Yes, for a static export, several hosts include a free tier. Expect limits: a subdomain instead of a custom domain, a bandwidth cap that throttles or bills once crossed, and no server-side code. Free is usually a trial of the paid tier, not a separate durable product.
What is the difference between a website builder and a hosting site?
A builder generates and hosts the page inside one closed product, and you rarely get the underlying files. A hosting site serves files or runs code you supply, usually from a repository, and you keep ownership of what you built and can move it elsewhere later.
Do I need a different host for a WordPress site than for a static site?
WordPress needs a database and a place to run PHP, which a plain static host does not provide. WordPress-specific hosting bundles that database, security updates for the CMS itself, and often a file manager, none of which a static site needs.
Why do free hosting tiers put ads on my page?
Hosting the page costs the provider bandwidth and compute, and a free tier that does not charge you has to fund itself somehow. Ads and forced branding are the most common trade, alongside a subdomain instead of your own domain name.