Blog

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.