Account Watchlist
Hosting for high traffic blogs — The client whose good day lands on your allotment
A publisher who has never had a busy day will not warn you before their first one, and the difference between a compliment and an incident is configuration you did months earlier.
Straight answer first
For a publisher client, cache configuration decides whether a spike costs you anything at all: a well-cached article is served without waking PHP, so the load lands as bandwidth against your reseller allotment rather than as compute against everybody else's account.
So the reseller's job on this account type is bandwidth planning and cache verification, not horsepower. Below: what a spike actually consumes on your plan, the cache settings to confirm before the client ever needs them, what to cap and what to leave open, and how to bill an account whose usage is genuinely unpredictable.
Written by the Hosting Seller staff · Checked 24 August 2026
Free
Migration for the client's archive
24/7
Cover when a post takes off
Daily
Backups on the client account
$0
Setup on reseller plans
A cached article can be handed to tens of thousands of readers as copies while the server itself deals only with the trickle of comments and searches. Surviving a stampede is a matter of cache design rather than raw horsepower — which is excellent news for a reseller, because cache design is something you do once and bandwidth is something you can plan.
The relevant allotments: Reseller 1 carries 300 GB of bandwidth a month across 30 GB of NVMe, Reseller 2 carries 600 GB across 60 GB, and Reseller 3 carries 1.5 TB across 100 GB. Those bandwidth figures, not the CPU, are what a viral day consumes.
What a spike actually costs you
Do the arithmetic in bandwidth rather than in drama. An article page with images, served cached, might be 800 KB. Fifty thousand readers in a day is roughly 40 GB. On Reseller 1's 300 GB monthly allowance, that is a noticeable but survivable event; on Reseller 2's 600 GB it is barely visible. The client's biggest day of the year is a line on your usage graph.
Where it stops being survivable is when the cache is not working. An uncached article is built by PHP against the database on every single request, and fifty thousand of those is a different category of event entirely — one that hits the CPU limit on the account, returns errors to the client's biggest ever audience, and produces the worst phone call in this trade.
So the number to verify is cache hit ratio, and the time to verify it is the quiet week when the client signs up, not the afternoon their post is on the front page of somewhere. LiteSpeed runs at the server rather than being bolted on by plugin, which is the arrangement that makes a hit never reach PHP at all.
The configuration to confirm before it matters
Server-level caching switched on and demonstrably serving. Open the article in a private window, check the response, and confirm a second request is served from cache. Do this at onboarding and write down that you did it.
The uncacheable exceptions identified. Comments, search, and anything logged in will always reach PHP. On a publisher's site that is a small fraction of traffic and it is fine — but you should know which URLs they are, because those are the ones that will fail first if anything does.
Image handling settled. WebP optimisation is built in and costs nothing, and it is the single biggest lever on the bandwidth figure above. A publisher uploading straight from a camera roll doubles your bandwidth consumption for no visible benefit to anybody.
And the client's own plugins reviewed. A related-posts plugin doing an unindexed query on every page load is invisible at two hundred visitors a day and fatal at fifty thousand. NVMe underneath helps every database-shaped operation, but it does not rescue a query that should not exist.
What to cap, and what to leave open
Cap disk. You set the limits each client account gets, and disk is the one where a publisher will quietly grow forever as the archive and its image library accumulate. A quota that notifies you is a sales conversation; no quota at all is a surprise on your own supplier account.
Do not cap bandwidth tightly on this account type. A publisher whose best day of the year is throttled by their own agency will remember it for the rest of the relationship, and the cost to you of an extra 40 GB is not worth the goodwill. Set the alert generously and watch the aggregate instead.
Cap processes and entry points thoughtfully. This is the setting that protects your other clients when the cache does fail, and it is worth being deliberate rather than accepting a default. A capped account returns errors under extreme load; an uncapped one can take neighbours with it, and you would rather explain the first than the second.
Billing an account you cannot predict
Publisher clients break flat-rate pricing in a way brochure sites do not, because their consumption is genuinely lumpy. Two structures work. The first is a flat retainer with a generous included allowance and a clearly published overage rate — the allowance is almost never exceeded, and the rate exists so the one month it is does not become an argument.
The second is to price the account for its peak from the start and never mention usage again. This is simpler to sell and simpler to administer, and publishers often prefer it because their own revenue is advertising-shaped and correlates with the traffic anyway. Charge for the ceiling, deliver the ceiling, stop counting.
What does not work is silence. A reseller who has never discussed traffic with a publisher client, and then raises the invoice after a big month, looks like a utility rather than an adviser. The conversation costs ten minutes at onboarding and prevents the only genuinely unpleasant version of this relationship.
Cache first, hardware second
LiteSpeed runs at the server on every shelf rather than being fenced off behind a premium tier, which means the arrangement that makes a spike cheap is available on the smallest package you build.
NVMe underneath handles the part caching cannot — the comment, the search, the archive query — so the uncacheable fraction stays quick even on the client's biggest day.
- Server-level caching, not a plugin imitation
- WebP optimisation included at no charge
- Per-account process limits you set yourself
- Bandwidth allowances published per plan
Why Hosting Seller
On every plan, as standard
A spike lands as bandwidth
Properly cached, a viral day consumes allowance rather than CPU, which is a number you can plan for months in advance.
LiteSpeed on every shelf
Server-level caching is not reserved for a premium tier, so the smallest package you build already has the mechanism that matters.
WebP included
Image optimisation at no charge is the largest single lever on a publisher client's bandwidth consumption.
Process limits you control
Set per-account caps deliberately so that if a cache does fail, the failure stays inside one account.
Published bandwidth allowances
300 GB on Reseller 1, 600 GB on Reseller 2 and 1.5 TB on Reseller 3 — real numbers to plan a publisher's year against.
Cover at the moment it matters
Round-the-clock support behind your desk, for the day the client's post takes off at two in the morning.
Price Tags Compared
How we compare with the household names
Typical sign-up and renewal prices across the market, set next to ours — the second number most comparison charts leave off.
| Line item | Hosting SellerBest seller | Typical big-brand host | Typical budget host | Typical loss-leader |
|---|---|---|---|---|
| Entry price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Price at renewal / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Renewal price on the entry plan is unchanged | ||||
| SSL on every plan | ||||
| Site migration included | ||||
| The entry plan uses NVMe storage | ||||
| Entry plan gets a backup daily | ||||
| Live human support, 24/7 |
*The number in our column is the cheapest plan on our shelf, priced on an annual term and pulled live from the very catalogue that feeds the pricing page, so it cannot drift out of date. Other columns show the ranges shared hosting tends to advertise inside each bracket: introductory rates that normally ask for a one-to-four-year commitment, then climb once that term expires. Naming individual competitors and printing their prices is something we have stopped doing. A figure we cannot re-check on the day you read it has no business sitting in front of you. So compare us with whoever you are genuinely weighing up, and read the renewal line first. That line tells you more than the headline ever will.
First Steps
From choosing to live
- 1
Verify the cache at onboarding
Load an article twice in a private window, confirm the second request is served from cache, and record that you checked.
- 2
List the uncacheable URLs
Comments, search and anything logged in will always reach PHP; know which they are before they are the ones failing.
- 3
Settle image handling on day one
WebP optimisation on, and a written export guideline for the client — this is most of the bandwidth figure.
- 4
Have the traffic conversation before the traffic
Agree an allowance and an overage rate, or price the peak outright, so a big month never arrives as a surprise invoice.
In the Box
Packed with every plan
- Server-level caching verified serving, not merely enabled
- The uncacheable URL list written down at onboarding
- WebP optimisation left on for image-heavy publishers
- A disk quota that notifies you before it blocks the client
- Process and entry-point limits set deliberately per account
- Aggregate bandwidth reviewed monthly against the allowance
- The client's plugin stack reviewed for unindexed queries
- An overage rate published, or the peak priced from the start
- Daily backups running on the publisher's account
- A separate cPanel account, never shared with quieter clients
Across the Counter
Things people ask us all the time
How much bandwidth does a viral article actually use?
Multiply page weight by readers. An 800 KB article page served to fifty thousand people is roughly 40 GB — significant against Reseller 1's 300 GB monthly allowance and modest against Reseller 2's 600 GB. Image optimisation moves that figure more than anything else you can do, which is why WebP being included at no charge matters more on this account type than on any other.
Does a publisher client need a VPS?
Almost never, and suggesting one usually means the caching has not been checked. A well-cached blog answers nearly every request without waking PHP, and shared resources handle that comfortably at volumes that sound alarming. The genuine triggers are sustained rather than spiky load, a heavy logged-in membership area, or software that cannot be installed in a shared package — not a single good day.
Should I let a publisher client into their own caching settings?
Give them the plugin and keep the server-level configuration. Publishers tend to be comfortable in WordPress and will happily clear a cache to see a change, which is fine. What you do not want is a client disabling server-level caching because a tutorial told them to, on the week they are about to be popular. Document what you have set and why.
What do I do if the client's biggest day happens anyway and the account struggles?
Check the cache before you check anything else — an account failing under load with caching working is rare, and an account failing with caching broken is the overwhelmingly common case. Upgrades apply in place with no migration, so raising the shelf mid-incident is a genuine option. Afterwards, the incident is the conversation that sells the account its proper tier.
How should I price an account whose traffic is unpredictable?
Either a flat retainer with a generous published allowance and a stated overage rate, or a price set for the peak with usage never mentioned again. Both work. What fails is having no conversation at all and then raising an invoice after a big month, which turns an adviser into a utility in one email.
Read next
Game Server VPS
The always-on client workload, and why constant load is easier to size than an occasional stampede.
WordPress Hosting
Managed WordPress with staging copies and daily backups, for client sites whose update liability is yours.
Web Hosting
cPanel accounts on NVMe with SSL, migration and year-one domain — the shelf most client packages are modelled on.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Plan the spike before it happens.
300 GB to 1.5 TB of bandwidth depending on the shelf, LiteSpeed on every package, and limits you set per client account.
See WordPress Hosting plans