The site loads a blank white page, a database connection error, or refuses connections entirely. Or visitors report errors while the admin appears to work. Or everything went down without any warning. WordPress site down situations are the highest-urgency WordPress problem because every minute the site is unreachable costs traffic, revenue, and credibility. This guide provides a systematic diagnostic and recovery process ordered from fastest to most thorough fix. For the bigger picture, our WordPress Errors Complete Guide pulls everything together.
WordPress Site Down — Diagnose Before You Fix
The first question when a WordPress site down situation is reported: is the entire site down, or only specific pages? Is it down for everyone, or just for you? Is the admin accessible while the front-end is not? Each answer narrows the cause significantly before any fix is attempted.
Check whether the site is down globally: navigate to isitdownrightnow.com or downforeveryoneorjustme.com → enter the site’s URL. If the tools report the site is up but you cannot access it, the issue is specific to your network, browser, or DNS cache — not a WordPress or server problem. Flush the local DNS cache: Windows → ipconfig /flushdns in Command Prompt; Mac → sudo dscacheutil -flushcache in Terminal. If the site is genuinely down for everyone, continue with the server-side investigation below. Check the hosting provider’s status page — AWS, SiteGround, Kinsta, and all major hosts maintain public status pages that report active outages. If the host has a known outage, the fix is waiting for their resolution rather than any WordPress-level intervention.
Check the specific error type: a blank white page (white screen of death) is a PHP fatal error — the PHP error recovery section applies. A “Error Establishing a Database Connection” means the database is unreachable — the database section applies. A 500 Internal Server Error is a server configuration error or PHP crash — check the server error logs immediately. A 503 Service Unavailable means the server is overloaded or in maintenance mode. A 521 or 522 error (Cloudflare error codes) means the origin server is down but Cloudflare is still responding. Each error type has a completely different root cause and fix — attempting generic troubleshooting without reading the specific error message is the most common reason WordPress site down recovery takes longer than necessary. Our guide on fixing WordPress fatal errors covers the PHP-level recovery procedure that applies to blank white screen down scenarios in detail.
Checking Server Resources and PHP Errors
The majority of unexpected WordPress site down events on shared hosting are caused by resource exhaustion — PHP memory limit exceeded, disk quota full, MySQL connection limit reached, or CPU throttling from the host. These resource-triggered outages often resolve themselves briefly but recur until the underlying cause is addressed.
Access the server error log: via cPanel → Logs → Error Log; via hosting file manager at /var/log/apache2/error.log or /var/log/nginx/error.log; or via the WordPress debug log at /wp-content/debug.log if WP_DEBUG_LOG is enabled. The error log entry time should match the time the site went down — the error message at that timestamp identifies the cause. Common error messages and their causes: “PHP Fatal error: Allowed memory size of X bytes exhausted” → PHP memory limit hit, increase via wp-config.php. “Can’t connect to MySQL server” → database server unreachable or MySQL service crashed. “Too many connections” → the hosting plan’s MySQL connection limit is exceeded by concurrent requests. “File not found: /path/to/file.php” → a plugin or theme file is missing, deleted, or at an incorrect path after a migration. Each error message points to a specific fix that resolves the WordPress site down situation.
Check disk space immediately when a WordPress site down event has no obvious error message: a server with 0 bytes of free disk space cannot write PHP session files, temporary files, or log entries, causing seemingly random failures across the site. cPanel → Files → Disk Usage shows total usage. If the disk is full, the priority actions are: delete old backup files from the server (use the hosting file manager to identify and remove the largest files), clear the WordPress uploads folder of unnecessary media (large video files are the most common disk-space offenders), and clear log files that have grown excessively large. Our guide on fixing WordPress disk space full covers the full disk cleanup and management process relevant when disk exhaustion is the cause of the site outage.
Database Connection Failures
“Error Establishing a Database Connection” causes WordPress site down error messages and has several distinct causes despite showing the same error message for all of them. Working through the causes in order resolves it quickly.
Verify database credentials — the first fix for database-caused WordPress site down: connect via FTP → open wp-config.php → check DB_HOST, DB_NAME, DB_USER, and DB_PASSWORD. These credentials must exactly match the database settings in the hosting control panel (cPanel → MySQL Databases → your database and user). A recent password change, a hosting migration, or an accidental edit to wp-config.php can leave credentials mismatched. Copy the exact credential values from the hosting control panel and paste them into wp-config.php — even a single character difference causes “Error Establishing a Database Connection.”
If credentials are correct, MySQL itself is the cause of WordPress site down. On shared hosting, contact support — you cannot restart MySQL on a shared server. On VPS or dedicated servers: SSH in → run service mysql status → if stopped, run service mysql start. If MySQL crashes on start, check the MySQL error log at /var/log/mysql/error.log for the crash reason. A corrupted InnoDB table often causes MySQL to fail to start — the recovery procedure involves setting innodb_force_recovery=1 in /etc/mysql/mysql.conf.d/mysqld.cnf, starting MySQL with forced recovery mode, exporting the database, and restoring to a clean MySQL instance. This InnoDB recovery is a hosting provider support escalation on managed hosting — provide the MySQL error log to support and request emergency database recovery assistance. For self-managed servers, the MySQL documentation covers the full InnoDB recovery procedure step by step. According to MySQL’s official documentation, innodb_force_recovery mode 1 through 6 provides progressively more aggressive corruption recovery, with 1 being the mildest and safest starting point before escalating if MySQL still fails to start.
Plugin and Theme Recovery Without Admin Access
When a WordPress site down event is caused by a plugin or theme update that introduced a fatal error — leaving the site completely inaccessible including the admin — recovery requires filesystem access rather than the WordPress admin interface.
Deactivate all plugins via FTP: connect to the server → navigate to /wp-content/plugins/ → rename the folder from “plugins” to “plugins_disabled”. WordPress deactivates all plugins when their folder is renamed. Reload the site — if it comes back up, a plugin caused the outage. Rename the folder back to “plugins” → log into the admin → reactivate plugins one at a time to identify the specific culprit. To deactivate a single plugin without FTP access when you suspect the specific offender: via phpMyAdmin → wp_options → find the “active_plugins” row → edit its value → remove the suspect plugin’s entry from the serialized array → save. The plugin is immediately deactivated without FTP.
Switch to a default theme when a theme update caused the WordPress site down event: via FTP → /wp-content/themes/ → rename the active theme folder (e.g., “astra” → “astra_disabled”). WordPress falls back to the most recently installed default theme. If no default theme is installed, install Twenty Twenty-Four via the admin (once accessible) or upload it via FTP. After the site comes back up on the default theme, the broken theme can be investigated, rolled back to a previous version using WP Rollback, or replaced. Reviews from the WordPress support community confirm that plugin-caused PHP fatal errors and database connection failures together explain the majority of WordPress site down events on shared hosting, and that FTP-based plugin deactivation and credential verification resolve most cases within 15 minutes of the outage beginning.
Restoring From Backup After a WordPress Site Down Event
When targeted fixes do not resolve a WordPress site down situation — the site was hacked, the database is too corrupted to recover, or multiple systems failed simultaneously — restoring from a recent backup is the fastest path to a functioning site.
Restore from UpdraftPlus backup: UpdraftPlus → Settings → Restore → select the most recent backup set before the outage began → choose which components to restore (database, plugins, themes, uploads) → Restore Now. UpdraftPlus handles the full restoration including database import, file extraction, and table prefix correction. After restoration, the site should be fully functional at the pre-outage state. If the outage was caused by a hack or malware injection, restore to a backup from before the compromise (which may be earlier than the most recent backup) and immediately change all passwords — WordPress admin, FTP, database, hosting control panel — before bringing the restored site online.
Prevent future WordPress site down events through proactive monitoring: UptimeRobot (free) and Pingdom check the site every minute and send immediate email, SMS, or Slack alerts when the site becomes unreachable. The alert arrives within 60 seconds of the outage beginning — allowing response before most visitors notice. Combine monitoring with automatic daily backups stored off-site, a staging environment for testing updates before production deployment, and a maintenance mode plugin (WP Maintenance Mode) that shows a branded “under maintenance” page to visitors while emergency repairs are underway — eliminating the raw error page that visitors and search engines see during an unplanned outage. Proactive monitoring converts a WordPress site down event from a surprise discovered hours later to a known issue being actively addressed within minutes.
Hacked WordPress sites present as a WordPress site down event when the attacker redirects the site to malware, defaces the homepage, or installs a payload that crashes PHP. The signs of a hack versus a technical failure: the site loads content but the content is wrong (redirects to gambling/pharmaceutical spam, homepage defaced), Google Safe Browsing flags the site, the hosting provider suspended the account citing malware, or the WordPress admin is inaccessible but FTP shows files that were not uploaded by the site owner. For a hacked site, restoration from a pre-hack backup is faster and safer than attempting to manually clean malware — malware that is partially cleaned continues to cause problems and often persists in unexpected locations. After restoration, change all credentials (WordPress admin, FTP, database, hosting cPanel) immediately, update all plugins and themes to patch the vulnerability that was exploited, and install a security plugin (Wordfence, Sucuri) to monitor for re-infection. Report the malware removal to Google via Google Search Console → Security issues → Request review, so Safe Browsing warnings are cleared after the site is confirmed clean.
CDN-caused WordPress site down events occur when Cloudflare or another CDN provider has an outage, when CDN configuration was changed incorrectly, or when the origin server’s IP changed and the CDN still points to the old IP. If the Cloudflare dashboard shows an active incident, the fix is waiting for Cloudflare’s resolution. If Cloudflare shows no incident but the site is down, toggle Cloudflare’s proxy off (change the DNS record from orange cloud to grey cloud in Cloudflare DNS settings) — this bypasses Cloudflare and serves the site directly from the origin server. If the site comes back up after disabling the Cloudflare proxy, the issue is a Cloudflare configuration problem rather than an origin server problem. Review recent Cloudflare firewall rule or SSL mode changes that may have inadvertently blocked all traffic to the origin. Re-enable the proxy after identifying and fixing the configuration issue that was causing the CDN to block or misroute traffic to the site.
SSL certificate expiry causes a specific WordPress site down variant where the site is technically running but browsers block access with a “Your connection is not private” error — effectively taking the site offline for visitors who do not override the security warning. Most hosting providers automatically renew Let’s Encrypt SSL certificates every 90 days, but the auto-renewal can fail if the domain’s DNS was changed, if file-based verification cannot access /.well-known/acme-challenge/, or if the hosting account has a billing issue. Check the SSL certificate expiry in the browser by clicking the padlock icon → Certificate → Validity period. If it is expired or expiring within 24 hours, trigger a manual renewal: cPanel → SSL/TLS → Let’s Encrypt → Renew. After renewal, the HTTPS connection is immediately restored and the site is accessible again. Setting a calendar reminder to check certificate expiry 30 days before renewal prevents this avoidable WordPress site down scenario from recurring. You might also run into WordPress Translation.
