Quick answer
An HTTP 500 error or a blank page does not by itself prove PHP is broken: the server, application code, database or configuration could be responsible. Record the time and affected URL, test from another device, inspect server and PHP logs, then compare with recent changes. Back up before editing, do not expose errors publicly, and do not delete plugins or data in bulk on a live site.
Key takeaways
- HTTP 500 is a server-side status code, not a specific PHP error.
- A blank page can also result from a hidden PHP error; use logs rather than guessing.
- Record the time, URL and recent changes, and check backups before changing anything.
- If code, a theme or a plugin was just updated, consider a tested rollback or isolation on staging.
- Do not turn on display_errors on a public site: error messages may reveal sensitive information.
What do a 500 error and a blank page mean?
HTTP 500 (Internal Server Error) means the server could not complete the request, but the status code does not identify the cause. A blank page can happen when PHP stops before rendering content, but cache, proxy, template or connection problems are also possible. Do not immediately assume you need a new host or a higher memory limit.
If only one URL fails, record that exact URL. If the whole site fails, check the homepage, admin page and a direct link from another device or network. This helps separate a single-page issue from a sitewide issue or a browser-specific problem.
What should you do in the first ten minutes?
Protect data and collect evidence first. If the website takes orders or leads, tell the team so several people do not change it at once. Someone with technical access should check hosting status, the latest backup and logs at the time the error began.
- Record the URL, time, screen message and most recent change (plugin, theme, code, PHP version or DNS).
- Check the site on another device and in a private window to see whether everyone is affected.
- Capture the error and save relevant logs, but redact tokens, passwords, email addresses and customer data before sharing.
- Confirm that a backup can be restored before editing files or the database.
- If a new release just went live, use a tested rollback procedure rather than making many random changes.
In what order should a technician check PHP, hosting and WordPress?
Start with web-server and PHP logs for the error time, then inspect resource limits and recent changes. The PHP manual says error_reporting determines which errors are reported; log_errors writes them to the location configured by error_log. On a production site, display_errors should be off to avoid exposing confidential information.
For WordPress, a recently updated plugin or theme is one hypothesis, not a verdict. Read the actual error, make a backup, then isolate changes on staging. Do not delete many plugins or edit the production database just because the screen is white.
| Symptom | Check first | Avoid doing blindly |
|---|---|---|
| 500 after an update | Server/PHP logs, recent release or changed plugin | Deleting plugins and data on the live site |
| Blank page | PHP log and template, plugin or theme errors | Showing error messages to all visitors |
| Allowed memory size exhausted | Memory-heavy code or plugin, memory_limit, available host resources | Raising the limit without finding the cause |
| Maximum execution time exceeded | Slow job, query, external service, max_execution_time | Only increasing the timeout |
| Failure only when submitting a form | Logs at submission time, mail/API, input validation | Repeatedly submitting real customer data |
Should you just raise memory_limit or enable display_errors?
A higher limit is not a complete fix. PHP uses memory_limit to cap the memory a script can consume. If a memory error has appeared, find the job, plugin or query whose usage grew. A temporary increase, after checking available resources, may restore service, but you still need monitoring and a root-cause fix.
PHP documentation recommends keeping display_errors disabled in production because error output can include confidential information. A technician should inspect logs privately; do not paste logs containing customer data into a public forum. If you cannot access logs or backups, contact your hosting administrator or website provider.
When should you call a technician or consider maintenance?
Get technical help promptly if orders or leads have stopped, the error recurs, there are signs of a data leak, or you lack a reliable backup. Share the URL, time, error screenshot and recent changes over a secure channel; never post a password in a public comment.
Nextchain.site describes technical maintenance, backups, uptime monitoring and fixing issues arising on websites covered by its monthly plan. For an existing site built elsewhere or an unusual PHP/WordPress problem, submit the details so the team can confirm scope and quote before work begins; do not assume every third-party repair is included.
- If the site still works: record the issue and schedule a root-cause check.
- If forms, checkout or the whole site fail: prioritise safe restoration and investigate on a test copy.
- After the fix: check the homepage, forms and contact page, and monitor logs for recurrence.
