Sooner or later, every WordPress site will experience a "crash," which we define as a site issue or downtime. But what should you do in such cases, and how can you recover a WordPress site after a crash?
Identifying the Problem
The site might have an issue with an update or a recently installed plugin or theme. Such problems should make you consider whether it’s still a good idea to use that theme or plugin if it leads to such a catastrophic failure.
The way to check if the issue is related to an execution error or script is often by enabling the debug mode on the WordPress site. By default, debug mode is off because you probably don’t want everyone to see where the site has crashed:
define( ‘WP_DEBUG’, true ); // enable debug mode – show errors
define( ‘WP_DEBUG’, false ); // disable debug mode – hide errors
You can find this setting in the wp-config.php file in your site’s root directory, and by changing this line, errors will be displayed. Based on the error messages, you can determine where the problem lies.
Some errors that are not related to the code will be shown by WordPress itself, such as database unavailability.
Solving Problems with WordPress Debug Output
If the debug output indicates where the problem lies, you should remove that component. If you cannot figure out the problem, temporarily move the variable parts of the site—themes and plugins. Move them to a folder outside the themes and plugins folders in WordPress, and if the site starts working again, try restoring them one by one to identify the culprit.
In some cases of site hacking, some WordPress files may have been altered. This usually doesn’t happen because such changes will be overwritten by the next update, but it is still possible. Simply unpack a fresh WordPress installation and overwrite the existing files. While this won’t cause you to lose the wp-config.php file, which contains settings like database connection details, we still recommend backing up this file.
If you receive a message saying that a folder or file is not writable, you likely have incorrect file permissions. For panels like cPanel, this is usually resolved by running the web server under the file owner, which allows access to them. If you don’t have a control panel, the owner should typically be www-data, httpd, or another user depending on your Linux distribution.
Resolving Database Issues
The database may become corrupted after a machine crash or power failure. It can also happen that the database content is altered in a way that WordPress cannot use it—such as if someone manually modified the site settings directly in the database.
Additionally, the entire service could be unavailable, which can be dangerous for the data if the database crashed or was killed due to an OOM (Out of Memory) error. In this case, simply restart the database and run a repair tool for any tables that may now be marked as crashed.
We recommend periodically creating backups of both your website and database to avoid potential issues with content, which could lead to the site becoming unavailable.
Resolving Issues with Services
A third issue could be related to services—such as when the web server fails to start or PHP-FPM doesn’t start if you’re using FastCGI, for example.
In cases of very high traffic or attacks, and sometimes even search engine bots, your site may become overloaded. If the site is demanding and page generation normally takes a long time, such a load can lead to the complete unavailability of the entire site. Among other things, it’s very important to have a fast website, especially if it’s a WordPress site with many plugins and a custom theme. If the PHP-FPM process has crashed, simply restart it. If the site is overloaded, you may need to either optimize the site or increase the resources.
Other Issues
A misconfigured Linux firewall can be the cause of closed ports 80 or 443, which would prevent the site from responding.
Another problem may occur if the site is using HTTPS but isn’t properly configured as HTTPS. In this case, you’ll need to configure it. If you get a warning about the certificate, it’s likely expired or incorrect. The site will still work, but the warning at the beginning is something you wouldn’t want users to see. If you’re using Let’s Encrypt, ensure that automatic renewal is correctly set up in cron.
Sometimes, a redirection issue may occur. For example, if the site is on HTTP and you have a redirection to HTTPS, a user who visits the HTTPS site will be redirected by WordPress to HTTP, which will then redirect back to HTTPS in an endless loop. Fortunately, browser engineers have ways to detect this and, after a certain number of redirections, display a warning.
