A 500 Internal Server Error means the web server received your request but a script or configuration rule failed before a page could be produced. The cause is almost always inside your own site files, PHP code, or permissions rather than in the visitor's browser, and the server hides the technical detail from the public on purpose. The fastest route is to read the PHP error log, fix the first error it names, and reload the page.

The steps below work for HTML and PHP sites. Change one thing at a time and reload after each change, so you know which change fixed the site.

Step 1: Confirm the scope of the failure

  1. Open the failing URL in a private browser window and write down the exact time.
  2. Test the home page and one inner page. One broken page usually means one script or one bad include; every page failing points to .htaccess, permissions, or the PHP version.

Step 2: Read the PHP error log

PHP writes the real reason to a log instead of to the page. Look for a file named error_log in your site folder and open the error log viewer in your control panel.

  • Read from the bottom up: the last lines match the time you recorded.
  • Look for Fatal error, Parse error, memory messages, or a file path.
  • A line such as PHP Parse error: syntax error, unexpected end of file in /home/user/site/wp-config.php on line 27 gives you the exact file and line to open.

If the log stays empty, add ini_set('display_errors', 1); at the top of the failing file, reload, and remove it afterwards.

Step 3: Rule out .htaccess

One bad line in .htaccess can take down every page. In the file manager, rename it to .htaccess.bak and reload. If the site returns, the fault is in that file: restore it, remove the block you added last, or replace it with the default WordPress rules if the site runs WordPress.

Step 4: Check permissions

Files should be 644 and folders 755. Permissions of 777 are commonly rejected by the server, while 600 prevents the web server from reading your files at all. Select your site folder in the file manager, open Permissions, and apply 755 to folders and 644 to files. Change nothing outside your own site folder.

Step 5: Test another PHP version

A theme written for PHP 8.1 can fail on 8.3, and very old code can fail on any recent version. Note the current version in the control panel, switch to the previous supported version, and reload. If the page recovers, update the theme or plugin before moving back up.

Step 6: Bisect plugins and themes

  1. Rename wp-content/plugins to plugins-off. If the site loads, a plugin is responsible.
  2. Rename the folder back and deactivate plugins one at a time, starting with the most recently updated.
  3. If plugins are not the cause, rename the active theme folder so WordPress falls back to a default theme, then test again.

What to send support

  • The full URL, the time with your time zone, and what you see on screen.
  • The last 30 lines of error_log as text, not a screenshot.
  • What changed just before the error started.
  • The PHP version and the steps you already tried.

If the log is missing or the site still fails, send these details through contact. For plan limits that can trigger errors on large sites, see the FAQ.