Set up LiteSpeed WebAdmin rules to cache custom CMSs. Learn to define TTL, exclude dynamic URLs, and automate purges for optimal speed.
5 min read
LiteSpeed Cache (LSCache) is a server‑level caching solution that works out of the box with popular CMS platforms such as WordPress and Joomla. For custom or less‑common CMSs that lack a native LSCache plugin, you can still obtain the same performance gains by creating custom WebAdmin rules. These rules tell LiteSpeed exactly how to cache, purge, and serve your pages.
Why Use WebAdmin Rules for Non‑Standard CMSs?
WebAdmin rules give you fine‑grained control over LiteSpeed’s caching behavior without requiring a dedicated plugin. They let you:
Define which URLs should be cached or excluded.
Set a cache TTL (time‑to‑live) based on content type.
Automatically purge the cache when content changes via API calls or webhook scripts.
Handle cookies, query strings, and request methods that your custom CMS relies on.
All configuration is done in the LiteSpeed WebAdmin console, so the rules are applied at the web‑server level and work for any PHP, Node.js, Python, or static‑site generator you may be using.
Prerequisites
Before writing rules, ensure you have:
A running LiteSpeed Enterprise or OpenLiteSpeed server with LSCache enabled.
Administrative access to the LiteSpeed WebAdmin UI (default URL: https://your-server-ip:7080).
Root or sudo privileges on the server to edit configuration files if needed.
Basic knowledge of your CMS’s URL structure, cache‑able endpoints, and how it invalidates content (e.g., via a webhook or CLI command).
Step 1 – Identify Cache‑able and Dynamic URLs
Map the routes your CMS serves. Typical patterns include:
Static assets: /assets/*, /images/*
Public pages: /blog/*, /products/*
Admin or API endpoints that must stay dynamic: /admin/*, /api/*
Record these patterns; you’ll reference them when creating Cache Rules and Purge Rules in the WebAdmin UI.
Step 2 – Create a Basic Cache Rule
Log in to the WebAdmin console and navigate to Cache → Cache Rules. Click Add and fill in the fields as shown.
Rule Settings
Name:CustomCMS_PublicPages
URI Pattern:/blog/* (replace with your own pattern)
Cache TTL:3600 seconds (1 hour – adjust as needed)
Ignore Cookies:0 (set to 1 if your pages set non‑essential cookies)
Vary By Query String:0 (enable if query parameters affect output)
Save the rule. LiteSpeed will now cache any request matching /blog/* for one hour.
Step 3 – Exclude Sensitive or Dynamic Content
Not everything should be cached. Create an Exclude Rule for admin panels, login pages, or API calls.
Example Exclude Rule
Name:CustomCMS_Admin
URI Pattern:/admin/*
Cache Control:no-cache
This tells LiteSpeed to bypass the cache for any URL under /admin/, ensuring authenticated users always see fresh content.
Step 4 – Set Up Automatic Purge Triggers
When content changes, the cached copy must be invalidated. LSCache supports purge via HTTP requests, which you can trigger from your CMS after a publish, update, or delete operation.
Creating a Purge Rule
In the WebAdmin UI, go to Cache → Purge Rules and add a new rule:
Name:CustomCMS_PurgeBlog
URI Pattern:/blog/*
Purge Method:GET (or POST if you prefer)
From your CMS, issue an HTTP request to the built‑in purge endpoint whenever a blog post is modified. The request format is:
curl -X GET "https://your-domain.com/purge?tag=CustomCMS_PurgeBlog"
If your CMS runs on the same server, you can use a local script. Below are example scripts for Debian/Ubuntu (apt) and AlmaLinux/Rocky/RHEL (dnf). Place the script in /usr/local/bin/lscache-purge.sh and make it executable.
Debian / Ubuntu (apt) Script
# Ensure curl is installed
sudo apt update
sudo apt install -y curl
# Purge function
purge_blog() {
local url="https://localhost/purge?tag=CustomCMS_PurgeBlog"
curl -k -s "$url"
}
# Execute the function (your CMS can call this script)
purge_blog
AlmaLinux / Rocky / RHEL (dnf) Script
# Ensure curl is installed
sudo dnf install -y curl
# Purge function
purge_blog() {
local url="https://localhost/purge?tag=CustomCMS_PurgeBlog"
curl -k -s "$url"
}
# Execute the function (your CMS can call this script)
purge_blog
Explanation of commands
sudo apt update / sudo dnf install -y curl – installs the curl utility needed for HTTP requests.
curl -k -s "$url" – sends a silent HTTPS GET request to the purge endpoint, ignoring self‑signed certificates (-k) and suppressing progress output (-s).
Step 5 – Test and Verify Your Rules
After configuring cache, exclude, and purge rules, run a quick test to confirm the expected behavior.
Testing a Cache Hit
# First request – should be a cache miss
curl -I https://your-domain.com/blog/sample-article
# Subsequent request – should show "X-LiteSpeed-Cache: hit"
curl -I https://your-domain.com/blog/sample-article
Look for the header X-LiteSpeed-Cache: hit on the second request. If you see miss, double‑check the URI pattern and TTL.
Testing a Purge
# Trigger purge (simulate a CMS publish)
curl -X GET "https://your-domain.com/purge?tag=CustomCMS_PurgeBlog"
# Request the page again – should be a miss after purge
curl -I https://your-domain.com/blog/sample-article
The header should revert to miss, indicating the cached copy was cleared.
Advanced Tips for Complex CMS Setups
Non‑standard CMSs often have nuanced caching needs. Consider these enhancements:
Vary By Cookie: If your site personalizes content based on a specific cookie (e.g., language or theme), enable Vary By Cookie and list the cookie name.
Cache By Query String: For pages that change based on query parameters (e.g., /search?q=term), enable Vary By Query String and specify the allowed parameters.
Edge Side Includes (ESI): Use ESI tags in your HTML to cache the bulk of a page while keeping small dynamic fragments (such as a logged‑in user’s name) uncached.
Conditional Purge via API: If your CMS provides a webhook, configure it to call the LiteSpeed purge endpoint directly, eliminating the need for a local script.
All of these options are available under Cache → Advanced Settings in the WebAdmin UI.
Conclusion
Even without a native LSCache plugin, you can achieve fast, reliable caching for any custom or lesser‑known CMS by leveraging LiteSpeed’s WebAdmin rules. Identify URLs that are safe to cache, explicitly exclude dynamic routes, and automate purges whenever content changes. By following the steps above—and adapting the patterns to your site’s structure—you’ll unlock the performance benefits of server‑level caching while keeping your custom application fully functional.
litespeed cachewebadmin rulescustom cms cachinglscache configurationcache purgeweb server performanceopenlitespeedurl caching
Try it on your own server
Follow along on a Cloud VPS with full root access, or read the step-by-step knowledge base guides.