500 Internal Server Error: A Shop Owner's Fix-It Guide
By Arash Latifi — Founder, The DevArt
What a 500 error actually means, the causes that explain almost every case, and the fix order that keeps your store — and its Google rankings — from bleeding out.
TL;DR — A 500 error means your server crashed mid-request and won't tell you why; the real answer is almost always in your server's error log, not on the page.
Why a 500 deserves the same urgency as a hack
You open your store one morning and instead of the homepage you get one line of text: 500 Internal Server Error. No explanation, no stack trace. Customers assume you've shut down, Google quietly starts dropping erroring pages from the index, and worst of all, your admin area is usually down too — the tool you'd normally use to fix it is unavailable.
A recent Sucuri post (October 14, 2026) makes a point most guides skip: a 500 is deliberately vague. The server is saying "something broke and I'm not telling you what" — the real detail lives in your error log, not on the visitor's screen. And sometimes a 500 isn't a bug at all: it's the symptom of a compromised website.
500 vs 502 vs 503 vs 504
They're neighbors, but they point in different directions:
| Code | Meaning | Clue | | --- | --- | --- | | 500 | The server itself crashed processing the request | Deliberately vague — read the log | | 502 | One server got a bad response from an upstream server | Problem between layers | | 503 | Service unavailable or overloaded | Load or planned maintenance | | 504 | Something upstream timed out | One layer isn't answering |
On WordPress, "There has been a critical error on this website" is the same PHP fatal wearing a friendlier coat. A completely blank page is usually a 500 too: the status code came back with no body.
The usual suspects
Nearly every 500 traces back to a handful of causes:
- A faulty plugin, extension, or theme — an update your PHP version can't run, or two plugins defining the same function.
- A corrupt or conflicting
.htaccess— one invalid directive takes down every URL under that directory. - PHP memory exhaustion or a version mismatch — the script dies mid-request.
- Wrong file permissions or ownership — typically files 644 and directories 755 on shared hosts.
- A compromise — files changed with no deployment, no update, no action from you.
The fix order — checklist
The sequence is deliberate: start with the step that reveals the actual cause, then work through causes by frequency.
- [ ] Take a full backup of files and database before changing anything.
- [ ] Read your server's error log — the single most valuable step; it usually names the file and line that failed (hosting panel → Logs).
- [ ] If the log is unhelpful, enable application-level logging (WordPress:
WP_DEBUGandWP_DEBUG_LOGinwp-config.php) — but never display errors on screen on a live site. - [ ] Rule out
.htaccess: rename it to.htaccess_oldand reload. If the site clears, re-save permalinks in WordPress to generate a clean one. - [ ] Deactivate all plugins, confirm the site loads, then reactivate one at a time. Locked out? Rename the
pluginsdirectory over SFTP. - [ ] If the log mentions memory exhaustion, raise
memory_limittemporarily — it's a diagnostic, not a cure; the memory-hungry plugin is the real issue. - [ ] Check your PHP version — if the error started right after a host-side upgrade, roll back temporarily and fix the incompatible code.
- [ ] Verify permissions and ownership: files 644, directories 755, owned by your hosting user. A 777 file is both a functional and a security problem.
- [ ] Check modification times on core, theme, and plugin files — a 500 with no deployment or update from you means something else modified your files.
- [ ] Purge every cache in the chain — page, object, CDN, reverse proxy — caches can keep serving a stale 500 after the fault is fixed.
- [ ] If the log points at something outside your control, ticket your host with the exact timestamp and log line.
How to tell it's a hack, not a bug
Three clear signals:
- The error started with zero deployments, updates, or config changes on your side.
- The log shows files you didn't write executing, or strange PHP files sitting in
uploads. - After a fix, the problem returns — especially in "self-healing" patterns like the malware mesh Sucuri documented in October.
If that's you, stop normal troubleshooting: run a security scan and audit access first, then repair.
After the fix: save your rankings
Downtime duration matters, but Google retries — don't panic, don't linger either:
- If the outage was site-wide and long, re-test key URLs with URL Inspection in Search Console and request reindexing.
- Put a simple (even free) uptime monitor on the store so you hear about the next outage before your customers do.
Q: Why do only some pages return 500 while others load fine?
Usually the failing code or data only loads on those pages — a shortcode, a plugin hook, or a corrupt database record. The error log names exactly which file crashed while rendering that page.
Q: My host says it's my code; I say it's the host. Who's right?
The log decides, not opinions. A log line referencing resource limits (memory, max_execution_time) or server modules points at the host; a file-and-line reference in your code points at you. Include the exact timestamp and log line in the ticket.
Q: The 500 came back after I fixed it. Now what?
The root cause is still alive. The most common pattern: a plugin that runs on cron or during customer checkout and crashes every time. Capture the log at the moment of recurrence — and if the failure "self-heals" and returns, treat compromise as a serious possibility.