Blog

A 504 Gateway Timeout means a server that passes requests along, such as nginx, your host’s proxy or a CDN, waited for the server behind it and gave up. RFC 9110, the HTTP standard, defines it like that: a gateway or proxy did not get a timely response from an upstream server it needed. On a WordPress site, that upstream is almost always PHP running WordPress, and behind PHP sits the database or a remote service.

So the code tells you where the waiting stopped. It doesn’t tell you what was slow. The most common mistake is to raise a timeout before working out which layer gave up and what work was taking so long. If you are seeing 503s as well, our explainer on what a 503 response code means covers the code that looks the most like this one.

How is a 504 different from a 502 or 503?

All three are server-side errors, but each one blames a different part of the chain. The table shows where each one sends you first.

Code	What happened	Where to look first
502 Bad Gateway	The upstream answered, but the answer was broken or unusable	PHP error log, crashed PHP processes
503 Service Unavailable	The server said it can’t take the request right now	Maintenance mode, overload, resource limits
504 Gateway Timeout	The upstream didn’t answer before the gateway’s limit ran out	Which request hung, and which layer ended it
524 (Cloudflare only)	Cloudflare’s own timeout waiting for your origin	Your origin server, not Cloudflare

The error page won’t tell you whether your host, a plugin, the database or a payment API was slow. It can also look different depending on who generated it: “504 Gateway Time-out (nginx)”, “Update failed: 504 Gateway Timeout” in the admin, an import plugin’s error line, or a checkout that spins and then fails.

Why the action may have worked even though you saw an error

A 504 means the gateway stopped waiting. PHP may keep going after that. In one WordPress.org thread, a menu save returned a 504 after about a minute, but the menu had been updated. In a WooCommerce thread, checkout hung for 60 seconds and showed “Gateway Timeout”, and the order email still arrived.

That changes what you do next. Don’t refresh a heavy request over and over. Every retry can start another copy of the same slow work, take another PHP worker and make the queue longer. Check what happened first: did the post save, did the import write rows, did the payment go through.

Step one: find the exact request that timed out

Most of the diagnosis comes before you change a single setting. Collect these facts while the error is fresh:

1. Write down the URL, the action and the time. “Saving the main menu at 14:32”, not “the admin is broken”.
2. Open the browser’s Network panel (right-click, Inspect, Network), repeat the action once and find the red 504 row. Note the request URL, such as /wp-admin/admin-ajax.php, /wp-json/... or ?wc-api=..., and how long it ran before failing.
3. Work out the scope. One action or many URLs? Admin only, or the front end too? Every time, or only some of the time?
4. Look at the duration. If failures keep stopping at about the same number of seconds, that number is a configured limit. It points you to the layer that set it.
5. Get the logs for that timestamp. You need the access log, the error log, the PHP error log and, if you can get it, the database slow-query log. On shared or managed hosting, ask support to match your URL and time against their logs and tell you which component returned the 504.

Kinsta’s server-errors documentation recommends the same thing: match the time and URL of the failure to the access and error logs. If you want PHP errors from WordPress too, turn on private logging in wp-config.php above the “stop editing” line:

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

Errors then go to wp-content/debug.log and visitors don’t see them. WordPress’s debugging handbook says these tools are meant for local or staging sites, so turn them off when you are done. In one Stack Overflow case, reinstalling and deactivating plugins did nothing, and the debug log showed the exact line that was breaking.

What usually causes a WordPress 504, and the fix for each

Nobody publishes data on how often each cause happens. The order below follows how often each one turns up as the confirmed answer in WordPress.org, Stack Overflow and Reddit threads. That partly reflects which fixes are easy to report, so treat it as a place to start, not a ranking.

A plugin doing too much work in one request

This is the usual cause when the 504 hits one action, especially in wp-admin, and the rest of the site works. Admin requests skip the page cache and run admin-only plugin code, so a slow hook shows up there first. In the Nav Menu Roles thread, deactivating the plugin turned a save that timed out after about a minute into a two-second save.

Scale can make this worse. A plugin that is harmless on 500 posts can rewrite every post on every dashboard load when you have tens of thousands. One detailed 2026 write-up described a post-ordering plugin doing exactly that. The 504 looked like a failed login.

Fix: use the Health Check plugin’s troubleshooting mode. WordPress’s support handbook explains that it turns off plugins and switches to a default theme for your logged-in session only, so visitors keep seeing the normal site. Turn plugins back on one at a time until the 504 comes back. Then update, configure, replace or report the plugin. Turning it off for good is a workaround, not a fix.

A long job running inside a browser request

Imports, backups, migrations, security scans and bulk image optimization all try to do minutes of work inside one web request. Messages like “Import Error 504 Gateway Time-out” come from this.

Fix: make the work smaller or move it out of the browser. Kinsta recommends WP-CLI or scripts for imports, exports and bulk operations. Use the plugin’s batch or chunk settings if it has them. For Duplicator, its documentation suggests directory filters, a different database build method or the DupArchive engine, which has a 500 MB limit in the free Lite version. Duplicator’s Max Build Time limits only the plugin’s own build. It does not lift your host’s limits.

A slow external service

Some plugins call out to SMTP servers, payment gateways, shipping APIs or licence servers while the page waits. If that service is slow, the whole request waits with it. In the WooCommerce checkout thread, turning off the SMTP plugin made checkout work but stopped all order emails. Trying other SMTP plugins didn’t help. Switching from the SMTP server to a mail API service fixed it.

Fix: find which remote call is hanging and replace it, cache its result or give it a shorter deadline. Turning off the feature only hides the symptom.

PHP workers are all busy

If many unrelated URLs return 504 at the same moment, think capacity before you think plugin. Kinsta’s documentation explains that requests can queue while they wait for a free PHP thread, then time out. Requests that visitors have already abandoned can still be holding workers.

Fix: find out what is filling the workers, such as uncached traffic, a bot or one slow endpoint called over and over. In one thread, restarting PHP-FPM brought a site back after renaming the plugins folder did not. That restart is a host or server task, and it clears the jam without explaining it. More workers need more memory, so a plan upgrade without a diagnosis can cost more and change nothing. One store on a 6-core, 12 GB plan still had 504s.

The limit was raised at the wrong layer

Every layer between the visitor and the database has its own clock, and whichever runs out first sends the error. In one WordPress.org thread, a scan of about 150,000 files kept dying at about 60 seconds. Nginx was set to 300 seconds, and raising PHP’s max_execution_time made no difference. Duplicator’s documentation makes the same point: if PHP limits are already high and the problem continues, the web server’s timeout may be the one cutting the request off.

Layer	Setting	Who usually changes it
PHP	max_execution_time	You (php.ini or host panel), if the host allows it
PHP-FPM	Pool and request time limits	Host or server admin
Nginx	proxy_read_timeout, fastcgi_read_timeout	Host or server admin
Host proxy (for example cPanel’s)	Proxy timeout	Host
CDN	Origin response timeout	CDN plan and settings

The nginx documentation gives proxy_read_timeout a default of 60 seconds. It measures the gap between two reads from the upstream, not the total time the response takes. Hosts often change these values, so a repeating 60-second failure is a clue, not proof.

Fix: raise a limit only at the layer the logs point to, and only for work that really needs the time. In one thread, a bulk image job failed at 60.081 seconds and worked once the cPanel proxy timeout went from 300 to 1,200. Raising limits everywhere just lets slow work hold workers for longer.

A CDN in front of the site

A CDN can have a shorter timeout than your origin server. Cloudflare reports its own timeout as 524, not 504, and its “Host Error” page points at your server. A CDN won’t fix a slow origin. It only caches pages for anonymous visitors, which is why the homepage can load fine while wp-admin and checkout time out.

A 504 at checkout: check the payment before anything else

On a WooCommerce store, a checkout that times out can still have charged the customer. One WordPress.org case with Stripe and PayPal shows exactly that: the payment went through, but the request back to the store returned 504 and the thank-you page never loaded. If the customer tries again, you can end up charging them twice.

WooCommerce’s troubleshooting guide for orders gives the order of checks. Open the order and read its status and notes. Search the payment gateway’s own records for the transaction. Read the gateway log under WooCommerce → Status → Logs. If the gateway shows a charge but the order is still pending, check the webhook or callback setup and match the two up before you ship anything. Only then tell the customer what to do.

When to stop and get help

Stop guessing once you have the URL, the time and a scope, but no logs. At that point the fix sits with whoever can see the server: your host for proxy, PHP-FPM and resource limits, or a developer for plugin code and slow queries. Send them the request, the timestamp, the duration and what you have already ruled out. If a store migration or plugin update stalls partway, don’t mark steps as complete by hand to get past the timeout. Keep the backup and get help.

If you’d rather hand over the whole job, SiteSelf’s WordPress troubleshooting and bug fixes work starts from the error on your live site: with hosting (SSH) access it reads the logs, makes the fix, fetches the page again and tells you in chat what changed. For other errors, the guide to why WordPress is not loading sorts problems by what you see on screen.

Frequently asked questions

Is a 504 my host’s fault or my site’s?

The code alone can’t tell you, and in public threads the answer goes both ways. Some 504s come from a plugin’s admin code, others from a crowded server. The logs decide it, so ask your host to match your URL and timestamp against them before you change plans or blame anyone.

Why does the 504 still happen after I raised max_execution_time?

Another layer is probably ending the request first, such as nginx, the host’s proxy or PHP-FPM. If the error still arrives at the same number of seconds after your change, you changed the wrong clock. Ask the host which component returned the 504.

Why does it happen only in wp-admin?

Admin pages skip the page cache and run plugin code that never runs for visitors. A fast cached homepage doesn’t mean the server behind it is healthy. Test with Health Check’s troubleshooting mode to find which plugin’s admin code is slow.

Will a CDN or better hosting fix a 504?

A CDN caches pages for anonymous visitors. It doesn’t make slow PHP faster, so admin pages and checkout still time out. Bigger hosting helps when the logs show the server is out of capacity, and does nothing for a plugin stuck in a loop.

Will moving away from WordPress stop the timeouts?

Not on its own. Replies in r/webdev made the point that heavy work times out on any framework if it runs inside a web request. The fix is the same anywhere: batch the work, queue it or run it from the command line.

Is there a fix for a 500 error that hides a 504?

Some hosts show a generic 500 page while their access log records a 504. If the 500 steps don’t help, ask what the access log recorded for that request. Our guide to fixing a server error 500 covers the real 500 cases.

The homepage loads. wp-admin works. The editor still shows the post you published. But the link you just sent a customer returns “404 Not Found”, and so does every other post, page and product you try.

That pattern means a routing problem, not missing content. Pretty URLs like /blue-shirt/ only work if two layers agree. WordPress needs a current set of rewrite rules, and the web server has to send each request for a path that is not a real file to WordPress’s index.php. The homepage needs no rewriting, which is why it still works. Your job is to find out which layer broke before you change anything. If the 404 is about one URL that moved, our guide to how WordPress slugs work is the better starting point.

Which 404 are you looking at?

Look at the error page before you touch a setting. If it shows your theme’s header, footer and styling, WordPress received the request and could not match it to content. That points at rewrite rules, the content itself or a plugin. If it is a plain white page that says “404 Not Found” with a server name like nginx at the bottom, the request never reached WordPress. That points at server configuration. WP Engine’s support docs make the same split between a WordPress-themed 404 and a default Nginx 404.

Then check the scope:

• Everything except the homepage fails. Rewrite rules or server routing. Keep reading.
• One URL or a few fail. Open the item in the editor. Check that it is published, not in the trash, and that the slug matches the link. A renamed or deleted page needs a redirect, not a routing repair.
• Only products, a custom post type or account pages fail. Probably a slug collision or a plugin. See the sections below.

One more quick test. Find the post’s ID in the editor’s address bar (post.php?post=123) and visit yoursite.com/?p=123. If that loads while /my-post/ does not, rewriting is broken. If ?p=123 fails as well, the problem is deeper than permalinks, usually theme or plugin code changing the query.

Re-save your permalinks first, without changing anything

Go to Settings → Permalinks and click Save Changes. Do not pick a different option. The WordPress documentation for that screen explains that WordPress regenerates its rewrite rules there. On Apache, if WordPress can write to .htaccess, saving also updates the file.

Test the URL that failed in a private window. If it loads, you are done. This is the standard fix after a migration, a backup restore, a change of host, or installing a plugin that adds its own URL types. Migration plugin vendors put this step at the end of their own checklists for exactly that reason.

For custom post types, WordPress documents a longer variant: switch to the default structure, save, switch back to your real structure, and save again. It is optional. Just make sure you finish on the structure you started with.

Developers with WP-CLI can run wp rewrite list to see whether a rule for the failing URL exists, and wp rewrite flush to rebuild the rules from the command line. Do not put flush_rewrite_rules() on every page load. WordPress’s function reference warns that flushing is expensive, and it does nothing for a server that ignores the rules.

Why saving did not fix it

Saving only rebuilds WordPress’s half of the routing. If the 404s are still there, check these in order. They start with the cheapest to rule out, not with whatever happens to be most common, because nobody has measured how often each cause turns up.

A cache is still serving the old 404

Your fix may have worked while a cache keeps handing out the old error page. Clear your caching plugin, any server cache your host runs (LiteSpeed, Varnish), and your CDN, then test logged out in a private window. WooCommerce’s product 404 documentation warns that cached 404s and testing while logged in can make a working fix look broken.

Apache is not reading the rules

On Apache and LiteSpeed, pretty permalinks depend on three things. WordPress’s Common Errors handbook names an inactive mod_rewrite module as a cause. Apache also ignores .htaccess completely when the directory is set to AllowOverride None. Your host controls both settings, so ask them to confirm both are on.

The third is the file itself. It lives in the WordPress root, next to wp-admin and wp-content. Your file manager may hide it because the name starts with a dot. For a site installed at the domain root, the WordPress block looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Download a copy of the file before you edit it. Many sites keep redirects and security rules in there, and pasting a fresh block over the whole file deletes them. Add or fix the WordPress block only, and keep custom rules above # BEGIN WordPress, as our guide to htaccess 301 redirects explains. Subdirectory installs need a different RewriteBase, so copy the rules WordPress shows you rather than the example above.

If WordPress cannot write the file, the Permalinks screen tells you to update .htaccess yourself and shows the rules to paste. That usually means the file’s ownership is wrong. Setting the file to world-writable (666) is not a fix. Ask your host to correct the ownership.

The server is Nginx, and .htaccess does nothing

Nginx has no per-directory config files. WordPress’s Nginx handbook says WordPress cannot generate Nginx rewrite rules, so no amount of saving in the dashboard will help. Editing .htaccess on an Nginx server is the most common wasted afternoon in this whole topic. A missing .htaccess on Nginx is normal, not a fault.

The handbook’s rule for a single site goes in the server block:

location / {
    try_files $uri $uri/ /index.php?$args;
}

If a location / block already exists, edit it rather than adding a second one. Run nginx -t before reloading. On managed hosting you probably cannot touch this file. Kinsta’s docs, for example, say its WordPress sites have no .htaccess and that server configuration changes go through support. Send your host the failing URL, what you have already tried, and the exact 404 page you see.

Two things are claiming the same URL

The Common Errors handbook notes that a custom post type and a page with the same name cause 404s. WooCommerce’s permalinks documentation warns against using the same value for the product base and the product category base. Re-saving cannot fix a collision. Rename one of the two, save permalinks again, and add a redirect for whichever URL changed.

A plugin or theme is intercepting the request

Plugins that register their own content types, custom fields or URL rules can break WooCommerce account endpoints, product pages or whole sections of a site. Themes can do it too, which is when even ?p=123 URLs fail. Start with whatever was installed or updated last. Use the Health Check & Troubleshooting plugin’s Troubleshooting Mode, which turns plugins off only for your own session, or use a staging copy. Change one thing at a time, and re-save permalinks after each change. Our guide to troubleshooting plugins that are not working covers the full isolation method.

A migration damaged the data

If someone moved the site by running a raw SQL find-and-replace on the old domain, they may have corrupted serialized data. PHP stores the length of each string inside serialized values, and a replacement that changes the length breaks them. Practitioners report 404s, missing images and plugin errors after this kind of move. Restore from backup and redo the replacement with wp search-replace, starting with --dry-run, or use a migration plugin that handles serialized data.

Why the 404s come back after you re-save

If saving fixes the site for a day or a week and then the 404s return, saving is hiding the problem, not fixing it. Something keeps overwriting the rewrite rules or caching a broken state. In community threads the usual suspects are security plugins that rewrite .htaccess, host-level caching, and plugin interactions nobody pinned down. None of those threads confirmed a single root cause.

To narrow it down, keep a copy of .htaccess from when the site works and compare it with the file the next time the site breaks. If the WordPress block has changed or disappeared, check which plugin writes to that file and look at its settings. If the file has not changed, look at caching. Do not settle for re-saving every few days on a store, where a broken return URL after payment costs you orders.

Do not fix a 404 by changing your URLs

Switching to “Post name” or renaming the WooCommerce product base can make the 404s go away, because WordPress rebuilds the rules along the way. It also changes every established URL. Links already shared, bookmarked and in Google’s index now point at nothing. WooCommerce’s documentation warns that old product links will return 404 unless you redirect them. Re-save the structure you have. Change it only on purpose, with a redirect map ready.

If URLs did change, Google’s site-move guidance asks for permanent server-side redirects from each old URL to its closest new equivalent. Sending everything to the homepage instead can be treated as a soft 404. Our explainer on permanent redirects and SEO walks through the mapping. Remember that a redirect plugin cannot rescue broken rewriting: the Redirection plugin’s installation docs say it needs WordPress permalinks working first.

When to stop and get help

Stop clicking Save and hand the problem over when the host has to change server configuration you cannot reach, when the 404s keep coming back, when a plugin or theme conflict points into custom code, or when a migration may have corrupted the database. Several public support threads in each of these groups never reached a fix, even after the owner had tried a dozen things. Give your host or developer the failing URL, which kind of 404 page appears, whether ?p= URLs work, and what changed just before the problem started.

If you would rather someone else does the diagnosis, SiteSelf can find and fix WordPress errors like this through chat. It needs hosting (SSH) access for server and .htaccess work, and it reports what it changed and what it checked.

Frequently asked questions

Where is the .htaccess file in WordPress?

It sits in the WordPress root folder, the one that contains wp-admin, wp-includes and wp-content. Because the name starts with a dot, many file managers hide it until you turn on “show hidden files”. If your server runs Nginx, there is no .htaccess, and that is normal.

Why does only the homepage work?

The homepage URL needs no rewriting, so it loads even when the rewrite layer is broken. Every other pretty URL needs WordPress’s rules and the server’s routing to work together. Re-save permalinks first, then check the server.

Should I switch to Plain permalinks to fix the 404s?

Only as a short test. Plain URLs like ?p=123 work without rewriting, so they confirm the diagnosis, but they change every public URL on the site. Switch back and fix the rewriting rather than leaving the site on Plain.

Why do my WooCommerce product attribute pages return 404?

WooCommerce’s permalinks documentation says attribute archive URLs only work when archives are turned on for that attribute. Go to Products → Attributes, edit the attribute, tick “Enable archives?”, then re-save permalinks.

Should I redirect every 404 my site reports?

No. Redirect URLs that used to have content to the closest page that replaced them. A URL that never existed can stay a 404, and sending everything to the homepage can be treated as a soft 404.

How do I check whether my server is Apache or Nginx?

Look in your host’s control panel or ask support. In WordPress, Tools → Site Health → Info → Server usually lists the web server software. The bare 404 page often names the server at the bottom too.

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.