HTTP 500 Error: Where Does Real Diagnosis Start?

What to record before contacting support

• The URL returning 500 and when it started.
• The last change you made (plugin, update, file edit).
• A snippet from the error log if available.
• Whether every page fails or only one.

These details cut support rounds from days to hours. Support is not a substitute for reading the log, but a precise description makes their help faster.

500 after moving hosts

Usually an old absolute path in the config, an incomplete database import, or permissions flipped during compression. Check wp-config first, confirm the tables exist after import, then reset permissions. If the site works locally and fails on the server, the problem is the environment, not the code.

The 500 error is the server's generic message: something unexpected happened and it will not say what. That vagueness pushes people into random fixes that make things worse. Structured diagnosis is faster: isolate the failing layer first, then read the evidence the server leaves.

First question: whole site or one page?

• Whole site down: usually configuration, permissions or a fatal in a core settings file.
• One page only: code on that page or a plugin tied to it.
• Dashboard works, front end does not: theme, cache or a front-end plugin.
• Right after an update: likely a plugin or theme incompatible with the PHP version.

Read the log before changing anything

Look for the error log in your hosting panel, or wp-content/debug.log if debugging is enabled. The last ten lines usually name the file and line. If no log exists, enable display_errors on a staging copy, never on a live site, and turn it off after diagnosis.

Most common causes, in order

A three-minute isolation routine

1. Rename the plugins folder to plugins-off and open the site.
2. If it works, the cause is a plugin; restore the folder and enable plugins one by one, testing after each.
3. If not, rename htaccess to htaccess.bak and test.
4. If it still fails, switch to the default theme.
5. If it persists, the problem is configuration, database or the host, not the front end.

After each step, open the page in a private window to bypass cache. Record the result; multiple random changes make the cause impossible to find later.

When is it the host?

If every site on the account returns 500, or something breaks without you touching it, the server, disk space or resource limits may be involved. Check resource usage in the panel and confirm services and the certificate work. In that case do not edit code; contact support with specifics: time, URLs and the last change.

Preventing the next one

• A backup before every update.
• Update plugins on staging when possible.
• Delete abandoned plugins, do not just disable them.
• Review logs monthly instead of waiting for an outage.

A 500 is not a punishment; it is a message that something failed in the last layer. Whoever reads the log first and changes one thing at a time reaches the fix in minutes; whoever changes everything at once ends up with a broken site and no idea why. Start with a backup via the backup plan, and learn permissions in the file manager guide.

The golden rule: one change at a time

Write down what you changed and what happened. If something changes after step three, you know the cause; if the error returns when you undo that exact step, you have confirmed it. This note helps on the next outage too, because failures repeat for similar reasons. And remember some hosts offer a full server-side restore; when available, it beats any diagnosis if you have not made important changes since the copy.