WordPress keeps crashing for one of eight reasons, and the first three account for most cases: a plugin or theme conflict after an update, PHP running out of memory (the default WordPress limit is only 40 MB), or a hosting plan that cannot handle the traffic or the plugins you have piled onto it. The other five are a corrupted core file, a database problem, an expired SSL certificate, a hack, or a PHP version the theme cannot run on. A site that crashes once has a bug; a site that keeps crashing has a cause nobody has found, and the table below is how you find it in the order that takes least time.
What does “crashing” look like, and what does each screen mean?
| What you see | Usual cause | First move |
|---|---|---|
| “There has been a critical error on this website” | A plugin or theme threw a PHP fatal error | Check the email WordPress sent you; it names the plugin and includes a recovery-mode link |
| White screen, nothing at all | Memory exhausted, or a fatal error with display turned off | Raise the memory limit; turn on WP_DEBUG to see the error |
| Errors naming a file in wp-admin or wp-includes, or a failed update | Corrupted or half-updated core file | Re-upload the wp-admin and wp-includes folders from a fresh WordPress download over SFTP; leave wp-content and wp-config.php alone |
| “Error establishing a database connection” | Database server down, wrong credentials, or the database is full | Check wp-config.php credentials; ask the host whether MySQL is up |
| “Briefly unavailable for scheduled maintenance” | An update was interrupted and left a .maintenance file | Delete .maintenance in the site root over SFTP |
| 503 or “resource limit reached” | Host CPU, memory or entry-process limit hit | Host dashboard shows which; usually a plugin or bot traffic |
| Site loads, then dies at busy times | Traffic beyond the plan, no caching | Add caching; move plan or host |
| Browser warning, “connection not private” | SSL certificate expired | Renew or re-issue in the host panel |
| Redirects to strange sites, spam pages | Hack, not a crash | How to tell if WordPress has been hacked |
Why do plugin and theme conflicts crash WordPress?
Because every plugin runs on every page load, and two plugins that both try to change the same thing, or one plugin written for a PHP version you no longer run, produce a fatal error that stops the page. Since WordPress 5.2 the fatal error handler catches most of these, shows the “critical error” notice, and emails the site administrator a link to recovery mode: a special login where the failing plugin is paused so you can deactivate it. Check that email address is one you read; on many sites it is the developer’s from years ago.
To find the culprit without the email: over SFTP, rename wp-content/plugins to plugins-off. If the site returns, rename it back and rename plugins one at a time until it breaks again. For a theme, rename its folder and WordPress falls back to a default theme. Then update or replace the one that failed, and delete anything you have not used in a year, because inactive plugins still sit on the server, still need updating and can still be exploited.
How do you fix WordPress memory errors?
WordPress limits itself to 40 MB of PHP memory by default (64 MB on multisite), which a page builder plus a few heavy plugins exceed easily. The WordPress common errors documentation gives the fix: add this line to wp-config.php above the “That’s all, stop editing” comment:
define( 'WP_MEMORY_LIMIT', '256M' );The host’s own PHP memory limit has to allow it; on shared hosting the panel usually has a PHP setting for memory_limit, and if it is capped below 128 MB that is a sign the plan is too small for the site. Raising the number does not fix a plugin that leaks memory; it buys time to find it. Site Health, under Tools, shows the current limit and the PHP version.
When is the host the problem?
When the crashes line up with traffic or with time of day rather than with a change you made. Shared hosting plans cap CPU seconds, memory and simultaneous processes; a burst of bot traffic or an uncached page hit by a newsletter send will trip the limit and the host returns a 503 until the load drops. Three checks: the host dashboard’s resource usage graph, whether a caching plugin (or the host’s own cache) is on, and the PHP version, which should be 8.2 or newer (WordPress itself now recommends 8.3). Sites still on PHP 7.4 crash on updated plugins that require 8.x. If the graph is flat and the site still falls over, the host is the problem, and moving is cheaper than debugging.
Could it be the database?
Yes, in two ways. A database that has been through years of plugin installs carries orphaned tables, thousands of post revisions and transient options that slow every query; WP-Optimize or the host’s tools can clean it. A corrupted table produces the “error establishing a database connection” screen; adding define( 'WP_ALLOW_REPAIR', true ); to wp-config.php and visiting /wp-admin/maint/repair.php runs WordPress’s own repair, then remove the line. If the database is simply full, the host panel shows the quota; most plans allow far more than a business site uses, so a full database usually means a logging plugin has run wild.
What stops WordPress crashing again?
- Update on a schedule, not on impulse. Once a week, with a backup first; where your backups are stored tells you whether you have one to fall back on.
- Test big updates on staging. Most hosts offer a one-click staging copy; a page builder update is exactly what it is for.
- Cut the plugin count. Twenty is a lot; thirty is a problem. The essential WordPress plugins covers what a business site actually needs.
- Turn on caching and a CDN, so traffic spikes hit the cache rather than PHP.
- Set the admin email to someone who reads it, so recovery-mode links and update notices reach a person.
- Keep PHP current and check Site Health monthly for the warnings it lists.
A crash is loud, but the causes are quiet and cumulative: one more plugin, one skipped update, one plan that was fine two years ago. Fixing the list above is a couple of hours; it is the maintenance half of every WordPress site I look after, and it is the reason those sites do not appear in this post.
Frequently asked questions
Usually a plugin or theme conflict after an update, PHP memory running out (WordPress defaults to 40 MB), or a hosting plan that cannot handle the traffic. Less often: a corrupted core file, a database fault, an expired SSL certificate, a hack, or an outdated PHP version.
Open the email WordPress sent to the admin address; it names the failing plugin and gives a recovery-mode link. Deactivate that plugin, then update or replace it. Without the email, rename the plugins folder over SFTP to confirm a plugin is the cause.
Add define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); to wp-config.php above the “stop editing” line. Your host’s PHP memory_limit must allow it; check Site Health under Tools to confirm the new value.
The update introduced code that conflicts with another plugin, the theme or your PHP version. Restore the pre-update backup, then apply updates one at a time, ideally on a staging copy first.
Yes. Every active plugin runs on every page load, so more plugins mean more memory, more conflicts and more chances of a fatal error. Keep the count low and delete anything inactive.
Usually not. A white screen is normally a fatal error or exhausted memory with error display turned off. Hacks tend to show as redirects, spam pages or unknown admin users rather than a blank page.
