WordPress 500 error – how to debug your website?

You open your WordPress website and instead of the homepage, dashboard or product page, you see 500 Internal Server Error. The message is frustratingly vague. It tells you that the server could not complete the request, but it does not tell you whether the problem was caused by a plugin, theme, PHP error, server configuration or exhausted resources.

The most effective way to deal with a WordPress 500 error is therefore not to guess, but to collect diagnostic information and read the logs. In this guide, you will learn how to safely debug WordPress, enable its built-in debugging tools, interpret common error messages and narrow the problem down to a specific component.

You will also learn what to do when you cannot access wp-admin, how WordPress Recovery Mode can help after a fatal PHP error, and when the problem should be escalated to your hosting provider or developer.

What does a 500 error in WordPress mean?

HTTP 500 Internal Server Error is a general server-side error. It means that the server received the browser’s request but encountered an unexpected condition that prevented it from generating a valid response.

The HTTP specification does not assign one specific cause to a 500 response. It is essentially a catch-all server error, which is why the message displayed in the browser usually contains very little useful diagnostic information. You can read more about the status code in the MDN documentation for HTTP 500.

On a WordPress website, common causes include:

• a fatal PHP error in a plugin, theme or custom code,
• a conflict after updating WordPress, a plugin or a theme,
• incompatibility with the PHP version used by the server,
• incorrect rules in the .htaccess file,
• an exhausted PHP memory limit,
• a script exceeding its maximum execution time,
• incorrect file or directory permissions,
• missing or corrupted WordPress files,
• a server or PHP configuration problem,
• a failed deployment or incomplete update,
• malicious or unauthorized modifications to website files.

A 500 error does not necessarily affect the entire website. It may occur only when you open wp-admin, save a page, process an order, upload an image, run an import, execute a scheduled task or call a particular REST API endpoint.

Make a note of the exact action that triggers the error. This will make it much easier to match the failure with the corresponding entry in the server or WordPress log.

Before debugging WordPress, protect your website

Before changing files or configuration, determine what happened immediately before the error appeared. A recent change is often the fastest clue.

• Was WordPress updated?
• Was a plugin or theme installed or updated?
• Was the PHP version changed?
• Was custom PHP code added?
• Was functions.php, wp-config.php or .htaccess edited?
• Was the website migrated or restored from a backup?
• Did the problem start during an import, backup or other resource-intensive process?

Before editing files, create a backup of both the website files and database. If the website is commercially important, consider reproducing the problem on a staging environment before making larger changes to production.

Be careful with restoring an old backup as your first response. On an active online store or membership website, restoring the entire database can also remove new orders, accounts, form submissions and content created after the backup was made.

Good practice. Change one thing at a time and test the website after every change. Disabling several plugins, changing PHP and replacing .htaccess simultaneously may make the website work again, but you will not know which change actually fixed the problem.

Start with the server error log

The server error log is usually the best place to start. Depending on your hosting environment, it may be available through a hosting control panel, file manager, SSH or a log management service.

Look for an error.log or equivalent PHP/web server error log and reproduce the problem in a second browser tab. Then refresh the log and check entries created at the same time as the HTTP 500 response.

Useful messages often contain phrases such as:

• PHP Fatal error – PHP stopped execution because of a critical error,
• Uncaught Error – an error was not handled by the application,
• Uncaught TypeError – PHP received or returned an unexpected type,
• Allowed memory size exhausted – the PHP memory limit was reached,
• Maximum execution time exceeded – the script ran for too long,
• Parse error or syntax error – PHP cannot parse part of the code,
• Permission denied – the application cannot access a required file or directory.

Pay particular attention to file paths. For example, an error referring to:

/wp-content/plugins/example-plugin/includes/example.php

strongly suggests that the plugin is involved. It does not automatically prove that the plugin itself is defective. The actual cause could still be a conflict with another plugin, the theme, WordPress core or the PHP version.

Do not analyse only the last line. A fatal error may be preceded by warnings or another exception that better explains what happened.

How to enable WordPress debugging

WordPress includes its own debugging system. The main switch is the WP_DEBUG constant in the wp-config.php file.

For troubleshooting a website, it is usually safer to write errors to a log instead of displaying technical details to visitors. Add or update the following settings in wp-config.php:

define( 'WP_DEBUG', true ); 

define( 'WP_DEBUG_LOG', true ); 

define( 'WP_DEBUG_DISPLAY', false ); 

@ini_set( 'display_errors', 0 );

Place these definitions before the line that ends the editable configuration section of wp-config.php.

When WP_DEBUG_LOG is set to true, WordPress normally writes debugging information to:

/wp-content/debug.log

Now reproduce the action that causes the error and inspect debug.log. WordPress documentation also allows WP_DEBUG_LOG to be configured with a custom log path. See the current official WordPress debugging documentation for details.

Important: the official WordPress documentation recommends using debugging tools primarily in development or staging environments. Do not leave debugging enabled indefinitely on a production website.

After troubleshooting, disable debugging again:

define( 'WP_DEBUG', false );

Also make sure that PHP errors are not publicly displayed. Error messages may reveal absolute server paths, plugin names and other technical details that visitors do not need to see.

Why does debug.log not exist?

The file may not appear until WordPress has something to log. After enabling debugging, reproduce the failing action again.

If debug.log is still missing, check the server’s PHP error log. Some failures happen before WordPress can initialise its own logging mechanism, and file permissions may also prevent WordPress from creating or writing to the log.

Check WordPress Recovery Mode

WordPress includes Recovery Mode, which can help when a fatal PHP error prevents normal access to the website. WordPress has supported this mechanism since version 5.2.

When WordPress detects certain fatal PHP errors during a normal page request, it may send an email to the website administrator. The message can contain information about the component that triggered the failure and a special link that allows an administrator to log in with Recovery Mode enabled.

Inside Recovery Mode, the problematic plugin or theme may be paused for your administrator session so that you can investigate the site and correct the problem without immediately using SFTP or a file manager.

If you see the WordPress message There has been a critical error on this website, check the administrator email address and spam folder. Remember that Recovery Mode does not handle every type of failure, and the email itself may fail to reach you.

More details are available in the official WordPress Recovery Mode documentation.

How to fix the most common causes of a WordPress 500 error

Once you have checked the logs, use the error message to narrow down the investigation. The following scenarios cover many of the most common WordPress 500 errors.

A plugin causes the 500 error

If the error started immediately after installing or updating a plugin and the log points to its directory, deactivate that plugin first.

If the WordPress dashboard is still accessible, deactivate it from the Plugins screen. If wp-admin also returns a 500 error, use SFTP or your hosting file manager and temporarily rename the plugin directory, for example:

/wp-content/plugins/example-plugin 

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

WordPress will no longer be able to load that plugin. If the website starts working again, check the plugin’s system requirements, compatibility notes and recent updates before reactivating it.

If you have SSH and WP-CLI available, you can also deactivate a plugin from the command line:

wp plugin deactivate plugin-slug

You can deactivate all standard plugins for diagnostic purposes with:

wp plugin deactivate --all

If the website works with all plugins disabled, reactivate them one at a time and test after each activation. On a production site, use this method carefully because disabling plugins can temporarily remove important functions such as payments, forms, caching or security features.

The active theme causes a fatal error

A theme can cause the same type of PHP failure as a plugin. This is especially likely after editing functions.php, adding a custom snippet or switching PHP versions.

If the log points to your active theme, undo the most recent code change first. When necessary, temporarily switch to a known working theme. Do not delete the current theme before you have backed it up and confirmed the cause.

The .htaccess file contains an invalid rule

On Apache-based environments, an invalid directive in .htaccess can generate a server error before WordPress finishes loading.

If the problem started after editing this file, make a copy and temporarily rename it:

.htaccess 

.htaccess-backup

If the website begins working, you have narrowed the issue down considerably. Once you regain access to WordPress, saving the permalink settings may recreate the standard WordPress rewrite rules.

Do not blindly overwrite the original file if it contains additional security rules, redirects or application-specific configuration. Compare the rules and restore only what is needed.

Also remember that .htaccess is specific to compatible web-server configurations. Websites running on Nginx, for example, use server configuration rather than WordPress-style .htaccess rules.

The error appeared after changing PHP

An older plugin, theme or custom code may use functionality that is no longer compatible with the PHP version configured for the website. The opposite can also happen: a newer plugin may require a newer PHP version than the server currently uses.

Check the error log for the file and function involved, then compare the requirements of WordPress, the active theme and plugins.

If the failure started immediately after a PHP version change, temporarily reverting to the previously working version may help confirm the diagnosis. Treat this as a diagnostic or short-term recovery step, not as a reason to keep unsupported software indefinitely. The proper solution is to update, replace or correct the incompatible component.

PHP memory has been exhausted

If the log contains:

Allowed memory size exhausted

the process tried to use more memory than PHP was allowed to allocate.

Increasing the memory limit may be appropriate if the workload genuinely requires more resources, but do not assume that a higher limit fixes the root cause. Sudden memory growth may be caused by a plugin loop, expensive database operation, large import, image processing task or faulty custom code.

Check which request caused the problem and whether memory usage increased after a specific update or configuration change.

A script exceeds the execution time

The message:

Maximum execution time exceeded

means that PHP stopped a process that was taking too long. This can happen during imports, backups, optimisation jobs, API requests, image processing or inefficient database operations.

Increasing the time limit may help legitimate long-running jobs, but first identify why the process needs so much time. A timeout can be a symptom rather than the actual problem.

File permissions are incorrect

Incorrect ownership or permissions can prevent PHP or the web server from reading or executing required files.

Values such as 644 for files and 755 for directories are common in many hosting environments, but they should not be treated as universal settings that must be forced onto every server. The correct configuration depends on the server architecture and ownership model.

If permissions changed unexpectedly, investigate why. Unexplained changes to website files can also justify a security review.

WordPress core files are missing or corrupted

An interrupted update, deployment error or manual modification can leave WordPress core files incomplete.

If logs point to core files and plugin or theme troubleshooting does not explain the problem, compare the WordPress installation with a clean copy of the same release. When using WP-CLI, experienced administrators can also verify WordPress core checksums.

Do not overwrite wp-config.php or the wp-content directory when replacing WordPress core files.

How to debug a 500 error when wp-admin does not work

A broken WordPress dashboard does not prevent you from diagnosing the website. You can still work through the file system, hosting control panel or SSH.

A practical sequence is:

1. Check the server error log.
2. Check whether WordPress sent a Recovery Mode email.
3. Create a current backup if possible.
4. Enable WP_DEBUG_LOG without publicly displaying errors.
5. Reproduce the failing request.
6. Read error.log and wp-content/debug.log.
7. If the log identifies a plugin, disable that plugin via SFTP, a file manager or WP-CLI.
8. If the error points to the theme, undo the recent change or temporarily switch themes.
9. If the problem followed a PHP change, verify compatibility.
10. If .htaccess was recently modified, test it separately.
11. Review memory, execution-time and permission errors only when the logs point in those directions.

This order is more reliable than randomly disabling components because each step attempts to preserve evidence about the original failure.

When should you contact your hosting provider or developer?

Some WordPress 500 errors can be fixed in a few minutes. Others require access to server-level logs, configuration or application code.

Contact your hosting provider when the evidence points to the hosting environment, for example:

• the server error log is not available to you,
• multiple websites on the same service fail at the same time,
• PHP itself does not appear to start correctly,
• the error is caused by a server-level configuration you cannot change,
• permissions or ownership cannot be corrected from your account,
• you suspect resource limits or another infrastructure problem.

Contact a developer when the logs identify faulty PHP code, a plugin/theme conflict or a custom integration that needs to be corrected.

To make troubleshooting faster, provide:

• the exact URL that returns the 500 error,
• the approximate time when the error occurred,
• the action that triggers the problem,
• the date or time when the issue first appeared,
• details of recent plugin, theme, WordPress or PHP changes,
• the relevant section of the server error log,
• the relevant section of wp-content/debug.log,
• a list of troubleshooting actions you have already performed.

A timestamp is particularly useful. It allows the person investigating the issue to match your request with a specific log entry instead of searching through thousands of unrelated messages.

FAQ – Troubleshooting WordPress 500 errors

What does a 500 Internal Server Error mean in WordPress?

It means the server encountered an unexpected problem while processing a request. The HTTP 500 status itself does not identify the cause. In WordPress, common causes include PHP errors, plugin or theme conflicts, incompatible PHP versions, invalid server rules, exhausted resources and configuration problems.

Where should I look first when WordPress shows a 500 error?

Start with the server or PHP error log and reproduce the failing request. Entries created at the same time as the HTTP 500 response often identify the file, plugin, theme or resource limit involved.

How do I enable debugging in WordPress?

In wp-config.php, set WP_DEBUG to true, WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false. This normally writes WordPress debug information to wp-content/debug.log without displaying technical errors to visitors.

Where is the WordPress debug.log file?

With the standard WP_DEBUG_LOG setting enabled, the file is normally created as wp-content/debug.log. It may not appear until WordPress has an error, warning or notice to write to it.

Can a plugin cause a WordPress 500 error?

Yes. A fatal PHP error or compatibility conflict in a plugin is a common cause. If the log points to a plugin, deactivate it through the dashboard, WP-CLI or by temporarily renaming its directory when wp-admin is unavailable.

Should I leave WP_DEBUG enabled after fixing the website?

No. WordPress debugging tools are intended primarily for development and troubleshooting. Disable WP_DEBUG when the investigation is complete and avoid displaying PHP errors publicly on a production website.

WordPress 500 error – diagnose the cause before changing the site

A 500 Internal Server Error tells you that something failed on the server, but the browser cannot tell you what. The most important troubleshooting tools are therefore the server error log, WordPress debug log and information about the changes made immediately before the failure.

Start with evidence. Reproduce the problem, compare timestamps and identify the file or process involved. Only then move on to disabling a plugin, testing the theme, checking .htaccess, verifying PHP compatibility or adjusting resource limits.

Once the site works again, disable debugging, verify both the frontend and wp-admin, test critical functions such as forms or checkout, and make sure the underlying cause has actually been corrected rather than merely hidden.