Incident response · Intermediate · 20–40 minutes
How to fix a WordPress 500 error — Start at the Log Line, Not the Guess
Visitors are getting an internal server error, you have no message to work from, and every minute spent guessing is a minute the site is down.
The short answer
Open the error log before you change anything: cPanel's error log, or wp-content/debug.log once WP_DEBUG_LOG is on, will usually name the exact file and line. The 500 page shown to visitors is intentionally vague because error text leaks your stack — the log behind it rarely is, and reading it turns a guess into a fix.
If the log is empty or the error predates WordPress booting, work the causes in order of frequency: a corrupted .htaccess, an exhausted PHP memory limit, a fatal in a plugin or theme, and a PHP version that moved under a component that was not ready for it.
By the HostingFast team · Reviewed 24 August 2026
Intermediate
Assumed skill
20–40 minutes
Wall-clock cost
5
Stages in the runbook
24/7
Engineers on shift
This is an incident runbook, so it is ordered by likelihood rather than elegance. Each step either produces the answer or eliminates a whole class of cause, and none of them requires the dashboard to be reachable.
Note the time the error started before you begin. Nearly every '500 out of nowhere' turns out to be an automatic update, a cron task or a PHP change, and all three leave a timestamp you can line up against the log.
The log ends most of these investigations
cPanel's Errors tool shows recent server-level entries with timestamps; wp-content/debug.log holds WordPress's own once you set WP_DEBUG and WP_DEBUG_LOG in wp-config.php. Check both — the server log catches faults that happen before WordPress boots, and the WordPress log is more readable for everything afterwards.
What you are looking for is a file path and a line number. With those, the remaining work is usually deleting a plugin, reverting an edit, or raising a limit. Without them, everything below is elimination rather than diagnosis, which costs three times as long.
Two checks that clear half the field
Rename .htaccess and reload. If the site returns, the rewrite rules were corrupted — rebuild them by re-saving permalinks under Settings, which regenerates the block cleanly. Broken rewrite rules are one of the three most common causes there are, and the test costs fifteen seconds.
Then memory. A script exhausting its allocation throws a 500, sometimes only under load, which is why the error can appear at four in the afternoon and vanish at seven in the morning. Raise the limit in wp-config.php or the panel's PHP settings and re-trigger whatever caused it.
Bisect from the filesystem
Rename wp-content/plugins to drop everything at once. If the site returns, rename it back and reactivate one at a time. If plugins are clear, rename the active theme's folder so WordPress falls back to a bundled default. Renaming folders works from File Manager or a shell, which matters because a 500 usually takes wp-admin with it.
Keep the passes bounded. Each halving of the plugin list gets you to the culprit in a handful of reloads rather than a linear crawl, and on a site with forty plugins that is the difference between five minutes and forty.
When the PHP version is the change nobody logged
A 500 arriving immediately after a PHP version bump means some component is not ready for it — a deprecated function removed in the new release, usually in an abandoned plugin. Step the version back in the control panel, confirm the site returns, update the laggard, then move forward again.
Per-site PHP switching lives in the panel here, so that whole loop is three clicks and no ticket. Once you are back up, put the offending component on staging and test the newer version there rather than on the site taking traffic.
Where the logs and PHP settings are yours
Every runbook here was exercised on the platform we actually operate — cPanel, LiteSpeed, NVMe storage, one-click installs — so the log locations and PHP screens match yours rather than a generic host's.
Support is a human being at any hour, and the scope covers the awkward practical questions other hosts bounce straight back to you.
- Error logs and PHP settings in the panel, not behind a ticket
- Per-site PHP version switching from the control panel
- Daily backups, so a bad deploy is a one-click undo
- Human support on duty every hour of every day
Why HostingFast
Standard on every plan
Diagnosis before treatment
The first move retrieves a file path and a line number, which is what separates a fix from a sequence of guesses.
Both logs, not one
Server-level errors and WordPress's own debug log catch different failures, and the guide says which catches what.
Ordered by frequency
htaccess, memory, plugin or theme fatal, PHP version — the order the support queue actually sees them in.
Works with wp-admin down
Every action runs from File Manager or a shell, because a 500 usually takes the dashboard with it.
PHP version rollback in the panel
Per-site PHP switching means stepping back a version is three clicks rather than a support ticket.
Scoped honestly
Tracing a 500 to its cause is an intermediate job — 20 to 40 minutes, most of it reading logs.
Quick Start
From order to online
- 1
Read the error log first
cPanel's error log, or wp-content/debug.log with WP_DEBUG_LOG enabled, usually names the file and line. The 500 shown to visitors is vague on purpose; the log behind it rarely is.
- 2
Line the timestamp up against the change
Note when the errors started and compare against update history, cron schedules and PHP changes. '500 out of nowhere' almost always has a timestamped cause.
- 3
Test .htaccess in fifteen seconds
Rename it and reload. If the site returns, rebuild the rules by re-saving permalinks under Settings. Corrupted rewrite rules are among the three most common causes.
- 4
Give PHP more headroom
A script exhausting its memory throws a 500, sometimes only under load. Raise the limit in wp-config.php or the panel's PHP settings, then re-trigger the request that failed.
- 5
Bisect plugins and theme, then check the PHP version
Rename folders in File Manager to disable components from outside WordPress. If the error started right after a PHP bump, step the version back in the panel, update the laggard, and move forward again.
Built In
Loaded onto every plan
- Error logs and per-site PHP settings available in the control panel
- Per-site PHP version switching from the control panel
- Daily backups, with self-service restores you run from the panel
- Staging environments for testing changes before they ship
- SSH, Git and Composer on the developer-focused plans
- NVMe SSD storage on every tier, not just the expensive ones
- LiteSpeed caching built into the server rather than patched in by plugin
- Human support on duty every hour of every day
- 99.9% uptime as the target, monitored around the clock
- In-place account upgrades — no migration when you change plan
Frequently Asked
What people ask us most often
The log is empty and the site still 500s — what now?
That pattern points at something failing before PHP hands control to WordPress: a corrupted .htaccess, a syntax error in wp-config.php, or a PHP-FPM level fault. Rename .htaccess first, then check the server-level error log rather than the WordPress one, since WordPress cannot log an error it never got far enough to raise.
How do I tell a 500 from a 503 or a memory ceiling?
Run `curl -sI https://yourdomain` and read the status line rather than trusting the browser's rendering. A 503 with a Retry-After header is maintenance mode or an overloaded worker pool; a 500 is a fatal in your code path. A memory ceiling usually shows as a 500 that appears under load and disappears when the site is quiet, which is a strong hint on its own.
Where does the platform physically run?
From a London datacentre with redundant power, cooling and multiple upstream carriers, fronted by server-level caching that keeps cached pages quick for visitors anywhere. For most sites the engineering matters more than the pin on the map — NVMe disks, LiteSpeed, and restrained account density per machine move the numbers further than geography does.
Does hosting include mailboxes on my own domain?
Yes — every plan includes mailboxes on your domain, with webmail, IMAP, POP and SMTP plus spam filtering on from the start. There is also standalone email hosting for a domain whose website lives somewhere else entirely.
Keep reading
How to Create a WordPress Child Theme
Customise a theme so the next update rolls straight through without erasing your work — intermediate, roughly 30 minutes.
How to Publish a DMARC Policy
Tell receiving servers what to do with mail that fails authentication, and read the reports before you enforce — intermediate, about 15 minutes plus a monitoring month.
Best Website Builder vs WordPress
Weighed on the numbers that differ: build model, plugin ecosystem, and what each does to page weight.
WordPress Hosting
WordPress on LiteSpeed and NVMe, with staging clones and daily backups included.
Web Hosting
Fast cPanel hosting on NVMe drives — SSL, migration and a year-one domain all included.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Debug where the logs are one click away.
Panel-level error logs, per-site PHP control, staging clones and daily backups — on NVMe behind LiteSpeed, with engineers on shift at any hour.
View WordPress Hosting plans