Why does my website show 500 Internal Server Error?

A 500 Internal Server Error means the server could not complete a website request. The page alone does not identify the cause. Note the failing URL, time and recent changes, then check matching error entries and hosting readings. If it started after a website update, investigate that update before changing PHP, restoring a backup or disabling software.

Record the failure before changing the site

Check whether the home page, another public page and the website's administration page fail in the same way. Record the exact message or take a screenshot. A blank page and a 500 can have similar causes, but report what you actually see.
Note the time and timezone, the action you took and any recent plugin, theme, website-file or PHP change. If the error appeared after a payment or form submission, check the order or submission record before trying again. The action may have completed even though the response failed.
Sign in to your account, open the correct hosting service in Services and choose Log in to cPanel. On a phone, choose cPanel.

Find evidence of the cause

In cPanel, open Errors. Under Latest web server error log messages, look for entries matching the domain, path and failure time. Copy the relevant lines. A message naming a file, an invalid rule or an exhausted memory allowance gives a more useful starting point than the 500 page.
Open Resource Usage and compare the readings with the time of the failure. Use our resource-limits guide to understand usage and faults. Record any faults at the time of the failure to include with your support request.
If the error followed a PHP change, use our PHP-version guide to check which handler and version the website uses. Record the previous and current versions. Do not switch repeatedly between versions or enable extensions at random.
If no matching entry appears in Errors, tell us the website software and failure time so we can help find its application log. Do not turn on public error display, which can reveal private file paths or settings to visitors.

Choose a correction that matches the evidence

If an error names a plugin, theme or recently edited file, ask the website maintainer to inspect that component and the last change. Make a backup before replacing live files or changing stored website data.
If a single update is confirmed as the cause, use the maintainer's tested rollback for that update. Disabling every plugin at once can interrupt checkout, forms and access controls while hiding which change caused the error.
If the log points to .htaccess, have its exact failing rule reviewed. Do not delete the whole file: it may contain security, redirect and routing rules used elsewhere on the website.
If the error mentions memory or a process limit, send us the exact line and resource readings. Increasing a setting or buying a larger plan without understanding the workload can leave the original fault unresolved.
A full restore can replace newer orders, messages or edits. Use it only after choosing the correct restore point and confirming what will be replaced. The backup and restore guide explains how to check the scope first.

Confirm recovery

After the confirmed fix, reload the failing page and check the features affected by the change. For a shop or form, first confirm whether the original attempt created a record, then make one controlled test if needed.
If the cause remains unclear, open Support → New Ticket → Tech/Server. Include the domain, failing URL, time and timezone, exact error, relevant log lines and recent changes. Do not attach a configuration file containing database or email passwords.