Site shows an error

A blank white page, an HTTP 500 error, or a WordPress critical-error message can result from a PHP error in a plugin, theme, or custom code. Check the error log to identify the cause before changing anything.

If instead you see "Briefly unavailable for scheduled maintenance", the site is stuck in maintenance mode - see Stuck in maintenance mode for the one-click fix.

Read the actual error

The fastest place to see the underlying error is the Logs tab in the Templ Panel - no setup required:

Open your site in the Templ Panel and go to the Logs tab.
Under Log, choose Error log, then click Fetch logs.
Reload the page that errors, fetch again, and read the latest entries. They usually name the file and line causing the error.

If the error log doesn't show enough detail, enable WordPress debugging to capture the full PHP error in a file:

Follow Enable WordPress debugging to turn on WP_DEBUG and WP_DEBUG_LOG.
Reload the page that errors, then read wp-content/debug.log. The last entries usually name the file and line causing the error.

The error message often points directly at a specific plugin or theme file.

Isolate the cause

If the error names a specific plugin, deactivate just that one from the Panel's Deactivate Plugins tool - it works even when the site is white-screened. If the error doesn't name an obvious culprit, deactivate plugins and themes to isolate it: deactivate all plugins and switch to a default theme, then re-enable them one by one until the error returns.

If the site isn't fully down - the error only hits some pages - troubleshoot on a staging site instead, so visitors aren't affected.

Common issues and solutions

Elementor errors after an update

Elementor and Elementor Pro versions that don't work together can cause a critical error or HTTP 500 response. The error log may show:

Class "Elementor\Modules\AdminBar\Module" not found

Check both installed versions under Plugins → Installed Plugins in WordPress. This error alone doesn't confirm a version conflict: an incomplete or corrupt update can look similar, and different version numbers aren't necessarily incompatible.

If the error started after updating one plugin, restore a known-working combination by updating the other to a compatible release or rolling back the recent update. Create a backup before changing versions. If you can't access WordPress, contact support with the error and any version details you have.

Afterward, review both plugins' automatic-update settings. If automatic updates caused the conflict, manage their updates together and test on staging first rather than leaving either plugin outdated.

Database connection errors after a restore or staging copy

If you see "Error establishing a database connection" after restoring a backup or copying staging, database access may have failed even if the data was restored. The message alone doesn't mean the database is missing. Before repeating the restore or replacing the database, contact support with the operation, time including time zone, and error so we can check access and the restored data.

Roll back a recent change

If the error appeared right after an update or edit, undo that change - and restore no more than needed.

If one plugin is at fault, deactivate it as described above - no restore needed.
If broken code is the cause, do a partial restore of only the affected files and check Do not restore database, so you don't lose orders, posts, and other data created since the backup.
For a plugin update, roll it back to the previous version over SSH.
A full backup restore is the last resort, since it also rolls back the database.

If you can't interpret the error, contact support with the relevant lines from the Error log in the Logs tab (or from debug.log) and we'll help you read them.

Verify the fix

Retest the original failing URL with ?nocache=123456 appended (use &nocache=123456 if it already has a query string). Confirm X-Cache-Status: BYPASS using the cache-status instructions; this bypasses Templ Cache, not necessarily a third-party cache.

Test the affected function, not just the homepage, and check logs for the new request's timestamp. An old error entry doesn't mean the problem remains.