WordPress HTTP 500 error: identify the failure and restore your site

Choose the route that matches your failure

An HTTP 500 error means the server did not complete the request. It may come from a plugin, a mistake in a PHP file, Apache rules or an exhausted resource. The number alone does not tell you which repair to choose. However, your last change, the access methods that still work and a log entry often help you make progress quickly.

This guide offers three routes. Start with the one that matches your situation; you do not need to perform every operation. After each test, check the same page in read-only mode and record the result without resubmitting a form or payment. Making one change at a time helps you understand what restored the site. File-based routes apply to self-hosted WordPress with the required access. On WordPress.com, use only the tools available with your plan; on multisite, have the network administrator approve shared changes.

• The dashboard still opens: start with approach 1. You can deactivate the suspected plugin or isolate a conflict with the Troubleshooting plugin.
• Both the site and dashboard are inaccessible: move to approach 2. Your hosting file manager or SFTP lets you disable a specific plugin and read PHP errors.
• The log mentions .htaccess, Invalid command or a rewrite rule: use approach 3, which applies only to the Apache configuration described below.
• The message contains Allowed memory size ... exhausted: then see the memory section. Increasing a limit without this evidence is not a diagnostic method.

Prepare a backup and a reproducible test

Before changing a file, download its original to your computer. For plugin or theme operations, check that a recent backup of both files and database is available. A copy of wp-config.php contains sensitive information: keep it in a private folder, never under a name such as wp-config.php.bak in the site’s public directory.

If your hosting offers staging, use it for tests that would affect visitors. This is a copy with its own database. Disable real payments, email and external automated processes as soon as it is created, before the first visit. If you are working directly on a store, avoid reproducing a payment: an order may have been recorded before its response ended in an error.

Your reference result should be simple: a specific address, a time and what you receive. An image that still displays does not prove WordPress works; it may be served without PHP or come from a cache.

1. Open the home page, a known post and your usual dashboard address. Record which pages fail and which respond.
2. In the browser, open F12, then Network. Reload a public page and select the Document request matching its address. Check that its status really is 500. If the failure appears after a click or save, inspect the Fetch/XHR request already recorded without repeating the action: the main document may return 200.
3. Note the last change: a plugin update, an added snippet, a PHP version change or a saved redirect rule.
4. In your hosting account, locate backups and the file manager. Download the original of the file you will edit, or record the state of the relevant plugin.
5. Keep the same browser and address for the first check. Then compare with a private window to detect a session or cache difference.

Approach 1: deactivate a plugin from the dashboard

This method is suitable when /wp-admin/ works and the failure follows a plugin activation or update. It requires no code. Start with the plugin named in the log or implicated by the last change, rather than deactivating everything.

Deactivation affects the live site and may remove a visible feature. For a payment, login or access-control plugin, test on staging or during a planned maintenance window. Deactivate is not the same as Delete: your aim is to temporarily stop its code loading, not to uninstall its data.

If the page returns, you have identified a likely dependency. You still need to establish whether this is a defect in that plugin or a conflict with another component. Keep its name and version so you can look for a fix. Reactivating it immediately without a change may simply bring the error back.

1. Open Plugins → Installed Plugins.
2. Find the suspected plugin and record its version and current state.
3. Click Deactivate for this plugin only. Do not run an update at the same time.
4. Reload the address that returned the 500 error, then open a post and the dashboard.
5. If nothing changes, reactivate the plugin to restore the initial state for this test, then consult the log before trying another lead.
6. If the site returns, leave the plugin inactive while testing a corrected version on a copy. Check the features it provided before treating the repair as complete.

Isolate a conflict with the Troubleshooting plugin

When the dashboard works but no component stands out, I recommend Troubleshooting for testing within your own session. This free plugin continues the troubleshooting mode previously included in Health Check. It lets you test a reduced set of plugins and a default theme without intentionally changing the configuration seen by ordinary visitors.

This is neither a copy of your database nor an automatic repair button. Do not create an order or change content as a test: writes remain real. Must-use plugins and some caching layers are not isolated like ordinary plugins. Staging remains preferable for an online store; also check the logged-out view if you use this mode.

At the time of this revision, the old Health Check is described as deprecated in its official repository. Use the new plugin listing linked in the callout, then check its required WordPress and PHP versions before installing. If WordPress no longer starts at all, go straight to SFTP: a plugin cannot restore a screen that will not load.

1. Under Plugins → Add New Plugin, search for the exact name Troubleshooting. Check the author Marius L. J. and the link to the official listing, then install and activate the plugin.
2. Open Tools → Site Health, then the Troubleshooting tab, sometimes translated as Dépannage. Enable the offered troubleshooting mode.
3. In this session, open the failing page. If it works with the minimal configuration, a conflict becomes a useful lead.
4. Re-enable your usual theme through the troubleshooting mode controls, then test again. This separates the theme’s effect from that of the plugins.
5. Then enable plugins one by one in the same mode, reloading the page after each. Note which plugin brings the 500 error back.
6. Exit the mode with Disable Troubleshooting Mode in the dashboard or admin bar. If the screen is inaccessible, delete only this domain’s cookies in the browser, then log in again: this also removes the troubleshooting session.
7. Compare with a private window. If the cache retains the troubleshooting view, purge the affected cache and check again. Then apply the targeted fix to the normal site or its staging copy.

Approach 2: disable the suspected plugin through SFTP

If WordPress no longer lets you log in, use your hosting file manager or SFTP with your usual credentials. Open the folder for the correct domain: it should contain wp-admin, wp-includes and wp-content. Do not assume that every account uses a folder named public_html.

The principle is to temporarily rename a single plugin’s folder. WordPress can no longer find its main file and stops loading it. This also affects visitors. On a multisite network, involve the network administrator: several sites may share the folder. Choose a plugin identified in the log or the one just changed; do not rename all of wp-content and hope for the best.

The path wp-content/plugins/extension-exemple below is a template: replace extension-exemple with the name actually present in the log and your files. This procedure does not apply unchanged to must-use plugins in mu-plugins or special cache files such as object-cache.php. If the log points to these elements, follow their provider’s specific instructions.

1. Open wp-content/plugins/ and locate the exact folder of the implicated plugin. Note its name before changing it.
2. For example, rename extension-exemple to extension-exemple.pause. Keep every file; do not delete them.
3. Reload the failing address and try to open the dashboard.
4. If the site returns, log in and open Plugins → Installed Plugins while the folder still has its temporary name. WordPress can then detect the missing file and record the deactivation.
5. Then restore the folder’s original name. In Installed Plugins, check that the plugin remains inactive; do not click Activate yet.
6. If the test changed nothing, restore the original name before pursuing another lead. If WordPress has already recorded the deactivation, also reactivate the plugin from the dashboard once it becomes available again.
7. For a plugin confirmed as the cause, find a corrected version and test it on a copy. Restoring the folder name before deactivation has been recorded may immediately bring it back into service and reproduce the failure.

Enable PHP logging without exposing errors

Start with the PHP log or error log provided in your hosting panel. Reload a public page that produces the 500 error and look for an event at the same time. For a sensitive operation, use the error already recorded. If this log lacks the useful detail and you have access to wp-config.php, WordPress logging can help identify an error that occurs while WordPress loads.

The code uses a private path that you must adapt. The folder must exist, be writable by the PHP process and lie outside every public root in the account. Ask your host for this path if you cannot determine it; do not copy COMPTE literally. On hosting that does not allow this private storage, use the built-in log instead of creating a file exposed to visitors.

Place the constants before the stop-editing line in wp-config.php, and before require_once ABSPATH . 'wp-settings.php'; when it is present: that instruction starts WordPress. The values true and false have no quotation marks. If the constants already exist, edit them in place: two definitions with the same name are not a valid troubleshooting configuration.

1. Download a private copy of wp-config.php and note the current values of WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY.
2. Have an appropriate private folder created, or select one, then replace the example path in the code.
3. Replace existing definitions or add the missing lines before WordPress starts. Do not add another <?php tag to the file.
4. Save, reload the failing page once and read the log file through SFTP or the hosting panel.
5. Record the fatal message, path and affected line. An older warning is not necessarily the cause of the 500 error.
6. If no event appears, check the path, write permissions and server log. This setting will not capture a failure before WordPress initializes. Then remove the temporary diagnostics as explained at the end of the guide.

// Remplacer ce chemin par un emplacement privé réel, accessible à PHP.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/COMPTE/private-logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Turn the log entry into a concrete action

The following three lines are fictional message examples, not records from your server. They show what to identify: the error type, the component named and sometimes the amount of memory. Do not copy these lines into WordPress; they help you interpret a result.

A path to a plugin shows where the failure was reported, but not always which component caused the original defect. For example, a plugin may call a function that depends on another plugin that has been deactivated. After isolating the issue, also compare the stated dependencies and recent updates. Keep a few surrounding lines without transmitting cookies, tokens or visitor data that the log may contain.

• Uncaught Error with a wp-content/plugins/... path: test targeted deactivation of that plugin, then look for the fix or missing dependency.
• Parse error after a file edit: restore that file from its previous copy or fix its syntax as explained in the dedicated section.
• Allowed memory size ... exhausted: check the effective limit and affected process before moving to the memory section.
• An Apache entry containing .htaccess and a rejected directive: follow the next route. If it points to a line outside the WordPress block, correct that specific line; replacing the permalink rules will not remove it.

PHP Fatal error: Uncaught Error: Call to undefined function exemple() in /site/wp-content/plugins/extension-exemple/plugin.php:42
PHP Parse error: syntax error, unexpected token "}" in /site/wp-content/themes/theme-exemple/functions.php on line 120
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

Approach 3: repair the WordPress block in .htaccess

Use this method if your hosting uses Apache with .htaccess rules and the log or your latest change points to those rules. The code below suits a single WordPress site installed at the domain root. It is not suitable for Nginx, a multisite network or an installation where WordPress or its public addresses require special paths.

The aim is to repair the WordPress rewrite block, not erase the server configuration. The same file may contain access restrictions, cache rules, redirects and the PHP engine selection. Keep these surrounding directives. If you have a copy of the file from just before the failure, first compare the recently changed line: a targeted rollback will often be simpler.

The example must replace the block between # BEGIN WordPress and # END WordPress, including the markers. Do not stack two blocks. If the file has a custom structure or no identifiable block, use the configuration for your installation rather than overwriting it. The expected result is restored access to the home page and internal addresses; if only the error changes, continue diagnosing that new message.

1. In the file manager, enable hidden files and open the domain’s document root.
2. Download .htaccess to your computer and keep this private copy for rollback.
3. Confirm that this is a single site at the root on Apache. Identify the two markers around the WordPress block.
4. Replace only that block with the example below. Keep all surrounding directives and save the file under its exact name, .htaccess.
5. Open the home page, a post with a readable address and /wp-admin/. The check must cover all three paths.
6. If the 500 error persists or worsens, restore the previous block from the copy. Restore the whole file only if no other change has occurred since. Read the new log entry to determine whether Apache rejects another directive or PHP fails afterward.
7. If the site returns, move on to permalink checks. Do not reintroduce a recently added rule until you have corrected its syntax or confirmed it is permitted.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Regenerate permalinks when the dashboard works

If the home page is back but posts show 404 errors, WordPress may need to rewrite its permalink rules. This restores the mapping between public addresses and WordPress; it will not repair a plugin that still causes a fatal PHP error.

The address structure must stay the same. Changing all post addresses as a test would create a second problem, particularly for links already shared. On Nginx, the server-side part is handled in a different configuration: saving the WordPress screen does not magically create usable Apache rules.

1. Open Settings → Permalinks and record the selected structure.
2. Without selecting another structure, click Save Changes.
3. If WordPress says the file is not writable, use the rules it supplies for this installation. Do not force 777 permissions.
4. Check two existing posts, a category and any store pages. Confirm that their addresses have not changed.
5. If a feature disappears, compare the file with its backup and restore the necessary custom rules. An accessible home page does not validate every route on the site.

Increase memory only when the log justifies it

The message Allowed memory size ... exhausted means the script reached its memory limit. For example, 134217728 bytes equals 128 MiB. You can consider increasing it to 256 MB if the effective limit is lower and your hosting permits it. This change does not create additional physical memory or bypass a cap imposed on the account.

In WordPress, WP_MEMORY_LIMIT targets normal operation. The dashboard also uses WP_MAX_MEMORY_LIMIT, whose default is generally already at least 256 MB. The suggested code therefore does not promise to fix a dashboard process that already exhausts 256 MB. Check the value applied to web requests in the PHP panel or Site Health information; the terminal value may differ.

An increase that allows a legitimate import may be enough. Consumption that grows with every test instead points to a loop, excessive volume or a component defect. In that case, fix the process rather than removing limits.

1. Note the current limit and the operation exhausting it. Check whether your hosting plan makes 256 MB available for this site.
2. Back up wp-config.php, then look for an existing WP_MEMORY_LIMIT definition.
3. Replace it with the value below, or add it before wp-settings.php loads if it is absent. Do not create a duplicate.
4. Reproduce the failing non-sensitive operation once and check the new log. If the limit has not changed, check the hosting PHP setting.
5. If the failure persists or consumption keeps growing, restore the previous value and examine the component or data volume. Do not use -1 as a universal fix.

// Exemple : uniquement si 256 Mo sont autorisés et utiles pour ce site.
define( 'WP_MEMORY_LIMIT', '256M' );

Fix a syntax error after adding code

If the 500 error appears immediately after editing functions.php, wp-config.php or a plugin file, start with the file named in the log. An extra brace, missing semicolon or second PHP tag may prevent parsing. The reported line is sometimes where PHP discovers the problem; the error may be immediately before it.

The quickest rollback is to remove your addition using the previous copy. Restore the entire file only if no other useful change has occurred since. This removes only the added snippet without restoring a whole database or deleting recent orders. If the snippet was saved in a snippets plugin, use its documented recovery mechanism; do not delete a theme file that was never changed.

The command below is an optional check for people who already have SSH access. It parses the file’s syntax without executing it. Replace the path with the actual file and use a command-line PHP binary with the same version as the site’s PHP. A successful syntax check tests neither WordPress dependencies nor code behavior.

1. Download the failing file to preserve the change and open your previous backup.
2. Compare only the added snippet and the surrounding lines. Do not edit WordPress core files to hide the message.
3. Through SFTP, undo the faulty addition while preserving other recent changes. Then reload the failing read-only page.
4. If you want to keep the new snippet, correct it and check its syntax on a copy before putting it back on the site.
5. With SSH, run the adapted command below. The expected result begins with No syntax errors detected. Otherwise, correct the indicated file and rerun only this check.
6. Finally, test the intended feature on staging: no syntax error does not guarantee no runtime error.

# Remplacer le chemin par celui du fichier à vérifier.
php -l "/chemin/du/site/wp-content/themes/theme-exemple/functions.php"

Check a theme or PHP version change

When the log points to the theme and you regain dashboard access, temporarily changing themes can help establish its role. Prefer staging, because menus, widget locations and presentation may change during the test. Keep the original theme installed for rollback; changing themes does not require deleting it.

A PHP version change can also expose an incompatibility in an old component. The appropriate fix depends on the function cited in the error. Return to the previous version only if the host still supports it and it is compatible with the site; do not choose an abandoned version simply because it makes the message disappear.

1. Under Appearance → Themes, record the active theme and its parent theme if it has one.
2. On the test copy, activate an already installed default WordPress theme that is compatible with your version.
3. Reload the failing page. If it returns, look for a fix to the theme, child theme or dependencies before reactivating everything.
4. If the failure followed a PHP change, open the domain’s PHP setting in the hosting panel and record both current and previous versions.
5. Test the compatible maintained version on the copy, then check the site and log. Some panels apply this setting to several domains: confirm its scope before saving.
6. If none of these tests changes the result, restore the theme and version used at the start of the test, then follow the log instead of trying more and more combinations.

Use Query Monitor for a partial failure

Query Monitor is useful when WordPress can still load the page or dashboard. It helps you inspect collected PHP errors, database queries and outgoing HTTP requests, with information that identifies the component involved. I recommend it for investigating a partial failure or one reproduced on staging, not as a replacement for the server log when the entire site is blocked.

It does not automatically repair a 500 error and shows data for the current page load, not the history of the failure. Collecting that data also uses resources. A failing outgoing HTTP request may explain a broken feature without causing the main response. Examine the items matching the action and the time of the problem. Panels display technical information: do not publish screenshots containing query data or private paths.

1. Under Plugins → Add New Plugin, install and activate Query Monitor by John Blackbourn after checking compatibility with your environment.
2. Using your administrator account, or super administrator account on multisite, open the read-only page that triggers the problem, then open Query Monitor in the admin bar.
3. Inspect the PHP Errors and HTTP API Calls panels when available. Identify the component and message corresponding to your action.
4. If a plugin stands out, confirm with a targeted deactivation or a test in the troubleshooting mode described above.
5. If the page stops before you can read the panels, return to the PHP log. The absence of a usable panel does not mean there is no error.
6. Deactivate Query Monitor after the investigation if you no longer need it, then check the page in an ordinary session.

When to act in hosting rather than WordPress

If the logs report a full disk, an unavailable PHP process or a process limit being reached, the intervention belongs in hosting. You can already record quotas and events from the panel. A healthy daily average is not enough to rule out a spike at the exact time of the error.

Support is needed for work your plan does not let you administer: restarting a failed PHP service, correcting file ownership or adjusting a managed server rule. Supply the evidence you have gathered rather than a general “my site no longer works” request. Ask for the observed cause and the setting changed so that you can verify the repair.

1. Open the domain’s disk-space, file-count and resource indicators. Record the time of any limit breaches.
2. If storage is full, identify large files before deleting anything. If an old backup archive is the cause, copy it to private storage outside the full quota. Verify the copy before removing only that archive from the account, leaving media and the database untouched.
3. If the log reports access denied, record the file and process involved. Do not apply 777 permissions to the entire installation.
4. If a proxy such as Cloudflare sits in front of the site, record the response identifier and ask whether the 500 comes from the origin or intermediary. Keep network protection and HTTPS in place.
5. Provide the domain, URL, time with time zone, exact message and list of tests with their results. Ask for the domain log at that time and the effective values of the relevant limits.
6. After the intervention, perform the checks below yourself. A restart may restore the home page without explaining a failure that will recur during the next process.

Validate the repair and close temporary diagnostics

A repair is conclusive when the page works, the 500 status has disappeared and useful features remain available. First exit Troubleshooting mode and return to the normal configuration chosen for the site, then perform the checks below. Do not settle for a success message in the hosting panel. Repeat the failing scenario with a read operation or a draft that has no commercial consequence.

Restore the previous diagnostic settings. If the site normally used WP_DEBUG set to false, restore that value; remove the private path and other lines added solely for the test, while keeping public error display disabled. Do not remove a permanent logging configuration set up by your provider. Archive the useful log extract in private storage, then remove the temporary file when it is no longer needed.

The final check concerns what the test may have changed: a plugin still inactive, a temporary theme or a removed access rule may leave the site usable but incomplete. Record the established cause, correction and repaired component version so that the next incident does not require starting the whole diagnosis again.

1. Check the home page, two posts, the dashboard and the main request’s status in the browser.
2. Compare with a private window and check the features previously supplied by the deactivated plugin.
3. Save a test draft and reopen it. Real payments or sends require their own test procedure; do not trigger them for this general check.
4. Check that no new corresponding error appears in the log during your test.
5. After the final log inspection, deactivate tools you no longer need and return debugging configuration to its normal state.
6. If an error response remains cached after the fix, purge only the affected cache and check the page again.
7. If the failure returns, keep the new message and time. The first test’s result should guide what comes next: do not repeat every change at once.

Why a successful Apache check does not clear .htaccess

A 500 error related to .htaccess can persist even when Apache’s global configuration check succeeds. Per-directory configuration files are examined in the context of the relevant requests. Checking server startup therefore does not replace loading the precise path and reading its error log.

Ask the administrator to identify the directive, its permitted context and the AllowOverride or AllowOverrideList rule applying to the directory. Two causes require different fixes: a syntax mistake in a permitted directive, or a directive not permitted at that location. Granting all configuration permissions across the whole domain to make one line acceptable would unnecessarily expand the change.

If a plugin wrote the line, also record its origin before correcting it: the plugin might reintroduce it. Change the setting that generates it or use the location recommended by the host. Keep protections outside the permalink block.

The useful validation is restored access to the original path, no new corresponding log error and access restrictions still in place. If it fails, restore only the modified directive from the private copy. A diagnostic plugin cannot fix a directive rejected before PHP and WordPress start executing.