LiteSpeed Cache Setup Guide: Get WordPress Configured Right

You installed LiteSpeed Cache, flipped it on, and... nothing changed. Or worse - your WooCommerce cart started showing the wrong items, or the site threw a 500 error the moment you activated it. LSCWP (LiteSpeed Cache for WordPress) is one of the fastest caching layers available on cPanel hosting, but the default install only gets you halfway there. The rest is configuration, and most people never touch it.

Symptom: Installed, Activated, Still Slow (or Broken)

A few variations of the same complaint show up constantly in support tickets:

• PageSpeed score barely moved after installing the plugin.
• A logged-in customer sees another visitor's cart total or account name.
• The homepage shows content from three edits ago, even after clearing cache.
• The site returns a 500 Internal Server Error right after activation.

All four have the same root cause: LSCWP ships in a safe, mostly-off default state. It doesn't know your site is running WooCommerce, doesn't know which pages must stay dynamic, and doesn't know if your server even has the actual LiteSpeed cache module behind it. You have to tell it.

Cause: The Plugin Alone Isn't the Cache

This trips people up constantly: LSCWP is a control panel, not the cache engine itself. The real caching happens at the web server level, in LiteSpeed's LSCache module. If your hosting runs plain Apache or Nginx instead of LiteSpeed (OpenLiteSpeed or LSWS Enterprise), the plugin quietly falls back to a much weaker PHP-only cache - it still 'works,' but you lose most of the performance gain.

Check cPanel > Software > LiteSpeed Web Cache Manager. If that icon exists, you're on a LiteSpeed stack and the full feature set applies. Getwebup's shared and VPS WordPress plans run LiteSpeed by default, so this step is usually just confirmation.

Fix: Configure It Properly, Section by Section

1. Cache tab - the toggles that actually matter

Under LiteSpeed Cache > Cache > Cache, set:

• Enable Cache - ON (both front end and, if you use the REST API heavily, that toggle too)
• Cache Logged-in Users - OFF for a typical blog/business site, ON only for membership or LMS sites where logged-in visitors need speed too
• Cache Commenters - OFF unless you have a reason to cache their view specifically
• Private Cache for Logged-in Users - ON if you enabled logged-in caching above; this keeps each user's cached copy private to them instead of shared

The customer-sees-someone-else's-cart bug almost always traces back to 'Cache Logged-in Users' being ON without 'Private Cache' also being ON.

2. Exclude pages that must never be cached

Go to Cache > Excludes and confirm cart, checkout, and my-account URIs are listed. If you're running WooCommerce, LSCWP auto-detects and adds these on activation - but verify it, especially after a theme or page-builder change that altered your URL structure. To exclude a custom path manually:

/checkout/*
/my-account/*
/cart/*

3. Purge rules - stop the stale-content complaints

Under Cache > Purge, enable auto-purge on: post/page publish or update, product stock change (if WooCommerce), and comment approval. Without this, editors keep hitting 'clear all cache' manually every time, which defeats the point of caching in the first place.

4. Turn on ESI for partial dynamic content

Edge Side Includes let you serve a fully cached page while still showing a live mini-cart count or a personalized 'Hi, Name' block. Enable it under Cache > ESI. Without ESI, a single dynamic element on the page forces you to either exclude the whole page from caching or accept a stale cart count - ESI fixes that trade-off directly.

5. Object cache - the upgrade most people skip

Page cache speeds up repeat visits; object cache speeds up every database-driven request, cached or not. Under Cache > Object, connect Redis or Memcached if your plan includes it:

Method: Redis
Host: 127.0.0.1
Port: 6379
Default Object Lifetime: 360

If Redis isn't installed on your server yet, our Redis setup guide for VPS covers installation before you flip this toggle - LSCWP will just fail to connect silently if the service isn't running.

6. CDN tab - don't let two caches fight each other

If you also run Cloudflare in front of the site, connect its API key under CDN > Cloudflare so a manual or auto purge in LSCWP also purges Cloudflare's edge cache. Skip this step and you'll keep seeing old content served from Cloudflare's edge for hours after LSCWP has already updated its own cache.

Common Errors Right After Setup

• 500 error on activation - usually a conflict in .htaccess between LSCache rewrite rules and another caching plugin's rules still present from before. Remove any old W3 Total Cache or WP Super Cache blocks from .htaccess first.
• Crawler running constantly, spiking CPU - under Crawler, lower the concurrent crawler threads (2-3 is plenty for most sites) and set a sane crawl interval instead of leaving it at aggressive defaults.
• 'Cache not purging' after an edit - check whether the edit happened through a page builder that doesn't trigger WordPress's native save_post hook; some builders need their own LSCWP purge-integration setting turned on separately.

Prevention

• After any theme, plugin, or page-builder update, re-check the Excludes list - updates occasionally add new dynamic endpoints that need excluding.
• View page source and look for the X-LiteSpeed-Cache response header (or the HTML comment LSCWP adds) to confirm a page is actually serving from cache - 'it feels faster' isn't proof.
• Never run two page-cache plugins together. If you're migrating from WP Rocket or W3TC to LSCWP, fully deactivate and remove the old one's rules first.
• Recheck object cache connectivity after any server migration - a hardcoded Redis IP will silently break if the new server's internal address changes.

Once these are set, LSCWP stops being a plugin you installed and forgot, and starts doing what it's actually built for - full-page caching with none of the stale-content or broken-cart side effects that give caching plugins a bad name.