Blog

A WordPress site is several layers stacked together: core, the theme, plugins, PHP, the web server, the database, and one or more caches. When something breaks, you usually see one of a few generic screens, no matter which layer actually failed. “There has been a critical error on this website” can mean a plugin crashed, the theme doesn’t work with your PHP version, or memory ran out.

So the most common mistake isn’t a wrong fix. It’s treating the symptom as the diagnosis: assuming every 500 is a plugin conflict, every spinner is a caching problem, and a cleared cache means the problem is gone. This guide gives you the order of checks first, then the fix for each common symptom. If your site won’t load at all, our guide to why WordPress is not loading matches the exact message to its cause.

What should you do before you touch anything?

Write down the evidence, make a backup, then change one thing at a time. WordPress’s own handbook, WooCommerce’s docs and most hosts recommend the same order, because guessing destroys the clues you need.

1. Record the exact message and when it appears. Note whether it shows on every page or one page, whether it shows logged in or logged out, and what changed just before it started. A plugin update, a PHP upgrade or a pasted snippet is usually the answer.
2. Check the admin inbox. Since WordPress 5.2, Recovery Mode can email the site admin a link when a fatal error happens. The email names the plugin or theme that failed and lets you log in with it paused.
3. Read the logs. Your hosting panel has a server error log, and often a separate PHP error log. Each can show a different problem. If WordPress debug logging is on, there is also wp-content/debug.log.
4. Back up files and the database together. Do this even if the site is half broken. A backup of the broken state still lets you undo your own mistakes.
5. Change one variable, then retest the action that failed. If you change three things and the site comes back, you still don’t know which change fixed it.

If no log exists yet, turn on WordPress debug logging in wp-config.php. Keep on-screen display off on a live site so visitors never see file paths:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Load the broken page again, then open debug.log. Look at the file path, not the wording. A path inside wp-content/plugins/some-plugin/ names your suspect. When you’re done, set WP_DEBUG back to false.

Which WordPress issues come up most, and how do you fix each one?

No public dataset ranks WordPress failures by how often they happen. The order below reflects how often each pattern comes up in WordPress.org support threads, WooCommerce documentation and hosting guidance. Plugin, theme and update conflicts top that list by a wide margin.

A critical error or white screen right after an update

This is usually a PHP fatal error in a plugin or theme. WordPress’s common-errors handbook lists plugin conflicts, an incompatible theme or PHP version, exhausted memory and corrupted files as the usual causes.

Start with the Recovery Mode link if you got one, and deactivate the component it names. If you can’t reach wp-admin, connect by SFTP or the host’s file manager and rename only the suspect plugin’s folder in wp-content/plugins, for example to some-plugin-off. If the theme is the suspect, switch to a default theme. Our walkthrough on reading a WordPress fatal error covers each route in detail.

Once you know which plugin broke, decide what to do about the version. If the update caused the crash, roll back to the previous release with a tool such as WP Rollback, which reverts WordPress.org plugins and themes to an earlier version. Report the bug to the developer too. A rollback is a workaround. The faulty release is still a problem until the developer ships a patched one.

A 500 Internal Server Error

A 500 has more possible causes than any other message on this list: .htaccess, a plugin or theme, PHP limits, file permissions, the database, corrupted core files or the server itself. Read the host’s error log first, because it often names the file and line.

If the log suggests .htaccess, or says nothing useful, download a copy of the file, rename it to .htaccess-old and reload the site. If the site works again, go to Settings → Permalinks and click Save Changes to generate a clean file. Then add back any custom redirect or security rules one at a time from your copy. If the 500 doesn’t go away, the file wasn’t the cause, so put it back and continue with plugins, the theme and memory. Our server error 500 guide walks through the rest.

“Allowed memory size exhausted”

Match the fix to the log line. Raising WP_MEMORY_LIMIT in wp-config.php only asks for more memory. If the server sets a lower memory_limit, the server’s limit applies, and only your host can raise it. And if one plugin keeps using more memory after an update, extra memory just delays the next crash. Roll back that plugin or replace it.

“Error establishing a database connection”

WordPress’s handbook names three causes: wrong credentials in wp-config.php, problems with your web host such as a database server that is down or over quota, and, if neither explains it, a compromised site. Check the host’s status page first. If the database server is down, wait. Editing files while the host recovers only adds risk.

If the host is fine, compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST with the database details in your hosting panel. A recent password change on the hosting account often explains the error.

Your changes don’t show, or the error won’t go away

Caches confuse diagnosis in both directions. They can show an old page after you edit it, and they can keep showing an error after it’s fixed. On one WordPress.org thread, WP Super Cache kept serving the “Error establishing a database connection” screen to logged-out visitors after a brief server problem. Logged-in users never saw it, and only clearing the cache fixed it.

Check every layer: the browser, the cache plugin, the host’s server cache and any CDN. Then test in a private window while logged out. If the problem is still there after every layer is purged, the cache isn’t the cause, so troubleshoot the site itself. Our guide on a WordPress page not updating covers the save failures that look like caching.

Posts and pages return 404 but exist in the admin

The rewrite rules are broken. The content is still there. Go to Settings → Permalinks and click Save Changes without changing the structure. WordPress’s documentation explains that if .htaccess isn’t writable, WordPress shows you the rules to add yourself. In that case the save didn’t fix anything, even though the button worked.

If saving doesn’t help, ask your host whether mod_rewrite is enabled on Apache. Also check for a page that shares its slug with a custom post type. Don’t change the permalink structure to fix a 404. Those URLs are meant to be permanent, and changing them breaks every existing link and search result.

WooCommerce checkout spins forever

WooCommerce’s spinner documentation explains that the browser is usually waiting for a request, rejecting its response, or failing to finish the JavaScript that updates checkout. Open your browser’s DevTools, go to the Network tab, filter by Fetch/XHR and place a test order. Note the status code, how long the request took and the response. Then open WooCommerce’s logs at the same timestamp.

Three warnings from those docs matter more than any fix. Check Orders before anyone retries Place order, because the first attempt may have gone through. Don’t switch from the Checkout block to classic checkout as a first step. It can hide the real problem, and extensions support the two differently. And remember that a staging copy can still send real emails and fire webhooks.

Should you deactivate every plugin at once?

Only when the site is already down, or when the test is invisible to visitors. Turning off every plugin is quick, but on a working store it also takes down checkout, forms and logins while you test.

WooCommerce’s conflict test is the careful version. Switch to a default theme, deactivate everything except WooCommerce and the extension that misbehaves, then reactivate plugins one at a time, repeating the steps that triggered the problem after each one. Two plugins can each work fine alone and fail together, so test suspect pairs both ways.

On a live site, run the test on a staging copy, or use the Troubleshooting mode in WordPress.org’s Health Check & Troubleshooting plugin. That mode disables plugins and switches the theme for your logged-in session only. It can’t disable must-use plugins, and it can’t reproduce a problem that only logged-out visitors see. Its directory listing also now warns that it hasn’t been tested with the latest three major WordPress releases. Test it on staging before you rely on it on a live site.

When should you stop and get help?

Stop when the evidence points to something you can’t change safely. Most failed self-fixes happen because the person kept going past one of these points:

• The log names custom code or a theme file you didn’t write. Editing it on a live site can turn a broken page into a broken site.
• A store is losing orders. The cost of each hour is now higher than the cost of help, and a wrong step can create duplicate orders.
• You see signs of a hack: redirects you didn’t add, browser malware warnings, or a database error your credentials and host don’t explain. Cleanup means closing the way in, not just deleting files. Our guide to WordPress security issues explains how to tell the difference.
• The fault is below WordPress. PHP versions, server limits and database outages belong to the host. Plugin, theme and custom-code faults usually go back to whoever maintains that code.

Whoever takes it on, send them the exact error, what you were doing when it appeared, what changed recently, the relevant log lines, the affected URL, and what you expected compared with what happened. If you’d rather describe the problem in chat and have it handled, SiteSelf’s WordPress bug-fix work reads the error, makes the fix on your live site (code-level fixes need hosting access), and reports what changed and what it checked.

Frequently asked questions

I disabled all my plugins and the error is still there. What next?

Switch to a default theme, then check .htaccess, then read the server error log. Look at memory, the database and the server before you go back to plugins. Also check for must-use plugins in wp-content/mu-plugins, because they keep running when you deactivate everything else.

Should I restore a backup instead of fixing the problem?

Usually not first. A full restore puts back every file and database row from the backup date, so you lose any orders, comments and posts created since then. If one change broke the site, undo that one change. Our guide to restoring WordPress from backup covers when a full restore is the right call.

Can I stop updating plugins so nothing breaks?

No. Skipped updates leave known security holes open, and a site that falls years behind ends up with one large, risky update instead of many small ones. Update one component at a time, with a fresh backup each time, and test login, forms and checkout after each update.

Is it safe to turn on WP_DEBUG on a live site?

Yes, as long as WP_DEBUG_DISPLAY is false, so errors go to the log file and not the screen. WordPress recommends doing your debugging on a staging or development copy where you can. Turn it off when you finish, because the log can grow large and it contains file paths.

My site is stuck on “Briefly unavailable for scheduled maintenance”. What do I do?

An update was interrupted and left a .maintenance file in the site root. Make sure no update is still running, delete the file by SFTP or the file manager, then run the update again. The interrupted update may have left a plugin half installed, so check that plugin too.

Does advice for WordPress.com apply to my self-hosted site?

Not always. WordPress.com and self-hosted WordPress from WordPress.org have different accounts, features and support channels. File access, error logs and PHP settings belong to your host on a self-hosted site, which is why most fixes in this guide mention the hosting panel.

Say your homepage is white and a customer can’t place an order, but the login screen still opens. That detail matters. It means the server answers requests and at least part of WordPress runs, so turning off every plugin would be the wrong first move.

“Not loading” covers at least eight different failures: a blank page, a critical error, a database error, a 5xx code, a stuck maintenance screen, a redirect loop, a domain that won’t resolve, and a checkout that spins forever. Each one lives in a different layer. Find the layer first and the fix is usually short.

Is the site down for everyone or just you?

Find that out before anything else. Open the site in a private window, then on your phone with Wi-Fi switched off. If it loads on mobile data, the fault is your browser, an extension, your router or your DNS resolver, not the site. Our guide to fixing DNS_PROBE_FINISHED_BAD_CONFIG errors covers that case.

If the site fails on every network, check your host’s status page before you edit anything. On Reddit’s r/webdev, one owner was sure a new forms plugin had broken their site. It turned out to be a host outage. Changing a working site to “fix” someone else’s outage is how one incident becomes two.

Clearing your browser cache only fixes your own browser. It does nothing for a server, database or DNS fault.

Which layer does your symptom point to?

Write down the exact message, the URL and the time it started. Then find it in this table.

What you see	Likely layer	First check	Who usually fixes it
Blank white page, or “There has been a critical error on this website”	PHP fatal error in a plugin, theme or custom code	Recovery Mode email, then the debug log	You or a developer
500 Internal Server Error	.htaccess, a plugin, the theme or memory	The host’s error log	You, a developer or the host
“Error establishing a database connection”	Wrong credentials, or the database server is down or full	Compare wp-config.php with your host’s values	Usually the host
“Briefly unavailable for scheduled maintenance”	An update left a .maintenance file behind	Is the update still running?	You
ERR_TOO_MANY_REDIRECTS	Two redirect rules or the SSL mode disagree	Site URLs, .htaccess, CDN SSL mode	You or whoever controls the CDN
502, 503, 504 or a timeout	Host capacity, resource limits or the database	Host status page and logs	The host first
“Site can’t be reached” or NXDOMAIN	DNS or nameservers	Domain records at the registrar	Whoever controls DNS
Store loads, but checkout spins	JavaScript, caching or CDN optimisation	Browser Console and Network tabs	You or a developer

Before you edit files, take a backup or a hosting snapshot, and include the broken state. You should know how to restore it without the WordPress dashboard.

Why a blank page usually points at a plugin or theme

A white screen or the “critical error” message almost always means PHP hit a fatal error. Practitioners most often find that a plugin, a theme or custom code caused it, usually right after an update or a PHP version change. That pattern comes from repeated reports, not from any measured failure rate.

Start with the Recovery Mode email. WordPress added Recovery Mode in version 5.2. When a fatal error happens, it can email the administrator a login link. That link pauses the faulty plugin or theme for your session only. Visitors still get the error. Use the session to find out which component the email names, then deactivate or update it.

The email doesn’t always arrive. WordPress’s documentation says Recovery Mode triggers only on fatal errors during normal page loads, not during cron or background tasks. Check spam. If nothing is there, use file access instead.

Without the dashboard, connect over SFTP or your host’s file manager. Rename the folder of the suspect plugin inside wp-content/plugins. If you can’t tell which plugin is at fault, rename the whole plugins folder. If the theme is the problem, rename the active theme’s folder and WordPress falls back to a default theme, provided one is installed.

Read the log before guessing. In wp-config.php, edit any existing debug lines rather than adding duplicates. Set them above the “stop editing” comment:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the failing page, then open wp-content/debug.log. Find the first fatal error with a matching timestamp. Its file path names the culprit. Later warnings are often side effects. WordPress’s debugging handbook covers these constants. Never show errors to visitors, and turn debugging off when you’re done, because the log can hold sensitive paths and data. Our guide to reading a WordPress fatal error goes through common messages one by one.

What a 500 error usually means

Check the host’s error log first. A 500 hides its cause from the browser, but the log usually names it. WordPress.org’s troubleshooting FAQ names a corrupted .htaccess as a likely cause. To test it, rename the file to .htaccess_old and reload the site. If the site comes back, go to Settings > Permalinks and click Save to create a clean file.

Keep the old file until you’ve compared the two. It may contain custom rules you still need, such as redirects or security directives. Security plugins sometimes leave rules behind that point to files that no longer exist, and those can cause a 500 on their own. If .htaccess wasn’t the cause, test plugins and the theme next. Our full guide to fixing a server error 500 covers the rest.

Check database credentials before you change them

“Error establishing a database connection” has two families of cause. The first is wrong values in wp-config.php: DB_NAME, DB_USER, DB_PASSWORD or DB_HOST. The second is on the host’s side: the database server is down, over its quota, or out of connections.

Compare each value with what your hosting panel shows. Don’t assume DB_HOST is localhost, because many hosts use a separate database server. If every value matches, contact the host. Guessing new credentials doesn’t fix a stopped database server, and it adds a second fault you’ll have to undo later.

Stuck on “Briefly unavailable for scheduled maintenance”

WordPress creates a .maintenance file in the site root during updates and deletes it when they finish. If an update is interrupted, the file stays and the site keeps showing the notice. First make sure no update is still running. Then delete the file (turn on “show hidden files” in your file manager to see it) and rerun the update that failed. Deleting the file only removes the notice. An interrupted update can leave a plugin half-installed, so test that plugin too. Why WordPress updating failed covers that half.

Redirect loops come from two rules that disagree

ERR_TOO_MANY_REDIRECTS is a configuration conflict, not a crash. First check that the WordPress Address and Site Address (Settings > General, or WP_HOME and WP_SITEURL in wp-config.php) both use the scheme you intend. Then look for competing redirects in .htaccess, in an SSL plugin and at your CDN.

Here’s a common version. Cloudflare is set to Flexible SSL, so it talks to your server over plain HTTP. Your server or WordPress redirects HTTP to HTTPS. Each side keeps sending the visitor back to the other. Cloudflare’s documentation recommends Full or Full (strict) mode when your server has a valid certificate, or removing the conflicting redirect.

To see the loop instead of guessing, run curl -sIL https://example.com. It prints every Location header in the chain. Adding another force-HTTPS rule makes the loop worse, and clearing cookies won’t fix a loop that starts on the server.

502, 503, 504 and timeouts belong to the host first

These codes usually mean the server ran out of capacity or a timeout cut the request off. Note the code and the time, check the host’s status page, and send the host the log lines. Let them recommend memory or execution limits. Raising limits blindly can hide the problem or make it worse. Our guide to fixing a WordPress 503 error explains why.

Moving to a bigger server can hide the cause too. On r/woocommerce, a store with about 50 plugins timed out for roughly two months. Disabling every plugin brought it back, but the timeouts returned on reactivation. Commenters warned that a dedicated server would only mask a slow plugin or query. Query Monitor, a plugin that shows which components and database queries are slow, is a better next step than a bigger plan.

When the domain doesn’t resolve at all

If the browser says the site can’t be reached, or a DNS lookup returns NXDOMAIN, the request never gets to WordPress. Check the A or CNAME records and the nameservers at your registrar or DNS provider against the values your host gives you. After a nameserver change, check that the old records were copied to the new provider. Then wait for the change to spread. Practitioners report waits of a few hours, and occasionally up to two or three days.

The store loads, but the checkout spins

On WooCommerce, start with the basics in WooCommerce’s pages-not-displaying guide. Check that the Cart, Checkout and My Account pages exist and are assigned under WooCommerce settings. Save Settings > Permalinks without changing anything. Make sure cart and checkout are excluded from every cache.

For a spinning checkout, open the browser’s Console and Network tabs and find the first request that fails. Common blockers are JavaScript errors, optimisation plugins, a content security policy, consent tools, ad blockers and CDN features such as Cloudflare’s Rocket Loader and minification. A theme that leaves out wp_head() or wp_footer() can also stop payment scripts from loading.

One warning before you test: WooCommerce’s Health Check guide says troubleshooting mode doesn’t put your payment gateway into sandbox mode. A test order can take a real payment.

A test is not a fix

Renaming .htaccess, disabling all plugins, letting Recovery Mode pause something and rolling back an update are all ways to find the cause. Each one also has a cost. With every plugin off, your forms, checkout and security plugin are off too. A rollback can bring back a vulnerability the update closed. Once you’ve found the culprit, turn everything else back on one at a time and replace or update the component that failed.

Then confirm the site actually works, not just that a page appears. Log out and load the page that failed. Submit a form. On a store, check that an order record and payment status were created, not just that the confirmation screen showed. Purge the plugin, host and CDN caches so visitors stop seeing the broken copy.

When to stop and get help

Call your host if the database server is down, if 5xx errors keep coming back, if your account is suspended, or if you can’t reach a backup. Call whoever controls DNS or your CDN when the fault is in their system. Get a developer in these situations:

• You have no file access, or you’re not comfortable editing wp-config.php.
• The error comes back as soon as you reactivate plugins.
• The log points to custom code or a PHP version mismatch.
• Checkout is broken and money is at stake.

Treat unfamiliar admin accounts, redirects to other sites or file changes nobody made as a security incident, not a loading problem.

When you hand it over, include the failing URL, the timestamps, recent changes, the log excerpt and the tests you’ve already run. Remove passwords and customer data first. If you’d rather describe the symptom in chat and have the logs read and the fix applied for you, SiteSelf’s agent does that work on your site using hosting (SSH) access and reports what it changed and checked: see getting your WordPress site working again.

Frequently asked questions

Should I disable all plugins at once or one at a time?

Do both, in that order. Disabling all of them tells you quickly whether plugins are involved at all. Reactivating them one by one tells you which plugin it is. On a live store, the Health Check & Troubleshooting plugin’s troubleshooting mode lets you run the test in your own session while visitors still see the normal site.

The front end works but I can’t get into wp-admin. Is that the same problem?

Usually not. A working front end with a broken login points to a login, cookie, security plugin or redirect issue, not a site-wide failure. Our guide to fixing WordPress login problems sorts those by symptom.

Could a plugin update have caused this?

Yes, and it’s the pattern practitioners report most often. Check the Recovery Mode email or the debug log for the plugin it names. Roll that plugin back only as a temporary measure, because the update may have fixed a security flaw.

Does updating WordPress fix a PHP version problem?

Not by itself. The PHP version is set by your host, and your plugins and theme need to support it. You can see the current version under Tools > Site Health > Info > Server. If the log shows errors about deprecated or removed functions, update the component named in the error or ask the host which PHP versions it offers.

Is a slow site the same as a site that’s not loading?

No. A site that loads slowly needs speed work: caching, fewer heavy plugins, better hosting. A site that returns an error needs repair. Mixing the two up leads to buying a bigger server for a broken plugin, or chasing errors that are really timeouts.

WordPress uses the words “updating failed” for two failures that have nothing in common. One appears in the block editor when you click Update on a post or page. The other appears on Dashboard > Updates or the Plugins screen when WordPress could not install new software. The causes are different, the fixes are different, and a fix for one can damage the other.

So start by working out which one you are looking at. Then read the full error message. “Updating failed” tells you something went wrong. The rest of the message tells you which part of the site failed.

Which “updating failed” are you looking at?

Look at where the message appeared and how it is worded. The table below covers the common versions.

Where you saw it	What it says	What failed
Block editor, after Update, Publish or Save draft	“Updating failed. The response is not a valid JSON response.” or “You are probably offline.”	The save request to the REST API
Dashboard > Updates or Plugins	“Download failed”, “Could not create directory”, “Could not copy file”, or a prompt for FTP credentials	The software update, before or while files were written
The public site	“Briefly unavailable for scheduled maintenance. Check back in a minute.”	An update that stopped partway
Admin email inbox	“An automated WordPress update has failed to complete”	A background core update that was interrupted
The site after an “Update successful” notice	A critical error, a white screen, or a checkout that does nothing	The new code ran and something conflicted with it

If it was the editor, the short version is below, and our guide to a WordPress page not updating goes through every cause. Everything after that section is about software updates.

If the editor said it, look at the failed request first

When you click Update, the block editor sends your post to the REST API and expects JSON back. “Updating failed” means it got something else: a firewall block page, a redirect, a login screen, a PHP warning, or stray output in front of the JSON. Until you see what actually came back, you are guessing.

Open your browser’s developer tools, go to the Network tab and click Update again. Then click the failed request and check three things: the status code, the Content-Type and the start of the response body.

• 403 Forbidden. A server security rule (ModSecurity, a web application firewall or a CDN) blocked the save. This is the cause people confirm most often in support threads. Ask your host to check the security log and whitelist that one rule. Don’t ask them to switch security off.
• HTML or a PHP warning in the body. A plugin, theme or snippet is printing output. Reported cases include an incomplete AIOSEO 5.0 database upgrade and a Google Ads tag pasted into a Custom HTML block.
• A redirect (301 or 302). Check that the WordPress Address and Site Address under Settings > General match, including https and www.

Reload the post in a new tab before you retype anything. Also, don’t change your permalink format to see if it helps. In one WordPress.org thread, a site owner switched to the default format, broke every link shared on social media, and later found the real cause was a ModSecurity rule. If you want to try it, re-save the existing structure without changing it.

Why plugin, theme and core updates fail

For software updates, WordPress’s own documentation and support threads keep pointing to the same few causes. The order below follows how often they come up in reports. Nobody has measured it, so treat it as a rough order. Two places help you sort them fast: Tools > Site Health, which flags problems such as the site being unable to reach WordPress.org, and your host’s error log.

“Could not create directory” or an FTP prompt usually means ownership

WordPress writes update files as the web server’s user. If that user doesn’t own wp-content/plugins or wp-content/upgrade, the write fails, or WordPress asks you for FTP details. Ownership is which server user owns a file. Permissions control what that user can do with it. Changing permissions doesn’t fix the wrong owner.

That’s why chmod 777 is the wrong fix. WordPress’s file permissions guide says to keep permissions as restricted as possible and warns about 777 specifically. On shared hosting, send the host the exact error and the folder it names, and ask them to correct ownership for that folder.

“Download failed” means the site could not fetch the package

The site either couldn’t reach WordPress.org or the vendor’s update server, or the server refused it. If Site Health says it cannot reach WordPress.org, the host needs to look at outbound connections. For paid plugins, check the licence before anything else. It may have expired, or it may be registered to an old domain or to the agency that built the site.

For WooCommerce Marketplace extensions, WooCommerce’s subscription troubleshooting page covers the usual causes: an expired subscription, a store disconnected from WooCommerce.com, or an outdated WooCommerce.com Update Manager. Changing files won’t fix any of these.

A full disk blocks updates that look like they would fit

The updater needs working space as well as room for the finished plugin. It unpacks the package into wp-content/upgrade and may keep a temporary backup of the old version while it works. Check your quota in the hosting panel. To free space, delete old backups stored on the server, not files in wp-content you don’t recognise.

Timeouts and memory limits leave a named line in the log

Look in the PHP error log for “Allowed memory size exhausted” or “Maximum execution time exceeded”. If one of those lines matches the time of the update, ask the host to raise that specific limit. If it isn’t in the log, raising limits only hides the real cause.

Conflicts and buggy releases

Sometimes the update installs fine and the new code is the problem. A 2023 study by Lin, Sayagh and Hassan found that 497 of the 500 most frequently released WordPress.org plugins had shipped at least one urgent fix within 24 hours of an earlier release. That measures how often releases need patching, not how often updates fail on real sites. It’s still a good reason to read the changelog, and to wait a day before installing a major release on a store.

To find a conflict without taking the site down, use Troubleshooting Mode in the Health Check & Troubleshooting plugin. The WordPress support handbook explains that it disables plugins and switches the theme for your logged-in session only, so visitors see the normal site. WooCommerce’s conflict-testing guide recommends the same approach, or a staging copy, rather than switching everything off on a live store.

How to get out of “Briefly unavailable for scheduled maintenance”

WordPress creates a file called .maintenance in the site root while an update runs and deletes it when the update finishes. If the update stopped partway, the file stays and visitors keep seeing the message. Fix it in this order:

1. Wait a few minutes. A slow update may still be running, and deleting the file mid-update can leave you with half the files from each version.
2. Once nothing has changed for a while, connect over SFTP or your host’s file manager. Turn on hidden files, because the name starts with a dot.
3. Delete .maintenance from the folder that holds wp-config.php.
4. Go to Dashboard > Updates and see what is still listed. Update the unfinished item on its own, one item at a time.
5. Check the installed version on the Plugins screen or under Dashboard > Updates.

The WordPress troubleshooting FAQ confirms that removing the file clears the message, and the same applies to “An automated WordPress update has failed to complete”. Clearing the message doesn’t prove the update finished. Step 4 is how you find out.

The update worked and the site broke

If the site shows “There has been a critical error” after an update, the new code is failing when it runs. WordPress usually emails the admin address with a recovery mode link that pauses the failing plugin or theme so you can log in. Our guide to fixing a WordPress fatal error shows how to read the file path in the error, which tells you which component failed.

Roll back that one component before you consider restoring a full backup. On a WooCommerce store, a full restore brings back yesterday’s database, which means losing every order placed since. Install the previous version from the vendor’s archive or a rollback plugin, then test the page that broke.

If wp-admin is locked, rename the plugin’s folder in wp-content/plugins (for example to plugin-name-off) and WordPress will deactivate it. If you don’t know which plugin it is, our guide to plugins that stop working walks through isolating it.

How to update manually when the dashboard keeps failing

A manual update gets around the updater itself. It does not get around wrong ownership, a full disk or a blocked network, so fix those first.

• Plugins. Download the current ZIP from WordPress.org or the vendor. Rename the old folder over SFTP so you can go back to it, then upload the ZIP under Plugins > Add New Plugin > Upload Plugin. Deactivate the plugin if you need to, but don’t delete or uninstall it. Uninstalling can delete its settings.
• Core. Follow WordPress.org’s manual update steps. Replace the core files, keep wp-config.php, and don’t delete the existing wp-content folder. That folder holds your uploads, themes and plugins.
• Themes. The same idea applies. Our guide to updating a theme without losing work covers child themes and licence errors.

What “Update successful” does not tell you

The notice means the installer finished. It doesn’t mean checkout works, forms send, or the version you wanted actually installed. Even update reports can be wrong: Easy Updates Manager’s changelog records a November 2024 fix for emails that marked some failed updates as “success”.

After every update, check the installed version, log out and back in, send a test form and look at a few key pages. On a store, WooCommerce’s update guide asks for more: a backup first, staging where you can, letting the update finish without refreshing, running any database update WooCommerce prompts for, and then testing products, cart, checkout, payment, shipping, tax and emails. Before any of that, make sure your backup can actually be restored, because a backup job that ran isn’t proof of that.

If you’d rather hand the update cycle off, SiteSelf runs plugin updates on request using hosting access, fetches the changed pages afterwards and reports what it updated and what it checked; the page on plugin updates and maintenance explains how that works.

When to stop and get help

Contact your host when the save request returns a 403, when the error names a folder WordPress can’t write to, when the disk is full, or when the log shows a PHP limit. These are server settings, and on shared hosting only the host can change them. Contact the plugin vendor when a paid update won’t download and the licence looks valid. Bring a developer in when a fatal error points at custom code, or when checkout is down and a single rollback hasn’t brought it back.

Whoever you contact, send evidence: the exact message, the time it happened, the plugin and version, the status code or log line, and what you’ve already tried. A vague “updating failed” ticket gets sent back to the forums. A ticket with the log line in it gets fixed.

Frequently asked questions

Did my post save even though the editor said updating failed?

Sometimes. The error tells you the editor didn’t get the reply it expected. That doesn’t always mean nothing was written. Open the post in a new tab or check its revisions before you retype anything.

Should I re-save my permalinks?

Re-saving the structure you already have under Settings > Permalinks is low risk, and it regenerates the rewrite rules. Changing the format is a different matter. Every existing URL changes, so links shared elsewhere start returning 404s.

Is it safe to set folders to 777 so updates work?

No. It lets anyone on the server write to those files, and it usually leaves the real cause, wrong ownership, untouched. Ask the host to correct ownership on the specific folder named in the error.

Can I disable all plugins to find the problem on a live store?

You can, but customers will see a broken store while you test. Use Troubleshooting Mode in the Health Check plugin, which changes plugins only for your session, or test on a staging copy.

Why do automatic updates fail when manual updates work?

Background updates depend on scheduled tasks and on the site sending requests to itself. A plugin conflict or a host firewall, DNS, SSL or password-protection rule can block those requests. Site Health reports loopback and scheduled-event problems, so start there.

Should I restore a full backup after a bad update?

Only after a targeted rollback has failed. A full restore replaces the database too, so on a store you lose any orders and customer accounts created since the backup was taken.

You change the opening hours, click Update, reload, and the old hours are still there. You save again and nothing changes. Saving again won’t help, because “page not updating” can mean at least five different things: the edit saved but a cache serves an old copy, the edit saved in the wrong place, the save failed, the styling is stale while the text is current, or Google is showing an old version.

Each one has a different fix. The order below starts with the test that tells them apart, then goes through the causes from most to least common. If you’re still learning where the editor’s controls are, start with how to edit pages in WordPress.

Which problem do you have? Run one test first

Open the exact public URL in a private or incognito window, where you’re logged out. Then compare three views: the editor, your normal logged-in tab, and the private window.

• New in the private window, old in your normal tab: your own browser kept an old copy. WordPress.org’s FAQ notes that a normal refresh often doesn’t clear it. Do a hard refresh (Ctrl+F5, or Cmd+Shift+R on a Mac) and you’re done.
• New in the editor and when logged in, old in the private window: a page cache is serving visitors an old copy. Logged-in admins often skip the page cache, which is why you see the change and your customers don’t. Go to the cache section below.
• Old everywhere, including after you reload the editor: the edit didn’t save, or it went to a different page, template or site. Go to the save and “wrong place” sections.

Never judge a fix from the logged-in session where you made the edit. That view is the one most likely to look right when it isn’t.

Why the cache is usually the cause, and why clearing it “didn’t work”

WordPress doesn’t include a page cache by default. WordPress.org’s FAQ says so, and it means there’s no core “clear cache” button. Any page caching on your site comes from a plugin, your host, a proxy such as Varnish, or a CDN. Each one keeps its own copy.

That explains most failed fixes. In one WordPress.org support thread, the poster disabled W3 Total Cache entirely and the page stayed stale, because the host’s own GoDaddy cache was serving it. In an r/webdev thread, a plugin purge did nothing. Clearing the whole-site cache in cPanel fixed it. The same FAQ adds a second trap: cache plugins generally purge a page when you publish it, but a change elsewhere, such as in the theme, can leave cached pages untouched.

Purge each layer, then retest logged out

Layer	Where the purge lives	Commonly missed because
Caching plugin (LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Fastest Cache, SiteGround Optimizer, Breeze)	The plugin’s admin bar menu or settings page	People purge one page when the stale URL is another
Host server cache	Your hosting panel (cPanel, Site Tools, MyKinsta, WP Engine portal)	Owners don’t know the host runs its own cache
CDN or edge cache (Cloudflare, host CDN)	The CDN dashboard, or a separate CDN tab in the host panel	It’s often purged separately from the server cache
Object cache (Redis, Memcached)	Host panel or the object cache plugin	It holds database results like menus and options, not pages
Browser	Hard refresh or private window	It’s the only layer people clear, over and over

Work outward: plugin, then host, then CDN, then your browser. Test in a private window after each step. The layer that fixes it is the one you’ll want to configure properly later.

Two hosts show why “clear cache” is ambiguous. Kinsta’s docs say the Clear cache button under Caching > Server Caching clears server and edge cache, plus Redis if it’s enabled, but not the CDN. You clear the CDN under Caching > CDN. WP Engine’s support docs list page, network/CDN and object cache as separate purge options. They also say a purge started from WP Engine’s WordPress admin doesn’t clear object cache, and that a full purge can make the site briefly slower while pages are cached again. If you don’t know which layers your site runs, ask your host. Thirty seconds of support chat beats an evening of guessing.

Confirm it from the response headers

If you’re comfortable with a terminal, read the headers instead of guessing:

curl -sI https://example.com/your-page/ | grep -iE 'cache|age|cf-'

A hit header (for example X-LiteSpeed-Cache: hit, or a CDN’s HIT status) and a large Age value mean a cache answered. LiteSpeed’s troubleshooting guide uses exactly this check. It also explains a quieter failure: when another plugin changes what a page shows without the page being saved, LiteSpeed may not know to purge it. A quick non-technical version is to add a made-up query string such as ?nocache=482 to the URL. Many page caches treat that as a different page. If the new content appears there, a cache is involved.

Don’t turn caching off to make edits show. DebugHawk’s report on 5.7 million pageviews found a median time to first byte of 106 ms for cached pages and 723 ms for uncached ones. Purge the stale layer instead, and make sure it purges itself automatically when content changes.

Text updated but the design didn’t: builder and minified CSS

When the words are current but the layout, colours or widget styling are old, the stale copy is usually a generated CSS file, not the page. Elementor’s help center gives the fix: Elementor > Tools > Clear Files & Data, then purge your other caches.

Minification caches cause the same symptom. In a WordPress.org thread about Elementor with W3 Total Cache’s CSS minification, purging only the minify cache wasn’t enough. What fixed the logged-out view was updating W3TC’s media query string and purging all caches. Our guide to layout and design changes in WordPress covers regenerating builder CSS in more detail.

You edited a different page than the one visitors see

This sounds unlikely until it costs you an hour. Check these in order:

1. Status. The page must say Published, not Draft or Pending Review.
2. Same URL. Copy the permalink from the editor and compare it with the address you’re testing. Duplicate pages with similar slugs are a common pitfall on Astra and Elementor sites.
3. Homepage assignment. If it’s the homepage, open Settings > Reading and confirm which page is set as the homepage. See setting a page as the front page.
4. Page or template. In the Site Editor, page content and template changes save separately. Check that the save dialog included the item you meant. A template edit changes every page that uses that template.
5. Environment and tab. Edits on staging don’t appear on production until someone pushes them. And check that you’re on the live site’s tab, not a local or staging copy.

Then open Revisions in the editor sidebar. WordPress.org’s Revisions documentation says autosaves don’t overwrite published content, so if your change only exists in an autosave, it was never published. Restore it, review it, and click Update on purpose.

The save itself failed

If the editor showed “Updating failed”, “Publishing failed”, “The response is not a valid JSON response” or “Updating page failed. You’re probably offline”, nothing reached the database. The offline message can appear when your internet is fine. Nexcess’s documentation ties it to the server or REST API, not your connection.

1. Copy your content somewhere safe before trying anything.
2. Open Tools > Site Health and look for REST API warnings. In the browser’s Network panel, find the failed request to /wp-json/ and note its status code.
3. Go to Settings > Permalinks and click Save Changes without changing anything. This rebuilds rewrite rules.
4. Ask your host to check firewall and server logs for blocked editor requests. Ask for a narrow exception, not a firewall switched off site-wide.
5. Test for a plugin or theme conflict on staging, as described in fixing plugins that stop working.

Installing Classic Editor has made saving work for some people, but that hides the cause rather than fixing it.

WooCommerce data that looks old

WooCommerce > Status > Tools has separate tools, and they don’t do the same job. “Delete all shop and product transient data” is for stale product or shop data. “Clear Template Cache” is for theme customizations that aren’t showing. “Clear expired transients” removes only expired entries. “Clear Customer Sessions” empties every shopper’s cart, so it’s not a refresh button.

WooCommerce’s docs also say cart and checkout pages should normally be excluded from caching, because their content differs for each shopper. If those pages show the wrong contents, a purge won’t last. Fix the exclusion rule in the plugin and at the host.

Google still shows the old version

That’s a crawl problem, not a site problem. In Search Console, use URL Inspection to request indexing for one URL, or submit a sitemap for many. Google’s documentation says crawling can take days to weeks and that requesting the same URL again doesn’t speed it up.

When to stop and get help

Stop if you’ve purged every layer you know about and the logged-out view is still old, if saves fail and you can’t see server logs, or if testing for conflicts would mean switching off plugins on a live store. At that point, give your host or developer four facts: the exact URL, the time of your last update from Revisions, what visitors see, and every cache you purged. If you’d rather hand the whole hunt over, SiteSelf works through WordPress bug fixes like this one on request. It needs hosting (SSH) access for cache and file work, and it reports what it changed and what it checked.

Frequently asked questions

How do I clear the cache in WordPress?

There’s no core page cache to clear. Use your caching plugin’s purge option, then your host panel’s cache tool, then your CDN. If you don’t know which of those your site uses, your host can tell you.

Should I just wait 48 to 72 hours?

No. A long wait usually means a cache layer nobody has purged yet. In one r/Wordpress thread, a maintenance company told the owner to wait, and the actual fix was clearing an edge cache.

Why does my phone show the old page when my laptop shows the new one?

Each device and browser keeps its own cache, and a CDN can serve different copies from different locations. Test in a private window on the phone. If it’s still old there, purge the CDN.

Will updating WordPress or my plugins fix it?

Usually not. A failed software update is a different problem: think maintenance mode, file permissions and PHP version. Update when a plugin’s changelog names your exact bug, not as a general cure for a stale page.

Is it safe to turn off my caching plugin to test?

For a few minutes, yes. But a host or CDN cache may still serve the old page, so a stale result proves nothing. Turn the plugin back on afterwards, because running without a page cache makes every page slower.

WordPress core is rarely what gets a site hacked. Patchstack’s 2025 security report counted 7,966 new vulnerabilities across the WordPress ecosystem in 2024. Of those, 96% were in plugins, 4% were in themes and 7 were in core. The count keeps rising: Patchstack’s 2026 report puts 2025 at 11,334.

That changes where to look. The weak point is the unmaintained site: the plugin nobody updated, the old contractor who still has an admin login, and the backup nobody ever tested. This guide ranks the causes, gives the fix for each, and covers the part most people get wrong, which is recovery.

Is it a security issue or an ordinary bug?

Rule out an ordinary bug first. The scary errors people read as “hacked” usually have ordinary causes. WordPress’s common-errors handbook explains that the message “There has been a critical error on this website” usually comes from a plugin conflict, a theme compatibility problem, the PHP version, a memory limit or corrupted files. For “Error establishing a database connection”, the handbook says to check the configuration and the host before you suspect a compromise.

So check the boring things before you pay anyone for malware removal. Read the email WordPress sends to the admin address, open wp-content/debug.log, and think about what changed recently. Our guides to fixing a WordPress fatal error and fixing a server error 500 go through that diagnosis step by step. If the cause is a broken plugin or setting and you would rather not do this yourself, SiteSelf takes WordPress troubleshooting and repairs on request through chat: the connector plugin is enough for settings work, and file-level fixes need hosting access.

The signs below point to an actual compromise, and a bug does not explain them:

• Administrator accounts you did not create.
• Spam posts or pages, often casino or pharmacy content, that you did not publish.
• Redirects to other sites, sometimes only for visitors who arrive from Google, so you never see them yourself.
• Unfamiliar PHP files, or recent changes to index.php or .htaccess that you did not make.
• A browser warning, a hosting suspension, or a flag in Search Console’s Security issues report.

What causes WordPress security issues, most common first

Outdated, abandoned or pirated plugins and themes

Extensions are where nearly all disclosed vulnerabilities sit, and attackers move fast. Patchstack’s 2026 report found a 5-hour weighted median time to first exploit for the heavily exploited vulnerabilities of 2025. About half of the high-impact ones were exploited within 24 hours. Updating once a month leaves weeks of exposure after a patch ships.

The fix:

1. Take a backup of the files and the database, and confirm it actually contains both.
2. Update core, every plugin and every theme, not just core. A current core next to a vulnerable plugin is still a vulnerable site.
3. Delete plugins and themes you do not use. Deactivating one leaves its code on the server.
4. Replace anything that has stopped getting updates.
5. Never install “nulled” (pirated) premium plugins. They are a common way malware gets in.

If a vulnerability is public and no patch exists yet, turn off the affected feature if the business can do without it for a while. If it can’t, such as checkout or a booking form, ask your host whether a firewall rule can block the exploit until the vendor ships a fix. A firewall rule buys time. It does not replace the update.

Weak passwords and too many administrators

Brute force is simple: a script tries username and password pairs until one works. WordPress’s brute-force handbook recommends strong unique passwords, two-factor authentication, passkeys and limits on login attempts. Practitioners prefer an authenticator app to SMS for the second factor.

Then go to Users and filter by Administrator. Every person should have their own account with the lowest role that still lets them do their job. Delete or downgrade accounts for former staff, agencies and freelancers. The hardening handbook calls security through obscurity an unsound primary strategy. Renaming the login URL is a small extra measure. It is no substitute for 2FA.

Loose file permissions and the server underneath

WordPress’s hardening handbook gives 755 for directories and 644 for files as “one possible scheme”. It suggests wp-config.php be readable only by its owner and the web server, often 400 or 440. Requirements vary by host, so confirm with yours before you change anything. Never set folders to 777 to get rid of a permissions error. That opens a hole and leaves the ownership problem unfixed.

The server matters too. Your host controls the PHP version, and updating WordPress does nothing for an unpatched PHP. On shared hosting, one infected site can reach the other sites in the same account. Server-side controls such as firewalls and headers are covered in our guide to Apache web server security.

Missing HTTPS

Without HTTPS, login details travel unencrypted. Install a valid certificate first. Once HTTPS works across the whole site, WordPress’s HTTPS handbook describes adding define( 'FORCE_SSL_ADMIN', true ); to wp-config.php, which forces logins and the admin area onto HTTPS. WooCommerce strongly recommends HTTPS for stores, even when payments are processed off-site.

Store abuse that is not a vulnerability

A wave of small failed orders is usually card testing, not a hacked site. WooCommerce’s security FAQ describes it as fraudsters running repeated low-value transactions to check whether stolen cards work. The fixes it suggests are CAPTCHA or anti-fraud tools, refunding the fraudulent orders, reviewing guest checkout and working with your payment provider. Store owners report that blocking IP addresses rarely works, because the addresses change every time.

How to recover from a hack without getting reinfected

The most common recovery failure is reinfection. Attackers leave ways back in. Sucuri’s 2023 threat report found backdoors on 49.21% of the compromised sites it cleaned, and malicious admin users in 55.2% of infected databases. Those figures describe what attackers left behind, not how they got in. They also explain a story that repeats on the WordPress.org forums: restore a backup, pass a scan, get hacked again a few weeks later.

WordPress’s “My site was hacked” FAQ and Google’s Search Console help add up to this sequence:

1. Preserve evidence. Take a snapshot of files and database before you change anything, and contact your host. Some hosts, Kinsta among them, ask you not to reset or delete the site first.
2. Write down what you saw. Note the symptoms, when they started and what changed recently.
3. Find the entry point. Look for an outdated plugin, a reused password or another site in the same hosting account. If you skip this, the cleanup will not hold.
4. Clean everything, not just the visible damage. Replace core, plugin and theme files with fresh copies. Check the database for rogue admins and injected content, and remove old WordPress copies left in subfolders.
5. Close the hole. Update or remove the vulnerable component.
6. Rotate every credential. Change the passwords for WordPress, the hosting panel, FTP or SFTP and the database. Change the secret keys in wp-config.php to end every active session, and change the passwords again once cleanup is finished.
7. Request a Google review last. Google says its sample URLs may not be complete and that issues must be fixed throughout the site before you request a review.

Restore from a backup only if you know it predates the infection, and only after the entry point is closed. Otherwise you have reinstalled the same hole. Our guide to malware removal that does not come back covers the file and database checks in detail.

Where security work causes its own problems

Security fixes break sites too. Updates can conflict with a theme or with each other, and owners who have been burned delay the next update, which widens the exposure window. Scanner “repair” options restore the repository copy of a modified file, which also wipes legitimate customizations. Copy the file before you accept a repair. Blanket permission changes can leave WordPress unable to write uploads or run updates.

A security plugin is a useful layer if you configure it with care. It does not do your updates for you, and a clean scan does not prove the site is clean.

When to stop and get help

Hand the job to someone experienced if the site keeps getting reinfected after cleanup, if a store’s customer data may be exposed, or if several sites in one hosting account are infected. Do the same if you cannot find the entry point. A one-site cleanup is often manageable. Recurring infections are a forensic job.

When a host tells you that you are hacked and offers its own security add-on in the same message, get an independent diagnosis before you pay. Moving to a new host does not close the entry point either. To stop it happening again, put updates, backups and access reviews in a written routine. Our guide to what a care plan should include sets out what that routine covers.

Frequently asked questions

Is WordPress secure?

Core has very few disclosed vulnerabilities: Patchstack counted 7 in 2024, against thousands in plugins. How secure a site is depends on how well it is maintained: how fast it gets updates, how many extensions it runs, and who can log in.

Do I need a security plugin?

WordPress’s own guidance is mostly configuration and habit: updates, strong passwords, 2FA, login limits, correct permissions, HTTPS and backups. A security plugin adds alerts, scanning and login protection. It helps if you set it up carefully, but it does not replace those habits.

Are deactivated plugins a security risk?

They can be. Deactivating a plugin stops it running inside WordPress, but its files stay on the server. If you don’t need it, delete it.

Can I just restore a backup after a hack?

Only from a backup you know predates the infection, and only after you close the entry point and change every credential. If you restore and skip those steps, attackers can walk back in the same way.

Does shared hosting affect my site’s security?

Yes. WordPress’s hacked-site FAQ warns that on shared hosting a compromise can reach beyond one site. If one site in the account is infected, check every other site in it during cleanup.

Why does Google still flag my site after I cleaned it?

Google’s sample URLs may not list every affected page, so the infection may still be live somewhere you did not check. Fix the whole site, test it, and then request a review in the Security issues report.

A customer sends you a screenshot that says “503 Service Unavailable”. The domain still resolves and your hosting account still exists, so the site hasn’t vanished. Something between the visitor and the finished page couldn’t answer when they asked.

That is all a 503 tells you. WooCommerce’s documentation on response codes describes it as the server being temporarily unable to handle the request. It doesn’t say which part failed. Usually the web server, the host or a proxy sends the response, even when WordPress code caused the trouble. So the job is to find which layer sent it, then fix that layer. If you see a bare 500 instead, that is a different failure, covered in our guide to fixing a server error 500.

Where does the 503 appear, and what does it say?

Spend two minutes on this before you touch a file. The same status code comes from very different places, and the pattern usually tells you which one. Open the site in a private window so you see what a logged-out visitor sees. Then check the homepage, a normal post, /wp-admin and, on a store, the cart and checkout.

What you see	Most likely layer	First move
“Briefly unavailable for scheduled maintenance. Check back in a minute.”	A leftover .maintenance file from an interrupted update	Delete the file, then rerun the update
The whole site fails right after a plugin update	That plugin	Disable it by renaming its folder
Public pages load, /wp-admin fails	Uncached PHP work hitting a limit, a security lockout, or a plugin’s admin-side task	Check host resource usage and any security plugin
Cart, checkout or logged-in pages fail, cached pages are fine	Exhausted PHP workers, or a route-specific fault	Ask the host for PHP worker usage at that time
Saving many product variations or opening many orders fails	mod_security or a server request limit	Ask the host to check firewall rules for that request
A page branded by a security plugin, such as Wordfence	A login lockout	Wait, or adjust the lockout settings
“cloudflare” or “cloudflare-nginx” in the error page	Cloudflare generated the response	Follow Cloudflare’s 503 steps
Only one page fails	A block or element on that page	Check what is on that page

Write down the time you first saw it and what changed beforehand: an update, a new plugin, a campaign that sent traffic, an email from your host. Logs are only useful if you know which minutes to read.

What causes a WordPress 503, and how do you fix each one?

No one has measured how often each cause happens, so this order comes from WordPress.org support threads and host documentation, not from a dataset. Plugin behaviour and host capacity show up far more often than anything else.

A plugin update, or a plugin doing heavy work

This is the most reported trigger, especially when the 503 starts within minutes of an update. In one WordPress.org thread, a user lost 12 client sites at once and traced the failure to WP-Optimize 3.2.22. Other users in the thread removed the plugin to get their sites back. Take reports like this as a pattern, not proof. In other threads, the plugin’s own support team disputed whether their plugin was to blame.

The fix is to disable the suspect and see whether the site recovers. If you can’t reach the dashboard, connect over SFTP or open your host’s file manager. Go to wp-content/plugins and rename the plugin’s folder, for example wp-optimize to wp-optimize-off. WordPress deactivates a plugin when it can’t find the plugin’s files. If you have no suspect, rename the whole plugins folder, confirm the site loads, then restore the plugins one at a time. Our guide to fixing a WordPress fatal error walks through the same folder method in detail.

Once the site is back, decide what to do with the plugin. Rolling back to an older version brings the site back but may reopen security holes the update closed. Replacing the plugin, or waiting for a fixed release, is often the safer choice.

PHP workers or host limits ran out

Every uncached request needs a PHP process to build the page. Kinsta’s documentation says each PHP thread handles one request at a time. When all the threads are busy, new requests time out or get a 503 or 504. Cached pages skip PHP, which is why the homepage can load while /wp-admin, the cart and checkout fail. Those pages can’t be served from cache, so they use up the workers first.

You can’t see this from inside WordPress. Look at your host’s resource dashboard for CPU, memory, I/O and process limits at the time of the failure. Then ask the host directly: were PHP workers or entry processes maxed out at that time, and which requests were slow? The fix might be caching more pages, fixing a slow query or a plugin that makes runaway requests, or a bigger plan. Only take the bigger plan once the logs show capacity is the actual limit.

The site is stuck in maintenance mode

During an update, WordPress creates a file named .maintenance in the site root. WordPress’s Advanced Administration Handbook explains that if the update is interrupted, the file stays behind and the maintenance message keeps showing. Make sure the update has really stopped by waiting a few minutes first. Then delete .maintenance over SFTP or in the file manager, and run the update again from Dashboard, then Updates. Dot-files are often hidden, so you may need to turn on “show hidden files” in your file manager.

If you delete the file while an update is still running, the site can end up half-updated. That is worse than the message.

A security plugin or server firewall blocked the request

A 503 on the login screen with a security plugin’s branding is usually a brute-force lockout, not an outage. Check how the plugin detects visitor IP addresses, since behind a proxy everyone can look like the same visitor. Also check whether it locks out invalid usernames immediately. Renaming the plugin’s folder gets you in, but it also switches off your protection. In one reported case, the lockout came back once the plugin was restored.

Server firewalls can do the same. WooCommerce’s documentation says mod_security blocking requests can cause 503 errors when saving large amounts of data, such as many product variations, and that your host can configure or disable the rule. Ask the host to allow the legitimate request. If you switch any firewall off to test, switch it back on afterwards.

Cloudflare or another proxy sent the 503

Cloudflare’s support docs say that if the 503 page contains “cloudflare” or “cloudflare-nginx”, Cloudflare generated the response. If it doesn’t, the 503 came from your origin server and you should investigate there: overload, exhausted connections, maintenance mode. Even a Cloudflare-generated 503 only tells you which layer answered, not why. A quick way to see the headers is curl -I https://yoursite.com from a terminal. Look at the status line and the server header.

One element on one page

When only one URL fails, look at what is on it. Forum cases include a Contact Form 7 block with no form selected, and a WooCommerce product-category element on a front page. Each was fixed at that page: selecting a form in one case, swapping the element in the other. Broad fixes miss problems like these. In one WordPress.org thread, a store owner ran a full conflict test, raised PHP memory, cleared caches and reinstalled WooCommerce. The cart still returned 503s. The cause turned out to be requests to an old /cart/ URL being caught by a temporary must-use plugin.

How do you read the logs without exposing them?

Your host’s server and PHP error logs are the first place to look, and reading them changes nothing on the live site. If PHP errors are involved, WordPress can also write its own log. Add these lines to wp-config.php above the line that says “That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WordPress’s debugging handbook explains that this writes errors to wp-content/debug.log instead of printing them on the page. Keep display off on a live site. Errors shown in the browser can reveal file paths, query fragments and sometimes data. Reproduce the 503, read the entries with matching timestamps, then set WP_DEBUG back to false and delete the log. WooCommerce gives the same advice: switch debugging off once the problem is diagnosed.

A memory error such as “Allowed memory size of 536870912 bytes exhausted” names the request that hit the limit. It doesn’t always show what caused it. Follow the file path in the error back to the plugin or block it names.

What does a conflict test miss?

The standard test, as WooCommerce’s conflict guide describes it, goes like this. Take a backup and use staging if you can. Switch to a default theme and deactivate plugins except WooCommerce and the extensions involved. Reproduce the problem, then reactivate plugins one at a time. It is the right method, and it has blind spots.

• Must-use plugins and drop-ins. WooCommerce notes that host-installed MU-plugins and drop-ins may not be deactivatable but can still cause conflicts. Look in wp-content/mu-plugins yourself.
• Caching. A page cache or CDN can keep serving the old result, so purge caches between tests.
• Live stores. Turning off plugins on a store taking orders can break payments and emails. Use staging, or pick a quiet hour and keep the test short.

Before any rollback or restore, confirm you can actually get back. A backup job that reported success is not the same as a backup that restores. Our explainer on what a backup plugin covers explains the difference.

WordPress’s Recovery Mode, available since version 5.2, helps when a plugin or theme causes a fatal PHP error. It emails the administrator a link and pauses the faulty extension for that session. It is built for fatal errors, so don’t expect it to catch a 503 caused by exhausted workers or a firewall rule.

Why more memory often isn’t the fix

“Increase PHP memory” and “upgrade your plan” are the most common advice in 503 threads. Sometimes they are right. A host raising PHP limits has fixed an orders page, and moving hosts has ended 503s caused by a plan that was too small. But Kinsta’s documentation points out the catch on its platform: raising the memory for each PHP thread leaves fewer threads. If the problem is how many requests can run at once, more memory per request means fewer requests served.

In an r/webdev thread, one commenter called buying more RAM without finding the cause “a sales pitch not a resolution”. That is the right instinct. Get the log line or the worker graph first, then decide what to buy.

Restarting PHP, switching PHP versions back and forth, or having the host restart the server often brings the site back for an hour. That is a symptom going quiet, not a fix. If the 503 comes back on a pattern, such as every five minutes or after a few minutes logged in, the pattern itself is evidence to give the host.

How long can a 503 stay up before search engines notice?

Google’s Search Central guidance treats a 503 as temporary, and for planned downtime that is the right signal. For a deliberate shutdown of a day or two, Google recommends returning 503 with a Retry-After header. It also says not to return 503 for robots.txt and not to use 404, 410 or noindex as a temporary signal. Google’s crawl troubleshooting page adds that if 503s go on for more than about two days, Google may start dropping URLs from its index. A 503 is a way to buy a day, not a way to sit out a broken site.

When to stop and get help

Stop changing things if any of these is true:

• the logs point at the server, PHP workers or a firewall rule
• the 503 keeps returning after a restart
• you have disabled the obvious plugin and nothing changed
• you are about to restore a backup on a store that is taking orders

Each extra guess on a live site adds a change someone will have to undo later.

Send your host a short note they can act on:

1. The failing URLs, and whether they fail for logged-out visitors, logged-in users or both.
2. The exact times, with your timezone.
3. The exact message, and whether the page mentions Cloudflare.
4. What changed just before.
5. Any matching log lines.
6. What you already tried and ruled out.

Ask specifically about PHP worker usage, slow requests and firewall rules at those times. A specific ticket gets someone to check the logs. A vague one gets a suggestion to upgrade.

If you’d rather not dig through logs and file managers yourself, the SiteSelf page on WordPress bug fixes explains how the agent works through errors like this one, using hosting (SSH) access for log and file work, and reports what it changed and what it checked.

Frequently asked questions

Is a 503 error my fault or my host’s?

It can be either. The host or web server sends the 503, but a plugin, a slow query or an unconfigured block can be what pushed it there. The scope table above, plus your host’s resource graph for the time of the failure, usually settles which.

Why does wp-admin show a 503 while the public site works?

Public pages are often cached and skip PHP, while every admin request runs PHP. If workers are exhausted, a plugin is running heavy admin tasks, or a security plugin has locked you out, the dashboard fails first. Check host limits and your security plugin before anything else.

How do I fix a 503 if I can’t log in at all?

Use SFTP or your host’s file manager. Rename the suspect plugin’s folder in wp-content/plugins, or rename the whole plugins folder if you have no suspect. If that doesn’t help, ask your host to check the server logs, because the cause may sit outside WordPress.

Should I use a maintenance plugin that returns 503 on purpose?

For planned work, yes. A deliberate 503 tells search engines the downtime is temporary. Keep it short, keep robots.txt reachable, and switch it off when the work is done, since a maintenance page left on is a self-inflicted outage.

What does “Error 503 backend fetch failed” mean?

That wording comes from Varnish, a caching proxy some hosts put in front of WordPress. Varnish asked your server for the page and didn’t get a usable answer in time. Treat it like any origin-side 503: check host resources and logs, and ask the host whether Varnish or PHP was the bottleneck.