A website update finishes, and the next page shows “There has been a critical error on this website.” Sometimes the public site is affected. Sometimes the homepage works while the dashboard, editor, or checkout fails.
That message tells you WordPress could not complete an operation normally. It does not identify a universal repair. The useful next step is to connect the failed request with the relevant error, recent change, and affected component.
This guide takes you through that process, including what to do when no recovery email arrives or you cannot open wp-admin. The aim is to recover access without losing current business data, make the smallest justified change, and verify the original task afterward.
How do you fix a WordPress critical error?
Preserve the current site and record what failed. If a legitimate WordPress recovery email is available, use its Recovery Mode link to inspect the reported component. Otherwise, ask the host for the PHP error associated with the failed request. Use that evidence to isolate a plugin, theme, custom change, runtime issue, or incomplete deployment, then test the repair outside the recovery session.
Start with these actions:
- Record the affected URL, action, time, and recent changes.
- Confirm a current backup or hosting snapshot before changing files.
- Use Recovery Mode if available, or collect the matching server error.
- Isolate the component or configuration identified by the evidence.
- Apply a supported repair or a carefully scoped rollback.
- Retest public pages, administration, and important customer functions.
- Remove temporary diagnostics and document what changed.
Do not overwrite the database or delete application folders simply because a generic tutorial lists those steps. A store or booking site can keep collecting valuable information even while one part of WordPress is failing.
What the critical error message does—and does not—mean
The message commonly accompanies a fatal PHP error, such as an uncaught exception, incompatible code, or memory exhaustion. The WordPress common-errors guide explains several failures that can interrupt normal operation.
The visible screen is a symptom, not proof that the database is lost or the website was hacked. A recent plugin update, a code edit, a runtime change, and a damaged file can require different responses.
Also distinguish this message from a certificate warning, a firewall denial, a database-connection message, or a hosting outage. Those problems may coexist, but a procedure aimed at one will not automatically resolve another.
Record the exact wording and where it appears. “Checkout fails after selecting shipping” is more useful than “the entire website is broken” if the catalog and account pages still work.
| What you can observe | Productive starting point |
|---|---|
| Error appeared immediately after a plugin update | Update history, dependencies, and the matching PHP error |
| Dashboard fails but public pages appear normal | Affected admin request and server logs; public pages may be cached |
| No recovery email arrived | Host logs and administrative email delivery; do not wait indefinitely |
| Error began after changing PHP | Actual web runtime, required extensions, and component compatibility |
| One page or action fails | Its template, request, integration, and matching log entry |
| Error followed a manual code edit | The exact edited file and a verified prior version |
| Suspicious accounts or altered files also appear | Incident assessment alongside ordinary troubleshooting |
Step 1: Preserve access, evidence, and current data
Before making changes, identify the hosting account and the installation you are working on. Many businesses have a production site, a staging copy, and an old installation under the same account. Editing the wrong directory can create a second outage.
Confirm an authorized route to the hosting file manager or secure file access. If the site was built by a provider, determine who owns that access and how emergency work is authorized.
Create a current backup or ask the host for a snapshot where practical. Preserve both files and the database. The WordPress file-backup documentation explains why copying application files alone usually does not capture the database.
Keep the current copy even if an older backup looks easier to restore. New orders, inquiries, reservations, account changes, and uploads may exist only in the current state. A broken plugin does not make those records disposable.
Record the immediate history:
- The first observed failure and its time zone.
- The URL and action that reproduce it.
- Recent plugin, theme, core, PHP, and configuration changes.
- Who made each change and which tool or provider performed it.
- The last known successful version of the affected function.
- Any troubleshooting already attempted.
Pause unrelated edits so the evidence remains interpretable. If several people are changing PHP, plugins, and DNS simultaneously, a successful request will not tell you which change mattered.
If a customer-facing transaction is unreliable, provide an appropriate alternative contact path and coordinate with the business team. Do not ask customers to keep retrying payments while you experiment; duplicate attempts need separate review through the payment and order systems.
Step 2: Take the branch that matches your available access
You do not need to complete every recovery method. Choose the route that provides reliable evidence with the least disruption.
| Available access | Next step | Important limit |
|---|---|---|
| Legitimate recovery email and working sign-in | Open Recovery Mode and record the reported error/component | Your recovery session is not proof the public site is repaired |
| wp-admin still works normally | Inspect recent changes and obtain the matching log entry | Do not deactivate unrelated live features blindly |
| No email, but hosting access works | Ask for logs or use the host’s error-log interface | Do not expose diagnostics publicly |
| No wp-admin, but controlled file access works | Use evidence to isolate a specific component reversibly | Confirm the directory and preserve dependencies |
| No authorized access works | Use the provider’s ownership and access-recovery process | Avoid unknown recovery scripts or public credential sharing |
If you received a recovery email
Verify that the message relates to your site and inspect the link destination before opening it. Treat the full recovery URL as sensitive access information. Do not paste it into a public forum, screenshot, or project document.
WordPress Recovery Mode can pause a faulty plugin or theme for your administrative session so you can inspect the problem. Read the notice and record the identified component and error before taking action.
Pausing something in that session is different from applying a global repair. If you deactivate a component, understand its business role and dependencies. After resolving the issue, exit Recovery Mode and test a normal logged-out session as well as the original failing action.
If the link is unusable, ask the administrator or host to help with the supported recovery process. Do not invent a replacement URL or assume a normal login address creates the same protected session.
If no recovery email arrived
Check the actual administrative mailbox, spam folder, and any organizational quarantine. Confirm that the expected administrative address is current through an authorized source; the address used for a contact form may be different.
WordPress has a dedicated recovery email service with its own sending and rate-limiting behavior. Repeatedly refreshing the failed page does not guarantee another message will arrive.
An early failure can also occur before a plugin that normally handles website email is available. Missing email does not establish that no PHP error occurred or that the site cannot be recovered.
Continue through the host’s logs and access tools. Once the website is stable, investigate its administrative email path separately so the next important notification has a better chance of reaching the right person.
Step 3: Find the error associated with the failed request
Ask the host for the relevant PHP or application error around your recorded timestamp. Include the site, affected URL, action, and time zone. A useful support request asks what stopped that request, not simply whether the server is online.
If the host offers an error-log interface, inspect the installation and time range involved. Different sites and PHP workers may write to different locations. A log from a neighboring domain or a command-line process may not describe your failing web request.
Reproduce the problem once using controlled data if it is safe to do so. Then look for the matching fatal error, uncaught exception, or other terminating failure. A long log may contain old incidents and unrelated notices.
Do not treat every warning as the cause. Some warnings are useful clues; others accompany requests that complete successfully. Correlate the message with the action and its timestamp.
Read a PHP error without jumping to a repair
This is an illustrative log line, not a result from a real website:
PHP Fatal error: Uncaught Error: Call to undefined function example_helper()
in /example/site/wp-content/plugins/example-plugin/src/handler.php:42It provides several leads:
- Type: execution stopped with an uncaught error.
- Operation: the code attempted to call a function that was unavailable.
- Location: the recorded file belongs to an example plugin.
- Line: the reported location is a place to investigate, not necessarily the original cause.
A missing function might reflect a dependency, incompatible versions, load order, a missing file, or another condition. Deleting line 42 is not a justified repair merely because the log mentions it.
Review the surrounding error and stack trace with a developer when needed. A component appearing in the trace may be where the failure surfaced while another component supplied invalid data or failed to load.
Before sharing a log, redact credentials, private paths where appropriate, customer content, authorization information, and sensitive URLs. Preserve the original securely so a qualified person can examine the required context.
Step 4: Use debugging carefully when existing logs are insufficient
Prefer the host’s established logging tools before editing a production configuration file. A developer may reproduce the issue on a restricted staging copy with appropriate diagnostics.
The WordPress debugging handbook documents debugging constants and their limitations. It recommends local or staging use; a temporary production investigation needs deliberate handling and prompt cleanup.
The following illustrative lines enable WordPress debugging and suppress WordPress’s debug display:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );This is not a complete wp-config.php file or a complete logging configuration. Before editing, preserve the original, check for existing or host-managed definitions, and have someone familiar with PHP make the change. Duplicate definitions or a syntax mistake can complicate recovery.
Have the host or developer choose and verify a protected log destination. WordPress supports WP_DEBUG_LOG, but setting it to true normally writes a log under the content directory. Do not create a publicly downloadable collection of customer information or configuration details to diagnose an outage.
The WordPress configuration reference provides broader configuration context. Use an appropriate private path and permissions if file logging is chosen; do not copy an example path without confirming it exists and is protected.
PHP also has server-level logging and display settings. The PHP error-configuration documentation explains these controls. A WordPress setting does not govern every failure that can occur before WordPress loads.
After capturing the needed evidence, restore the appropriate production diagnostic settings and handle retained logs according to their sensitivity. Hiding the error screen alone does not fix the operation that failed.
Step 5: Isolate an implicated plugin reversibly
If the error and recent history point to a plugin, identify its purpose and dependencies before deactivating it. A payment gateway, security integration, membership component, or booking engine can affect more than the page where the error appeared.
When wp-admin works, use its normal plugin controls or a controlled staging test. Record the active state before making the change and test the exact failed action afterward.
When wp-admin is inaccessible, the official troubleshooting documentation describes temporary folder renaming as an access-recovery method. Use authorized hosting file access or a secure method supported by the provider, and confirm you are in the correct installation.
For a targeted example, a folder at wp-content/plugins/example-plugin could be temporarily renamed to example-plugin.disabled. This is an illustrative name, not a command to apply to an unknown installation. Preserve the original name and contents, and rename only the component supported by your evidence.
Do not delete the plugin to perform this test. Deletion, deactivation, and uninstall routines can have different consequences. Restoring the folder name also does not guarantee that the plugin will be active again; check the actual state deliberately.
When all ordinary plugins need to be isolated
A broader isolation test may be useful when evidence is inconclusive, but it can interrupt many business functions. Prefer staging or coordinate a suitable maintenance arrangement with the owner and provider.
The WordPress troubleshooting FAQ describes renaming the ordinary plugins folder, visiting the relevant administration screen, restoring the folder name, and manually reactivating components. Keep a record of the original active set and dependencies.
Do not interpret improvement as proof that every plugin is faulty. Re-enable the required components in a controlled order, reproduce the action, and identify the smallest combination associated with failure.
Ordinary plugin isolation does not cover everything WordPress can load. Must-use plugins, host integrations, and other special components may remain involved. Ask the host to review those rather than removing unfamiliar files at random.
Step 6: Investigate the theme and recent custom code
If the error points into the active theme or a recent custom edit, recover the exact prior version of the affected file from a trusted source. A missing bracket, incompatible function, or incomplete edit requires a different response from a plugin dependency problem.
Compare the changed code with the intended change. Do not remove a line merely because it appears in the error message. A parser can report the place where it finally encountered an inconsistency rather than the place where the mistake began.
For a child theme, distinguish the child’s custom code from the parent theme it requires. Replacing either with an arbitrary theme package can remove functionality or introduce a version mismatch.
If a theme isolation test is justified, use a known compatible installed theme through an authorized workflow, preferably on staging. Preserve the original theme state and relevant settings. Switching themes can change layouts, templates, widgets, menus, and functions that customers rely on.
Do not delete the active theme to force a fallback unless a qualified person has verified the complete recovery path for that installation. Regaining an administration screen is useful, but a public site with broken navigation or checkout is not a completed repair.
For custom code maintained in version control, have the developer review and reverse the specific deployment where appropriate. Check related database or configuration changes before assuming the prior file alone reproduces the prior working environment.
Step 7: Check PHP compatibility, extensions, and memory
PHP changes can expose compatibility problems in code that previously ran without an obvious issue. Confirm the web runtime actually serving the affected site, along with the installed versions of WordPress and its required components.
Do not rely only on a PHP version reported by a command-line session. The hosting configuration used for web requests can differ. Ask the provider to verify the version, relevant extensions, and effective settings for the specific site.
Review component requirements and current support information. The PHP supported-versions page describes the upstream lifecycle; compatibility and provider maintenance also need checking.
If the failure began after a PHP change, capture the matching error before making another change. A missing extension, an unsupported language feature, and a type error do not have the same remedy.
A provider may recommend temporarily returning to a known compatible supported runtime while a component is repaired. Treat that as a documented recovery decision, with follow-up and testing. Leaving an unsupported environment in place indefinitely is not a durable repair.
Avoid creating a publicly accessible diagnostic page that reveals the server’s full configuration. Share the relevant version and settings through an appropriate support channel instead.
When the log reports memory exhaustion
An “Allowed memory size exhausted” error indicates that the request reached its available memory limit. It does not establish why the request needed that much memory.
Examine what triggered the failure: a large import, a complex editor action, a plugin change, unexpectedly broad queries, or another workload. Determine whether the request is reasonable and whether a code problem is causing excessive use.
WordPress documents memory settings in its wp-config.php API reference. The practical limit also depends on the hosting environment and effective PHP configuration. Adding a large number to a configuration file may not change what the worker is allowed to use.
Ask the host or developer to establish the effective limit and the intended resource budget. If an increase is justified, make it within the supported plan and retest the original request. Do not disable limits or use an arbitrary extreme value to conceal a repeating failure.
A higher limit can be a valid capacity adjustment, but it is not proof that inefficient or faulty code has been corrected. Keep the change record and inspect the relevant error after the test.
Step 8: Check incomplete updates and file integrity
A failed deployment or interrupted update can leave missing or mismatched files. Use the update history, file state, and error together before assuming that an intact package needs replacing.
An error about a missing required file may indicate an incomplete package, but it can also involve an incorrect path or dependency. Verify the expected source and version of the component.
For standard WordPress core, a qualified administrator can compare files with the appropriate trusted package or checksum source. The official core checksum command explains its scope and version/locale considerations. An integrity result for core does not validate plugins, custom files, or database content.
Follow the official WordPress upgrade instructions when a core repair or reinstall is needed. Preserve the installation’s content, database, configuration, and custom requirements. Do not replace the entire directory with an empty installation or delete wp-content and wp-config.php as a generic critical-error fix.
For a plugin or theme, obtain a legitimate matching package and understand the consequences of replacement. Premium packages, child themes, and custom code may require their maintainer’s help. Avoid downloading an unofficial copy because it is available more quickly.
If unfamiliar accounts, suspicious modifications, or malicious redirects accompany the error, widen the investigation appropriately. A fatal error alone does not prove malware, and making the page load does not resolve evidence of compromise.
Step 9: Choose a rollback that preserves current business data
A rollback is a recovery method, not automatically a full-site restore. Decide what must be reversed and which current records must remain.
| Proposed action | What to establish first |
|---|---|
| Restore one edited file | The prior file is trusted and compatible with the current environment |
| Return a plugin or theme to an earlier package | Compatibility, security, dependencies, and any changed database structure |
| Revert a PHP change | Provider support, component compatibility, and an appropriate temporary plan |
| Restore the database | Which orders, inquiries, users, and other changes would be overwritten |
| Restore the complete site | The recovery point, data gap, source trust, and validation process |
Preserve the current state before restoring older material. For a brochure site, a recent full restore may be straightforward if little changed. For an active store, the same action can remove legitimate transactions.
WooCommerce’s subscription restore guidance describes risks involving orders, customer information, and subscription changes during the gap between a backup and the present. Involve someone who understands the application and its external payment records before overwriting commerce data.
Also account for code-driven data migrations. Returning only the files to an earlier version may not reverse a database change made during the update. A qualified developer or vendor should establish the compatible recovery path.
Where practical, restore a candidate copy into a restricted environment first. Keep it from sending real customer notifications, charging payments, or triggering fulfillment. Validate the intended result before reconnecting production services.
If a rollback temporarily restores an older vulnerable component, do not treat that state as the finished repair. Coordinate suitable containment and a supported replacement or patch. Record the responsible person and next action.
Step 10: Validate the original task and nearby functions
After a change, reproduce the same failing action using controlled data. Check the matching log window for a new terminating error. A different failure can appear once the original one is removed.
Exit Recovery Mode before confirming normal operation. Use a regular logged-out session as well as authorized administration. A dashboard that works only in a recovery session does not establish that visitors can use the site.
Be aware of caching. A cached homepage may look healthy while an uncached form, cart, or editor still fails. Clear relevant caches after the underlying change according to the host’s process, then test dynamic functions directly.
Use a verification list suited to the business:
- The original page, editor action, or administration screen loads.
- A public visitor can navigate the important pages.
- Forms accept controlled submissions and retain entries where configured.
- Expected notifications reach a controlled recipient.
- Customer account access and password reset work where applicable.
- Cart, checkout, payment handoff, and order state work in an authorized test setup.
- Relevant scheduled work and integrations continue operating.
- The repaired component can run in its intended state.
Do not send real orders to fulfillment or charge a customer to prove a debugging change. Use the appropriate test workflow and verify that any temporary test configuration is removed before ordinary operation resumes.
For a suspected conflict, document the smallest configuration that reproduces it and the configuration that passes. WooCommerce’s conflict-testing guide provides an application-specific reference for that investigation.
If the website works only with an essential feature disabled, record that limitation clearly. The business may choose an interim operating arrangement, but the missing feature still needs an owner and repair plan.
Check scheduled work after pages recover
Some failures occur outside the page a visitor opens. A scheduled email, import, renewal task, or background process can continue failing after the homepage and dashboard appear healthy.
Review the work that matters to this application. Ask whether expected tasks ran during the incident, whether a backlog remains, and whether a later retry could affect customers. The absence of another visible critical-error screen is not enough to answer those questions.
WordPress documents the relationship between WP-Cron and a system task scheduler. Confirm which scheduling arrangement this site actually uses. Other applications may add their own queues and records, so use their supported inspection tools as well.
For a failed task, preserve its identifier, scheduled time, observed status, and matching error. Compare the environment and component versions with those used by the successful web request. A background process may encounter a different workload or execution limit.
Do not run every queued action manually to see what happens. Some jobs can send messages, change inventory, process renewals, or trigger external integrations. Have the responsible administrator determine which operations can be retried safely and which require reconciliation first.
Record the outcome of that review in the repair handoff. If public pages are restored but important scheduled work remains paused, describe the site as operating with that limitation and assign the remaining repair. This prevents an apparently resolved outage from becoming a later customer-service problem.
When the error persists or moves to another component
Stop broad, repeated changes and revisit the evidence. Confirm that you are inspecting the correct installation, request, time range, and log. A new failure message may indicate a second issue rather than proof that the previous change did nothing.
Check whether a deployment or scheduled process is restoring the files you changed. Confirm whether the host applied a configuration adjustment to the site you tested. Note whether the error appears only for an administrator, a customer role, a particular product, or a specific integration.
If ordinary plugins and the theme have been reviewed, the next investigation may involve host-level components, must-use plugins, special cache/database integrations, runtime settings, or custom code loaded elsewhere. Have the responsible developer or host inspect that scope.
Do not start editing database options or renaming special components merely because the simple test failed. Those changes can affect the site’s ability to load and may obscure the original evidence.
Escalate when you cannot establish a reversible step, when records are at risk, or when the fault is outside your access or expertise. Preserving the current state and a useful error report is a productive result, even if the final repair belongs with another provider.
Give the host or developer a report they can use
A concise report can save several rounds of clarification. Include:
- The site and environment affected.
- The exact page or action that fails.
- A timestamp with time zone.
- The matching sanitized error and relevant trace context.
- WordPress, PHP, theme, and implicated plugin versions where known.
- Recent updates, edits, migrations, and configuration changes.
- Changes already tested and their observed results.
- Backup availability and business data that must be preserved.
- The temporary operating state and any disabled features.
Share access through the provider’s agreed secure process. Do not include credentials, recovery links, customer exports, or unredacted payment information in an ordinary ticket.
Ask the provider to explain the suspected cause, proposed change, verification, and remaining uncertainty. “It works now” is useful news, but a short repair record helps prevent the next incident and identifies temporary fixes that still need attention.
Three examples of evidence-led recovery
These are illustrative scenarios, not customer case studies or outcomes from performed tests.
A plugin update breaks the editor, but the public site still loads
Imagine an administrator cannot save a page after an update. A cached public page continues to display normally. The matching error identifies an unavailable function in a plugin extension.
The next step is to check the extension’s required base component and installed versions. A targeted isolation test can establish the relationship. Restoring the entire database would be a broad change without evidence that stored page content caused the failure.
The recovery email never appears
Suppose the owner sees the critical-error screen and finds no administrative message. The host can still provide the PHP error for a controlled request.
That log allows investigation to continue. Recovery does not depend on repeatedly refreshing the page or guessing a special login link. Once the fault is fixed, the owner can separately verify administrative email settings and delivery.
A PHP change interrupts checkout
Consider a store whose catalog loads but checkout fails after the host changes its runtime. The current error points to code that is incompatible with the new environment.
The developer and host should agree on a supported compatibility repair or temporary recovery state, then test the payment path and order behavior. Repeated customer payment attempts or an unplanned database restore would introduce additional business risk.
Reduce the chance of repeating the same outage
Keep an inventory of important components and dependencies. Record changes and their results, including PHP adjustments made by the host. Preserve access to legitimate software packages and the people responsible for custom code.
Maintain a staging process that resembles production in the ways relevant to the test. A staging site with a different PHP version or missing integration may fail to reveal the compatibility issue you were trying to catch.
Use a backup and restore process that accounts for both files and current data. WooCommerce’s backup documentation is a useful reference for stores; the same principle applies to other applications whose data changes between backups.
Verify administrative notifications and an alternative support route. Keep logs available with appropriate retention and access restrictions. A useful baseline is knowing where to obtain the error for one failed request before the next outage occurs.
After recovery, confirm what the installed version and compatibility information show in the available administration tools. The WordPress Site Health documentation explains one source of environment information; its status is not a substitute for testing the repaired business task.
Frequently asked questions
Does the WordPress critical error mean my content is gone?
Not by itself. The message indicates an operation could not complete, commonly because of a fatal PHP error. Content may still exist in the database and files. Preserve the current state and inspect the evidence before attempting a restore that could overwrite newer records.
What if I cannot access wp-admin or receive a recovery email?
Use the host’s official support and access tools to obtain the matching PHP error. With authorized file access and a recoverable copy, a qualified person can isolate a component or repair a specific change. If access itself is missing, complete the provider’s ownership-recovery process first.
Is Recovery Mode the same as fixing the website?
No. It can provide an administrative session in which a faulty component is paused. The public site and normal sessions still need verification after a supported repair. Exit Recovery Mode and test the original failed task rather than relying only on a working dashboard.
Should I deactivate every plugin immediately?
Prefer a targeted test when the evidence identifies a component. A broader isolation test may be appropriate, but it can interrupt payments, security, forms, and other services. Use staging or a coordinated maintenance arrangement, record the active set, and restore dependencies deliberately.
Will increasing the PHP memory limit fix the error?
It may help when the observed failure is memory exhaustion and the request reasonably needs more supported capacity. It will not repair every fatal error. Confirm the effective limit with the host and investigate excessive use instead of setting an arbitrary large value.
Can clearing the cache fix a critical error?
It can remove an old served response after the underlying cause has been corrected. It does not repair incompatible PHP code, missing files, or an exhausted request. Test an appropriate dynamic action and its log so a cached page does not conceal the fault.
Should I restore yesterday's backup?
Only after checking the recovery point and the data that would be overwritten. A scoped file or package repair may be more appropriate. Stores and other active applications need a plan for recent orders, inquiries, customer changes, and any database migrations associated with the update.
Does a file path in the log prove that plugin caused the problem?
It identifies a location involved in the failure, which is a useful lead. The underlying cause may include a missing dependency, incompatible input, runtime differences, or another component. Use the surrounding error, recent changes, and controlled tests before assigning blame or editing code.
When should I stop troubleshooting and get professional help?
Get help when the next step is not reversible, essential business data is at risk, no trustworthy backup exists, or the failure involves code and infrastructure you cannot confidently administer. Provide the matching error and change history so the specialist can continue from evidence.
Recover the function and keep a clear repair record
A durable repair explains what failed, which change addressed it, and how normal operation was verified. Preserve that record alongside the relevant version information and backup arrangements.
Web Expert Solutions provides WordPress troubleshooting, critical-error repair, plugin and theme conflict resolution, and backup restoration. If you need help recovering the site, ask for an investigation of the matching error, recent changes, and safest repair path. Agree on how current business data and access will be protected before work begins.
