Shared hosting explained simply: your website sits on one server with many other accounts, all drawing from the same CPU, memory and disk. It is the cheapest hosting tier and it suits most small sites. The limits are resource ceilings, not storage, and they bite under traffic rather than at rest.
Shared hosting is the plan almost everyone starts on, and the one most often described badly. Sales pages sell it on storage and bandwidth. Those are rarely what runs out. This article covers what you are actually sharing, where the real ceilings sit, and how to tell whether you have reached one.
What shared hosting actually is
A physical server is a powerful computer. Running one for a single small website would waste most of its capacity, so hosts divide it between many accounts.
Each account gets its own file space, its own databases, its own domains and its own control panel login. Those are isolated from each other. What is not isolated is the underlying hardware. Every account on that machine draws from the same pool of processor time, memory and disk throughput.
That is the whole model. The economics follow directly: split a server between hundreds of accounts and each one costs very little. If the underlying idea is new to you, start with what web hosting is.
What you share, and what you do not
You share: CPU cycles, RAM, disk read and write throughput, the server’s IP address in most cases, and the network connection out of the rack.
You do not share: your files, your databases, your email accounts, your control panel, or your SSL certificate. On a properly configured host, one account cannot read another account’s data.
The shared IP address is the part people overlook. If another site on your IP sends spam or gets flagged, your email deliverability and occasionally your search visibility can suffer through no fault of yours. Good hosts monitor for this and act on abuse quickly. It is also one of the practical reasons infrastructure ownership matters, since a host that controls its own IP space can move you off a damaged range far faster than one leasing addresses from a wholesale provider. IP reputation and hosting explains how to check yours.
The limits that actually matter
Hosting plans advertise storage and bandwidth. Neither is usually your constraint.
Storage rarely runs out. A WordPress blog with several hundred posts typically sits well under 5 GB. Most entry plans include more than that.
Bandwidth rarely runs out either. Unmetered means there is no hard counter, not that there is no limit, a distinction we unpack in unlimited vs unmetered hosting. Small sites do not approach the fair use threshold.
CPU and memory are the real ceilings. This is what runs out, and it runs out during your busiest hour rather than gradually. When you exceed the allowance, the server queues or rejects requests. You see slow pages, or a 503 error, or a resource limit notice in the control panel.
Entry processes and I/O are secondary ceilings. Entry processes cap how many requests your account can handle at the same time. I/O caps how fast you can read and write to disk. Both are invisible until a traffic spike makes them visible at once.
Inodes cap file count. Usually only relevant for sites with enormous media libraries or aggressive caching that generates thousands of small files.
If you take one thing from this article: judge a shared plan by its CPU, memory and entry process allowance, not by its storage number.
Who shared hosting genuinely suits
Shared hosting is the correct choice, not a compromise, for a large share of websites.
- Personal blogs and portfolios.
- Small business brochure sites.
- Local service businesses with a contact form.
- Community and club sites.
- Landing pages and campaign microsites.
- WordPress sites with moderate traffic and sensible caching.
- Small stores with a modest catalogue and occasional orders.
If your site is mostly content, gets cached well, and does not run heavy background processing, shared hosting will serve it for years. Paying for a VPS in that situation buys you headroom you never use and administration you did not want.
Who should not be on shared hosting
- Stores with steady order volume or large catalogues, where checkout pages cannot be cached.
- Membership and learning platforms, where most pages are logged in and therefore dynamic.
- Applications that need Node.js, Django, custom daemons or root access.
- Sites with strict compliance requirements around data location or isolation.
- Anyone running scheduled jobs that are heavy or frequent.
- Sites with predictable large traffic spikes, such as ticket sales or event launches.
The common thread is dynamic, uncacheable work. Caching is what makes shared hosting fast. Remove the cache and the plan’s resource allowance is exposed.
Signs you have outgrown it
You do not need to guess. Shared hosting tells you.
- 503 errors or resource limit notices during busy periods, but not at quiet times.
- Pages that load quickly at 3am and slowly at 3pm.
- CPU or memory warnings in cPanel, or emails from your host about usage.
- The admin dashboard getting sluggish while the front end still looks fine.
- Backups or plugin updates slowing the whole site while they run.
One of these occasionally is normal. Several of them weekly is a signal.
We have a full guide to when to move from shared hosting to a VPS, including the traffic thresholds and a no-downtime migration path, so it is covered properly there rather than summarised here.
Managed and unmanaged, applied to shared hosting
Almost all shared hosting is managed. The host patches the operating system, configures the web server, runs the firewall and handles hardware.
What that does not include is your application. If a WordPress plugin has a vulnerability, or your theme generates 400 database queries per page, that is yours to fix. Support boundaries vary, so it is worth asking where the line sits before you need the answer.
This is a reasonable division, but it is stated less clearly than it should be across the industry, ours included.
What to check before buying a shared plan
| Check | Why it matters |
| CPU and memory allowance | The ceiling you will actually hit |
| Entry processes | Caps concurrent request handling |
| Renewal price | Usually several times the intro rate |
| Backup frequency and retention | Daily is standard; a seven-day window is thin |
| Self-service restore | The difference between minutes and a day |
| Free SSL with auto-renew | Should not be an upsell |
| PHP version control | You will need to change it eventually |
| Data centre location | Latency to your actual audience |
| Server-level caching | The main reason shared hosting feels fast |
| Free migration in | Saves real work |
If a provider will not publish the resource allowances, treat that as the answer. For what each line should cost, see how much web hosting should cost, and for the wider buying process, how to choose a web host.
An honest word about density
Shared hosting quality comes down to one number that no host publishes: how many accounts sit on each server.
A provider can sell the same specification and deliver very different results depending on density. Low density costs more to run and produces better response times under load. High density is cheaper and more profitable. There is no way to check this from the outside before you buy, which is why running your own uptime and response monitoring for the first three months is worth the small effort.
That applies to us as much as to anyone else. If you want to test it, our shared hosting plans are the place to start.
Frequently asked questions
For most small business sites, yes. A brochure site or local service site with a contact form runs comfortably on shared hosting. The tier becomes a poor fit once most of your pages are dynamic and uncacheable, such as a store checkout or a members area.
Not inherently. A well-cached site on a low-density shared server can be very fast. Slowness usually appears under concurrent traffic, when your account reaches its CPU or entry process allowance, rather than at quiet times.
Account isolation on a properly configured shared server prevents one customer reaching another’s files. The larger risk on any tier is your own application: outdated plugins, weak passwords and unpatched themes cause most small site compromises.
There is no universal number, because it depends on how cacheable your pages are. A static content site handles far more visitors than a store on the same plan. Watch your resource usage in the control panel rather than a visitor count.
On shared hosting you draw from a common pool of CPU and memory. On a VPS those resources are reserved for your account, and you usually get root access. A VPS costs more and, unless it is managed, requires you to administer the server.
Yes. The standard approach is to build the site on the new plan, test it on a temporary address, and only then change DNS, which keeps the old site live throughout the transition.
