How Much Traffic Can Shared Hosting Handle?

There’s no honest single number. A shared plan runs out of room when too many uncached requests arrive at the same moment, not when monthly visits pass a threshold.

A well-cached site can serve far more visitors than an uncached store on the same plan.

What matters is your peak concurrency, your cache hit rate, and your plan’s process and CPU limits.

Below is a method to estimate your own plan’s ceiling from its published limits, and a safe way to test it.

Why monthly visits are the wrong measure

Monthly visits describe volume over 30 days, but servers fail in seconds, so capacity depends on how many requests arrive together.

Take 30,000 visits a month. Spread evenly, that’s about one visit every 90 seconds. Almost any plan handles that.

Traffic is never even. A newsletter send, a social post, or a crawler can push a day’s traffic into one hour.

Hosts still advertise monthly figures, so read them as rough guides. Here are a few hosts’ own estimates, as listed on October 4, 2026:

These are the hosts’ claims, not our measurements. None of them says what cache rate or page type the estimate assumes.

For your site, this means the label is a starting point. Your own peak and cache rate decide the real answer.

Still choosing a plan type? The web hosting basics for first-time buyers compare them.

What actually uses up a shared plan

A shared plan runs out when uncached requests fill its process slots or use up its CPU share, and bots count as much as people.

Three things drive that:

• Concurrent uncached requests. Each one needs a PHP process until it finishes. Plans cap these as entry processes or PHP workers.
• CPU per request. Slow plugins, searches, carts, and admin pages use more processor time than a cached blog post.
• Bots. Crawlers, uptime monitors, and scrapers send requests too, often to pages your cache doesn’t cover.

A cached page skips PHP entirely, so it barely touches those limits. That’s why caching layers and how they work matter more to capacity than the plan name.

Each shared hosting limit is explained, with where to see it in your panel, in a separate guide: Hosting Resource Limits Explained.

How to estimate your plan’s capacity

You can estimate capacity in five steps, using your analytics and your plan’s published limits.

Every input below is an example assumption. Replace each one with your own numbers.

Step 1: find your peak hour

Peak-hour visits = monthly visits / 30 x peak-day factor x share of the day in the busiest hour.

Example: 30,000 / 30 = 1,000 a day. Assume your best day is three times average, so 3,000 visits.

Assume its busiest hour holds 15% of that day. That’s 450 visits in the peak hour.

Step 2: turn visits into concurrent visitors

Concurrent visitors = peak-hour visits x average visit length in seconds / 3,600.

Example: 450 visits x 180 seconds / 3,600 = about 23 people on the site at once.

That’s people reading. Most of the time they aren’t requesting anything, which is why 23 readers don’t need 23 processes.

Step 3: count the requests that reach PHP

Uncached requests per second = peak-hour pageviews / 3,600 x share not served from cache, then add bot traffic.

Example: 450 visits x 2.5 pages = 1,125 pageviews an hour, or 0.31 a second. At an 80% cache hit rate, 0.06 a second reach PHP.

Assume bots double that load, to about 0.12 uncached requests a second. Check your own logs for the real bot share.

Step 4: compare with your process limit

Busy processes = uncached requests per second x average seconds each one takes.

Example: 0.12 x 0.5 seconds = 0.06 processes busy on average. Against a 20-entry process limit, that leaves wide headroom.

The ceiling from this limit is your process count/seconds per request. For 20 processes at 0.5 seconds, that’s about 40 uncached requests a second.

Step 5: check the CPU limit

CPU often runs out before process slots do, so estimate it too.

CPU ceiling = CPU cores allowed / CPU seconds each uncached request uses.

Example: with half a core available, if each uncached request uses 0.3 seconds of CPU, the ceiling is 0.5 / 0.3, or about 1.7 uncached requests a second.

That’s far below the 40 a second from Step 4. In this example, CPU sets the limit.

Putting the example together

At 80% cache, 1.7 uncached requests a second means about 8.5 page requests a second, bots included.

With bots doubling the load, as assumed in Step 3, that’s roughly 15,000 human pageviews in one hour.

That’s the ceiling for this set of assumptions, not a promise. At a 50% cache rate, the same CPU ceiling allows only about 3.4 page requests a second.

You can’t easily measure CPU seconds per request on shared hosting. A load test on a staging copy, described below, is how you find out.

For your site, this means two levers matter most: raise your cache hit rate, and cut the work each uncached request does.

Example: two real plans side by side

Here is how the same method reads two published plan limits. The workload numbers are still example assumptions.

Limits come from Namecheap’s resource limits guide and Hostinger’s plan parameters article.

Treat the bottom two rows as arithmetic on assumed inputs. Neither host has been load-tested by us, and burst allowances can change the picture for short spikes.

What our own data shows, and what it doesn’t

Our accounts show that a shared plan comfortably runs several small sites and that bots make up most requests on a new site. They don’t show a maximum visitor number.

The Hostinger Business plan we’ve paid for since December 2024 runs eight live sites plus our test site.

Over 30 days, UptimeRobot logged 100% uptime on it, with a 336 ms average response.

The same test site scored 99 in PageSpeed Insights on desktop and mobile. The nine-site Hostinger account behind those numbers was serving normal, modest traffic, not a stress load.

Bot traffic is the other lesson. In the first three days of our Kinsta WP2 account, 53,394 of 59,234 requests came from verified bots.

Only 1,093 requests, 1.8%, were human.

That’s a short window on a brand-new site with little real traffic, so the bot share is likely to be lower on an established site.

Still, the three-day Kinsta traffic log shows why capacity planning must count bots. On shared hosting, they spend the same process slots and CPU as people.

How to test your own plan safely

A load test on a staging copy shows your real ceiling, using your own pages, plugins, and cache.

Ask your host first. On shared hosting, a load test also loads the server your neighbors use, and some hosts restrict it in their terms.

• Step 1, make a staging copy. Test a copy of the site, never production. Use the host’s staging tool or a second site on the same plan.
• Step 2, install k6. Grafana k6 is a free, open-source load testing tool. Its guide to running k6 covers setup.
• Step 3, write a short script. Request your home page and one uncached page, such as a search result. Add a pause between requests to mimic reading.
• Step 4, ramp up slowly. Use k6 stages to step virtual users up in small increments, for example 5, then 10, then 20.
• Step 5, watch your panel. Keep the resource usage page open and note when entry process, CPU, or memory faults start.
• Step 6, stop at the first sign of trouble. That’s 508 errors, failed requests, or response times that jump sharply.
• Step 7, record the level. The last stage before trouble is your practical ceiling for that page mix.

A virtual user (VU) is not a visitor. The k6 documentation calls VUs “essentially parallel while(true) loops,” so without pauses, one VU sends far more requests than one reader.

Compare your result with the math above. If the test fails well before your estimate, the bottleneck is usually a slow plugin or poor caching, not the plan.

For your site, this means one afternoon of testing replaces guesswork. Repeat it after big changes, like adding a store.

When to move beyond shared hosting

Move up when your measured peak regularly reaches your plan’s ceiling even after caching and cleanup, not when a monthly visit number looks big.

The common signs you’ve outgrown a plan cover the symptoms that show up first.

How hosts spread load across servers is a separate topic, covered in load balancing on shared hosting.

The usual next step is cloud hosting, where CPU and memory are allocated to your server rather than capped per account on a shared one.

The cloud hosting picks for growing sites compare those plans.

If your numbers show headroom, a larger shared plan may be enough. The shared plans compared by published limits show process, CPU, and RAM caps side by side.

Frequently asked questions

How we researched this

The capacity method in this article is arithmetic: published plan limits combined with example inputs that are labeled as assumptions.

No shared plan has been load-tested by us, which is why no host gets a visitor-capacity number here.

Namecheap’s and Hostinger’s limits come from their official help articles, rechecked October 4, 2026.

The hosts’ own visit estimates were read on the SiteGround, HostGator, and FastComet pricing pages on September 25 and rechecked on October 4, 2026.

Our own numbers cover 30 days of Hostinger monitoring and the first three days of the Kinsta WP2 plan.

The load-testing steps follow Grafana’s k6 documentation, and our monitoring follows the published testing method.