The debug log records every PHP error, warning, and notice WordPress runs into, and it's usually the fastest way to find out why a plugin broke, a page went white, or an update failed. Turn it on by adding three lines to wp-config.php, reproduce the problem, then read the newest entries at the bottom of wp-content/debug.log.
Turning on the debug log
Open File Manager from your service in the portal, or connect over FTP (see FTP Accounts in the portal), and edit wp-config.php in your site's root directory. Find the line that says /* That's all, stop editing! Happy publishing. */ and add these lines directly above it:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_LOG writes errors to a file instead of printing them on the page. WP_DEBUG_DISPLAY set to false keeps those errors off your live site, which matters since visitors shouldn't see raw PHP warnings. If your wp-config.php already has a WP_DEBUG line further up, either edit it in place or delete the duplicate. WordPress only reads the first definition it finds.
Once the constants are set, reproduce whatever's broken: load the page that errors, trigger the plugin action, or run the import that fails. WordPress will start appending entries to wp-content/debug.log from that point on.
Finding and reading the file
In File Manager, navigate to wp-content/ and look for debug.log. If it doesn't exist yet, nothing has triggered an error since you turned logging on, which is itself useful information. Open it with the built-in code editor, or download it and open it locally, since these files can grow large on an active site.
Read from the bottom up. The newest entries are appended last, so scroll to the end for whatever happened most recently. Each line typically starts with a timestamp, then a severity label:
- PHP Fatal error stops execution. This is almost always the cause of a white screen or a 500 error.
- PHP Warning means something went wrong but WordPress kept running. Common, and often safe to ignore if the site still works.
- PHP Notice or Deprecated flags style issues or upcoming PHP changes. Rarely urgent on its own.
Focus on fatal errors first. The line usually names a file and line number, like in /home/username/public_html/wp-content/plugins/some-plugin/file.php on line 42. That tells you exactly which plugin or theme file to investigate, and whether the problem traces back to a plugin, your theme, or WordPress core.
Matching errors to a recent change
If the fatal error points to a plugin you recently updated or installed, that's your answer: deactivate it from wp-admin → Plugins and confirm the error stops appearing. If you can't reach wp-admin because the error is fatal on every page, rename the plugin's folder in File Manager (add anything to the end, like -disabled) to deactivate it without needing the dashboard.
Before touching a live, working site to test a theory, do it on a staging copy instead. See Using WordPress staging for the safe workflow, and take a fresh backup first regardless, since accounts include nightly automatic backups you can restore from if something goes sideways. On a WooCommerce store, this matters even more: see Running a WooCommerce store for why testing on staging before a risky change protects orders.
Cleaning up after
Debug logs grow fast on a busy site and can eat disk space over time. Once you've diagnosed the issue, delete or truncate debug.log, and consider setting WP_DEBUG back to false if you don't need ongoing logging. Leaving it on doesn't slow the site down much, but an unbounded log file is easy to forget about.
If the log points to a WordPress core file rather than a plugin or theme, or if you're not sure what a fatal error actually means, open a ticket from Support → New ticket in the portal. It goes to a real person, not a bot, and pasting the exact error line from debug.log gets you a faster answer than describing the symptom alone.