Fix a WordPress 500 Internal Server Error

Narrow down where the 500 error appears

Keep the affected address, the action you attempted and the time together before changing anything. A failure across the whole site needs a different starting point from an error confined to one editor save or upload. Record the last update or hosting change too, so the investigation below can connect the visible symptom with a specific request and recent event.

Chrome Network panel with a selected request and its Status Code in the Headers tab — To inspect a failing page in Chrome, right-click it and choose Inspect, select Network and reload the page. Click the request matching that page address, then open Headers and record Status Code. This unchanged Google example shows 200 OK, not a WordPress failure; match your actual result and time to the hosting log. Credit: Chrome for Developers / Google, CC BY 4.0.

Record the failure and preserve a recovery point

Note the page address, time and action that failed. Check whether the homepage, dashboard and other pages fail too. If a payment or form submission produced the error, check its records before repeating it; a failed response does not prove nothing was saved.

Review the last change: a plugin update, PHP setting, migration or edit to a server file. Take a current backup and retain the last working one. Keep hosting File Manager available so you can reverse a change if dashboard access fails.

Get the matching server error

Open the site's Errors or Logs area in hosting. Ask support for the PHP and web-server error entries matching your recorded time and address if the panel does not show them. The web server receives the request; PHP runs WordPress. A failure before PHP starts will not appear in a WordPress debug log.

Tell the host whether the error affects every request or one action. Ask them to identify a rejected configuration instruction, PHP fatal error, resource limit or upstream failure. If WordPress-level evidence is needed, use the private logging guide and turn it off after collecting the result.

Follow the cause shown by the log

For a plugin fatal error immediately after its update, use targeted plugin deactivation to recover access. Check a compatible repair on staging before reactivation.
An allowed memory size exhausted message needs the memory-error checks. Raising every hosting limit without that evidence does not identify the fault.
A parse error after editing PHP calls for restoring the edited file from its known working copy.
If the host identifies account limits, unavailable services or PHP-process failures, have support correct that hosting condition and repeat the same request.

Undo a confirmed .htaccess change

The .htaccess file contains rules used by Apache and compatible servers. It can control redirects and access restrictions as well as WordPress page addresses. This route applies only if your host confirms the server reads that file and the log or recent edit points to it. Nginx does not use it.

In hosting File Manager, enable the option to show hidden files and open the affected site's directory. Download .htaccess to private storage. If you have the exact copy from before the failed edit, restore that copy and test. Otherwise ask the host to remove or correct only the rejected instruction named in its log.

Avoid deleting the whole file or replacing it with a generic example. That can remove security rules, redirects and configuration needed by a site in a subdirectory or a Multisite network. If the host has restored a standard single site's WordPress rules, open Settings > Permalinks, keep the existing structure and choose Save Changes. Report any unwritable-file notice to the host rather than widening permissions.

Test the repaired action and dependent features

Open the original page while logged out and repeat the failed action with test data. Confirm the dashboard, forms and shop checkout as applicable. If a plugin was disabled during recovery, its feature still needs a compatible repair before you declare the site restored.

Compare the new request time with the error log. Remove temporary diagnostics, record the confirmed cause and keep the working backup. When the error remains unexplained, give the host the failed address and log excerpt instead of moving on to unrelated file replacements.

Reference material

WordPress documents internal server errors. Apache explains the scope of .htaccess configuration; hosting support can confirm whether it applies to your server.

Get help with the next step

If the log points to unfamiliar code or server rules, ask BugShield to investigate the 500 error. Include the failed action and what changed so we can assess a focused repair and confirm its price.

Questions answered

How to fix a WordPress 500 internal server error FAQs

Does a 500 error mean WordPress itself is broken?

No. The status reports a server-side failure without naming its cause. Hosting configuration, PHP code and resource problems need different repairs, so start with the matching error log.

Should I rename .htaccess to fix every 500 error?

No. Confirm that the server uses it and that the error relates to it. Restoring a known working copy preserves custom access and redirect rules that a blanket replacement would remove.

Why does only saving a page produce a 500 error?

Saving runs code and database writes that a normal page view does not. Record that exact action and its error time. Check whether the edit was saved before submitting it again.

Will a cache clear solve the server error?

A cache clear removes stored responses; it does not repair the underlying failed request. Diagnose the server error first, then purge any cached error page after the repair.

What should I send hosting support?

Send the affected address, action, exact time with time zone, recent changes and whether other pages fail. Keep passwords and full configuration files out of the initial message.

Keep troubleshooting

How to fix a WordPress 500 internal server error