Category: Troubleshooting

A hacked WordPress site rarely makes the problem obvious. Google shows “This site may be hacked” under your listing, or a customer says your homepage sent them to a casino. Or there is an admin user you never created. The obvious move is to restore last night’s backup and get back to work. That is also how many sites end up hacked twice.

Restoring a backup, deleting the strange script or running one clean scan all fix the symptom. If the attacker still has a way in, they come back. The steps below are in order, and the order is the point.

Is the site actually hacked, or just broken?

Check this before anything else, because the two problems need opposite responses. WordPress.org’s hacked-site FAQ lists these as stronger signs of a hack:

• Google or a browser flags the site.
• A scanner reports malware.
• Your host suspends the account.
• Users appear that nobody created.
• Pages are visibly defaced.

Add redirects you didn’t set up and scripts in the page source that you don’t recognise.

Some messages look alarming but usually have ordinary causes: “500 Internal Server Error”, “There has been a critical error on this website”, “Error establishing a database connection” and the white screen. Most come from a plugin conflict, a PHP fatal error or a database login problem. Our guides to fixing a 500 server error and fixing a WordPress fatal error cover those. If what you have is a fault rather than an intruder, SiteSelf can find and fix the broken part when you ask in chat. A confirmed hack is work for your host or a security specialist.

A clean-looking homepage doesn’t prove much either. Injected redirects often target only mobile visitors, logged-out visitors or people arriving from Google, so administrators see a normal site. Open a private window, stay logged out, and check on a phone too.

What to do in the first hour, before you delete anything

Your first job is to stop harm to visitors and keep evidence. Cleaning comes later. Kinsta’s malware documentation warns that wiping or resetting the site straight away can destroy forensic evidence without closing the hole the attacker used.

1. Write down what you see. Note the symptom, when you first noticed it, the URLs involved and anything that changed recently. WordPress.org’s FAQ recommends doing this before you contact your host.
2. Contact your host. Ask them to look at the whole hosting account and whether they can restrict public access while you work. A maintenance page served by compromised WordPress code may not block direct requests to malicious files.
3. Save a copy of everything, infected or not. That means files, the database, and the access and error logs. Label the copy as compromised and store it away from your normal backups so nobody restores it later by mistake.
4. If you run a store and the checkout may have been changed, pause it. Contact your payment provider through its normal support channel.

Don’t install three security plugins, bulk-delete unfamiliar files or restore the newest backup during this hour. Each one changes the evidence you need to find the way in.

How attackers usually get into WordPress

The entry point decides whether the cleanup holds, so find it before you rebuild. Here are the routes, from most to least common.

Vulnerable or outdated plugins and themes

Patchstack’s 2026 report counted 11,334 new WordPress vulnerabilities in 2025, 42% more than the year before. 91% were in plugins and only six were in core. 46% had no fix from the developer when they were made public. Patchstack also reports a weighted median of five hours from disclosure to the first observed attack. That figure is weighted toward the most heavily attacked bugs, so it doesn’t mean every flaw is hit in five hours. It does mean a monthly update routine is slow compared with an attack. All of these counts are found flaws, not hacked sites.

Stolen credentials

Firewalls and login-lockout plugins don’t see logins to your hosting control panel, SFTP or database. WordPress.org’s FAQ also names malware on the administrator’s own computer as a way FTP and wp-admin passwords get stolen. If you change your passwords on an infected laptop, the attacker gets the new ones too.

Pirated (“nulled”) plugins and themes, and neighbours on shared hosting

Pirated premium plugins often ship with a backdoor already in place. On shared hosting, one compromised site can reach the other sites in the same account. That is why moving hosts on its own often brings the infection along.

Expect some uncertainty here. A disabled security plugin, a strange file and a new admin are all clues, but they rarely show which came first. Host logs are usually the best evidence you have.

Why deleting the malicious code is not the fix

The code you can see was put there by something you can’t see yet. WordPress.org’s FAQ points out that the dashboard’s reinstall only overwrites existing files. Files the attacker added stay where they are. Attackers commonly leave a way back in these places:

• Administrator accounts that exist in the database but don’t appear in the Users screen.
• Changed rows in wp_options, or injected content in posts.
• Redirect rules in .htaccess, and edits to wp-config.php.
• PHP files in wp-content/mu-plugins, drop-ins, or wp-content/uploads.
• WordPress cron events and server cron jobs.
• Files outside public_html, or a second WordPress install in a subfolder.

On the WordPress.org forums, one agency reported several client sites hacked the same way: the same rogue user, a plugin called “hellos”, and file-manager plugins installed. Cleaning didn’t stop it, and the sites kept getting reinfected. That pattern points to access outside WordPress, not a missed file.

If you have SSH and WP-CLI, these commands give you a fast first look. They change nothing.

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator
wp cron event list

The plugin checksum check only covers plugins from WordPress.org. To find admins that the dashboard hides, query the database directly. Change the wp_ prefix if yours is different:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

How to clean the site without restoring the hack

Rebuild from copies you trust instead of patching what is there. Keep the site restricted until you finish.

1. Replace core with the same version. Delete wp-admin and wp-includes, then upload fresh copies from the matching official release. WordPress.org says this is appropriate only with the same version. Uploading on top of the old folders leaves the attacker’s extra files in place.
2. Delete plugin and theme folders and reinstall them from the original source. Remove anything unused or pirated. Keep custom code aside and review it before you put it back.
3. Check uploads, configuration and scheduled tasks by hand. Look for PHP in uploads, files with double extensions, unknown cron events and edits to .htaccess or wp-config.php. Ask the host to check server-level cron jobs and anything above the web root.
4. Clean the database. Remove unknown admins, then search posts and options for injected scripts and links. Kinsta notes that database infections can take more than one round.
5. Use a backup only if you know it is clean, and only after the entry point is closed. A backup made before you noticed the hack may still contain it. Our guide to restoring a WordPress site from backup covers how to do the restore once you have a trustworthy copy.

Scanners help here, but they don’t diagnose the problem for you. One site owner on the WordPress.org forums reported six months of returning malware despite running Wordfence every day. Treat scan results as leads, and back up any file before you change it. Our guide to malware removal that doesn’t come back covers the file and database checks in more detail.

Which credentials to change, and why you change them twice

Change every credential, not just your WordPress password. Do it from a device you trust.

• Every WordPress administrator and editor account.
• The hosting control panel, and the email address it sends password resets to.
• SFTP and FTP accounts. Remove the ones nobody uses, and remove SSH keys you don’t recognise.
• The database user. Update wp-config.php to match.
• API keys and SMTP passwords stored on the site.
• The WordPress secret keys (salts). Changing them logs everyone out. WP-CLI does it with wp config shuffle-salts.

WordPress.org’s FAQ says to change passwords again once the cleanup is done. Anything you changed while malicious code was still running may have been captured.

How to confirm the site is clean and get Google’s warning removed

Check the site the way the attacker wanted visitors to see it. Use a logged-out browser and a phone, open the exact URLs that redirected before, and try a link from Google search results, not just the homepage. Clear the page cache, the host’s cache and any CDN cache first.

Google’s Search Console help says the sample URLs in the Security issues report may not be a complete list. It also advises against opening infected pages directly in your browser; use URL Inspection to see what Google gets. Request a review only after every issue is fixed across the whole site, and explain what you fixed. Google says reviews often take days or weeks. Don’t submit another request while one is pending.

After you reopen, watch the site for a few days. Check for files coming back, new admins, spam going out from the site’s email, and forms that suddenly behave differently.

If the hacked site is a WooCommerce store

WooCommerce’s security FAQ says a store is only as secure as its WordPress installation, and that one badly written plugin or code snippet can put the site and its data at risk. Customer contact details and orders are stored in your site’s database. Card numbers and security codes generally go straight to the payment processor, but payment tokens may be stored on the site. After a store hack, ask your payment gateway and your host what they can see, not just WordPress. Get qualified advice on whether you have to notify customers. The rules depend on where you and your customers are.

When to stop and get help

Hand the job to your host or a security specialist if any of these is true:

• Files come back after you delete them.
• An admin account keeps reappearing.
• You have no logs.
• The host reports that the hosting account itself was compromised.
• You can’t tell which files are clean.

Give them the copy you saved, the timeline and a list of what you changed. Some hosts help for free. Paid cleanups range widely, so ask whether reinfection is covered.

Once the site is stable, preventing a repeat is mostly routine work: update plugins promptly, delete what you don’t use and limit who has admin access. Our list of common WordPress security issues and our guide to what a care plan should include cover the routine.

Frequently asked questions

Can I just restore yesterday’s backup?

Only if you know the backup is clean, and only after you have closed the entry point. A backup made before you noticed the hack may already contain it. A restore also brings back the vulnerable plugin, so the attacker can come straight back in.

I had a security plugin installed. Why was I still hacked?

Login lockouts mostly stop repeated failed password guesses. A stolen valid password, a vulnerable plugin, or access through hosting, SFTP or the database gets around them. A security plugin reduces risk, but it can’t stop every attack.

I can’t log in to wp-admin after the hack. What now?

Attackers sometimes change the admin email or redirect wp-admin. Get control through your hosting account first. Use SFTP, phpMyAdmin or WP-CLI to check the admin users, then change passwords and the secret keys. If you can’t get into the hosting account either, contact your host before doing anything else.

Should I take the site offline?

If visitors could be harmed, for example by redirects, malware downloads or a changed checkout, yes. Ask your host to restrict access at the server level. A short outage costs less than sending customers to malware.

Can one hacked site infect my other sites?

Yes, if they share a hosting account or server user. Ask your host to check every site in the account. Cleaning one site while a neighbouring site still has a backdoor usually leads to reinfection.

When a WordPress site breaks today, WordPress itself is rarely the cause. The cause is usually one plugin, one theme, the PHP version, a cache or the host, and each of these fails in its own way. Patchstack’s report on 2025 found 91% of new WordPress vulnerabilities in plugins. Everyday breakage follows the same pattern: the trouble is in the layers around core.

This matters because your first move decides how long the fix takes. Find the failing request or component before you change any settings. Our guide to fixing WordPress issues without guessing covers the method in depth. This page matches today’s common symptoms to the first safe step for each.

Is WordPress down, or is it just your site?

It is almost always just your site. Self-hosted WordPress has no central server that can go down for everyone. WordPress.com is a separate hosted service with its own status page, and that page tells you nothing about a site on your own hosting.

Rule out the cheap explanations before you touch plugins:

• Load the site on mobile data instead of your office Wi-Fi.
• Confirm the domain hasn’t expired and the hosting bill is paid.
• Check your host’s status page.

Each of these can produce the same blank page or timeout as a broken plugin, and no amount of plugin testing will fix them.

Which problems turn up most, and what to do first

Nobody publishes a reliable count of which WordPress problems are most common. The table below follows the order that WordPress.org’s documentation, WooCommerce’s docs and the support forums consistently point to. Find your symptom before you change anything.

Symptom	Usual cause	First safe step
Something broke right after an update	Plugin or theme incompatibility	Roll back or disable that one component, on staging if you can
“There has been a critical error on this website”	PHP fatal error in a plugin, theme or custom code	Recovery Mode email, or the error log
White screen or 500 error	PHP fatal error, .htaccess or memory	Read the error log
“Allowed memory size … exhausted”	The process named in the error	Fix that process before you raise the limit
Changes not showing	A cache layer still serving the old copy	Purge every layer and test in a private window
Checkout stuck on a spinner	A failed background request	Browser Network tab, then check Orders
“Error establishing a database connection”	Wrong wp-config.php details, or the database server	Check the credentials, then ask the host
Every post 404s, homepage loads	Stale rewrite rules	Save Settings > Permalinks

The site broke after an update

This is the problem people hit most often. WordPress.org’s Recovery Mode documentation says fatal errors often come from an incompatible or faulty plugin, theme or custom code, and updates are when those incompatibilities show up. An update can break the whole site, only wp-admin, or a single feature such as checkout, a form or a layout.

Start with what changed. If one plugin updated this morning and checkout broke this afternoon, roll back or deactivate that plugin first. If nothing obvious changed, run a conflict test the way WooCommerce documents it:

1. Switch to a default theme.
2. Disable all plugins.
3. Turn them back on one at a time, and repeat the exact action that failed after each one.

The common trap is disabling everything and calling the site fixed. Some conflicts only happen when two specific plugins run together. A blanket disable brings the site back but hides which pair caused the problem.

One store owner on the WordPress.org forums handled this well. They updated a cookie consent plugin and a few others on staging, and guest checkout stopped working. Testing showed the consent plugin was blocking a WooCommerce script. A settings exception worked around it until the plugin’s author released a fix. The live store never saw the failure.

If WordPress said the update itself failed, that’s a different problem. See why WordPress updating failed.

“There has been a critical error” means PHP stopped

This message means a PHP fatal error, almost always from a plugin, theme or code snippet. WordPress emails the admin address a Recovery Mode link, which pauses the failing component for your login session only. Visitors still see the error until you deactivate or fix that component. WordPress’s documentation calls deactivation a temporary fix, not the real one.

The email often never arrives, especially when the admin address is an inbox nobody reads anymore. In that case, open your host’s file manager or connect over SFTP and rename the suspect plugin’s folder in wp-content/plugins. WordPress then treats that plugin as deactivated. The error log names the file that failed, which tells you which folder to rename. Our guide on how to fix a WordPress fatal error shows how to read that log.

A white screen or a bare 500 is often the same failure with error display turned off. WordPress’s common-errors handbook lists .htaccess, plugins, the theme and memory limits as causes of a 500. The log tells you which one it is. See fixing a server error 500 on WordPress.

Memory errors: fix the process, not the limit

When the log shows “Allowed memory size of … bytes exhausted”, visitors usually see a critical error, a blank page or a 500. Kinsta’s documentation advises fixing the process named in the error rather than simply raising the limit. Raising WP_MEMORY_LIMIT in wp-config.php only helps when the limit really is the problem. Your host may also enforce a lower ceiling than WordPress requests, so the edit can do nothing at all.

If the error names a plugin file, that plugin is your first suspect. Before you edit anything, ask your host what memory limit your plan actually allows.

Changes not showing usually means a cache is still serving the old page

A WordPress site can have five caches: a caching plugin, the host’s server cache, an object cache, a CDN and the browser. Clearing one doesn’t clear the others. Purge each layer you have, then check the page in a private window.

Stores have a second cache problem. WooCommerce’s documentation says the Cart, Checkout and My Account pages usually need to be excluded from page caching because their content is specific to each shopper’s session. If they get cached, those pages can display incorrectly or stop working.

A stuck checkout spinner means a request failed

WooCommerce’s documentation says the spinner alone doesn’t tell you the cause. To find it:

1. Open your browser’s developer tools and go to the Network tab.
2. Filter by Fetch/XHR.
3. Place a test order and find the request that failed.

The failed request points to the layer at fault:

• 403: a firewall, security rule or authorization check rejected the request.
• 500: a PHP fatal error or server failure. Check the error log.
• HTML or a redirect where JSON should be: a cache, security layer, proxy, redirect or PHP warning changed the response.

The same document gives three warnings:

• Check WooCommerce > Orders before you retry “Place order”. The order may already exist.
• A staging copy can still charge real payments, send email and fire webhooks unless you turn those connections off.
• Don’t switch between the Checkout block and classic checkout as a first step. The switch can hide the original incompatibility.

“Error establishing a database connection”

WordPress’s handbook gives two kinds of cause:

• A wrong database name, user, password or host in wp-config.php.
• A problem at the host, such as a database server that is down or over its quota.

If you haven’t changed the credentials and the error comes and goes, suspect the database server.

Extreme cases exist. One site on the WordPress.org forums had intermittent connection errors on shared hosting. Replies traced them to a wp_options table that had grown to about 32 GB, which caused table locking. The right fix in a case like that has three parts: find the plugin writing the data, back up, and have the host look at the database. A cleanup plugin that removes the data but leaves the plugin writing it only buys a few weeks.

Every post 404s but the homepage loads

This usually means the rewrite rules are stale. Go to Settings > Permalinks and click Save Changes without changing anything. That rebuilds the rules.

If that doesn’t help, check two things. The server may not have Apache’s mod_rewrite module enabled, which WordPress.org’s troubleshooting FAQ lists as a cause. Or a page and a custom post type may share a slug. If you aren’t comfortable editing .htaccess, ask your host.

Why the plugin security problem keeps getting bigger

Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024:

• 91% were in plugins and 9% in themes. Only six were in core, all low priority.
• 46% had no fix from the developer by the time they were made public.

Treat these numbers with care. Patchstack sells security products. Other security companies count vulnerabilities differently and get different totals. Some of the growth comes from more researchers looking. A vulnerability count is not a count of hacked sites. What every source agrees on is that the risk is in plugins, so an up-to-date core does not mean an up-to-date site.

Site owners feel this too. In WordPress.org’s 2023 Annual Survey, the top frustration was “too many plugins (finding the right one)” at 18.6%. Security followed at 16.4%, slow performance at 16.2%, and maintenance and updates at 12.3%.

The practical response is routine work:

• Delete plugins you don’t use.
• Keep the rest updated.
• If a plugin has a publicly known flaw and no fix, deactivate or replace it.

If you suspect a hack, WordPress security issues and how to fix them explains how to tell a compromise from an ordinary error.

Which quick fixes make things worse

Each of these feels like progress and often isn’t:

• Raising the memory limit before reading the log. It hides a faulty plugin, and the host may ignore the new value anyway.
• Clearing one cache and assuming the job is done. The CDN or server cache can still serve the old page.
• Disabling the security plugin to see if it helps. Confirm that it blocked the request first. Otherwise you have removed protection and learned nothing.
• Disabling plugins on a live store at a busy hour. Customers lose the features those plugins provide while you test.
• Changing PHP because the site is slow. A PHP change is a compatibility project, not a speed fix. Test it on staging.
• Restoring a full backup first. A restore overwrites every order, form entry and edit made since the backup was taken. Rolling back one plugin keeps them. If you do need a restore, how to restore a WordPress site from backup covers what to protect first.
• Changing several things at once. If the site comes back, you won’t know which change fixed it.

When to stop and get help

Stop doing it yourself in any of these situations:

• You are locked out of both wp-admin and your hosting files.
• A live checkout is failing and you have no staging copy you can safely test payments on.
• There are signs of a compromise: redirects you didn’t add, admin users you don’t recognise, or browser warnings.
• Database errors continue even though the credentials are correct.

Whoever takes the job needs the same information either way:

• the URL;
• the exact action that fails;
• when it last worked;
• what changed in between;
• the relevant lines from the error log.

Get the scope and any extra charges in writing before work starts. “Investigation” means different things to different providers.

If you’d rather describe the symptom in chat than trace it yourself, SiteSelf’s agent can do WordPress troubleshooting and bug fixes on your existing site, using hosting access for file and code work, and reports what it changed and checked.

Frequently asked questions

How do I find which plugin is causing the problem?

Disable all plugins, then turn them back on one at a time, repeating the exact action that failed after each one. Switch to a default theme too if the problem survives. Do this on staging for a store, because disabling plugins on the live site removes features customers rely on.

Does updating WordPress fix every security issue?

No. Core updates cover core. Plugins and themes update separately. PHP is updated on the server by your host. A dashboard that says everything is up to date tells you nothing about the PHP version running your site.

Should I turn on automatic plugin updates?

For well-maintained plugins on a simple site, auto-updates close security holes faster than you would by hand. On stores and sites with custom layouts, an update can break checkout or a template without warning, so test those updates on staging first. Either way, keep a backup you know you can restore.

Why did my site suddenly slow down?

“Slow” is a symptom with several possible causes: a plugin, large images, the host, caching, the theme, external scripts or the database. Measure the page with PageSpeed Insights before you change anything or pay for optimisation. Turning plugins off doesn’t always reveal the cause.

Can two plugins that work fine on their own break the site together?

Yes. Some conflicts only appear when two specific plugins, or a plugin and a theme, are active at the same time. That’s why the conflict test turns plugins back on one at a time instead of judging each plugin alone.

Can my host fix it?

Hosts handle server problems: database outages, memory ceilings, PHP versions and missing server modules. Most won’t debug a plugin conflict, and some charge for investigation. Ask your host to confirm your account’s limits and check the server logs, then take that information to whoever fixes the site.

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.

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.