Your site is down. The browser shows a white screen or a 502 Bad Gateway. You panic, check the server status, and see everything is 'green.' The CPU isn't pegged. The disk isn't full. Yet the site is dead.
In support tickets I handled, the usual culprit was rarely the hosting provider's hardware. It was a mismatch between the software stack and the server limits. Most site owners treat hosting as a black box. You pick a plan, upload WordPress, and expect it to run. That mindset leads to specific, avoidable errors that degrade performance until the site collapses under its own weight.
This isn't about finding the "fastest" host. It's about configuring the environment correctly. Here are the five errors that cause crashes, and how to fix them without switching providers.
1. Ignoring the PHP Memory Limit
The most common cause of the "White Screen of Death" is running out of memory. WordPress is a PHP application. PHP has a hard limit on how much memory a single script can use. When a plugin, theme, or database query exceeds this limit, the PHP process dies. The web server returns an error, and you see white.
Many shared hosting plans default to 128 MB or even 64 MB of PHP memory. Modern WordPress installations with a few active plugins can easily exceed this during peak loads. If you are on a VPS or dedicated server, you control this setting. If you are on shared hosting, you may need to edit a .htaccess file or ask your provider to increase it.
How to check and fix it
First, determine your current limit. Create a file named phpinfo.php in your root directory with the following content:
<?php phpinfo(); ?>
Load it in your browser and search for memory_limit. If it says 128M or lower, you are at risk.
To increase it, add this line to your .htaccess file:
php_value memory_limit 256M
If you have access to the php.ini file, edit it directly:
memory_limit = 256M
Restart PHP or Apache for changes to take effect. In my experience, 256 MB is a safe baseline for most sites. High-traffic sites or those with heavy plugins like WooCommerce may need 512 MB or more. Do not set it to unlimited. That is a recipe for a single bad script to consume all server memory and crash the entire node.
2. No Object Caching Layer
Page caching handles the HTML output. It is the first line of defense. But page caching does nothing for dynamic queries. If your site displays user-specific content, recent posts, or custom post types, those elements are generated on every request. Without object caching, every single visitor triggers a fresh database query for that data.
Object caching stores the results of database queries in memory (usually Redis or Memcached). The next time that query runs, the server pulls the result from RAM instead of querying the database. This reduces database load by orders of magnitude.
Most shared hosting plans do not enable Redis or Memcached by default. They assume you only need page caching. If you are running a site with more than a few hundred daily visitors, the lack of object caching will eventually cause timeouts. The database gets hammered, connections pile up, and the site slows to a crawl or crashes.
How to implement it
Check if your host offers Redis or Memcached. Many modern cPanel and Plesk panels have a toggle for "Redis Cache" or "Persistent Object Cache." If you have a VPS, you can install Redis yourself.
For WordPress, you need a drop-in replacement for the default object cache. Install a plugin like "Redis Object Cache" or use a custom object-cache.php file in your wp-content directory. Here is a basic example for Redis:
if ( defined( 'WP_REDIS_HOST' ) ) {
require_once ABSPATH . 'wp-content/plugins/redis-cache/object-cache.php';
}
After enabling it, clear your cache and monitor your database queries. You should see a significant drop in query count per page view. If your host does not support object caching and you cannot install it, consider moving to a host that does. This is not a "nice to have." It is a requirement for stability at scale.
3. Undersized Database Connection Pool
PHP memory limits how much memory a single script uses. The database connection pool limits how many simultaneous connections the database can handle. These are two different resources. You can have plenty of PHP memory and still crash if your database connection pool is too small.
MySQL and MariaDB have a setting called max_connections. If this value is too low, new connections are rejected when the limit is reached. WordPress throws a "Too many connections" error. This often happens during traffic spikes. A single popular post or a marketing email can send a burst of traffic that exceeds the pool size.
Shared hosts often set max_connections very low to prevent one user from starving others. This is a fair approach, but it means your site is vulnerable to bursts. If you are on a VPS, you control this setting. Increase it to match your expected traffic. A good starting point is 100-200 connections for a small to medium site.
How to adjust it
Edit your my.cnf or my.ini file:
[mysqld]
max_connections = 150
Restart MySQL. Monitor your database using a tool like mysqladmin or a monitoring plugin. Look for the number of active connections. If you see it hitting the limit regularly, increase it further. Also, check for long-running queries. A single slow query can hold a connection open for seconds, blocking others. Optimize your queries or add indexes to free up connections faster.
4. Misconfigured Caching Plugin Rules
Caching is powerful, but it is also fragile. If your caching plugin is misconfigured, it can serve stale content, block admin access, or cause conflicts with other plugins. I have seen sites where the caching plugin cached the login page, locking users out. Or where it cached the cart page, showing the wrong items to different users.
The problem is usually a mismatch between the caching rules and the site's dynamic elements. Not everything should be cached. User-specific pages, admin pages, and pages with dynamic forms should be excluded.
How to audit your caching rules
- Exclude Admin Pages: Ensure
/wp-admin/is never cached. - Exclude User-Specific Pages: If you have a "My Account" page, exclude it. Caching it means User A sees User B's data.
- Exclude Dynamic Content: If you use AJAX for loading content, ensure the AJAX endpoint is not cached.
- Check for Conflicts: Disable all plugins except your caching plugin. Test the site. If it works, re-enable plugins one by one to find the conflict.
Many caching plugins have a "purge" button. Use it after making changes. But do not rely on it alone. Set up automatic purging when posts are updated. This ensures users see fresh content without manual intervention.
5. Ignoring Server-Side Limits
PHP memory, database connections, and caching are all software-level settings. But they run on a server with physical limits. CPU, RAM, and I/O are finite. If your site is heavy, it will eventually hit these limits, no matter how well you configure the software.
Shared hosting is the most common place for this to bite. Your site shares resources with hundreds of other sites. If one of those sites runs a heavy script, your site slows down. This is called "noisy neighbor" effect. You have no control over it. If your site is critical, shared hosting is a risk. Move to a VPS or dedicated server where you have isolated resources.
On a VPS, you still need to monitor resource usage. Use tools like htop, iostat, or a monitoring service like Datadog or New Relic. Set alerts for high CPU, low memory, or high I/O wait. If you see these metrics spiking, investigate. Is it a bad plugin? A traffic spike? A database query? Fix the root cause, not just the symptom.
How to monitor your VPS
Install sysstat on your VPS:
sudo apt install sysstat
Then use sar to check CPU usage:
sar -u 1 5
This shows CPU usage over 5 seconds. If you see high %user or %system time, your application is consuming too much CPU. If you see high %iowait, your disk is slow. Check your storage type. If you are on shared storage, consider moving to SSD or NVMe.
What to check first
When your site crashes, do not panic. Do not restart the server immediately. Restarting hides the problem and makes it harder to diagnose. Instead, check these things in order:
- Check the Error Logs: Look at your web server error log (
/var/log/apache2/error.logor/var/log/nginx/error.log). Look for PHP errors, memory limits, or database connection errors. - Check PHP Memory: Run
phpinfo.phpand checkmemory_limit. If it is low, increase it. - Check Database Connections: Use
mysqladmin statusto see the number of active connections. If it is near the limit, increasemax_connections. - Check Caching: Ensure your caching plugin is not serving stale or incorrect content. Purge the cache and test.
- Check Resource Usage: Use
htopor a monitoring tool to see if CPU or RAM is maxed out. If so, investigate the cause.
FAQ
How much PHP memory does WordPress need?
A baseline of 256 MB is safe for most sites. High-traffic sites or those with heavy plugins may need 512 MB or more. Do not set it to unlimited.
Is object caching necessary for small sites?
For small sites with low traffic, page caching may be enough. But if you have dynamic content or more than a few hundred daily visitors, object caching is recommended to reduce database load.
Can I fix these issues on shared hosting?
You can increase PHP memory and adjust caching rules on shared hosting. But you cannot change database connection limits or server-side resource allocation. If you hit these limits, you need to move to a VPS or dedicated server.
How do I know if my caching plugin is misconfigured?
If you see stale content, locked-out users, or conflicts with other plugins, your caching plugin is likely misconfigured. Audit your exclusion rules and test with all plugins disabled.
What is the "noisy neighbor" effect?
It is when another site on shared hosting consumes excessive resources, slowing down your site. You have no control over it. If your site is critical, move to isolated resources like a VPS.
Choosing WordPress hosting is not just about picking a provider. It is about configuring the environment correctly. These five errors are avoidable. Check your PHP memory, enable object caching, adjust your database connection pool, audit your caching rules, and monitor your server resources. Do this, and your site will stay up under pressure. Stop guessing. Start measuring.