When a page shows "Internal Server Error" or simply comes up blank, the server already knows why. It wrote the reason down at the moment it happened. Most site owners never look, and spend an hour changing things at random instead. Reading the log takes a minute and usually names the exact file and line.
Where the logs are
- The web server's log. In cPanel, open Errors in the Metrics section. It shows the most recent few hundred messages for your sites, newest first: blocked requests, missing files, bad
.htaccesslines, firewall hits. - PHP's log. PHP errors are normally written to a file named
error_login the same folder as the script that failed. A problem in a WordPress admin page lands inwp-admin/error_log; a problem on the front page lands in the site's top folder. Open it in File Manager and scroll to the end. - The application's own log. WordPress can keep one when asked; see below.
Timestamps are in the server's time zone, which may not be yours. Reload the broken page, note the time on your watch, and look for the newest lines.
Anatomy of a line
[03-Oct-2026 14:22:07 UTC] PHP Fatal error: Uncaught Error: Call to undefined
function get_field() in /home/youraccount/public_html/wp-content/themes/news/single.php:41Read it in four parts: when it happened, how serious it is (Fatal error stops the page; Warning and Notice do not), what went wrong, and where: the full path of the file and, after the colon, the line number. The "where" tells you which plugin or theme to look at, even if the "what" means nothing to you.
PHP messages, translated
| The log says | It means | What to do |
|---|---|---|
| Call to undefined function … | The code relies on a plugin or PHP extension that is not there. | Reactivate the plugin it belongs to, or enable the extension for your PHP version. |
| Allowed memory size of … bytes exhausted | The script needed more memory than memory_limit allows. | Raise the limit in MultiPHP INI Editor. If it recurs at any size, one plugin is leaking; the path shows which. |
| Maximum execution time of 30 seconds exceeded | The script ran too long. | Usually an import, a backup or a slow outside service. Run big jobs from cron instead of a web page. |
| Parse error: syntax error, unexpected … | A typo in a PHP file. | Open the file at the line given and undo the last edit, or restore the file from backup. |
| Cannot redeclare … / Cannot declare class … | Two pieces of code define the same thing. | Two copies of a plugin, or a snippet pasted twice. |
| Access denied for user … | The database login was refused. | Check the database name, user and password in the app's configuration file. |
| failed to open stream: No such file or directory | The script tried to load a file that is missing. | An incomplete upload or update. Re-upload the plugin or theme. |
| Deprecated: … | The code uses something that a future PHP version will remove. | Not urgent. Update the plugin; it matters at the next PHP upgrade. |
Web server messages, translated
| The log says | It means | What to do |
|---|---|---|
| client denied by server configuration | A rule refused the request. The visitor saw 403. | Find the deny rule in .htaccess in that folder or above it. |
| Invalid command '…', perhaps misspelled | A line in .htaccess is not understood. Every page in that folder returns 500. | Fix or remove that line. The message quotes it. |
| File does not exist | A 404. Often harmless: browsers and bots ask for icons and files you never had. | Ignore the noise; act on the ones that are your own links. |
| ModSecurity: Access denied with code 403 … [id "…"] | The firewall blocked a request it judged suspicious. | If it was a legitimate action, give your host the rule number in the id field and ask for an exemption. |
| End of script output before headers | The script died before sending anything. | Look in PHP's error_log for the same moment; check the file's permissions are 644. |
| Request exceeded the limit of 10 internal redirects | Rewrite rules are sending the request in a circle. | Two conflicting redirect rules. Remove the most recent one you added. |
Turning on WordPress's own log
Add these lines to wp-config.php, above the line that says to stop editing:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Errors are then written to wp-content/debug.log and never shown to visitors. Reproduce the problem, read the file, and when you are done set WP_DEBUG back to false and delete the log. It can grow large, and it is readable by anyone who knows the address.
Keep errors off the public page
In MultiPHP INI Editor, display_errors should be off on a live site and log_errors on. Errors printed on the page reveal file paths and sometimes database details to every visitor. Turn display on only on a staging copy.
Housekeeping
An error_log file that is being written to on every page load can grow to hundreds of megabytes and fill the account. If one is large, read the last lines to find the repeating error, fix that, then delete the file; PHP creates a fresh one when it next has something to say.
When the log is empty
If the page fails and nothing new appears in either log, the request probably never reached your site's code. Check that the domain points at this server, that a proxy in front is not the one returning the error, and that logging is switched on for the PHP version the domain uses.