A WordPress website often breaks without warning: after an update, the page goes completely white, a “critical error” message appears, or the administration panel keeps looping at the login screen. The first rule of WordPress troubleshooting is to read the symptom on screen through logs rather than guesswork; the same white screen may conceal a plugin conflict or an exhausted memory limit. Attempts to resolve WordPress errors without a proper diagnosis often postpone the problem until the next update.
This page presents the most common errors in a table of symptoms, possible causes, and initial checks; white screens, critical errors, 500 errors, and dashboard login problems are then addressed separately. The explanation is based on WordPress.org’s official error and debugging documentation. From Maltepe Gülsuyu, Onur Freelance diagnoses and repairs WordPress websites throughout Istanbul and, through remote access, across Turkey.
Let’s read the error screen together
When a screenshot of the error, any error text, and the most recent change are sent through WhatsApp, an initial assessment of possible causes and the next steps is shared.
When the website crashes, what should remain untouched and what should be recorded first?
When a website produces an error, the first task is to record which change preceded the failure rather than delete files. The error is often connected to the last action taken, and this information is the most valuable clue for shortening diagnosis during WordPress troubleshooting. The following sequence allows subsequent steps to be performed safely:
- Record the exact error text: Note the on-screen message, the URL in the address bar, and which pages show the error (the frontend, dashboard, or both).
- Recall the most recent change: Record whether there was a newly installed plugin, theme update, PHP version change, or hosting migration.
- Check the administrator’s email: When WordPress catches a fatal error, it sends a message containing the error source and a recovery link to the site administrator’s email address.
- Copy the broken state: Before intervention, save the website files and database unchanged in a separate location; this provides a restore point if a wrong step is taken.
- Avoid bulk deletion: Renaming a plugin folder instead of deleting it is a safe way to deactivate it without losing its settings.
Common WordPress errors: symptoms, possible causes, and initial checks
Most WordPress errors fit a few familiar patterns, each with a clear initial checkpoint. The common WordPress errors documentation at WordPress.org lists these patterns individually; the following table makes the same structure, presented in Turkish in the original, readable at a glance.
| Symptom | Possible cause | Initial check |
|---|---|---|
| A completely white page with no information | PHP error, plugin or theme incompatibility | Deactivating all plugins together and switching to a default theme |
| “There has been a critical error on this website” message | Plugin conflict, theme incompatibility, unsuitable PHP version, memory limit | Details and recovery link in the administrator’s email, followed by debug.log |
| 500 Internal Server Error | Corrupted .htaccess, plugin error, PHP memory limit | Temporarily renaming the .htaccess file |
| “Error establishing a database connection” | Incorrect database details in wp-config.php, exhausted quota, server outage | Verifying the database name, username, password, and server address |
| Stuck on the “Briefly unavailable for scheduled maintenance” message | A .maintenance file left behind by an interrupted update | Removing the .maintenance file in the root directory and checking that the update has completed |
| Pages return 404 errors while the homepage opens | Broken permalink rules, missing redirect rule after migration | Saving the Settings > Permalinks screen again |
| “Allowed memory size exhausted” error | Insufficient PHP memory allocated to the operation | Memory limit in wp-config.php or server settings |
| ERR_TOO_MANY_REDIRECTS in the browser | A loop between HTTPS settings, the site address, or a redirect plugin | Comparing the two addresses in General Settings with server and CDN redirects |
| Changes do not appear on the website | Browser, plugin, or server cache | Clearing the cache layer by layer |
The initial checks in the table do not always resolve the problem; they indicate where to look during WordPress troubleshooting. Since a symptom may have more than one underlying cause, the next possibility is investigated when a check produces no result.
Page contents
What causes the WordPress white screen (WSOD), and how is it diagnosed?
A WordPress white screen occurs when a PHP or database error leaves the page blank without showing the visitor any information; the community knows it as the “White Screen of Death” (WSOD). A newly activated plugin or theme usually causes this situation.
If the administration panel is accessible, all plugins are deactivated and reactivated individually to identify the trigger. If the dashboard also fails to open, wp-content/plugins is renamed through FTP or the hosting file manager; this deactivates all plugins without touching their settings. If the plugins are not responsible, the active theme folder is renamed so WordPress falls back to a default theme.
If the white screen appears only on certain pages, the problem is usually a shortcode, page builder component, or form plugin running on that page. In such situations, an error log provides results much faster than deactivating plugins by guesswork.
The WordPress critical error message and recovery mode
The WordPress critical error message reports that a fatal error has occurred on the website, preventing WordPress from working as expected. Recovery mode, introduced with WordPress 5.2, lets the administrator enter the dashboard and pause the problematic plugin or theme in this situation.
According to the WordPress developer note on recovery mode, the process works as follows:
- When a fatal error occurs, visitors see a screen reporting technical difficulties.
- The site administrator’s email address receives the error details and a special recovery mode link.
- For the person logging in through this link, the plugin or theme causing the error is paused and the dashboard opens normally.
- The dashboard shows which plugin was paused and which error caused it; the plugin can be deactivated, fixed, or reported to its developer.
The limitation of recovery mode matters: pausing applies only to the session in that browser, and other visitors continue to see the broken website until the error is fixed. If the administrator’s email address is outdated or inaccessible, the link is never seen; keeping the address in Settings > General current is a prerequisite for recovery mode.
WordPress 500 error: what should be checked on the server?
A WordPress 500 error (Internal Server Error) means the server encounters an error while processing a request without telling the browser why. WordPress.org identifies a corrupted .htaccess file as the most likely cause of this error.
The first check is temporarily renaming .htaccess in the root directory and trying the website again. If it opens, the Permalinks setting is saved again to generate a clean .htaccess. If the error continues, plugins and the theme are ruled out using the same method, the PHP memory limit is increased, and, as a last resort, wp-admin and wp-includes are replaced with those from the official package.
With a 500 error, the main clue for WordPress troubleshooting is often in the server error log in the hosting panel rather than WordPress. The file path and line number in the log directly identify which plugin or PHP version incompatibility is responsible.
I cannot access the WordPress admin panel: causes of login problems
“I cannot access the WordPress admin panel” is a shared symptom of several different problems rather than a single error. Where the login screen gets stuck largely distinguishes the cause:
- The password reset email does not arrive: WordPress sends email through the PHP mail() function by default; if the server does not allow this, the message never arrives. Configuring delivery through SMTP is the lasting solution.
- Logging in returns you to the same screen: Browser cookies, cache, or a mismatch between WordPress Address and Site Address in General Settings creates a login loop.
- “Too many failed attempts” warning: A security plugin has temporarily blocked the IP address; this is bypassed by deactivating the plugin through its files or waiting for the block to expire.
- The dashboard opens, but menus are missing: The user’s role may have changed; user permissions in the database are checked.
- wp-admin shows a white screen: A plugin loaded only in the dashboard is producing an error; the white screen steps are repeated for the dashboard.
If an unfamiliar administrator account, an unexplained password change, or visitors being redirected to other websites accompanies the login problem, the issue may be a security breach rather than a configuration error. In this situation, the hacked WordPress site recovery process is followed instead of a standard repair.
Let’s repair the source rather than the symptom
Once dashboard or hosting access is shared securely, the error log is read first, the source of the problem is shared with the site owner, and repairs are performed within the approved scope.
Debugging with WP_DEBUG: safe use on a live website
WP_DEBUG is a constant added to wp-config.php that allows WordPress to display PHP errors, warnings, and notices. Because its default value is false, error details are normally hidden; this constant reveals the file and line behind a white screen or critical error message.
The debugging documentation at WordPress.org recommends using debugging tools on local or test (staging) installations rather than live websites. When brief diagnosis on a live website is necessary, errors are written to a file without being displayed on screen:
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );
With this setting, errors are collected in wp-content/debug.log and visitors see no technical details. The lines must be added before the “That’s all, stop editing!” comment. Once diagnosis is complete, the settings are turned off and the log file is deleted; the WordPress Site Health screen also flags a potentially public log file as a critical issue.
The WordPress troubleshooting process step by step
The WordPress troubleshooting process consists of collecting information, making a safe copy, isolating the problem, repair, and verification. At Onur Freelance, every job begins with a backup taken before intervention.
- Initial information: The error text, screenshot, latest change, and the website’s critical functions (forms, payments, membership) are established.
- Access and backup: Dashboard, hosting, or FTP access is obtained; a full backup of the files and database is saved outside the website.
- Reading logs: The server error log, debug.log, and Site Health report are reviewed.
- Isolation: For testing without affecting live visitors, troubleshooting mode in WordPress.org’s Health Check & Troubleshooting plugin is used; it disables plugins and the theme only for the logged-in user. If necessary, a copy of the website is placed in a test environment.
- Repair: The problematic plugin is updated or replaced, or incompatible code is corrected; server settings such as the PHP version, memory limit, or redirect rules are adjusted.
- Verification: The homepage, contact form, and any cart and checkout steps are tested on desktop and mobile; debugging settings are turned off.
- Reporting: The identified cause, changes made, and recommendations to prevent recurrence are communicated to the site owner in writing.
Why is simply turning off the plugin insufficient?
Disabling the plugin producing the error opens the website, but often also removes the function that plugin provided. In common practice, the job ends here; a website with a nonworking form, a missing checkout page, or lost translations is handed over as “fixed.”
In root-cause-focused repair, the question is why the plugin fails rather than which plugin fails. The same plugin may have broken because it is incompatible with PHP 8, conflicts with another plugin performing the same function, or suffered an interrupted update; each has a different solution. If there is incompatibility, a current version or equivalent plugin is found; if there is a conflict, the unnecessary plugin is removed; if server settings are insufficient, they are corrected on the hosting side.
In WordPress troubleshooting, this approach makes the initial intervention slightly longer, but reduces the likelihood of the same error returning with the next update and leaves the site owner a record explaining what changed and why.
Common mistakes that make the problem worse and the correct method
Some rushed interventions when an error occurs can turn a small problem into data loss. The most common mistakes encountered in practice and what should be done instead are:
- Updating without a backup: A core, theme, or plugin update is performed without a backup; if the update is interrupted, no restore point remains.
- Deleting the plugin folder: Deletion can also remove settings for some plugins; renaming provides the same diagnosis without loss.
- Writing the WP_DEBUG value in quotation marks: A quoted value such as ‘false’ is read as text and keeps debugging enabled instead of disabling it.
- Leaving the error screen visible on the live website: When WP_DEBUG_DISPLAY remains enabled, file paths and server information are visible to visitors.
- Editing theme files from the dashboard: A single missing semicolon in functions.php can take the entire website offline; code changes are made through FTP and with a backup.
- Installing overlapping caching plugins: Two plugins doing the same job disrupt each other’s rules and make the “changes do not appear” problem persistent.
Service scope, required access, and quotation
Onur Freelance’s WordPress error resolution service covers diagnosis, backups, repair, testing, and written reporting. Work is performed remotely, face-to-face meetings are available within Istanbul on request, and inquiries are answered between 09.00–21.00.
To begin, the error text or screenshot, a WordPress administrator account, and hosting panel or FTP access are sufficient. Since the depth of each problem differs, pricing is shared through a quote finalized according to scope after an initial review. The main factors affecting the quote are whether the problem originates on the server or in the application, whether a current backup exists, and whether the website includes sensitive functions such as WooCommerce or membership.
If the error originates in slowness or timeouts, it can be addressed through speed optimization and performance improvement; if the problem began after a hosting change, it can be addressed within WordPress site migration. Preventing the same errors through regular updates and backup checks falls within the annual WordPress maintenance and updates service.
Let’s get your WordPress website working again
You can ask what a single error message means or plan a complete repair. Once the website address and symptom are shared, an inspection is performed, followed by a written job description and price.
Related guides
- How can a 500 Internal Server Error be fixed?
- 403 Forbidden error: resolving an access block
- ERR_TOO_MANY_REDIRECTS redirect loop
- How can a WordPress critical error be fixed?
- Error establishing a database connection
- If the website broke after a WordPress update
- If you cannot log in to the WordPress admin panel
- If a website does not open: causes and solutions
- If Elementor is not loading: troubleshooting
- WordPress specialist in Istanbul
Frequently asked questions
How is the WordPress white screen error fixed?
A white screen is usually caused by a plugin or theme incompatibility. If the dashboard is accessible, all plugins are deactivated and reactivated individually; if it is inaccessible, wp-content/plugins is renamed through FTP. If the cause cannot be found, errors are logged with WP_DEBUG_LOG.
What does "There has been a critical error on this website" mean?
The message indicates a fatal PHP error that stops WordPress from working. WordPress then sends the error source and a recovery mode link to the site administrator’s email address; this link allows access to the dashboard to pause the problematic plugin.
What causes a WordPress 500 error?
The most common cause is a corrupted .htaccess file. A plugin error, an insufficient PHP memory limit, and a PHP version incompatibility can also produce the same error. The exact cause is read from the server error log in the hosting panel.
I cannot access the WordPress admin panel; what should I do?
First, check where the login screen gets stuck: if the password email does not arrive, check SMTP settings; for a login loop, check cookies and site address settings; for an IP block, check the security plugin. If an unfamiliar administrator account or suspicious redirect is present, the website is examined for hacking.
How is the "Error establishing a database connection" error fixed?
First, verify the four details defined in wp-config.php: the database name, username, password, and server address. If the details are correct, ask the hosting company about the database quota and server status.
Can WP_DEBUG be left enabled on a live website?
It should not be. WordPress.org recommends debugging tools for test environments; if brief diagnosis is necessary on a live website, errors are written to debug.log rather than displayed, and after diagnosis the setting is disabled and the log file deleted.
What information is needed to resolve WordPress errors?
The error text or screenshot, the most recent change, a WordPress administrator account, and hosting panel or FTP access are sufficient. Access details are shared through a secure channel, and changing passwords after the job is recommended.
How is the fee for WordPress troubleshooting determined?
The fee depends on the source of the problem, backup availability, and whether the website includes sensitive functions such as WooCommerce or membership. A fixed list price is not applied; the scope and a firm quote are shared after the initial review.
