If you’ve encountered the dreaded WordPress message that reads “There has been a critical error on this website”, you’re not alone. Whether you’re a seasoned developer or a site owner with limited technical expertise, this white screen of death can be distressing. However, in many cases, the fix is simpler than it appears. One effective solution involves purging your object cache. In this article, we’ll delve into what this error means, how object caching works, and provide a step-by-step guide to resolving the issue using an object cache purge.
Understanding the “Critical Error” in WordPress
This error typically surfaces due to PHP-related issues—often from faulty plugins, themes, server limitations, or misconfigurations. It results in a complete halt of your WordPress site, often accompanied by an email sent to the admin with more details. While it may sound severe, the error doesn’t always mean permanent damage. Many times, it’s simply the result of cached data clashing with new updates or changes.
What Is Object Caching?
Object caching is a method used in WordPress to store the results of expensive or frequently used queries so that they don’t have to be run repeatedly. This improves your site’s performance and scales better under heavy traffic. WordPress has a built-in object caching mechanism, often enhanced by caching plugins like Redis, Memcached, or third-party services.
However, object caching can sometimes cause problems when changes aren’t registered properly, especially after a theme update, plugin installation, or site migration. In those cases, purging the object cache might resolve the critical error without further interventions.

Why Purging the Object Cache Works
When WordPress caches data using object caching, it stores “snapshots” of your site’s elements—such as database queries and API call results. If any of this cached data becomes corrupted or outdated, it can lead to system-level errors, including the infamous critical error message.
Purging or clearing the object cache forces WordPress to regenerate these elements freshly, ensuring there are no conflicts or obsolete code executions. Essentially, this gives your site a clean slate to rerun its functions correctly.
Steps to Fix the Critical Error via Object Cache Purge
If you’re ready to roll up your sleeves, follow this comprehensive guide to troubleshoot the error and safely purge your object cache:
Step 1: Access Your Site’s Backend
Unfortunately, since your site is showing the critical error message, you may not be able to log in to the WordPress dashboard. Instead, you’ll need to access your site files via:
- FTP client like FileZilla
- cPanel File Manager offered by your web host
- SSH access, if you’re familiar with command-line operations
Step 2: Disable Object Cache Temporarily
Locate your wp-config.php
file in the root directory of your WordPress installation. Add the following line before /* That's all, stop editing! Happy publishing. */
:
define('WP_CACHE', false);
This line disables caching temporarily and may allow you to regain access to your dashboard. Be sure to enable it again after the issue is resolved.
Step 3: Identify the Caching Mechanism Used
WordPress sites can use various object caching backends. Common ones include:
- Redis
- Memcached
- WP Rocket’s object cache
- W3 Total Cache
Check your wp-content
folder for files or folders with names like object-cache.php
or directories named after caching plugins. This gives you a clue about the caching system in place.
Step 4: Flush or Purge the Object Cache
This step varies based on your setup:
1. For Redis Users
Use an SSH terminal and run:
redis-cli flushall
Note: Only do this if you’re comfortable with Redis and understand the consequences of flushing all data. It will remove all cached content from Redis.
2. For Memcached Users
echo "flush_all" | nc localhost 11211
Alternatively, contact your hosting provider and ask them to do it for you.
3. Via WordPress Dashboard
If you regain access to your site, use the caching plugin’s built-in purge function:
- W3 Total Cache: Go to Performance > Dashboard and click “Empty All Caches”
- WP Rocket: Navigate to Settings > WP Rocket and choose “Clear Cache”
- LiteSpeed Cache: Go to LiteSpeed Cache > Toolbox and select “Purge All”

Step 5: Restart Services (If Needed)
If you’re on a VPS or dedicated server, restarting services like PHP-FPM and web servers (Nginx or Apache) can help reset the cache effects.
sudo systemctl restart php-fpm
sudo systemctl restart nginx
Best Practices After Resolving the Error
Now that your site is back up and running, here are a few actionable tips to prevent future occurrences:
- Update plugins and themes regularly: Always use the latest stable versions.
- Use well-maintained caching plugins: Not all caching tools are created equal. Opt for those with active support and frequent updates.
- Clear cache after major changes: Anytime you make structural changes to your site, clear the cache to avoid conflicts.
- Implement monitoring tools: Use tools like New Relic, Query Monitor, or Debug Bar to identify slow queries and prevent future errors.
Alternatives If Purging Cache Doesn’t Fix the Error
If purging the object cache doesn’t resolve the issue, you might want to try these alternatives:
-
Enable Debug Mode: Add the following line to
wp-config.php
to display detailed error messages:
define('WP_DEBUG', true);
plugins
folder inside wp-content
to plugins_old
and see if the error persists. If resolved, enable plugins one by one to identify the culprit.Conclusion
Seeing a “critical error” on your WordPress site might initially cause panic, but it can often be solved through a logical, calm process. Purging the object cache clears out outdated or conflicting data, giving your site the opportunity to boot with fresh configurations. Whether you’re using Redis, Memcached, or a plugin-based architecture, the steps outlined above will help you diagnose and remedy the issue effectively.
Always remember: regular maintenance is your best defense. Keep your WordPress installation tidy, purge unnecessary data, and keep an eye on system logs. That way, the next time a critical error appears, you’ll be well-equipped to handle it without missing a beat.