Skip to content
ThemesIonic — home
Troubleshooting

How to Fix a 500 Internal Server Error in WordPress

A WordPress 500 error is a server-side failure. Find its log entry first, then test plugins, the active theme, rewrite rules, PHP limits and core files in a safe order.

4 min read intermediate

Quick fix: open the hosting error log and match the newest entry to the failed request. If it names a plugin or theme file, disable that component. If it reports an invalid directive in .htaccess, restore valid rewrite rules. A 500 response is generic; the log contains the useful error.

Take a backup before changing files. Test the failing URL after each step so you know which action fixed it.

Confirm that it is an HTTP 500

Open browser developer tools, select Network, reload the page and inspect the document request. Hosting-branded error pages sometimes hide the exact status.

Determine the scope:

  • one page only;
  • all frontend pages;
  • wp-admin only;
  • both frontend and wp-admin;
  • intermittent failures under load.

One broken page points toward its template, shortcode or data. A site-wide failure immediately after an update points toward PHP code or configuration. Intermittent 500s can indicate resource exhaustion or a failing upstream service.

Check the host’s status page and disk quota before editing WordPress.

Read the server and PHP error logs

Look in the hosting control panel for Error Log, PHP Log or Raw Logs. With SSH, common locations include server-specific log directories, but your host’s documentation is authoritative.

Request the broken URL once, note the exact time, and inspect the corresponding entry. Useful messages include:

PHP Fatal error: Uncaught Error ... /wp-content/plugins/example/...
Allowed memory size of ... bytes exhausted
Invalid command ... in .htaccess
Permission denied
Primary script unknown

WordPress logging can help when PHP runs far enough to load wp-config.php:

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

If wp-content/debug.log remains empty, rely on the web-server or PHP-FPM log. See How to Enable WordPress Debug Mode for safe cleanup.

Disable the plugin named in the error

With WP-CLI:

wp plugin deactivate plugin-name

Without wp-admin, rename that plugin’s directory through SFTP or the file manager. If no component is named, disable all standard plugins temporarily using this no-admin procedure.

When the site returns, reactivate plugins one at a time on staging. Replace or roll back the component that recreates the 500 error. Do not leave every plugin disabled without confirming forms, security and caching behavior.

Test the active theme

If the log points into the theme, activate an installed default theme on staging:

wp theme list
wp theme activate twentytwentysix

Use an actual installed slug from the first command. If the error disappears, check the theme changelog, child-theme overrides and PHP compatibility.

Regenerate .htaccess on Apache or LiteSpeed

This step applies to servers that use .htaccess; it does not apply to Nginx.

Rename the file in the WordPress root:

.htaccess → .htaccess.disabled

Reload the page. If the site works, sign in and open Settings → Permalinks, then click Save Changes to generate WordPress rewrite rules. Re-add security, caching or redirect directives carefully instead of restoring the entire broken file.

On Nginx, ask the host or server administrator to inspect the site configuration. Creating an .htaccess file will not change Nginx behavior.

Check memory only when the log supports it

For Allowed memory size exhausted, request a temporary WordPress limit:

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

The effective PHP limit may be lower, and increasing it can hide a plugin that consumes memory without bound. Follow the memory-limit guide to verify the effective setting and isolate the workload.

Review PHP changes and file permissions

If the failure began after changing PHP, compare every plugin and theme requirement with the selected version. Roll back the failing component or deploy its compatible release; do not keep an end-of-life PHP branch as the permanent fix.

Incorrect ownership can prevent PHP from reading scripts or writing cache files. Use the host’s recommended ownership and permissions. Do not recursively apply 777.

Verify WordPress core files

An interrupted update can leave missing or modified core files:

wp core verify-checksums

If verification fails, replace wp-admin and wp-includes from the matching official WordPress package. Preserve wp-content and wp-config.php, and back up first.

When to contact the host

Send support a concise diagnostic package:

  • failing URL and UTC time;
  • HTTP status;
  • relevant log lines;
  • last known working time;
  • recent deployment, update or PHP change;
  • steps already tested.

Ask them to check PHP-FPM, web-server configuration, disk/inodes, resource limits and upstream availability. “Please fix WordPress” is less actionable than one timestamped 500 request.

After recovery, disable public debugging, clear only relevant caches and test forms, wp-admin, cron and checkout. If the site returns a blank body rather than a 500 page, use the White Screen of Death guide.

Frequently asked

Common causes include a PHP fatal error in a plugin or theme, invalid server configuration, exhausted memory, incorrect permissions, an incompatible PHP change or incomplete WordPress files.
Not necessarily. A database outage can produce a server error, but WordPress often shows a specific database connection message. Use the server and PHP logs to identify the failing layer.
No. World-writable permissions create a security risk and often do not address the cause. Restore the permissions recommended by your host and correct file ownership instead.
Tagged Debugging

Related guides