It is the call every agency owner and freelance developer dreads. The phone rings, or an urgent Slack notification pops up, and a panicked client delivers the news: their website is completely inaccessible. When a client's WordPress site cr
By InstaRenewal Admin
Article image
Top 5 Reasons Your Client's WordPress Site Just Crashed (And How to Fix It Fast)
It is the call every agency owner and freelance developer dreads. The phone rings, or an urgent Slack notification pops up, and a panicked client delivers the news: their website is completely inaccessible. When a client's WordPress site crashes, the clock instantly starts ticking. Revenue is potentially being lost, search rankings are at risk, and your agency's reputation is suddenly on the line.
In these high-pressure moments, your first question is inevitably: why did the website go down?
It's tempting to assume the worst — a catastrophic server failure or a sophisticated hack. But the reality is usually more mundane. WordPress still powers roughly 43% of all websites on the internet, and that scale comes with a tradeoff: a huge, interconnected ecosystem of third-party themes, plugins, and hosting environments, each one a potential point of failure.
To run an effective emergency repair, you need to move past guesswork and work through a systematic diagnostic process. This guide breaks down the five most common causes of sudden WordPress outages, with exact steps to get a client back online — plus a look at why operational oversights, like lapsed licenses and expired certificates, are an increasingly common (and entirely preventable) cause of downtime.
- The Incompatible Plugin Update (The "White Screen of Death") Plugin and theme conflicts remain the single most common cause of a sudden WordPress crash. This usually shows up as the infamous White Screen of Death (WSOD) or a generic 500 Internal Server Error — a blank screen with zero information, caused by a fatal PHP error that halts execution before WordPress can finish loading.
It often happens overnight, when an automatic plugin update runs and turns out to be incompatible with another plugin, the active theme, or the site's PHP version. WordPress's own core team has built in some protection here: since recent core releases, a rollback feature will automatically restore the previous version of a plugin if an update itself fails outright. That safety net doesn't help, though, if an already-installed plugin conflicts with something else without any update triggering it — which is still the majority of real-world cases.
How to Fix It Fast: The SFTP Isolation Method
If you can't reach wp-admin, bypass the browser and go straight to the server.
Access the server. Log in via SFTP/SSH, or use the File Manager in the hosting control panel.
Locate the plugins folder. Navigate to wp-content.
Force deactivation. Rename the plugins folder to something like plugins-deactivated. WordPress will treat every plugin as missing and deactivate them all.
Test the frontend. Reload the site in an incognito window. If it loads (even looking broken), you've confirmed a plugin conflict.
Isolate the culprit. Rename the folder back to plugins. Then rename each individual plugin sub-folder one at a time, reloading the site after each change, until the site comes back. The last one you renamed is the offender.
Get exact error detail — safely. Don't display raw PHP errors on a live production site; that exposes file paths and server details to anyone visiting during your debugging window. Instead, in wp-config.php, set:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
This writes the exact fatal error to wp-content/debug.log without printing it on-screen for visitors. Pull the log via SFTP, find the culprit file and line number, then turn WP_DEBUG back off once you're done.
- Exhausted PHP Memory Limits (or Sudden Traffic Spikes) Every hosting environment allocates a fixed amount of memory for PHP to execute scripts and database queries. When a heavy plugin, an inefficient query, or a sudden traffic spike demands more than the server allows, the process gets killed. You'll typically see a 500 error or a timeout, and in the logs, the phrase Allowed memory size exhausted.
How to Fix It Fast: Increase the Memory Limit
Open wp-config.php via SFTP.
Just before the line /* That's all, stop editing! Happy blogging. */, add:
define( 'WP_MEMORY_LIMIT', '256M' );
Save and reload. If the host's server-level PHP memory_limit in php.ini is set lower than this value, you'll need to raise it there too (or ask the host to) — the wp-config.php constant can't exceed what the server itself allows.
Agency note: bumping the memory ceiling is a bandage, not a cure. If a site keeps hitting it, audit for bloated plugins, unoptimized database queries, or outdated caching — or move the client off cheap shared hosting entirely.
A 2026-specific wrinkle worth flagging to clients: WordPress 7.0, released May 20, 2026, raised the platform's minimum supported PHP version to 7.4 (dropping 7.2 and 7.3 entirely) and its minimum database version to MySQL 8.0. If a client's site is still on an older PHP or MySQL version, it won't be offered the core update at all — and any plugin built assuming the new baseline can throw fatal errors on incompatible hosting. Checking a client's PHP version is now a five-minute task worth doing proactively rather than after a crash. The currently recommended production target is PHP 8.3 or 8.4.
- The Expired SSL Certificate (The "Not Secure" Lockdown) Not every "crash" is broken code — sometimes the site is fine, but the browser refuses to load it. If a client's SSL certificate expires, Chrome and Safari intercept the connection and show a large "Not Secure" or "Not Private" warning. To the average visitor, that reads as "this site is hacked or broken," even though nothing on the server actually failed. An expired certificate will also silently break anything relying on a secure endpoint — Stripe or PayPal checkouts, CRM webhooks, API integrations.
Most sites today run on free, auto-renewing Let's Encrypt certificates, which are valid for 90 days and are supposed to renew automatically well before expiry. When a certificate does lapse, it's almost never because someone forgot to pay for it — it's because the automated renewal process (a cron job or ACME client) silently failed, and nobody was watching for it.
How to Fix It Fast: Certificate Re-issuance
Verify the error. Open the browser console (F12). "Mixed Content" errors or outright connection refusals citing the certificate confirm an SSL issue.
Access the host or DNS manager (e.g., the hosting control panel or Cloudflare).
Force a re-issue. Most hosts offer free Let's Encrypt certificates — trigger a manual renewal or re-issue from the SSL/TLS settings.
Check DNS. A misconfigured A-record or CNAME will prevent the certificate from validating, even if you trigger a manual renewal.
The real problem: SSL lapses are almost entirely preventable — they're an operational monitoring failure, not a technical one.
- Lapsed Premium Theme/Plugin Licenses This one catches even experienced agencies off guard. Modern WordPress relies heavily on subscription-based premium plugins and page builders — Elementor Pro, WP Rocket, Gravity Forms, Advanced Custom Fields Pro, and similar. If the card tied to a license expires, the plugin loses access to security patches and update checks. As WordPress core keeps evolving, the frozen, outdated plugin eventually becomes incompatible and throws a fatal error that takes the whole site down. In some cases, license-gated plugins will actively degrade or lock features if they can't verify against the vendor's license server.
There's also a more specific, real example of this risk worth knowing: in October 2024, WordPress.org took the unusual step of forking Advanced Custom Fields into a separate free plugin, Secure Custom Fields, amid a dispute with ACF's parent company. Agencies running client sites on ACF Pro have had to actively track which fork and license each site is running — a clear case of "license identity," not just license expiry, becoming a real operational risk.
Security stakes are real here too: the average WordPress site is currently targeted roughly once every half hour, according to Wordfence's own published figures, and the large majority of publicly disclosed WordPress vulnerabilities trace back to plugins and themes rather than WordPress core itself. A frozen, unpatched premium plugin because of a billing lapse is exactly the kind of gap automated bots are built to find.
How to Fix It Fast (and Prevent It Forever)
Immediate remediation. If a lapsed plugin is throwing a fatal error, manually disable it via SFTP (Section 1's method) to regain dashboard access.
Resolve the billing. Log into the vendor's site, update the payment method, download the current .zip, and upload it manually to override the broken version.
The agency prevention step: tracking who pays for a license is just as operationally important as tracking the code itself. Manually maintained spreadsheets tend to go stale. Dedicated renewal-tracking tools built for this exact problem exist now — InstaRenewal, for example, is built specifically to let agencies log domains, SSL certificates, hosting, and plugin licenses against each client, with ownership, payment responsibility, and renewal-risk flags in one place, so a failed card doesn't surface for the first time as a production outage.
- Corrupted Database or wp-config.php Errors The files that make up WordPress control how a site looks and behaves; the database holds the actual content — posts, pages, users, plugin settings. If the files can't talk to the database, everything stops. You'll see a plain white screen with the message: "Error Establishing a Database Connection."
This typically has one of three causes:
Incorrect database credentials in wp-config.php
The database server itself is down or overwhelmed
Corrupted database tables
How to Fix It Fast: Rebuilding the Connection
Verify credentials. Open wp-config.php via SFTP and cross-check these four values against the client's hosting control panel:
DB_NAME
DB_USER
DB_PASSWORD
DB_HOST (usually localhost, but can be a specific server IP)
Repair the database. If credentials check out but the error persists, the tables may be corrupted. Add this to wp-config.php:
define( 'WP_ALLOW_REPAIR', true );
Run the repair tool. Visit yourclientsite.com/wp-admin/maint/repair.php and click "Repair Database." Once done, immediately remove that line from wp-config.php — leaving it in place exposes an unauthenticated repair tool to anyone who finds the URL.
One more thing to watch going forward: WordPress 7.0 also raised the platform's minimum supported database version to MySQL 8.0 (up from 5.5.5). On older, self-managed hosting stacks still running an ancient MySQL version, this is a new possible source of database-layer failures after a core update — worth checking before a site is due for its next WordPress upgrade, not after.
Quick Reference Diagnostic Matrix
Crash Symptom Primary Suspect Required Access Est. Time to Fix
Blank white screen (WSOD) Plugin conflict / fatal PHP error SFTP / File Manager 10–20 min
"Error Establishing Database Connection" Bad wp-config.php credentials or downed MySQL server SFTP + Hosting Control Panel 15–30 min
"Not Secure" browser warning Expired SSL certificate Hosting Control Panel / DNS 5–15 min
500 Internal Server Error Exhausted PHP memory / corrupted .htaccess SFTP 10–20 min
Broken layout / missing features Lapsed premium license (outdated plugin) WP-Admin / vendor billing portal 10–45 min
Conclusion: Shifting from Reactive to Proactive
Knowing how to answer "why did the website go down?" is a vital technical skill — but constantly fighting these fires is an exhausting, unprofitable way to run an agency.
Technical crashes, like a bad plugin update, will always happen occasionally. But operational crashes — an expired SSL certificate, a lapsed domain, an unrenewed premium license — are almost entirely preventable with the right tracking in place.
Standardizing your WordPress environments, staying ahead of core changes like the WordPress 7.0 PHP and MySQL requirement bumps, and using a dedicated renewal-tracking tool instead of a scattered spreadsheet turns this from a reactive fire drill into a proactive maintenance habit — so your team gets a heads-up weeks before an expiring asset becomes a client's emergency phone call.
Top comments (0)