WordPress 500 Internal Server Error: 13 Fixes That Actually Work

Key Takeaways

• Most WordPress 500 errors trace back to a corrupt .htaccess file, a plugin conflict, or an exhausted PHP memory limit.
• Resetting .htaccess, deactivating plugins via FTP, and bumping PHP memory resolve the majority of cases.
• Managed hosting with automated backups, PHP version control, and permission resets prevents most 500 errors entirely.

Your WordPress site loaded fine yesterday. Today it’s showing a 500 internal server error and you can’t even log in to the admin to figure out why. That’s the worst part of this error. It locks you out of the one place you’d normally go to fix it.

The 500 error in WordPress is almost always caused by one of four things:

• a broken .htaccess file
• a plugin or theme conflict
• a PHP memory limit that got hit
• or a corrupted core file

The fastest way to find out which one is yours is to enable WordPress debug logging and read the actual error message. The .htaccess fix alone resolves a large share of cases and takes about two minutes.

This guide walks through 13 solutions in the order you should try them. If the error appeared after a specific event, like a migration, a plugin update, or while saving a page in Elementor, you can jump directly to the relevant section using the table of contents below.

You’ll need an FTP client (FileZilla works well) or your host’s file manager. A WordPress dashboard won’t help here because the dashboard is part of what’s broken.

Let’s get started…

What Is the WordPress 500 Internal Server Error?

The WordPress 500 internal server error means PHP failed before WordPress could finish loading. The server hit a problem it couldn’t recover from, so it sent back a generic 500 status code instead of your homepage.

This isn’t WordPress doing something unusual. The 500 error exists across the web on any server running PHP, Python, Node, or anything else. What makes it confusing in a WordPress context is that the error doesn’t tell you which file, plugin, or theme caused it. WordPress has tens of thousands of moving parts, and any one of them can trigger a fatal error that the server then reports as a 500.

The way the error appears depends on your setup.

On a standard browser request, you’ll usually see a plain 500 page from the server itself.

On newer WordPress installs, you might see the “critical error” page instead. That page is WordPress’s own fatal error handler stepping in to give the visitor a friendlier message before the underlying 500 reaches the browser. The server is still returning a 500 status code in the background. The screen just looks different.

You might also see one of these variations depending on your browser, host, or CDN:

• 500 Internal Server Error
• HTTP 500 Internal Server Error
• HTTP Error 500
• “Sorry, something went wrong”
• “The website cannot display the page, HTTP 500”
• “Currently unable to handle this request, HTTP ERROR 500”

The wording differs. The cause is the same. Something broke server-side before WordPress could load.

One quick clarification before we move on. The 500 is part of a family of 5xx errors. A 502 bad gateway, a 503 service unavailable, and a 504 gateway timeout are all separate problems with their own causes. If you’re actually seeing one of those instead of a 500, the fixes in this guide won’t help you. Check the exact status code in your browser’s developer tools (Network tab) before going further.

Fixing WordPress Errors is Easy With Cloudways!

Try Cloudways WordPress hosting with 1-click install for an error-free experience.

Start Today

Common Causes of the WordPress 500 Internal Server Error

The 500 error in WordPress almost never appears for no reason. Something specific triggered it, and that something usually falls into one of seven buckets. Knowing which bucket your error belongs to cuts your troubleshooting time from hours to minutes.

Here are the causes we see most often when Cloudways support handles 500 errors for WordPress sites.

Cause	What Triggers It	Where to Jump
Corrupt .htaccess file	A plugin update, a manual edit, a security tool, or a botched migration leaves the file with broken rewrite rules	Solution 3
Plugin conflict or fatal error	A newly installed, updated, or auto-updated plugin runs PHP that the server can’t execute, often after a WordPress core or PHP version change	Solution 4
Theme conflict	An outdated theme, a child theme calling missing parent functions, or custom code in functions.php breaks during page load	Solution 5
PHP memory limit exhausted	A heavy plugin, a memory leak, or a large bulk operation (import, backup, image processing) uses more memory than your host allows	Solution 6
Wrong file or folder permissions	A manual file upload, a transferred backup, or a server change leaves files with permissions WordPress can’t read or execute	Solution 7
PHP version mismatch	Your host upgraded PHP (often to 8.2 or 8.3), and an older theme or plugin uses functions that no longer exist	Solution 8
Cloudflare or CDN-level 5xx	The error is coming from Cloudflare or another CDN, not your WordPress origin server, and looks identical from the browser	Solution 11

One quick note before moving on. If your error appeared right after you updated something (a plugin, a theme, WordPress core, or PHP), that update is almost certainly the cause. Start with Solution 4 and work backward from the most recent change.

For everything else, work through the solutions in order. The first three resolve the majority of cases on their own.

How to Fix the WordPress 500 Internal Server Error

You’ll need FTP access for almost every fix in this guide. You can download FileZilla or just use your hosting file manager.

If you are on Cloudways, you’ll find your FTP credentials right under Server Management in your dashboard.

Solution 1: Back Up Your WordPress Site

Always back up your site before touching any files. A 500 error is relatively easy to fix, but a corrupted database is a massive headache.

Choose your backup method below depending on what you can still access.

If you can still access wp-admin

Sometimes the 500 error only breaks your public site, meaning your admin area still loads perfectly fine.

If you can log in, just install a backup plugin like UpdraftPlus or Duplicator. Run a full backup of your files and database, and then download the zip file to your computer.

If wp-admin is completely inaccessible

If you can’t reach the dashboard, you will have to run a manual backup using FTP instead.

Connect to your server and download the entire WordPress root folder to your computer. This includes important directories and files like wp-admin, wp-content, .htaccess and more.

Next, log into your hosting control panel and open the phpMyAdmin tool. Click your database name in the left sidebar.

Click the Export tab at the top, select the Quick export method, and hit Go to download your SQL file.

You now have both halves of your backup sitting safe on your computer.

If you use Cloudways

We handle backups at the server level for our users, so you don’t need any plugins or FTP access.

Open your dashboard, navigate to Server Management, and click Backups. You can trigger an on-demand backup with a single click.

You can also run an application-level backup by opening your WordPress application, going to Backup and Restore, and clicking the on-demand backup button.

Ready for a Managed WordPress Hosting Platform That Prevents 500 Errors?

Get PHP version control, automated backups, and one-click permission resets — all built into your Cloudways dashboard.

EXPLORE CLOUDWAYS

Solution 2: Refresh the Page and Clear Your Browser Cache

Server resource spikes often cause temporary 500 errors. Refresh your browser tab first, as the error might already be gone.

Still seeing the error? Your browser might just be loading an old cached copy of the page, so you will need to clear your cache to know for sure.

How to clear your browser cache

You can use these keyboard shortcuts on any major browser:

• Windows: Press Ctrl + Shift + Delete
• Mac: Press Cmd + Shift + Delete

A settings window will pop up on your screen. Select the “Cached images and files” option, choose a time range of the last 24 hours, and click Clear.

Now reload your website and see if it loads normally.

Is the error only affecting you?

Your site might actually be online right now, meaning the error is isolated to your local computer.

Test your site on your mobile phone by turning off your Wi-Fi and using cellular data instead. You can also type your URL into a free tool like downforeveryoneorjustme.com to check it from an external server.

If the site loads on your phone, your local network or DNS is the real problem. If the site is completely down everywhere, keep following the troubleshooting steps below.

Solution 3: Check and Reset the .htaccess File

A corrupt .htaccess file is the single most common cause of the WordPress 500 internal server error. It is also the easiest fix on this list, which is why we are starting with it before anything more involved.

The .htaccess file controls how your web server handles requests, redirects, and permalinks. When something corrupts the file, often a plugin update, a security tool, or a botched migration, the server cannot process requests properly, and you get a 500 error.

The fix is to reset the file with the default WordPress rules.

Note that this only applies to sites running on Apache servers. If your site runs on Nginx, you can skip this section because Nginx does not use .htaccess files.

How to reset your .htaccess file

Connect to your site using FTP or your hosting file manager. The .htaccess file is located in your WordPress root folder, the same directory that contains wp-admin, wp-content, and wp-includes.

If you do not see the file, your FTP client might be hiding it. Enable the option to show hidden files, which is usually under Server settings depending on your client.

Right-click the .htaccess file and rename it to something like .htaccess_old. This keeps the original file as a backup but tells WordPress to ignore it.

Now visit your website. If the 500 error is gone, the corrupt .htaccess file was your problem. If the site still loads with the error, rename the file back to .htaccess and continue to the next solution.

How to generate a new .htaccess file

If renaming the file fixed the error, you still need to create a new .htaccess file with the proper rewrite rules. Without it, your permalinks will break and your post pages will return 404 errors.

The easiest way is from the WordPress dashboard. Log in, go to Settings, then Permalinks, and click Save Changes without modifying anything. WordPress will automatically generate a new .htaccess file with the default rules.

If you cannot access the dashboard, create the file manually. Inside your WordPress root folder, create a new file named .htaccess and paste in the default WordPress code:

# 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

Save the file and upload it back to your server.

If you are running WordPress Multisite

WordPress Multisite installations need a different .htaccess code. If your site uses Multisite with subfolders, paste this code instead:

# BEGIN WordPress Multisite

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ – [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

RewriteRule . index.php [L]

# END WordPress Multisite

Save the file and reload your site to confirm the error is gone.

If the .htaccess fix did not resolve your 500 error, the cause is somewhere else. The next solution checks your plugins.

Solution 4: Audit Your Plugins

If the .htaccess reset did not fix your 500 error, the next most likely cause is a plugin. Plugin conflicts and fatal errors are the second most common trigger for WordPress 500 errors, especially after an update.

A plugin can cause a 500 error in a few different ways. It might be poorly coded, it might conflict with another plugin, or it might use PHP functions that no longer exist in your current PHP version. Whatever the specific cause, the fix is the same: deactivate all plugins, then reactivate them one by one to find the one causing the problem.

How you do this depends on whether you can still access your WordPress dashboard.

If you can access wp-admin

Log in to your WordPress dashboard and go to the Plugins page. Select all plugins using the checkbox at the top, choose Deactivate from the bulk actions dropdown, and click Apply.

Visit your site to check if the error is gone. If your site loads normally, one of your plugins was the cause.

Now reactivate your plugins one at a time, checking your site after each one. When the 500 error returns, the plugin you just activated is the problem. Delete it or replace it with an alternative.

If wp-admin is inaccessible

If you cannot reach the dashboard, you can still deactivate all plugins using FTP.

Connect to your site via FTP or your hosting file manager. Navigate to the wp-content folder in your WordPress root directory.

Find the plugins folder and rename it to something like plugins_disabled. WordPress looks for plugins in a folder named plugins, and if it cannot find that folder, it deactivates all plugins automatically.

Now refresh your site. If the error is gone, you have confirmed that a plugin was the cause.

To find the specific plugin, rename the folder back to plugins. The plugins are now restored but still deactivated. Inside the plugins folder, rename each individual plugin folder one at a time and refresh your site after each rename. When the 500 error disappears, the plugin you just renamed is the culprit.

Once you find the bad plugin, delete it or look for an updated version that fixes the issue.

When the error appears right after a plugin update

If your 500 error appeared immediately after a plugin update, the new version of that plugin is almost certainly the cause. Instead of deactivating everything, you can roll the plugin back to its previous version.

The easiest way is to use the WP Rollback plugin, which lets you revert any plugin to an earlier version directly from the WordPress dashboard. If you cannot access the dashboard, you can manually replace the plugin folder via FTP with an older version downloaded from the WordPress plugin repository.

Rolling back the specific plugin is faster than auditing your entire plugin list, and it is the right approach when you know exactly what changed before the error appeared.

If a plugin audit did not fix the error, the issue is somewhere else. The next solution checks your theme.

Solution 5: Audit Your Theme

If your plugins are not the cause, the next suspect is your active theme. Themes can trigger 500 errors when they include broken code, use outdated PHP functions, or call functions from a parent theme that no longer exist.

The fastest way to test if your theme is the problem is to switch to a default WordPress theme like Twenty Twenty-Four. If the error disappears after the switch, your theme was the cause.

How you switch themes depends on whether you can access the dashboard.

If you can access wp-admin

Log in to your WordPress dashboard and go to Appearance, then Themes. If you have a default theme already installed, click Activate on it.

If no default theme is installed, click Add New Theme at the top of the page, search for Twenty Twenty-Four (or any current default theme), and install it. Then activate it.

Visit your site to see if the 500 error is gone. If the site loads normally with the default theme active, your original theme was the cause.

If wp-admin is inaccessible

If you cannot reach the dashboard, you will need to deactivate your theme using FTP.

Connect to your site and navigate to the wp-content folder, then open the themes folder. You will see a folder for each theme installed on your site.

Find the folder for your active theme and rename it to something like yourtheme_disabled. When WordPress cannot find the active theme folder, it automatically falls back to the most recent default theme installed.

If you do not have a default theme installed, you will need to upload one. Download a default theme like Twenty Twenty-Four from the WordPress theme directory, extract the zip file on your computer, and upload the extracted folder to your wp-content/themes directory via FTP.

Refresh your site. If the error is gone, your original theme was the issue.

What to do once you confirm the theme is the cause

If switching themes fixed the error, you have a few options.

Check the theme developer’s website or support forum for known issues with the current WordPress or PHP version. There may already be a patch or an update available.

If your theme is outdated and no longer maintained, replacing it with a maintained theme is the safest path forward. Outdated themes are a common source of recurring 500 errors and can also be a security risk.

If you have made custom changes to the theme, like edits to functions.php, those edits could be the cause rather than the theme itself. Restore a clean copy of the theme files and reapply your customizations through a child theme to keep them safe from future updates.

If switching themes did not fix the error, the next solution looks at your PHP memory limit.

Solution 6: Increase the PHP Memory Limit

A 500 error often pops up when your WordPress site simply runs out of memory. This usually happens when a heavy plugin or a bulky theme tries to pull more resources than your server allows, so the process just crashes.

Giving WordPress a little extra memory gives it room to breathe. Most modern setups need at least 256MB, but you might need 512MB if you run a heavy store.

Here is how you can bump up that limit.

Edit your wp-config.php file

The easiest way to fix this is by tweaking your core configuration file.

Connect to your server using FTP and find the wp-config.php file sitting in your root folder. Always download a quick backup to your desktop before you make any changes.

Open the file using a simple text editor. Look for the exact line that says:

/* That’s all, stop editing! Happy publishing. */

Paste this new line right above it:

define( 'WP_MEMORY_LIMIT', '256M' );

Save the file and upload it back to your server.

Still seeing the error? Try bumping that value up to 512M instead. Just keep in mind that WordPress can’t use more memory than your hosting provider actually allows at the server level.

Edit the php.ini or .user.ini file

If editing your config file didn’t work, your memory limit is probably controlled by PHP directly.

Some hosts let you create a php.ini or .user.ini file right inside your WordPress root folder. Just create the file and drop this single line inside:

memory_limit = 256M

Save the file and reload your site to see if the error clears.

If you use Cloudways

We let you change the PHP memory limit straight from the dashboard, so you don’t need to mess with any code.

Open your Cloudways dashboard and navigate to Server Management. Click on Settings & Packages.

Look under the Basic tab to find the Memory Limit field. Just type in your new value and hit Save Changes.

This immediately applies the new limit to every application on your server.

What if more memory doesn’t help?

If raising the limit only delays the crash, a badly coded plugin is probably draining your resources.

Adding more memory is just a band-aid in this situation. You’ll need to check your debug log to find out exactly what is eating up your server power.

Solution 7: Check and Fix File and Folder Permissions

Wrong file permissions will trigger a 500 error instantly. If your permissions are too strict, your server literally can’t read the files it needs to load your site.

If they are too loose, your host will actively block access to protect your security.

Permissions usually break after a site migration or a botched backup restore. You’ll need to reset them to the exact values WordPress expects.

The correct WordPress permission rules

WordPress relies on a very specific set of standard permissions to work properly:

• Folders: 755
• Files: 644
• wp-config.php: 600 or 644

If your files step outside these boundaries, the server throws a 500 error. Setting anything to 777 is incredibly dangerous and will almost always trigger an automatic security block.

How to fix permissions via FTP

Connect to your server using your FTP client. You can usually check current permissions by right-clicking a file and picking File Permissions.

You’ll see a numeric value field. You can fix broken permissions by typing the correct number right into that box.

Want to fix everything at once? You can use the recursive option in your FTP client.

Right-click your main WordPress folder and select File Permissions. Type 755 into the numeric value box.

Check the box that says “Apply to directories only” and hit OK.

Now, repeat that exact same process for your files.

Right-click the root folder, select File Permissions, and type 644. Check the box that says “Apply to files only” and hit OK.

This automatically secures your entire WordPress installation in just two passes.

How to change permissions via SSH

If you know your way around SSH, you can fix this much faster using the command line. Connect to your server and open your WordPress root folder.

Run these two commands in order:

find . -type d -exec chmod 755 {} \;

find . -type f -exec chmod 644 {} \;

The first command locks your folders to 755, and the second secures your files at 644.

Once that finishes, you should lock down your wp-config.php file to protect your database passwords. Run this exact command:

chmod 600 wp-config.php

If you use Cloudways

You don’t need to touch FTP or run command lines to fix this. We built a reset button directly into the platform.

Open your dashboard and select your WordPress application. Go to Application Settings and click the Reset button under the permissions section.

The system automatically resets every file and folder to the perfect WordPress standards. Check your site again to see if the error is finally gone.

Solution 8: Switch or Update Your PHP Version

Your PHP version matters a lot more than you might think. When hosting providers upgrade their servers to modern PHP versions, older themes and plugins usually break. They try to use outdated code that no longer exists.

This quietly causes a huge number of 500 errors. Your site runs perfectly fine for months, but a server upgrade suddenly kills an old plugin. Now, nothing loads at all.

You can fix this by downgrading your PHP version temporarily. This buys you time to find a plugin update that actually supports the newer PHP requirements.

How to check your current PHP version

You can find your active PHP version from your hosting panel or right inside WordPress.

If your dashboard still works, head to Tools » Site Health and click the Info tab. Scroll down to the Server section to see your active version.

If your admin area is broken, check your host’s control panel instead. Look for a section called PHP Settings or PHP Manager.

How to switch PHP versions

You can usually downgrade your PHP directly from your control panel.

On cPanel hosts, look for “Select PHP Version” inside the Software section. Pick a slightly older version and save your changes.

If you use Cloudways

We let you switch PHP versions in just a few clicks. Open Server Management and click Settings & Packages.

Switch to the Packages tab and use the PHP dropdown menu to pick your version. Click Continue, and the server will update in about a minute.

Reload your site after the switch finishes. If the error disappears, you just confirmed PHP was the cause.

Spotting PHP errors in your debug log

Once you turn on debug logging, the file will tell you if PHP is to blame.

Look for fatal errors mentioning “undefined function” or “deprecated” code. These are classic signs that a plugin is calling something PHP no longer recognizes.

What to do once you confirm PHP is the cause

Downgrading gets your site back online, but it isn’t a permanent solution. Your host will eventually drop support for that older version entirely.

Use this extra time to update the broken software. If the developer abandoned the plugin, find a modern replacement before your host forces another upgrade.

Solution 9: Enable Debug Logs in WordPress

Stop guessing and let WordPress tell you exactly what is broken.

WordPress has a built-in debug system that logs every PHP error to a hidden file. A quick log check often shows you the exact plugin file causing the crash. You just have to switch the feature on.

How to turn on debug logging

Connect to your site through FTP and find the wp-config.php file. Always pull a quick backup copy to your computer first.

Open the file and look for the line that says define( ‘WP_DEBUG’, false );. Change that “false” to “true“.

Paste these two lines right below it:

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

The first line tells WordPress to write errors to a secure log file. The second hides those errors from public visitors, so your site doesn’t leak sensitive data.

Upload the file back to your server. Reload your broken website to trigger the error again, which forces WordPress to write the failure into the log.

How to find and read the log

WordPress automatically writes everything to a file called debug.log. You’ll find this inside your wp-content folder.

Open it with any text editor. Each entry tells you when the error happened and what kind of error it was. It also shows the exact PHP file involved and the specific line number.

Here is what a real log entry looks like:

[07-May-2026 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /home/site/public_html/wp-content/themes/customtheme/header.php:24

Reading that one line tells you exactly what to fix. It shows a fatal error happened on May 7th, and the function get_field() is missing. It even tells you the crash happened inside your theme’s header.php file on line 24.

In this example, the theme is calling a function from a missing plugin. You can easily fix it by installing the plugin or removing that line of code.

When debug.log doesn’t appear

Sometimes you turn on debug logging, but no file actually shows up.

The error might not be a PHP issue at all. A bad .htaccess file crashes the site before PHP even runs, so nothing gets logged.

Your wp-content folder might also lack write permissions. Set the folder to 755 so WordPress can actually create the file.

You also need to visit the broken page at least once to trigger the error. The log file only generates after an actual failure happens.

Reading server-level error logs

Your host keeps its own error logs separate from WordPress. These catch severe server crashes that happen before WordPress even loads.

On cPanel, look for the Error Log option under the Metrics tab.

If you use Cloudways

You’ll find these logs right inside Application Management.

Open your dashboard and pick your server. Click the www icon to select your WordPress application.

Next, click Monitoring in the left menu and open the Logs section.

You’ll see tabs for both Access Logs and Error Logs. The Error Logs tab displays your last 1,000 Apache errors, and you can easily filter them by type.

How to check older logs via SSH

Need older data? You can connect to your server using SSH to pull your archived log files.

Navigate straight to your application’s log folder using this command:

cd /home/master/applications/<your-application-name>/logs

Look for a file that starts with backend_ and ends with .error.log. This is exactly where your Apache and PHP errors land.

You can actually watch these errors live while you troubleshoot your website. Run this command in your terminal:

tail -f backend_<your-domain>.error.log

Your terminal will print new errors exactly as they happen.

Reload your site in a new browser tab to trigger the 500 error. The message will pop up on your terminal screen within a second or two.

Just press Ctrl+C on your keyboard to close the live view when you finish.

How to read the error log

Here is what a real entry from our error log looks like:

You can clearly see the exact timestamp and the specific error type right at the start. The actual problem always sits at the very end of the line.

In this specific example, an Object Cache plugin simply failed to authenticate with Redis.

Reading that last part tells you exactly what broke, so you don’t need to decode the entire technical entry.

Solution 10: Replace Core WordPress Files

Sometimes a 500 error comes from a corrupted core WordPress file. This usually happens after a failed update, a malware infection, or an interrupted file transfer during a migration. The fix is to overwrite your core files with a fresh copy from WordPress.org.

This is one of the more aggressive solutions on the list, but it does not touch your content, plugins, themes, or media. Your posts and pages stay safe because those live in the database and the wp-content folder, neither of which we are replacing.

Download a fresh WordPress copy

Head to WordPress.org and click the Download button. You will get a zip file containing the latest WordPress version.

Extract the zip file on your computer. Inside, you will see a folder called wordpress with three main directories: wp-admin, wp-content, and wp-includes, plus a handful of loose files like index.php and wp-login.php.

Replace your core files via FTP

Connect to your site through FTP and open your WordPress root folder.

From your computer, select everything inside the extracted wordpress folder except the wp-content folder. You want to upload wp-admin, wp-includes, and all the loose root files, but leave wp-content alone.

Drag the selected files to your WordPress root folder on the server. When your FTP client asks if you want to overwrite the existing files, select Yes and apply that choice to all files.

The transfer will take a minute or two depending on your connection. Once it finishes, your WordPress core files have been replaced with clean copies.

Files you must never overwrite

Skipping wp-content is critical because it holds your themes, plugins, and uploaded media. Overwriting it would wipe everything.

Two other files also need protection during this process:

• wp-config.php in the root folder. This file holds your database credentials. If you overwrite it with the default version from WordPress.org, you lose your database connection.
• The .maintenance file if it exists. This file appears temporarily during updates. Leave it alone.

Most FTP clients give you the option to skip specific files when overwriting. Use that option to protect wp-config.php during the transfer.

Reload and check

Visit your site after the transfer finishes. If a corrupted core file was the cause, your site should load normally now.

If the error is still there, the cause is something outside the core files. Move on to the next solution, which checks whether your CDN is the actual source of the problem.

Solution 11: Check for Cloudflare or CDN-Level 5xx Errors

Sometimes the 500 error is not coming from your WordPress site at all. It is coming from Cloudflare, a CDN, or another service sitting in front of your server.

This trips up a lot of people because the error in your browser looks identical no matter where it originated. You see “500 Internal Server Error” and assume WordPress is broken. But if your origin server is fine and the failure is at the CDN layer, none of the previous fixes in this guide will work.

The good news: it is easy to tell the difference once you know what to look for.

How to tell if Cloudflare is the source

Cloudflare-generated 500 errors usually have specific visual cues that WordPress 500 errors do not.

Look for these signs:

• A Cloudflare logo or branding on the error page

• An “Error code 500” or “Error reference number” near the bottom of the page
• A “Cloudflare Ray ID” string (something like 9a07c1c33ef3cceb)
• The phrase “There is an internal server error on Cloudflare’s network”

If you see any of those, the error is happening at Cloudflare, not on your origin server. Your WordPress site might actually be working fine, but Cloudflare cannot reach it or is having its own issues.

You can confirm this by temporarily bypassing Cloudflare. If your site loads when you go around Cloudflare but breaks when you go through it, the problem is on the CDN side.

How to bypass Cloudflare to test your origin

The quickest way to bypass Cloudflare is to pause it temporarily.

Log in to your Cloudflare dashboard, select your site, and scroll down on the Overview page. On the right side, you will see an option labeled “Pause Cloudflare on Site.” Click it and confirm. This routes traffic directly to your origin server without going through Cloudflare’s network.

Wait a minute or two for the change to apply, then reload your site. If it loads normally, you have confirmed Cloudflare was the cause. If the 500 error still appears, your origin server is broken and you need to keep working through this guide.

After testing, you can re-enable Cloudflare from the same panel.

Common causes of Cloudflare 500 errors

Once you have confirmed Cloudflare is displaying the error, the cause usually falls into one of these categories:

• It is actually an origin error being passed through: Cloudflare often just displays its own branded page while passing a standard 500 error from your WordPress server. If pausing Cloudflare reveals a raw 500 error on your origin, the issue is still your server.
• Cloudflare Workers errors: If you use Cloudflare Workers to modify traffic at the edge, a buggy or crashed Worker script will return a true 500 Internal Server Error. Check your Workers dashboard for exception logs.
• Misconfigured Page Rules: A bad redirect or transform rule can occasionally force a 500 error on specific URLs.
• Cloudflare network outages: It doesn’t happen often, but Cloudflare’s own internal network can trip up. A quick glance at cloudflarestatus.com will tell you if there is an active incident in your region.

A quick note: If Cloudflare simply can’t reach your server or hits an SSL mismatch, it usually throws a 52x series error (like 521, 522, or 525)—not a 500. If you are seeing a 52x, your server is either completely down, blocking Cloudflare IPs, or missing a valid certificate.

For most true edge-level 500s, the fix lives inside Cloudflare’s dashboard, not your WordPress site. If you can’t hunt down the cause from the list above, Cloudflare’s support team can usually pinpoint it using your Ray ID.

If you use Cloudflare through us, we offer Cloudflare Enterprise as an add-on natively. If you use this add-on and start hitting 500 errors, skip the manual troubleshooting and hit up our support chat. We manage the integration, so we can troubleshoot the routing directly.

Solution 12: Clean Up Corrupted Database Transients

If you’ve exhausted every fix above and the site is still crashing, the culprit might be hiding in your database. Specifically, in the wp_options table where WordPress stores temporary data known as transients.

Transients are just short-lived database caches. Plugins and themes use them to store API responses, cart sessions, or product feeds. Normally, they expire and delete themselves. But sometimes a plugin writes a corrupted transient, or thousands of expired ones pile up and bloat the database until queries just start failing.

When that happens, WordPress throws a 500 error—especially on WooCommerce sites or setups running heavy session data. It is a very real problem that almost no other troubleshooting guide covers.

How to spot a transient issue:

• The 500 error is intermittent. Sometimes the page loads, sometimes it crashes.
• It primarily targets dynamic pages (cart, checkout, search results) while static pages work fine.
• Your site felt sluggish right before the 500 errors started.
• Your database size is massive (e.g., 200MB+ for a relatively basic site).

Cleaning transients via a plugin

If you still have access to your dashboard, WP-Optimize is the easiest tool for this. Install it, navigate to WP-Optimize > Database, select “Remove expired transient options,” and run the cleanup. Check your site. If the 500 error vanishes, transients were the problem. You can even schedule automatic cleanups in the plugin so it doesn’t happen again.

Cleaning transients from phpMyAdmin

Locked out of wp-admin? You’ll need to clear them manually.

• Log into your hosting panel and open phpMyAdmin.
• Select your WordPress database from the sidebar.
• Click the SQL tab and paste this exact query: DELETE FROM wp_options WHERE option_name LIKE ‘%_transient_%’;
• Hit Go.

This wipes every transient entry in your wp_options table. Don’t worry, WordPress will automatically rebuild the ones it actually needs the next time a page loads. (Note: If your database uses a custom security prefix instead of wp_, make sure to swap wp_options for your actual table name).

When transients keep coming back

If clearing the database fixes the site but the 500 error returns a few days later, a specific plugin is generating bad entries. The usual suspects? WooCommerce extensions, page builders, and anything pulling data from a third-party API. Find the offending plugin and update or replace it.

Solution 13: Bring In Your Hosting Provider

If you’ve worked through this entire guide and your site is still flatlining, it’s time to escalate.

Your hosting provider has root-level access, server monitoring, and raw error logs that you simply can’t see. They can spot real-time memory exhaustion, check resource limits, and identify infrastructure-level network blocks.

How to write a ticket that actually gets a fast fix

Vague support tickets result in hours of frustrating back-and-forth. If you want a fix in the first reply, send a single message containing exactly this:

• The URL: Note if the error is global or isolated to one specific page.
• The timestamp: e.g., “This started around 2:30 PM EST.”
• Recent changes: Mention any plugin updates, migrations, or PHP version bumps that happened right before the crash.
• What you already tried: List the fixes you attempted (resetting .htaccess, bumping memory) so they don’t ask you to repeat them.
• The error log: Paste the exact fatal error line you found in Solution 9. This is the single most valuable piece of data you can provide.

A good host will analyze the logs, check server resources, and tell you exactly what failed—whether it was a runaway PHP script, a misconfigured server setting, or a network block.

If you are on Cloudways

Just open a live chat from your dashboard. Our L2/L3 engineers have direct access to your server and application history. Paste that error log line into the chat, and they can usually diagnose a persistent 500 error within minutes.

Fixing the 500 Error in Specific Scenarios

If the 500 error only triggers under very specific conditions, the root cause is usually narrow. Here is how to tackle the most common trigger-specific crashes.

Scenario: 500 Error in wp-admin Only

The front-end loads perfectly but the dashboard crashes? The issue is admin-specific. It is almost always an admin-only plugin (like a heavy SEO suite or backup tool), a corrupted wp-admin core file, or a memory limit being hit by dashboard queries.

Fix: Deactivate plugins via FTP, swap the wp-admin folder for a fresh copy, and bump PHP memory to 512MB. Try them in that order.

Scenario: 500 Error After a Migration

Post-migration crashes usually trace back to a stale .htaccess file referencing the old host, a PHP version mismatch, or busted file permissions that reset during the transfer.

Fix: Force a reset by renaming .htaccess, verify your PHP versions match, run a search-and-replace for hardcoded URLs, and reset your permissions to 755/644.

Scenario: 500 Error When Saving or Publishing

Saving a post requires significantly more memory than just loading one. A crash here means your PHP memory ran dry, a firewall blocked the REST API, or a plugin hooked into the save action is failing.

Fix: Bump PHP memory to 512MB. If your debug log mentions /wp-json/, a security plugin is blocking the REST API. Whitelist the endpoint.

Scenario: Elementor 500 Internal Server Error

Elementor crashes usually happen on editor load or during an autosave. It is a heavy builder, and the fix is almost exclusively about resources.

Fix: Push PHP memory to 512MB and max_execution_time to 300s. If the editor still throws a 500, clear Elementor’s cache by deleting everything inside /wp-content/uploads/elementor/css/ via FTP.

Scenario: WooCommerce Checkout 500 Error

A crash right at checkout points to a botched payment gateway update, a session handler conflict, or PHP memory tapping out during cart calculations.

Fix: Roll back any payment plugins you recently updated. If that fails, bump your memory and check the debug logs for WC_Session_Handler errors (which usually point to conflicts with caching or login plugins).

Scenario: 500 Error on Internal Links Only

If the homepage is fine but every subpage throws a 500, your rewrite rules are broken.

Fix: Go to Settings > Permalinks and click Save Changes to force WordPress to rebuild .htaccess. (If you use Nginx, you’ll need to update the rewrite rules directly in your server config).

Scenario: 500 Error During Media Uploads

Upload failures mean you are hitting strict PHP limits or incorrect folder permissions on the uploads directory.

Fix: Raise upload_max_filesize and post_max_size to 64M. If the limits are fine, reset permissions on /wp-content/uploads/.

Stop Fighting Server Errors — Try Cloudways

Cloudways handles PHP versioning, automated backups, and permission resets out of the box, silently preventing most 500 errors before they happen.

START FREE TRIAL

Wrapping Up

A 500 error looks like a nightmare, but it is honestly one of the more fixable WordPress problems once you know what to check. Most of the time, it traces back to a broken .htaccess, a rogue plugin, or PHP memory running low.

Walk through the solutions above in order. If nothing obvious fixes it, rely on your debug log—it will tell you exactly what crashed and where.

And if you find yourself constantly fighting 500 errors on the same site, your hosting environment is probably making things harder than they need to be. We built Cloudways to handle PHP versioning, automated backups, and permission resets seamlessly, quietly preventing these errors from happening in the first place.