This is an old revision of the document!

General Troubleshooting Guide For LSCWP

Here are a few common issues and how to deal with them. Please follow these steps first before logging any ticket with us since your issue might have been resolved.

Our LSWCP plugin has been developed at a very fast pace. Some compatibility issue with other plugins/or break message may have already been fixed in the latest version. You should always upgrade to the latest version and advice us which LSWCP you are using.

Please check out image optimization guide first to resove your issue.

This problem is caused when using multiple web applications under a single domain. You can find more information on this issue and how to resolve it in our Handling Logged-in Cookie Conflicts page.

If your site uses a plugin that updates the content of a page without editing/saving that page, such as a “like” button that updates a counter when pressed using ajax, LSCache will not be made aware that the page should be purged from cache. As long as the now outdated copy of the page is still in cache and being served, it will appear like these changes never happened.

To fix this, you can add our LiteSpeed_Cache_API::purge_post($id) API call to the offending plugin to have it notify LSCache that the page should be purged.


  1. Purge the cache and with the inspector open (right click page → Inspect) access the page as a guest/non-logged in user.
  2. In the inspector, click into the Network tab and select the page request - this is usually the first entry. With this selected, click the Header tab and check that the Response Header does not contain “X-LiteSpeed-Cache: hit”.
  3. (If your plugin updates on each visit, skip this step) Refresh the page. You should now see “X-LiteSpeed-Cache: hit” in your response header. This indicates that the page was served from cache.
  4. Trigger your plugin and make sure that the page is updated as expected.
  5. Refresh the page one last time. “X-LiteSpeed-Cache: hit” should once again be gone from the Response Header and the page should still contain the updated information.

Scheduled Posts are published in WordPress through a WP cron job. Normally, WordPress triggers the cron job each time a request hits the backend. The backend is rarely hit, however, when using a cache, which causes scheduled posts to publish late.

LSCWP will correctly purge the cache when a scheduled post is published in the cron job. All you need to do is make sure that you can reliably hit the backend. This can be done by scheduling a cron job to hit wp-cron.php at your ideal interval.

For Example, to update scheduled posts every 15 minutes:

*/15 * * * * wget http://your_wp_site/wp-cron.php

When using a server level cron job, WordPress suggests defining DISABLE_WP_CRON in your wp-config file to disable checking wp-cron on a backend hit.

define('DISABLE_WP_CRON', true);

This may be useful in reducing the number of calls made to wp-cron if that is desired.

For a more in-depth discussion of this issue, see our blog.

Most likely, this is not an LSCache issue, since LSCWP doesn't cache static files.

If your theme's CSS is not properly loaded after an update, check your browser cache. Does the reload work? Do you have a CDN or a reverse proxy in front of your webserver, such as CloudFlare? These caching mechanisms may need to be purged. See this forum post for more details.

If you generate sitemap but see crawler still Size 1 or 2. You can try following steps to debug the issue.

  1. Step 1. Verify sitemap URL works
  2. Step 2. Verify any URL's of sitemap is able for public visit
    1. Fix: If only visible for private may cause sitemap generate issue
  3. Step 3. Verify /wp-content/plugins/litespeed-cache/var/crawlermap*.data exist (Optional)
    1. Fix: Probably a permission issue
  4. Step 4. Verify environment home_url is identical to Step 2's URL. e.g. are different.
    1. Fix: Change Settings>General>Site Address (URL) value to match sitemap.
  • Admin
  • Last modified: 2018/07/19 15:20
  • by Jackson Zhang