Reseller runbook · Density and margin · 20 minutes

How to enable LiteSpeed caching — Caching Is How You Fit More Clients on the Same Package

Your reseller package has a fixed amount of headroom, and uncached client sites spend it on requests that could have been answered from memory.

See Reseller Hosting plans More in How-To Library

Straight answer first

Switch caching on for every client site as part of the build, because a cache hit answers without touching PHP or the database — which is directly how many client accounts one reseller package can comfortably carry. Caching is a density decision before it is a performance decision.

Practically: install the LiteSpeed Cache plugin on each WordPress account, leave the defaults alone at first, then prove the hit in the response headers rather than assuming. The exceptions to check are the shop and membership clients, where cart, checkout and account pages must stay out of the cache.

Written by the Hosting Seller staff · Checked 24 August 2026

Beginner

Skill assumed

Stages in the runbook

Free

Cost of support

Tested

Verified on our platform

Resellers read caching as a speed feature and price it as a nice-to-have. It is really a capacity feature, and it decides how much of what you bought you actually get to sell.

The work itself is small and identical on every account, which is exactly what makes it worth doing as a standard rather than as a favour for the clients who complain.

The density argument for switching it on everywhere

A cached page is served without running PHP, without a database query and without the application waking up. On an estate that means the same package absorbs considerably more traffic before anything feels slow, and the constraint you paid for goes further than it otherwise would.

Because it is a capacity argument, it applies most to the accounts you would never bother optimising: the small brochure sites that get modest traffic and no attention. Those are also the ones with the heaviest themes and the least maintenance, and switching cache on for them costs you five minutes each.

Fitting it into the build so nobody has to remember

Put the plugin and its baseline settings into your standard build for WordPress accounts, alongside the plugin set you already install every time. Anything that depends on remembering will be present on the accounts you set up while you were thinking about it and absent from the rest.

Then leave the defaults alone. Out of the box the lifetimes and rules fit most sites, and the urge to tour every setting before confirming the basics work is where resellers create their own tickets. A standard configuration you can compare across forty accounts is worth more than a tuned one you cannot reproduce.

The shop and membership clients that need checking

Cart, checkout and account pages must never be cached, and with a common shop plugin those exclusions apply themselves automatically. The word doing the work there is 'automatically' — verify it rather than trusting it, because the failure mode is a customer seeing somebody else's basket.

Then add anything custom to the never-cache list: a bespoke members' area, a personalised dashboard, a quote form that renders differently per visitor. On a client site that takes money, do this check before you switch caching on rather than after, and put it on the checklist for every ecommerce build you do.

Proving the hit to a client who does not believe you

Clients test their own site immediately after you touch it, usually while logged in, which is exactly the state that bypasses the cache. They then report that nothing has changed and you spend an afternoon on an explanation.

Get ahead of it. Open the network tab in browser dev tools and look at the response headers on a second visit: the cache header reporting a hit is your proof, and a screenshot of it is a better answer than any amount of prose. Tell the client to test in a private window, and tell them before they test rather than after.

Server-level caching, not a plugin doing its best

LiteSpeed caching runs at the server rather than being bolted on by a plugin, and it is on the shelf at every price point rather than behind a premium tier — so the cheapest package you sell has the same engine as the dearest.

NVMe storage underneath means the requests that cannot be cached are still answered from fast disk.

LiteSpeed caching at the server, every plan
NVMe storage underneath every account
WebP image optimisation built in, free
Packages you define and price yourself

Why Hosting Seller

On every plan, as standard

Framed as capacity, not speed

The argument is about how many client accounts a package carries, which is the number that affects your margin.

A standard, not a favour

Written to go into the build for every WordPress account rather than only the clients who complain.

Shop clients handled first

Cart and checkout exclusions are treated as a pre-flight check on any site that takes money.

The disbelief anticipated

How to prove the cache is working, to a client testing while logged in, is part of the routine.

Included at every price point

Server-level LiteSpeed is on the shelf on every plan, so density is not something you have to buy up to.

Support at any hour

People answer for you and your clients, including when a purge is the answer nobody has tried.

First Steps

From choosing to live

1
Add it to the standard build, not to a to-do list
Plugin plus baseline settings, in the build you use for every WordPress account. Anything that depends on remembering will be missing from most of the estate within a year.
2
Check the exclusions before you enable, on any site that sells
Cart, checkout and account pages out of the cache — verified rather than assumed. On a client shop this check precedes switching caching on, because the failure mode is a customer seeing the wrong basket.
3
Leave the defaults alone until it is proven working
The out-of-the-box lifetimes and rules fit most sites. Touring the settings first is how a working configuration becomes an unreproducible one across forty accounts.
4
Prove the hit in the response headers
Browser dev tools, network tab, second visit. The cache header saying hit is the evidence. Take a screenshot; it saves the conversation you are otherwise about to have.
5
Tell the client how to test before they do
In a private window, logged out. Logged-in views bypass the cache, and a client testing while logged into their own admin will report that nothing happened.

In the Box

Packed with every plan

NVMe SSD underneath and LiteSpeed cache in front, at every price point
WebP image optimisation built in and costing nothing extra
cPanel, the panel your clients and your contractors already know
WordPress Toolkit, with updates applied for you
Packages you build, name and price yourself
WHM for you, and a cPanel of their own for every client account
Client-account allowances of 100, 250 or 500, depending on the package
Real people answering, for you and for your clients, at any hour
Staging on the plans that carry it, so nothing untested reaches a client
A 99.9% uptime target, watched by monitoring day and night

Across the Counter

Things people ask us all the time

Does caching let me host more client sites per reseller package?

In practice yes, and that is the main argument for doing it everywhere. A cache hit is served without running PHP or touching the database, so the same package absorbs more traffic before anything feels slow. The accounts that benefit most are the small ones you would never otherwise optimise.

Is LiteSpeed on the accounts I create, or only on my own?

It runs at the server rather than per account, and it is on the shelf at every price point rather than behind a premium tier — so the smallest client package you build has the same engine as your own site. That is what makes an estate-wide standard possible.

A client's checkout is showing stale prices. What did I miss?

An exclusion. Cart, checkout and account pages must never be cached, and while a common shop plugin excludes them automatically, that needs verifying rather than trusting. Add any custom personalised page to the never-cache list too.

Who purges the cache after a client changes their logo?

Whoever made the change, ideally the client, which means the purge button belongs in the handover document. Design and structural changes need a purge before anybody sees them, and that button is the answer to most reports that a change has not appeared.

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.

Get more from the package you already pay for.

Server-level LiteSpeed caching and NVMe storage at every price point, with packages you define, name and price yourself.

See Reseller Hosting plans