WordPress 500 Internal Server Error: Causes and a Step-by-Step Fix

A 500 Internal Server Error means the server received a request but could not complete it because of an unexpected internal condition. The message does not identify a single cause. The same status may result from a fatal PHP error, an incompatible plugin, a broken .htaccess rule, exhausted memory, incorrect permissions, or a hosting-layer failure.

The worst response is to clear every cache, change PHP, disable all plugins, and overwrite files at the same time. If the website comes back, you will not know which action fixed it. If it gets worse, you will not have a clean rollback point. The reliable workflow is to record the symptom, preserve the current state, inspect the logs, test one hypothesis at a time, and repeat the same request after each change.

If the site processes orders, payments, or leads and you do not have file and log access, use professional website technical support. An uncontrolled emergency change on a live store can cost more than the original outage.

What status 500 actually means

The HTTP specification defines 500 as a general response for an unexpected server condition. A browser sees the result, but it cannot tell which layer failed.

A typical WordPress request crosses several layers:

1. DNS routes the visitor to the server.
2. Apache or Nginx accepts the request.
3. PHP starts WordPress.
4. WordPress loads core, the active theme, plugins, and configuration.
5. The application queries the database and external services.
6. The server builds the HTTP response.

A failure at any stage can surface as a 500 response. That is why the browser message is rarely enough to diagnose the problem.

Do not confuse 500 with nearby errors

You can confirm the initial code in browser DevTools or with the BB STUDIO HTTP header checker. Test the failing URL, not only the homepage.

The first 15 minutes

Use this short incident sequence:

1. Open the site in a private window and from another network.
2. Record the exact time, URL, and action that preceded the error.
3. Define the scope: the whole site, admin area, one page, form, or checkout.
4. Take a snapshot or backup of the current state when possible.
5. Open the hosting, PHP, or WordPress error log.
6. If an update immediately preceded the outage, test that component first.
7. Change one item at a time and keep a short incident log.
8. After recovery, test forms, cart, payment, and admin—not only the homepage.

Before editing files, create a recoverable copy. The separate guide to website backups and tested restores explains how to preserve files, the database, and configuration properly.

Define the scope before changing anything

Scope narrows the search immediately.

The entire site and /wp-admin/ fail

Likely areas include an early fatal error, a damaged configuration file, PHP incompatibility, .htaccess, unavailable PHP-FPM, or a server incident.

The public site fails but admin works

Investigate the active theme, page templates, page cache, optimization plugins, and code that runs only on the frontend.

Admin fails but the public site works

The cause may be an admin-only plugin, an import or backup process, the editor, insufficient memory, or a request that exceeds execution limits.

Only one page fails

Look at that template, shortcode, widget, database query, external API, or damaged content. A local failure does not justify switching off the entire site.

The error occurs only during save, import, or payment

Inspect the AJAX or REST request, memory, execution time, request size, PHP-FPM, webhook, and payment gateway response. In the browser Network panel, capture the failing URL, method, response code, and timestamp.

Error logs are the shortest route to the cause

Start with evidence, not guesses. Hosting panels may label the relevant file Error Log, PHP Log, Apache Error Log, or Nginx Error Log. WordPress can temporarily write diagnostic events to wp-content/debug.log.

Add the following before the final “stop editing” line in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

This records errors without showing technical details to visitors. After diagnosis, return WP_DEBUG to false and remove or protect the log. It may contain file paths, table names, request details, and other sensitive information.

How to read a typical entry

PHP Fatal error: Uncaught TypeError ...
in /wp-content/plugins/example-plugin/file.php on line 184

Focus on:

• the error class, such as Fatal error, TypeError, or Allowed memory size exhausted;
• the full file path;
• the plugin or theme name;
• the line number;
• the timestamp matching your test.

Do not chase an old warning at the top of a large file. Reproduce the failure, refresh the log, and inspect the new events written at that moment.

Cause 1: an incompatible or damaged plugin

A plugin is the leading candidate when the error begins immediately after an update, new installation, configuration change, or PHP switch.

If the dashboard is available

1. Deactivate the most recently changed plugin.
2. Clear only the related cache.
3. Repeat the exact action that returned 500.
4. If the site works, compare the log and plugin changelog.
5. Do not keep an old vulnerable release as a permanent fix.

If the dashboard is unavailable

Use SFTP or the hosting file manager to rename the suspected directory:

wp-content/plugins/example-plugin
wp-content/plugins/example-plugin.disabled

If there is no clear suspect, you can temporarily rename the whole plugins directory. That disables every regular plugin. On WooCommerce, it may affect cart, checkout, shipping, email, payment, and integrations. Restore the directory name and enable plugins one at a time.

Must-use plugins and drop-ins

Files in wp-content/mu-plugins load automatically and do not appear as ordinary deactivatable plugins. If the error remains after regular plugins are disabled, inspect MU plugins and drop-ins such as object-cache.php, advanced-cache.php, and db.php.

Unknown code, new administrators, injected links, or mobile-only redirects indicate a security incident rather than a normal conflict. Follow the separate website malware and security check and rotate hosting, SFTP, database, and WordPress credentials.

Cause 2: an error in the active theme

A theme may fail after an update, a manual edit to functions.php, a PHP change, or a call to a function provided by a plugin that is no longer active.

If WordPress Recovery Mode sends an email, use its protected link to enter the dashboard and deactivate the failing theme. Without that email, rename the active theme folder over SFTP. WordPress will attempt to fall back to an installed default theme.

Confirm that a default theme is available before testing. Do not delete the active theme or overwrite it with an arbitrary archive. Preserve the current version, local modifications, and child-theme relationship first.

If only one template fails, compare it with the last working revision. Common causes include:

• a syntax error after manual editing;
• a call to a removed function;
• stricter type handling after a PHP update;
• infinite recursion;
• an expensive query inside a loop;
• dependency on a plugin that is no longer active.

Cause 3: a broken .htaccess file

On Apache, a syntax error or disallowed directive in .htaccess can return 500 before WordPress starts.

A safe test:

1. Download a copy of the current .htaccess.
2. Rename it to .htaccess.old.
3. Test the homepage and the failing URL.
4. If the site works, open Settings → Permalinks and save the current structure to generate basic WordPress rules.
5. Restore custom rules in small blocks and test after each block.

Do not paste an entire .htaccess from another website. It may contain domain-specific redirects, a different PHP handler, caching rules, or directives your server does not permit.

Nginx does not use .htaccess. If that advice has no effect, inspect the virtual host configuration, Nginx error log, PHP-FPM, and reverse-proxy rules.

Cause 4: PHP memory or execution limits

Allowed memory size exhausted directly indicates that one process exceeded its memory allowance. It does not automatically mean that raising the limit is the correct long-term fix. An infinite loop, large image, import, expensive query, or plugin conflict may be consuming the memory.

A temporary increase can help complete diagnosis, but record the existing settings first. On managed hosting, the effective limit may come from php.ini, .user.ini, the panel, a pool configuration, or plan policy rather than WordPress.

Related log messages include:

• Maximum execution time exceeded — the request ran too long;
• upstream timed out — the web server did not receive a response from PHP-FPM;
• server reached max_children — every PHP worker was busy;
• MySQL server has gone away — the database connection was lost;
• No space left on device — storage space or inodes were exhausted.

Recurring limits require profiling of the request, cron job, plugin, database, and hosting plan. A suitable website hosting environment matters, but a larger server cannot repair an infinite loop in application code.

Cause 5: an incompatible PHP version

An old plugin may call functionality removed from a newer PHP release. A new plugin may require a version the server does not provide. The outage often begins after a panel switch or an automated environment upgrade.

Check:

• the PHP version assigned to the affected domain;
• requirements of WordPress, the theme, and critical plugins;
• PHP extensions required by ecommerce and integrations;
• the error log immediately after the version change;
• whether web requests and CLI/cron use the same PHP branch.

Do not switch production versions blindly. Reproduce the site on staging, update the incompatible component, and test key journeys. A temporary rollback may restore access, but it must not leave the site on an unsupported branch indefinitely.

Cause 6: wrong file permissions or ownership

This often follows a manual upload, archive extraction, migration, or command run by the wrong operating-system user. PHP cannot read a file, write cache, or create a temporary directory.

Do not use 777 as a universal fix. It expands access and hides an ownership or group problem. Exact values depend on the server model; common configurations often use 644 for files and 755 for directories, but your host’s policy is authoritative.

Compare the failing file with adjacent working files, inspect owner and group, and locate the exact Permission denied event in the log.

Cause 7: damaged WordPress core files

An interrupted update, disk issue, incomplete copy, or infection may damage core files. Before reinstalling, establish that the failure is not in wp-content or configuration.

A controlled process is:

1. create a complete backup;
2. record the installed WordPress version;
3. obtain a clean official package for the same or deliberately newer version;
4. replace core files without touching wp-content or wp-config.php;
5. test logs, admin, media, forms, and cron.

If files change again after replacement, investigate malware or an automated process that is rewriting them.

Cause 8: server resources, WAF, disk, or database

When code has not changed and 500 appears intermittently or under load, investigate infrastructure:

• CPU, RAM, I/O, and process usage;
• free space and inode count;
• PHP-FPM health;
• Apache or Nginx errors;
• MySQL/MariaDB availability;
• ModSecurity or another WAF;
• rate limits and IP blocking;
• cron, imports, backups, and queues;
• external APIs that block the request.

A WAF may return 500 or 403 only for a particular payload, such as saving a page containing code. Do not disable protection globally. Find the rule ID in the audit log and create a narrow exception only after the request is understood.

If you are unsure whether DNS and the server are resolving and responding correctly, use the domain, hosting, and server diagnostic guide. A certificate or HTTPS failure should not be treated as a generic 500; use the separate SSL and HTTPS troubleshooting guide.

Symptom-to-check matrix

The WooCommerce case

Restoring the homepage is not enough for a store. Test:

1. product pages and variations;
2. adding and removing cart items;
3. coupon application;
4. guest and account checkout;
5. every active payment and shipping method;
6. customer and admin emails;
7. webhooks, CRM, stock, and fiscal integrations;
8. background jobs and Action Scheduler;
9. order creation without duplicate charges.

Do not repeat a live payment without a controlled plan. Use the gateway sandbox or a documented test order and inspect the logs immediately.

What not to do

Do not make five changes at once

You lose causality and cannot identify the correct rollback.

Do not display PHP errors publicly

Absolute paths, directory structures, and request fragments help attackers as well as administrators. Log them privately.

Do not delete plugins, themes, or the database without a copy

Renaming is reversible. Deletion is not.

Do not apply 777 permissions

That is an unsafe mask for the real ownership problem.

Do not restore an arbitrary old database over current orders

Save the current database first, identify the incident window, and plan how new transactions will be preserved.

Do not update everything in production during the outage

Bulk updates add new variables. Isolate the cause and restore service first; modernize components in a controlled release afterward.

How to verify a real recovery

A 200 response on the homepage is only the beginning. Verify:

• the homepage and several representative internal pages;
• /wp-admin/, login, and saving a post;
• forms and message delivery;
• search, filters, and accounts;
• cart, checkout, and a test payment;
• cron and background queues;
• new error-log entries after testing;
• mobile and desktop layouts;
• a clean-session cache path;
• external status and response time.

Run the website speed test after service is restored. If 500 is gone but TTFB has increased sharply or the server still fails intermittently, the root cause may remain and return under traffic.

Preventing the next 500 error

1. Update WordPress, themes, and plugins on staging first.
2. Create automatic backups and a separate pre-update restore point.
3. Retain logs with rotation and restricted access.
4. Monitor HTTP status, response time, storage, and SSL expiry.
5. Delete unused plugins instead of leaving them deactivated.
6. Use a supported PHP version and test compatibility before switching.
7. Document manual code and configuration changes.
8. Maintain an access inventory and a named recovery owner.
9. Test a restore in an isolated environment every quarter.
10. Record the root cause after an incident, not only the actions taken.

When to involve a specialist

Get help when:

• the site processes payments or business-critical leads;
• there is no verified backup;
• 500 returns after a temporary fix;
• logs point to the database, PHP-FPM, WAF, or server;
• there are signs of compromise;
• orders must be reconciled between a backup and the current database;
• several sites in the account fail together;
• you do not know what a previous contractor already changed.

Prepare the failing URL, incident time, screenshot, recent changes, hosting and WordPress access, and a log excerpt with secrets removed. That turns a vague outage into a focused investigation. For a controlled recovery, contact BB STUDIO. We will isolate the cause, restore service, test critical journeys, and document prevention steps.

Final checklist

• URL, timestamp, and preceding action recorded;
• failure scope defined;
• current state backed up;
• web-server and PHP logs inspected;
• WP_DEBUG_DISPLAY is not exposing errors;
• plugins and theme tested one at a time;
• .htaccess saved before modification;
• PHP, memory, timeout, disk, and permissions checked;
• forms, admin, and checkout tested after recovery;
• new log events reviewed;
• monitoring and a fresh recovery point enabled;
• root cause documented.