Blog

A customer sends a screenshot that says “SSL handshake failed.” The site loads fine on your laptop, the certificate dashboard says valid, and nobody has touched the theme. Don’t reinstall the certificate or start deactivating plugins yet. A WordPress site has at least three connections that can fail this way, and each has a different fix and a different person who can fix it.

An SSL handshake is the negotiation two machines go through before they send each other encrypted data. The protocol is really called TLS now, but the old name stuck. The two sides have to agree on a protocol version and a cipher, and the client has to accept the server’s certificate for the hostname it asked for. All of this happens before WordPress sees the request. So when the handshake fails on page load, a plugin or theme setting is rarely the fix.

Which connection failed? Start with where the message appeared

Where the error shows up tells you more than its wording does. Match what you see to one of these rows before you touch anything.

Where you see it	What it looks like	Connection that failed	Who usually fixes it
A Cloudflare-branded error page	“Error 525: SSL handshake failed”	Cloudflare to your server	Your host
Site Health, a plugin log, a failed payment, licence activation or import	cURL error 35	WordPress to another service	Your host, sometimes the remote vendor
The browser, for every visitor	ssl_error_rx_record_too_long or a certificate warning	Browser to your server	Your host
The browser, on one device or network only	A handshake or certificate error that others don’t see	Browser to your server	The visitor’s device or network

Write down four facts: the exact message and when it happened, whether it hits everyone or one device, whether a CDN or proxy like Cloudflare sits in front of the site, and whether it fails on page load or only on an outbound action such as checkout or email. If the browser can’t find the site at all, that is a DNS problem, not a handshake problem. The guide to fixing DNS_PROBE_FINISHED_BAD_CONFIG errors covers that case.

Cloudflare Error 525 points at your server, not WordPress

Cloudflare’s Error 525 documentation defines it as a failed TLS handshake between Cloudflare and your origin server. It can only happen when the zone’s SSL/TLS mode is Full or Full (strict). Cloudflare lists four causes: no valid certificate on the origin, port 443 (or your configured secure port) closed, no SNI support, and no cipher suite both sides share.

That explains why the padlock can look fine while the site is down. Visitors see Cloudflare’s edge certificate. A 525 is about the certificate on your own server, which visitors never see. On WordPress sites the usual cause is a certificate on that server that expired, went missing after a migration, or was issued for a different hostname.

1. Test the origin directly, keeping your hostname. With your server’s IP in place of the example address, run curl -v --resolve example.com:443:203.0.113.10 https://example.com/ or openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts. Check whether the connection completes, the certificate’s dates, the names it covers, and whether the chain verifies (Verify return code: 0 (ok)). Don’t leave out -servername. Without SNI, a shared server can hand back its default certificate and send you down the wrong path.
2. If there is no valid certificate, install one for the exact hostname. Use a Let’s Encrypt certificate through your host, or a Cloudflare Origin CA certificate. Cloudflare suggests the Origin CA option when the origin has no certificate at all.
3. If the connection never gets as far as a certificate, ask the host to check that something is listening on port 443, that no firewall is dropping Cloudflare’s requests, and that SNI and cipher settings are in place.
4. If the error comes and goes, compare the failure times with the origin’s SSL error logs, as Cloudflare recommends. Twenty good responses in a row do not prove the problem is gone.
5. Once the origin has a valid certificate, set the mode to Full (strict). Full encrypts the connection but does not validate the certificate. Full (strict) validates it and accepts either a public CA certificate or a Cloudflare Origin CA certificate.

Pausing Cloudflare, or switching the DNS record from proxied to DNS-only, is a good test. If the site loads over HTTPS with the proxy off, the origin is reachable and the problem is in the Cloudflare-to-origin leg. Treat it as a test only. Fix HTTPS at the origin, then turn the proxy back on.

Why switching to Flexible is the wrong fix

Cloudflare’s Flexible mode sends traffic from Cloudflare to your server over plain HTTP. The 525 goes away because no handshake is left to fail. The broken certificate is still broken, and the traffic between Cloudflare and your host is now unencrypted. If your server or an SSL plugin redirects HTTP to HTTPS, every request bounces back and forth in a redirect loop that WordPress can’t break. Dropping from Full (strict) to Full lowers security in the same way without repairing anything.

cURL error 35 means WordPress can’t reach another service

Here the site loads for visitors. What fails is a request your server makes to somewhere else: a payment gateway, a licence server, an update check, an SMTP relay or a webhook. Common versions of the message include OpenSSL SSL_connect: Connection reset by peer, wrong version number, Peer reports incompatible or unsupported protocol version and gnutls_handshake() failed.

Really Simple Security’s article on cURL error 35 says the error appears when PHP’s cURL library can’t make the SSL connection. Its first step is updating cURL and PHP, and its second is asking your host. Practitioners add a few more causes: an outdated OpenSSL library or CA bundle, a remote service that requires a newer TLS version than your server offers, and a firewall, mod_security rule or security product that interferes with outbound traffic.

That last cause can come from a surprising place. In one WordPress.org support thread, email failed on more than ten sites, and the cause turned out to be Norton 360’s outbound email scanning.

Two checks narrow it down:

• Site Health. Go to Tools > Site Health. The WordPress support handbook explains that Health Check tests two separate things: whether visitors reach the site securely, and whether WordPress can talk securely to outside services. A failure in the second test confirms an outbound problem.
• One plugin or all of them. If only one plugin’s feature fails, such as a social login or a single licence activation, while updates and other connections work, the cause is probably that plugin or its vendor’s server. Contact the vendor early. If the remote end is the problem, nothing you change on your own site will fix it.

Don’t make the error go away by turning off certificate verification, for example by setting sslverify to false or disabling CURLOPT_SSL_VERIFYPEER. Your server would then accept any certificate, including a forged one, on the same connections that carry payments and licence keys.

When the browser refuses the connection

Every visitor sees it

WooCommerce’s documentation for ssl_error_rx_record_too_long describes a browser that expected HTTPS and got unencrypted data back. The listed causes are no certificate, a wrong port setting, a misconfigured Apache VirtualHost for port 443, or WordPress URLs switched to HTTPS before the server could serve HTTPS. That last one can trigger the error on every page request.

The order matters. Your host gets HTTPS working on the server first. Only then do you change the WordPress Address and Site Address under Settings > General to https://, which is the sequence WooCommerce’s SSL and HTTPS guide gives. If those two fields are greyed out, WordPress.org’s Settings General documentation explains why: WP_HOME or WP_SITEURL is defined in wp-config.php, so you edit them there. The article on securing Apache for WordPress walks through the full HTTPS sequence on an Apache server.

Only one device or network sees it

If the site works everywhere except one phone or one office, look at that phone or office. Check that the device’s clock is correct, update the browser, and try a private window with extensions off. Then try mobile data instead of the office Wi-Fi. Antivirus software and corporate networks that inspect TLS traffic can swap in their own certificates or break the negotiation. Turn security software off only for a quick test. If that was the cause, allowlist the site and switch the protection back on.

Lookalikes that are not handshake failures

“Not Secure” after installing a certificate. This is mixed content. The page is HTTPS but still loads some images, scripts or stylesheets over http://. WooCommerce’s fix is to change those URLs to HTTPS or to relative paths. A database search-replace does this more cleanly than a plugin that rewrites URLs on every page load.

Too many redirects. Two layers are forcing HTTPS against each other. WooCommerce’s SSL guide names Easy HTTPS Redirection conflicting with Force SSL as one example. Pick one layer to handle HTTPS and switch off the others.

An expired-certificate warning. Renew the certificate, then find out why automatic renewal failed. A common reason is a firewall rule that closed port 80, which Let’s Encrypt’s HTTP-01 challenge needs.

When to stop and hand it to your host

Stop once the fix involves installing a certificate, changing server or VirtualHost configuration, opening a port, changing a firewall, or upgrading PHP, cURL or OpenSSL. That work belongs to your host or server admin, and a settings change in WordPress can’t stand in for it. Send them a ticket they can act on:

• the affected hostname and the exact error text, with times and time zone;
• whether it hits every visitor or one device, and on page load or on an outbound action;
• your Cloudflare SSL/TLS mode, and whether the site loads with the proxy paused;
• the output of the curl or openssl test and the Site Health message.

If you’d rather not run these checks yourself, SiteSelf can take on fixing errors on your WordPress site from a chat request. It uses hosting (SSH) access for server-side work, reports what it found and checked, and does not change settings in your Cloudflare account. Once the site is back, add certificate expiry and renewal checks to your WordPress website care plan so the next expiry doesn’t take the site down first.

Frequently asked questions

Do I need a certificate on my server if Cloudflare already gives me one?

Yes, if you use Full or Full (strict), and you should use Full (strict). Cloudflare’s certificate only covers the connection between visitors and Cloudflare. Your server needs its own certificate for the connection from Cloudflare to the origin, either from a public CA such as Let’s Encrypt or a Cloudflare Origin CA certificate.

Can an SSL plugin fix a handshake failure?

No. The handshake happens before WordPress runs, so a plugin can’t repair a missing certificate, a closed port or an outdated OpenSSL. SSL plugins can help with mixed content and redirects. Stacking several of them is a common cause of redirect loops.

Why does the 525 only happen some of the time?

Intermittent 525s usually mean something between Cloudflare and the origin drops some connections, such as a firewall, rate limiting or an overloaded server. Note the exact times of failures and ask your host to check the origin’s SSL error logs for those times. Don’t call it fixed after a short run of successful loads.

Should I leave the Cloudflare proxy turned off?

Only while you test. Turning the proxy off tells you whether the origin works on its own. It doesn’t fix anything, and you lose whatever Cloudflare was doing for the site. Get HTTPS working at the origin, then turn the proxy back on with Full (strict).

Is it safe to change the site URLs back to http:// to get the site loading?

It can get you back into the dashboard, but it is a stopgap. Visitors lose HTTPS, and you will have to redo the switch later in the right order. A better move is to have the host fix the certificate and VirtualHost, then keep the URLs on https://.

“Login not working” covers about ten different failures. WordPress might reject your password. It might accept it and bounce you back to the form. The login page might be missing, a security plugin might have locked you out, or the site might be crashing before the form even loads. Each of these has a different fix.

The most common mistake in support threads is resetting the password again and again. That only works when the password was the problem. So start with one question: does WordPress reject your credentials, or does it accept them and then fail? If you aren’t sure you’re even on the right login page, our guide on how to sign in to WordPress covers the default addresses first.

Which kind of login failure do you have?

Watch what happens after you click Log In. Each symptom points to a different layer of the site.

What you see	Where the problem usually is	Start here
“The password you entered is incorrect” or “unknown username”	The account or the password	Basic checks, then a password reset
The form reloads or returns to itself, often with reauth=1 in the address	Cookies, site URLs, cache, CDN or a plugin	The loop section below
“Cookies are blocked or not supported by your browser”	Authentication cookies	The loop section below
“Too many failed attempts”, a greyed-out button, a CAPTCHA that never passes	A security or login plugin	The security plugin section below
/wp-admin returns a 404 or sends you to the homepage	A login-hiding plugin, redirect rules or the host	The hidden login page section below
“There has been a critical error” or a blank white page	A PHP fatal error	The fatal error section below
“Error establishing a database connection”	The database or the server	Your host. A password reset can’t help here.

Run these checks before changing anything

These checks take two minutes, you can’t break anything with them, and they tell you whether the problem is in your browser or on the site.

1. Check the username or email. WordPress’s documentation says usernames and passwords are case-sensitive. Your public display name isn’t your username.
2. Check autofill. A password manager may be filling in an old password, especially if you reset it recently.
3. Try a private window, then a second browser. If login works there, the cause is your browser’s cookies or an extension. If it fails everywhere and for other admins too, the problem is on the site.
4. Use the exact address the site normally uses. Same domain, same HTTPS, same www or no www. If you log in at one version and the site lives at another, the browser can drop the cookie.
5. Stop retrying for 15 minutes if you’ve failed several times. Lockout plugins can extend the block with every new attempt.

If WordPress rejects your password

Use the “Lost your password?” link on the login page. If the email never arrives, check spam first. WordPress’s troubleshooting FAQ says site email can fail when the server’s mail setup isn’t configured. The email may also be going to a different address from the one you expect. The admin notification address in Settings and your user account’s email are separate fields, and they don’t have to match.

Also check that you’re using the right account. WordPress.com and a self-hosted WordPress site have separate logins. Your host, your domain registrar and WooCommerce.com each have their own login as well.

If the reset email doesn’t work, your hosting account is the fallback. Most hosts let you reset or create WordPress users from their control panel. With SSH and WP-CLI you can do it directly:

wp user list --fields=ID,user_login,user_email,roles
wp user update 1 --user_pass='temporary-long-password'

Log in, then set a proper password from your profile right away, because the temporary one is now in your shell history. Editing user_pass in phpMyAdmin is the last resort. DreamHost’s knowledge base calls that method “no longer recommended”. Old recipes that tell you to paste an MD5 hash are a common source of failed attempts.

If the reset worked but the old password still seems to apply, the site may have a server object cache. DreamHost documents this on DreamPress Pro, where running wp cache flush over SSH clears the stale data.

If the right password sends you back to the login form

This failure has nothing to do with the password. WordPress accepted your credentials but couldn’t set or read its login cookie, or a redirect sent you somewhere else first. WordPress’s Advanced Administration Handbook lists these causes:

• browser cookies are disabled, or a plugin conflicts with the login
• the cookie domain doesn’t match the site
• some URLs use HTTP and others HTTPS
• a server cache is serving the login page
• the WP_HOME and WP_SITEURL constants conflict, or the home and siteurl database options don’t match
• redirect rules at a CDN, proxy, Nginx, Apache or the host

Check the site URLs first, especially after a move

Migrations are a common trigger. Duplicator reviewed more than 8,000 of its support tickets and found that nearly 1 in 10 migration tickets were wp-admin lockouts after a successful move, usually from URL mismatches or redirect loops. Read the stored values over SSH:

wp option get home
wp option get siteurl
grep -E "WP_HOME|WP_SITEURL|COOKIE_DOMAIN" wp-config.php

WordPress’s wp-config documentation explains the two settings. WP_SITEURL is where the core files live and WP_HOME is the public address. Constants in wp-config override the database options. Don’t just set both to the same value. On sites installed in a subdirectory they are meant to be different. If old URLs are left in the content, back up first and preview the fix before running it:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run

Then look at caches you can’t clear from the browser

Clearing your browser cache doesn’t touch the host’s page cache, a caching plugin, a CDN, or an object cache in wp-content/object-cache.php. Exclude wp-login.php and any custom login address from page caching, then clear the server cache. In one Reddit case the loop came from a CDN the host had switched on. Turning it off fixed the loop. If someone else controls your DNS or CDN, for example a former developer’s Cloudflare account, changes inside WordPress may not help.

“Cookies are blocked due to unexpected output”

This variant means something printed output before WordPress could send its cookie headers. In one resolved WordPress.org thread, the cause was two blank lines at the end of the theme’s functions.php. The poster had already allowed cookies and cleared them, and neither helped. Look for whitespace after a closing ?> in functions.php, wp-config.php or a recently edited plugin file.

When a security or login plugin is the cause

Lockout, CAPTCHA, 2FA and login-hiding plugins protect the login page, and they also cause many of the lockouts people report. Two resolved WordPress.org threads show the pattern:

• A Wordfence user could enter a username and password, but the Login button greyed out. The cause was mismatched reCAPTCHA keys. Updating the keys fixed it.
• A site running Wordfence 2FA looped back to the form and never showed the code field. Reinstalling Wordfence and redoing the QR code didn’t help. Deactivating a second plugin, Invisible reCaptcha, did.

Without dashboard access, open your host’s file manager or SFTP, go to wp-content/plugins, and rename the suspect plugin’s folder, for example wordfence to wordfence-off. WordPress deactivates a plugin whose folder it can’t find. Log in, fix the setting that caused the problem, and turn the plugin back on. Don’t leave it off as the fix.

If the login page itself has disappeared

Plugins such as WPS Hide Login move the login page on purpose. Their documentation says that while the plugin is active, /wp-login.php and /wp-admin become inaccessible, so guessing the default address won’t work. The custom address is stored as whl_page in the options table, or in sitemeta on multisite:

wp option get whl_page

Deleting or renaming the plugin’s folder brings back the default login. A cached 404 or a short redirect loop can follow, so clear the cache before assuming it failed.

How to find a plugin conflict without breaking the live site

If you can still reach any admin screen, use the Health Check & Troubleshooting plugin. Its troubleshooting mode turns plugins off and switches to a default theme for your user only. Visitors keep seeing the normal site while you turn plugins back on one at a time.

If you’re locked out completely, rename folders one at a time, starting with whatever changed most recently. Renaming the whole plugins folder gets you in fastest, but it also switches off forms, checkout and security for every visitor, and it doesn’t tell you which plugin was at fault. Updates are a frequent trigger. In one thread, WPO365 version 42.2 sent /wp-admin to the homepage, and rolling back to 41.3 fixed it. Our guide to fixing WordPress plugins that stop working covers the isolation method in more detail.

When the login page shows an error instead of a form

A critical error message or a white screen is a PHP fatal error, not a login problem. WordPress’s Recovery Mode documentation says WordPress can email the admin a special login link after some fatal errors. Through that link you can deactivate the failing plugin or theme. It only works for some fatal errors, so if no email arrives, read the PHP error log before you start guessing. The file path in the error usually names the plugin. Our WordPress white screen guide walks through it.

“Error establishing a database connection” means WordPress failed before it could show the form. Check the database name, user and password in wp-config.php against your hosting panel, and contact your host if they match.

Customers can’t log in to a WooCommerce store

Store customers log in through a different path from admins. WooCommerce’s documentation says the My Account page is set under WooCommerce → Settings → Advanced, and that page needs the [woocommerce_my_account] shortcode to show the sign-in form. For Social Login, WooCommerce lists these causes:

• wrong provider keys
• default (plain) permalinks
• cURL missing on the server
• cached authentication requests

Exclude /wc-api/*, the wc-api query argument and wp_woocommerce_session* cookies from caching. Facebook login also fails when iThemes Security’s “Filter Long URL Strings” is on.

When to stop and get help

Stop and get help in any of these situations:

• The fix needs SSH, the database, server logs, DNS or CDN settings, and you don’t have that access.
• Plugin isolation didn’t identify a cause.
• You see admin accounts, must-use plugins or redirects that nobody recognises. Treat that as a possible compromise rather than a login bug, and read our guide to WordPress malware removal before changing anything.

Ask the original developer or agency first, then your host. Also check now who owns the domain, the hosting and the CDN account. A developer who disappears with your registrar login is a bigger problem than any login loop.

If you’d rather not do this yourself, SiteSelf handles WordPress bug fixes like this one. You describe the symptom in chat. It needs hosting (SSH) access for file, cache and log work, says what it’s about to change and whether it can be undone, and reports what it checked afterwards.

Frequently asked questions

Is the login URL /wp-admin or /wp-login.php?

Both work on a standard install. Visiting /wp-admin while logged out redirects to wp-login.php. If WordPress lives in a subdirectory, the path includes that folder. A login-hiding plugin replaces both with a custom address.

Login works on my phone but not my laptop. Why?

If one device works, the site is fine and the problem is local to the other device. Clear that browser’s cookies for your domain, turn off extensions, and check security software or a VPN. A loop that happens on every device and for every admin points back to the site.

Should I delete .htaccess to fix an admin 404 or 403?

Rename it, don’t delete it. Renaming lets you test whether a rule in it is the cause and put it back in seconds. Deleting it removes your permalink rules and any security rules your host or plugins added. Once you’re logged in, regenerate the WordPress section by saving Settings → Permalinks.

Why does my AI tool or app reject my admin password?

Access through the REST API uses Application Passwords, not your login password. Create one under Users → Profile → Application Passwords and give it to the tool. Retrying the admin password will keep failing however correct it is.

Does changing the salt keys in wp-config.php fix a login loop?

Changing the salts logs everyone out, which helps after a suspected compromise. It rarely fixes a loop caused by URLs, caching or a plugin. In one Reddit thread a team changed the salts and turned on debugging without effect, and a login-related plugin turned out to be the cause.

Is it safe to edit wp-login.php?

No. WordPress removed old advice that involved changing core files, and core updates overwrite any edits you make there. Every fix in this article works through settings, plugins, wp-config.php or the host.

The page loaded an hour ago. Now it shows “500 Internal Server Error”, “HTTP ERROR 500” or nothing at all. The message names no file and no plugin, and turning plugins off at random can turn one failing request into a whole-site outage.

Treat the 500 as a symptom. You fix it in three moves: find the log entry for the failing request, make the one change that entry points to, then confirm the original request works again.

What a 500 tells you, and what it doesn’t

A 500 tells you the server hit a problem it couldn’t recover from while building the response. It doesn’t tell you why. WordPress.org’s Advanced Administration Handbook lists several possible causes behind the same message: a corrupted .htaccess file, a plugin or theme problem, PHP running out of memory, and damaged core files. Hosts add permissions, PHP version mismatches, database limits and server configuration.

Where the error shows up is your first clue. It can take down the whole site, only /wp-admin, or a single action: saving WooCommerce settings, publishing in a page builder, uploading media through async-upload.php, or checkout. If a PHP fatal error is caught by WordPress, you may see “There has been a critical error on this website” instead of a bare 500. If the screen is simply blank, our guide to fixing a WordPress white screen covers that version of the problem.

Why the log comes before the plugin list

The log entry is the diagnosis. Everything before it is guessing. WordPress, WooCommerce and the major hosts all give the same order:

1. Write down the failing URL and the time. Note whether you were logged in and what you clicked.
2. Reproduce it once. Now you have an exact timestamp to match in the log.
3. Open the server’s PHP error log. On most hosts it sits in the control panel under a name like “Errors” or “Logs”. If you can’t find it, ask the host for the entries at your timestamp.
4. On a WooCommerce store, also check WooCommerce → Status → Logs. WooCommerce’s documentation says this log records PHP fatal errors. Look for a log named fatal-errors.
5. Read the file path and line number. A path inside wp-content/plugins/some-plugin/ tells you which plugin to look at.

If the host log is out of reach and WordPress still loads far enough to run, turn on WordPress’s own log in 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 );
@ini_set( 'display_errors', 0 );

Errors then go to wp-content/debug.log and visitors don’t see them. WordPress’s debugging documentation says these tools are meant for local and staging sites and recommends logging over displaying. Turn the lines off when you’re done, because the log can hold file paths and request data.

An empty debug.log tells you something too. In one WordPress.org support thread, the 500 happened before WordPress loaded, so WordPress never had the chance to write anything. That points you back to the server log.

Which fix matches which log line

What the log shows	Likely cause	First move
Fatal error in /wp-content/plugins/name/	That plugin	Rename its folder, then roll it back or update it
Fatal error in /wp-content/themes/name/	Theme or a recent code edit	Revert the edit or switch to a default theme
“Allowed memory size of … bytes exhausted”	PHP memory	Raise the limit, or ask the host to
“Invalid command” or “Request exceeded the limit of 10 internal redirects” pointing at .htaccess	Rewrite rules	Back up the file, rename it, regenerate it
“Permission denied”	Permissions or ownership	Reset to the host’s recommended values
Failed opening a file in wp-includes	Missing or damaged core file	Replace wp-admin and wp-includes
Nothing from WordPress at all	Server, database or firewall	Escalate to the host with URL and time

Nobody publishes measured data on which cause is most common. Support threads lean toward plugins, and some tutorials name .htaccess first. The sections below follow how often each one comes up in support threads.

A plugin or theme, usually right after an update

This is the pattern support forums see most. In one WordPress.org thread, updating Elementor to 3.22.0 produced a 500 only when editing a WooCommerce single-product template. The homepage still edited fine. Deactivating the ReviewX plugin made it go away, and reinstalling it did not.

If wp-admin works, deactivate the suspect named in the log, or roll it back to the last version that worked. If wp-admin is down, connect over SFTP or the host’s file manager and rename wp-content/plugins/plugin-name to plugin-name-off. WordPress deactivates a plugin whose folder has disappeared. No suspect in the log? Rename the whole plugins folder, then bring plugins back one at a time. Our guide to fixing plugins that stop working walks through that routine.

On a live store, turning plugins off breaks things for customers. The Troubleshooting plugin gives you a Troubleshooting Mode that disables plugins for your session only. Two cautions. Deactivating a plugin can trigger its own 500 when other plugins depend on it. And having everything switched off is a diagnosis, not a fix. Once you’ve found the culprit, turn the rest back on.

A broken .htaccess file, on Apache only

Download a copy of .htaccess from the site root, then rename the file on the server to .htaccess-old. If the site comes back, go to Settings → Permalinks and click Save Changes. WordPress then writes fresh rewrite rules. Copy any custom redirects or security rules back from your saved copy one block at a time, and test after each one.

This only applies on Apache. On Nginx, WordPress doesn’t read .htaccess, and renaming it changes nothing. If the file keeps breaking after you fix it, something keeps rewriting it. Look at which plugin writes to it, often a security or cache plugin, and fix that.

PHP memory exhausted

Only raise memory when the log says “Allowed memory size … exhausted.” WordPress’s wp-config documentation gives the setting as define( 'WP_MEMORY_LIMIT', '128M' );. The host’s PHP memory_limit still caps it, so if your number has no effect, ask the host. A site that already has 512M or more and still runs out usually has a plugin stuck in a loop or loading too much data. Find that plugin rather than raising the limit again.

File permissions

WordPress’s permissions documentation gives 755 or 750 for directories and 644 or 640 for files, and says never to set directories to 777. A recursive 777 is a security hole, and it can still leave the wrong user owning the files. Use the values your host documents.

Damaged core files

When the log names a missing file in wp-includes or wp-admin, download the same WordPress version your site runs. Then replace those two folders. Leave wp-content and wp-config.php alone, since they hold your site.

Causes below WordPress

Some 500s never show up in WordPress logs. In one WordPress.org thread, a 500 that appeared only in wp-admin after a plugin update came from a database write hitting MySQL’s max_allowed_packet limit, not from a plugin bug. In an agency case study, a database on shared hosting had reached its 2 GB cap because one plugin’s logs were never rotated. Clearing the data would only have bought time. Changing the plugin’s logging settings stopped it from coming back.

Other causes in this group: upload and request-size limits during imports, firewall rules such as ModSecurity rejecting legitimate requests, and underpowered hosting failing on and off under traffic. These are the host’s to confirm.

How to tell it’s actually fixed

A homepage that loads proves very little. Retest the exact request that failed. Then check the admin screen your team uses and one real transaction, such as a form submission or a test order. Read the log again for new fatal errors. Clear page and CDN caches separately: a cached error page can outlive the fix, and a cached good page can hide one that’s still broken. Turn debugging off, and write down what you changed and how to undo it.

Check Google Search Console as well. Google’s crawler documentation says Google slows crawling when it gets 5xx responses and can eventually drop URLs that keep returning server errors. A plugin can return 500s only to bots or scripts, so “it works for me” doesn’t mean Google sees a working page. The URL Inspection live test shows what Google gets.

When to stop and get help

Stop when the WordPress logs are clean, when the log points at the database, PHP-FPM or a firewall, or when you can’t reach the files at all. Send the host the failing URL, the exact time you reproduced the error, and what you’ve already ruled out. Ask them to check the server log for that moment, your resource limits, and any firewall rule that matched. Before you restore a backup, read what your backup plugin actually covers, and make sure you aren’t restoring from the same source that broke the site.

Access is the usual bottleneck. A freelancer with only a wp-admin login can do nothing once wp-admin itself returns 500, so get SFTP or control-panel access before the next incident. If you’d rather hand the diagnosis off, SiteSelf can find and fix site errors through chat. For a 500 that locks you out of wp-admin, it needs hosting (SSH) access, not just its connector plugin.

Frequently asked questions

Is a 500 error caused by my browser?

No. A 500 comes from the server. Clearing your browser cache or trying another device is a cheap way to rule out a stale cached page, but it won’t fix the fault behind the error.

Why does wp-admin return 500 when the front end works?

Admin pages run code the public pages don’t, such as settings screens, update checks and database writes. Don’t assume it’s a plugin. In one WordPress.org case the cause was a MySQL max_allowed_packet limit. The log tells you which it is.

Why does the 500 only happen at checkout?

Checkout calls payment, shipping and anti-spam code that other pages never load. Check WooCommerce → Status → Logs. Then open the browser’s developer tools, go to the Network tab and run the checkout again. The request marked 500 shows you which endpoint is failing.

Is “There has been a critical error on this website” the same thing?

They’re related. That message is WordPress catching a PHP fatal error and showing a friendlier page. WordPress usually emails the admin address a link to a recovery mode, where you can pause the plugin or theme that crashed.

Should I just switch PHP versions?

Only when the log shows a compatibility error, such as a function that doesn’t exist in your PHP version. Switching without evidence can create new errors in plugins that haven’t been updated for the newer version.

Will deleting .htaccess break anything?

It removes any custom redirects, caching rules and security rules stored in the file. Download a copy first, regenerate the WordPress rules from Settings → Permalinks, then add your custom rules back one block at a time.

Your contact page loads fine, but clicking Submit returns “405 Method Not Allowed”. Or the store looks normal until an integration tries to update a product and gets the same answer. The site isn’t down. One request is being refused, and the code tells you what kind of refusal it is.

What does a 405 tell you, and what doesn’t it tell you?

Every web request is a URL plus a method. GET reads. POST submits. PUT and PATCH update, DELETE removes, and OPTIONS asks what is allowed. A 405 means the server reached the URL and recognised the method, but that resource doesn’t accept it. RFC 9110, the HTTP standard, defines the status this way. It also requires the server to send an Allow header that lists the methods the resource does support.

That narrows the problem down without naming a culprit. On a WordPress site, the refusal can come from the request itself, WordPress routing, a plugin, leftover custom code, a cache, a security layer or the web server’s configuration. The fix depends on which of those said no.

Status	What it means	Where to look
404 Not Found	The URL doesn’t resolve to anything	Permalinks, rewrite rules, the address itself
403 Forbidden	The request reached something that refused access	Permissions, security rules, logins
405 Method Not Allowed	The URL exists but rejects this method	The method sent versus the Allow header
501 Not Implemented	The server doesn’t support the method anywhere	Server software and configuration

The 404 comparison is the one people get wrong most often. Much of the standard WordPress troubleshooting advice is written for 404s, and editing your custom WordPress 404 page won’t touch a method mismatch.

How do you find the request that is failing?

Capture the request before you change any setting. If you change settings first, you can lose the evidence and leave the cause where it was.

1. Open the page in Chrome, Firefox or Edge and press F12. Choose the Network tab.
2. Repeat the failing action once: submit the form, click Publish, add to cart.
3. Find the request with status 405. It usually isn’t the page address. Look for admin-ajax.php, something under /wp-json/, or the form’s own handler.
4. Note four things: the request URL, the method, the response headers (especially Allow) and the time.

WooCommerce’s guide to troubleshooting AJAX issues uses the same Network-tab method. Then compare the method with the Allow list. If the request sent POST and the header says Allow: GET, HEAD, the request went to a URL that was never meant to take a submission, or something in front of WordPress answered for it.

If you’re comfortable in a terminal, repeat the exchange outside the browser:

curl -i -X POST https://example.com/wp-admin/admin-ajax.php

The -i flag prints the response headers. A bare curl request has no form body, cookies or nonce, so it only shows which layer answers, not whether the real submission would succeed. If Allow is missing, or the response headers name a cache or a firewall, then something other than WordPress probably produced the 405. MDN’s 405 reference covers the header in more detail.

Two cautions. Don’t keep resubmitting a checkout while you investigate. And don’t “fix” the request by switching POST to GET. A method that is allowed is only correct if it matches what the endpoint is for.

When is a 405 not a problem at all?

A browser address bar always sends GET. Paste wp-comments-post.php, admin-ajax.php or a form’s processing script into it, and a 405 or an error page is normal behaviour, because those URLs exist to receive POST. A 405 only matters when it shows up during the real action: the comment form submitting, the editor saving, the integration calling.

What causes a 405 on a WordPress site?

Nobody has published figures on which cause is most common, so be wary of any guide that claims to know. The list below runs from cheapest to check to most involved, and leans on cases where someone reached a confirmed fix.

The request uses the wrong method for that endpoint

WordPress REST routes are specific to each method. The REST API Handbook’s key concepts page explains that one route maps to separate endpoints by method. The posts route lists posts on GET and creates one on an authenticated POST. A route that accepts POST doesn’t automatically accept PUT or DELETE. Check the documentation for that exact endpoint.

For WooCommerce integrations, check three things in the WooCommerce REST API documentation. The permalink structure can’t be Plain. The API key needs Write or Read/Write permission to change data. And the integration must not depend on the legacy REST API, which was removed from WooCommerce core in version 9.0. Install the separate WooCommerce Legacy REST API plugin only if the integration really calls the legacy API. It isn’t a general 405 fix. Seeing JSON at /wp-json/ only proves the API index responds. It doesn’t prove the route you need works.

A cache is answering a POST with a static page

Forms or add-to-cart buttons that fail only when caching is on point here. The server hands a cached HTML file to a request that is trying to submit data, and a static file can’t accept POST. In one WordPress.org support thread, Gravity Forms and WooCommerce AJAX requests returned 405 on a server running WP Rocket behind WordOps Nginx rules. The owner fixed it by replacing those Nginx rules with the SatelliteWP rocket-nginx configuration, and kept WP Rocket.

That is one case, not proof that WP Rocket causes 405s. The lesson is narrower: when switching off a cache plugin “fixes” it, the real fault may be the server rules around the plugin. If you can’t change the server rules, exclude the affected URL. In WP Rocket that is Advanced Rules, then Never cache URL(s), one URL or path per line. WP Rocket notes that an excluded page also loses its other optimizations. Keep the exclusion narrow, and remember that a pattern like /(.*) excludes every URL. If your host runs the cache, ask the host to add the exclusion.

A firewall or security rule is refusing the method

ModSecurity, a host firewall, Cloudflare rules or a security plugin can return a 405 that looks like a WordPress fault. Typical signs: the block editor or Elementor fails to save, widgets won’t update, or plugin updates fail with “Download failed. Method Not Allowed.” If the same failure appears on several sites on one server at once, the block is almost certainly upstream of WordPress.

WordPress’s loopback guidance gives a sensible order. Test plugin and theme conflicts first. If that changes nothing, ask the host about firewall or security rules, DNS, SSL and HTTP authentication. If you switch a security layer off to test, do it briefly, on staging where you can, and switch it back on. Leaving protection off is not a fix. The fix is a rule that allows the specific path and method.

The web server only allows certain methods

Server software can restrict methods directly. On IIS, the PHP handler in web.config lists the verbs it accepts. In a WordPress.com forum case, a WooCommerce setup-wizard 405 cleared once the handler allowed all verbs (verb="*"). An earlier attempt with a stripped-down web.config broke the site until the inherited handler settings came back. On Apache, look for Limit or LimitExcept blocks. Nginx has its own method rules.

Edit only the rule that covers the failing path. Don’t paste .htaccess examples into an Nginx or IIS server, because they won’t be read. Our guide to Apache web server security covers which directives belong where.

A plugin, a theme or leftover custom code

Plugins can register routes with narrow methods or filter REST requests. Test the way the Manage Plugins documentation describes: deactivate, then reactivate one plugin at a time, then try a default theme. Do this on staging for a live store. Our guide to fixing plugins that aren’t working walks through it.

On sites with history, also check code a previous developer left behind: snippets in the theme’s functions.php, a must-use plugin, or a filter on rest_pre_dispatch or rest_authentication_errors. “The host says nothing is blocked” doesn’t end the search. Custom code can block PUT and DELETE while GET and POST still work.

Which popular fixes don’t fix a 405?

Saving permalinks. Visiting Settings > Permalinks and clicking Save flushes rewrite rules. If .htaccess is writable, WordPress also updates it, according to the Permalinks screen documentation. That repairs broken pretty URLs, which show up as 404s. It’s harmless to try, but it doesn’t change which methods a URL accepts.

Disabling the REST API. The REST API Handbook’s FAQ warns against it, because WordPress admin features depend on the API. You would swap one broken request for a broken editor.

Editing core files or turning off auto-updates. Core edits disappear at the next update, and turning off updates leaves known security holes open.

Deactivating everything on a live store. This tells you a combination fails, not which layer is at fault, and customers see the broken site while you test.

Why does a 405 on a public page hurt search?

Google’s documentation on how HTTP status codes affect its crawlers says Google doesn’t index URLs that return a 4xx status other than 429. Indexed URLs that start returning one are removed over time. A 405 on a form endpoint doesn’t matter for search. A 405 on a product or landing page, caused for example by a firewall rule that misfires on GET, takes that page out of Google.

When should you stop and get help?

Hand it over when the evidence points outside WordPress (no Allow header, a firewall or cache signature, many sites failing together), when the fix means editing server configuration you can’t easily undo, or when the failing action takes money. Send the host or developer the request URL, method, response headers, timestamp, and a list of what you already tried. That turns a vague ticket into a five-minute log lookup.

If you would rather not trace it yourself, SiteSelf can diagnose and fix broken site errors on request through chat. Code, server and cache work needs hosting (SSH) access, not just the connector plugin.

Frequently asked questions

Is a 405 error caused by the visitor?

Almost never on a WordPress site. It’s classed as a client error because the method didn’t suit the URL, but the request usually comes from the site’s own form, editor or integration. The fix belongs on the site or the server.

Why do GET and POST work but PUT and DELETE return 405?

Something between the client and WordPress is filtering methods: a host or server rule, a security plugin, or custom code hooked into the REST API. In a browser, a cross-origin PUT or DELETE also sends an OPTIONS preflight first, and a server that rejects OPTIONS can produce the failure. Check which of the two requests the Network tab shows failing.

Elementor or the block editor shows a 405 when I publish. What now?

Capture the failing save request in the Network tab. It is usually a POST to admin-ajax.php or a REST route. Many forum threads on this end without a confirmed fix, and rolling back plugins or raising memory rarely helps. Ask your host whether ModSecurity or a firewall rule logged that request.

Site Health says the loopback request failed with a 405. Is that serious?

It can be, because WordPress uses loopback requests to run WP-Cron and scheduled posts. Follow WordPress’s loopback steps: test plugins and the theme, then ask the host about firewall rules, DNS, SSL and HTTP authentication. If deactivating plugins changes nothing, the cause is likely on the server.

Should I install the WooCommerce Legacy REST API plugin to fix a 405?

Only if the integration calls the legacy API. That API was removed from WooCommerce core in version 9.0. For anything else, the plugin adds code without fixing the cause. Check the integration’s documentation or ask its vendor first.