Is 500 Server Error My Fault? WordPress Troubleshooting

500 Internal Server Error stares back at you, and your first thought is: what did I break? Usually nothing — a plugin update, a bad .htaccess rewrite, or a PHP memory cap you never touched is the real culprit about 70% of the time. WordPress throws this error for a dozen different reasons and the on-screen message never tells you which one, which is why “Is 500 Server Error My Fault? WordPress Troubleshooting” is one of the most-searched phrases in every hosting forum. The good news: your database is almost certainly intact, and the fix is usually a config check, not a rebuild. Grab SSH or SFTP access to your server and give this five minutes — you’ll know exactly whose fault it is before you finish your coffee.

tail -f /path/to/wp-content/debug.log

What a 500 Server Error Actually Means

A 500 Internal Server Error is Apache or Nginx shrugging. It’s the server’s way of saying “something crashed while I was building this page,” without telling you what. That’s not a WordPress-specific error code — it’s an HTTP status generic to every web server on earth, which is why WordPress core doesn’t display a friendlier message. You get the raw HTTP status instead of a diagnosis.

And yes, in the vast majority of cases it is your fault — not in a blame sense, but in a “something in your stack changed” sense. The four usual suspects: a plugin or theme with a PHP fatal error, a memory limit that’s too low for what you just installed, corrupted or misconfigured .htaccess, or file permissions that got scrambled during a migration or manual upload. Server-side outages from your host are rare enough that you should rule out your own site first.

You’ll see this error in three places: the public-facing site, the /wp-admin/ dashboard, or both at once. If only wp-admin is broken, that narrows things toward a plugin conflict rather than a server-wide config issue. If the whole site is down including the frontend, suspect .htaccess or a fatal PHP error affecting every request.

WordPress can log the exact PHP error to wp-content/debug.log if WP_DEBUG and WP_DEBUG_LOG are enabled in wp-config.php — we’ll turn that on in the next section, since it usually names the broken file directly. From here we go through causes in order of how often they actually happen.

Enable Debug Logging to See the Real Error

Before touching plugins, permissions, or .htaccess, get WordPress to tell you what’s actually failing. This step is non-destructive — it only writes text to a log file — and it applies to every WordPress install from 5.0 through the current 6.x releases. Skipping this and guessing at fixes is how a 5-minute problem turns into a 45-minute one.

Edit wp-config.php and Enable Debug Mode

SSH into your server and open wp-config.php, usually located at /var/www/html/wp-config.php on Nginx/Apache setups, or inside your container volume if you’re running Docker:

sudo nano /var/www/html/wp-config.php

This opens the file in a terminal text editor. Find the line that says /* That's all, stop editing! Happy publishing. */ and add these three lines directly above it:

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

WP_DEBUG_DISPLAY set to false keeps errors out of the visitor-facing page — you don’t want raw PHP warnings showing up on your live site while you debug. Save with Ctrl+O, then Enter, then exit with Ctrl+X. Nano will briefly flash [ Wrote 132 lines ] or similar at the bottom, confirming the save.

Reload the broken page once to generate a fresh log entry, then check that the log file exists:

ls -la /var/www/html/wp-content/debug.log

You should see a file with a recent timestamp. Now tail it live while you reproduce the error:

tail -f /var/www/html/wp-content/debug.log

Expect one of three patterns: a line reading PHP Fatal error: Uncaught Error: followed by a plugin path like /wp-content/plugins/some-plugin/file.php on line 42, a PHP Warning: Allowed memory size of 268435456 bytes exhausted message pointing to a memory limit problem, or a stack of PHP Deprecated notices that are noisy but harmless. The fatal error line is the one that matters — it names the exact file causing your 500, which tells you which fix below to run first.

Plugin or Theme Conflict (Most Common Cause)

If your debug.log pointed at a file inside /wp-content/plugins/, you’ve already found the cause. This is what triggers a 500 error roughly 80% of the time — a plugin update that broke compatibility with your PHP version, or two plugins fighting over the same function name. It applies to every WordPress version currently in use, from 6.4 through the 6.8.x line running in 2026.

Disable All Plugins via WP-CLI

If your host gives you SSH access, wp-cli is almost certainly already installed — every major managed host (WP Engine, Kinsta, Cloudways, SiteGround) has shipped it by default since well before 2026. Run:

wp plugin deactivate --all

Expect output reading Plugin 'akismet' deactivated. repeated for each plugin, ending with Success: Deactivated 12 of 12 plugins. Load your site in the browser now. If the 500 error is gone and you’re staring at an unstyled homepage, a plugin was the problem — not the server, not the theme.

If you need to isolate the theme too, switch to a default one temporarily:

wp theme activate twentytwentyfour

This confirms whether a custom or premium theme is the actual conflict rather than a plugin.

Disable All Plugins via Database if No WP-CLI

No SSH, no wp-cli, just phpMyAdmin or a raw MySQL connection? You can force-deactivate every plugin by editing one row in wp_options. Connect first:

mysql -u your_db_user -p your_db_name

Enter your database password when prompted. Then run:

UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

Expect Query OK, 1 row affected. This isn’t destructive in the sense of deleting anything — you’re overwriting a serialized array with an empty one, and your plugin files stay untouched on disk. Reload the site. If it comes back up, reactivate plugins one at a time from wp-admin’s Plugins screen, reloading the site after each one, until the 500 error returns. That last plugin you activated is the culprit — check its changelog for a recent update, or open a support ticket with the developer.

PHP Memory Limit Exceeded

This is the cause about 20% of the time, and it’s the easiest to confirm. Open your debug log and look for this exact line:

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)

The first number is your current limit in bytes — 268435456 is 256M. If you see this, WordPress or a plugin tried to allocate more RAM than PHP will hand out. Check your current setting with wp-cli:

wp config get WP_MEMORY_LIMIT

If nothing prints, WordPress is falling back to PHP’s default, which is often 128M — too low for anything running WooCommerce, Elementor, or more than a dozen active plugins. This applies to PHP 7.4 through 8.3 and every currently supported WordPress version.

Increase Memory Limit in wp-config.php

Open wp-config.php and add this line before the /* That's all, stop editing! */ comment and before the require_once ABSPATH . 'wp-settings.php'; line:

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

Placement matters — if you put it after the wp-settings.php include, it won’t take effect. Edit and verify:

wp config get WP_MEMORY_LIMIT

Expect the output 256M back. Reload the site — it should load normally instead of throwing the 500. This is the safest method on shared hosting because it doesn’t touch server-level PHP settings you may not have permission to edit anyway.

256M covers most sites. Bump it to 512M if you’re running WooCommerce with 50+ products, or a page builder stack like Elementor plus a dozen add-ons. If 512M still exhausts, the problem usually isn’t memory — it’s a plugin loop or bad query, and increasing the limit further just delays the same crash.

If wp-config.php edits get overwritten or ignored, check your php.ini directly:

php -i | grep 'Loaded Configuration File'

Expect something like Loaded Configuration File => /etc/php/8.2/fpm/php.ini. Open that file, find the memory_limit directive, and set:

memory_limit = 256M

Restart PHP-FPM afterward (sudo systemctl restart php8.2-fpm on Ubuntu 22.04/24.04) for the change to take effect.

File Permissions or Ownership Issues

This is the culprit maybe 15-20% of the time, usually after a manual file upload via SFTP, a restored backup, or a migration script that ran as root. WordPress on Linux expects specific permission and ownership patterns, and when they drift, PHP can’t read or execute the files it needs — resulting in a 500 with nothing useful in the browser. This section applies to self-hosted Linux/Unix setups only. Skip it if you’re on Windows IIS hosting.

Check current permissions first:

ls -la /var/www/html/wp-content/

Look at the permission string on the left. Directories should read drwxr-xr-x (755) and files -rw-r--r-- (644). If you see 777 anywhere, or a mix of root-owned and www-data-owned files, that’s your problem.

Check ownership the same way:

ls -l /var/www/html/ | head

The owner and group columns should both say www-data on Debian/Ubuntu with Apache or Nginx+PHP-FPM, or nginx on some CentOS/AlmaLinux setups. If you see your SFTP username or root instead, PHP-FPM running as www-data can’t write to or sometimes even read those files.

Fix Directory and File Permissions

Warning: these commands recurse through every file under the path you give them. Double-check you’re pointing at your actual WordPress root before running anything — running this against / or the wrong docroot will break permissions site-wide across the server.

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

The first sets all directories to 755 (owner read/write/execute, group and others read/execute). The second sets all files to 644 (owner read/write, everyone else read-only). Expect no output on success — no output is normal for find with -exec.

Then fix ownership:

chown -R www-data:www-data /var/www/html/

This recursively assigns every file and directory to the www-data user and group, matching what PHP-FPM runs as on most Debian/Ubuntu stacks. Reload the site. If wp-admin was locking you out with a blank white screen before this, it should now load the login form normally. Getting ownership wrong in the other direction — for example leaving files owned by root after an SFTP upload — is the single most common cause of “stuck at 500 after restoring a backup.”

PHP Version Incompatibility or Fatal Error

If permissions check out fine, the next likely cause is PHP itself throwing a fatal error that Apache or Nginx converts into a blank 500 page. WordPress 6.4+ requires PHP 7.4 as an absolute floor, but plenty of 2026-era plugins — WooCommerce 9.x, Elementor Pro 3.24+, most AI-writing plugins — require PHP 8.0 or 8.1 minimum. Running an older PHP version against a newer plugin is the second most common cause of a 500, right behind permissions.

Check PHP Version and Read Fatal Errors

php -v

Expect output like PHP 7.4.33 (cli) (built: Nov 2024) or PHP 8.2.15 (cli). Note the major.minor number — anything below 7.4 is unsupported by current WordPress core, and anything below 8.0 will break a growing number of premium plugins.

tail -50 /var/www/html/wp-content/debug.log

Look for a line starting with PHP Fatal error: or PHP Parse error:. It’ll read something like:

PHP Fatal error:  Uncaught Error: Call to undefined function str_contains() in /var/www/html/wp-content/plugins/some-plugin/includes/class-helper.php:42

The file path tells you exactly which plugin is responsible — here it’s some-plugin. str_contains() didn’t exist before PHP 8.0, so this confirms a version mismatch, not a corrupted file. If debug.log doesn’t exist yet, you’ll need to enable WP_DEBUG_LOG in wp-config.php first and reproduce the error.

Verify the Fix and Prevent Recurrence

Once you’ve applied a fix, don’t just assume it worked — check it. Load both the frontend homepage and /wp-admin in a browser. Both need to return a normal page, not a blank white screen or the “There has been a critical error” message.

tail -20 /var/www/html/wp-content/debug.log

Reload the pages once, then run this again. If no new PHP Fatal error: lines appear with a fresh timestamp, the fix held. If the 500 comes back or new fatal lines show up, the plugin/PHP mismatch you fixed wasn’t the only problem — move to the next likely cause (permissions, then .htaccess, then memory limits).

For prevention, treat plugin updates like production deploys, not background chores. A self-hoster running WooCommerce plus five plugins should never update all of them directly on a live site.

wp plugin update --all

Run this on a staging clone first — most managed hosts (Kinsta, WP Engine, Cloudways) give you one-click staging environments. If staging survives the update without a 500, push to production.

Set up log rotation so debug.log doesn’t quietly grow to 4GB and fill your disk:

sudo tee /etc/logrotate.d/wp-debug <<'EOF'
/var/www/html/wp-content/debug.log {
  weekly
  rotate 4
  compress
  missingok
  notifempty
}
EOF

This keeps four weeks of compressed history and truncates the live file weekly. Check debug.log at least that often — a growing fatal-error pattern usually shows up days before the site actually goes down.

Frequently Asked Questions

Related Reads

• Fix GRUB Rescue Unknown Filesystem Error

  GRUB rescue unknown filesystem error? Copy-paste fixes ordered by likelihood. Works on Ubuntu, Debian, Fedora. Senior en…

• Maximum Open Files in Linux: Fix "Too many open files" Error

  Fix "Too many open files" errors in Linux. Check current limits with ulimit, raise file descriptors per-user and system-…

• Fix 'Cannot Open Shared Object File: No Such File' Error

  Cannot open shared object file: no such file error on Linux? Copy-paste fixes ordered by likelihood. Developers and sysa…