How-To

WordPress 500 Internal Server Error: Beginner’s Fix Guide

A safe sequence for diagnosing WordPress 500 errors using logs, recent changes, plugins, themes, PHP and rewrite configuration.

WordPress 500 Internal Server Error: Beginner’s Fix Guide
Quick answer

For a WordPress 500 error, check the most recent change and the server/PHP error log first. Then isolate plugins/themes, .htaccess and PHP compatibility in a controlled order.

A 500 Internal Server Error is deliberately broad: the server failed while handling the request but the browser does not know the underlying reason. The useful evidence is usually in server/PHP logs and the timing of the failure.

WordPress 500 internal server error illustration
TechGuru illustration

Start with the last change

If the 500 appeared immediately after installing or updating a plugin/theme, changing PHP or editing .htaccess, treat that as your first lead.

Check error logs before guessing

A PHP fatal error, memory exhaustion or configuration error often leaves a specific log entry. WordPress documents its debugging tools in the Advanced Administration Handbook.

Test plugins and the active theme methodically

Disable the suspected component first. If you need broader isolation, disable plugins in a controlled way and restore them one at a time while testing.

Inspect .htaccess/rewrite configuration

A malformed directive can trigger server errors. Preserve a copy before editing and do not remove unrelated security or hosting rules blindly.

Check PHP version and resource limits

Use the error message/log to determine whether compatibility or memory is actually involved before changing limits.

Use hosting diagnostics

Hostinger maintains a dedicated 500-error resource within its website troubleshooting section. If the error persists, send support the failing URL, approximate time and relevant log lines.

500 diagnosis checklist

Use the symptom to choose the next check instead of changing several settings at once. Make one change, retest the exact URL, and keep a note of what changed.

Symptom What it suggests Next check
After update Error began after plugin/theme update Isolate that component first
PHP fatal Logs name a PHP file/function Resolve compatibility error
After .htaccess change Error started after rewrite edit Restore known-good configuration
Resource error Logs show memory/time limit Fix the underlying workload or appropriate limit

Before you make a risky change

Take a current backup or restore point before editing configuration files, permissions, PHP settings or database URLs. Avoid deleting unrelated DNS, email, security or rewrite rules simply to see whether the problem disappears.

How to confirm the fix

Retest the exact public URL in a private browser window and, where relevant, on a second device or network. A fix is only confirmed when the original symptom is gone without creating a new error elsewhere on the site.

Keeping this guide accurate

Technology changes quickly. We review and update guides when products, pricing or recommendations materially change.