There Has Been a Critical Error on This Website: How to Fix It in WordPress

A WordPress critical error usually appears at the worst possible time: right after an update, during a busy sales day, before a client reviews your site, or when someone finally clicks through from Google. Instead of your homepage, product page, login screen, or dashboard, visitors see a plain message that says:

There has been a critical error on this website.

That message can feel vague, but it does tell you something important. WordPress has hit a fatal PHP error that stopped the page from loading. The cause is often a plugin conflict, a theme problem, a failed update, a PHP version mismatch, a memory limit issue, or custom code that broke after something changed.

The good news is that “wordpress there has been a critical error on this website” is usually fixable. The key is to work carefully. Do not randomly delete plugins, overwrite files, or keep refreshing the site hoping it resolves itself. A calm troubleshooting process can help you restore access, identify the cause, and reduce the risk of the same problem happening again.

Key Takeaways

• A WordPress critical error usually means a fatal PHP error stopped WordPress from loading normally.
• Start by checking your admin email for a WordPress recovery mode link.
• If recovery mode is unavailable, use hosting access, FTP, or File Manager to disable the likely plugin or theme.
• Avoid deleting files unless you have a verified backup and know exactly what you are removing.
• Most critical errors after updates come from plugin, theme, PHP, or compatibility issues.
• A staged update process, backups, and routine maintenance can prevent many repeat failures.

What the WordPress Critical Error Message Means

When WordPress displays “There has been a critical error on this website,” it means WordPress encountered a fatal error that stopped the current request. In plain English, something in the site’s code failed badly enough that WordPress could not continue loading the page.

That “something” might be a plugin function, theme file, PHP compatibility problem, missing file, database issue, memory exhaustion, or custom code snippet. WordPress has built-in error protection and recovery mode features designed to help site owners regain access when a plugin or theme causes a fatal error, and its official recovery mode documentation explains how this can help users log in safely and troubleshoot the issue.

For business owners, the error matters because it does not just affect the technical side of the website. It can interrupt leads, calls, quote requests, online sales, appointment bookings, ads, email campaigns, and organic traffic. If the broken page is your homepage, a service page, or a checkout flow, the issue can quickly become a business problem rather than a simple website annoyance.

Critical error vs. white screen vs. 500 error

These issues are related but not always identical. A critical error is the message WordPress shows when it catches a fatal problem. A white screen of death may show nothing at all. A 500 internal server error may come from WordPress, the server, PHP, file permissions, or a hosting configuration issue.

Error type	What visitors may see	Common cause	Best first step
WordPress critical error	“There has been a critical error on this website”	Plugin, theme, PHP, or code failure	Check recovery mode email
White screen	Blank page with no visible message	Fatal PHP error or memory issue	Check logs and enable debugging
500 internal server error	Browser/server error page	Server, PHP, permissions, or .htaccess issue	Review hosting logs
Dashboard-only crash	Front end works, admin area fails	Admin plugin, builder, update, or code conflict	Disable recent plugins
Page-specific crash	One page fails, others load	Builder module, shortcode, custom template	Check that page’s plugins/templates

The important point is not the label. It is the process. You need to identify what changed, isolate the failing component, restore access, and test the site before calling it fixed.

Why this error often appears after an update

Many site owners see a WordPress critical error after update work. That does not always mean the WordPress core update itself was the problem. More often, the update exposed a compatibility issue between WordPress, a plugin, a theme, a page builder, PHP, or custom code.

For example, a plugin that worked on an older PHP version may fail after the hosting environment changes. A theme function may rely on outdated code. A custom snippet may call a plugin function that no longer exists. A WooCommerce extension may conflict with another extension after both are updated.

That is why a professional update workflow includes backups, staging, update order, error log checks, and post-update testing. If your site is important to your sales or operations, routine WordPress website maintenance and updates should be treated as part of keeping the business open online, not as a minor admin task.

How to Fix WordPress There Has Been a Critical Error on This Website

The safest way to fix wordpress there has been a critical error on this website is to start with the least destructive options. Your goal is to restore access without losing settings, content, design work, orders, form entries, or SEO data.

Before changing anything, pause and answer one question: what changed right before the error appeared? The answer often points you toward the cause.

Maybe someone updated plugins. Maybe the host upgraded PHP. Maybe a developer added custom code. Maybe a theme update failed halfway through. Maybe the site was moved to a new server. Write that down before you start clicking around.

Step 1: Check your WordPress recovery mode email

When WordPress detects certain fatal errors, it may send an email to the site administrator address. That email often includes a special recovery mode link. The link can let you access the dashboard in a limited state so you can deactivate the plugin or theme that caused the failure.

Look for an email with wording related to a fatal error, technical issue, or recovery mode. Check the inbox, spam folder, and any shared admin mailbox your business uses. If the email points to a specific plugin or theme, do not ignore that clue.

Once inside recovery mode, deactivate the problem plugin or switch away from the problem theme. Then test the site in a normal browser window. Recovery mode is usually a temporary way to regain access, not the full fix by itself.

Step 2: Back up the site before making deeper changes

If you still have hosting access, create a backup before making file-level changes. Ideally, back up both website files and the database. If your host has automatic backups, download or create a fresh backup point before you disable plugins, rename folders, edit wp-config.php, or change PHP settings.

This matters because troubleshooting can create a second problem if it is done too aggressively. For example, deleting a plugin folder may remove files that are still needed for settings, add-ons, or custom features. Changing the wrong PHP version may break another part of the site. Editing a file with one missing character may create a new fatal error.

A backup gives you a way back if the first fix does not work.

Step 3: Disable the most likely plugin

If the error appeared right after a plugin update or installation, disable that plugin first. If you cannot access the WordPress dashboard, use your hosting File Manager or FTP.

A typical path looks like this:

/public_html/wp-content/plugins/

Find the folder for the plugin you suspect and rename it. For example:

contact-form-plugin

could become:

contact-form-plugin-disabled

Renaming the folder prevents WordPress from loading that plugin. If the site comes back, you have likely found the source. WordPress also recommends using its common WordPress errors documentation as a starting point when troubleshooting issues such as critical errors, white screens, database errors, and login problems.

If you do not know which plugin caused the issue, rename the whole plugins folder to something like plugins-disabled. Then create a new empty folder named plugins. If the site loads, restore the original folder name and disable plugins one by one until you identify the conflict.

Step 4: Switch to a default theme

If plugins are not the issue, the active theme may be causing the fatal error. This can happen after a theme update, PHP update, child theme edit, or custom function change.

If you can access the dashboard, switch to a default WordPress theme temporarily. If you cannot access the dashboard, use your hosting File Manager or FTP and go to:

/wp-content/themes/

Rename the active theme folder. WordPress may fall back to another installed theme if one is available. If no default theme exists, you may need to upload one through hosting access or restore the previous working theme from backup.

Theme-related errors are common on older business sites where the theme has been heavily customized over several years. A small edit in functions.php can break the entire site if the code contains a syntax error or calls a missing function.

Step 5: Turn on WordPress debugging carefully

If you still cannot identify the issue, debugging can show the exact file and line where the error occurs. WordPress provides debugging constants such as WP_DEBUG and WP_DEBUG_LOG, and its debugging in WordPress guide explains how these settings can help write errors to a log file instead of displaying them publicly.

In wp-config.php, you may add or adjust:

define( ‘WP_DEBUG’, true );

define( ‘WP_DEBUG_LOG’, true );

define( ‘WP_DEBUG_DISPLAY’, false );

This can create a log file at:

/wp-content/debug.log

Use the log to look for the fatal error. You may see a path that points to a plugin, theme, custom code file, or PHP compatibility issue.

Do not leave debugging visible on a live site. Public error messages can reveal sensitive file paths or technical details. The WordPress Site Health screen documentation also notes that debug information can contain sensitive details that should not be publicly available.

Step 6: Check PHP version, memory, and server logs

If the critical error started after a hosting change, check the PHP version. Some older plugins and themes may not work with newer PHP versions. Some newer plugins may expect a more current PHP version than your server provides.

In your hosting panel, look for PHP settings, error logs, or server logs. Common clues include:

• “Allowed memory size exhausted”
• “Call to undefined function”
• “Cannot redeclare function”
• “Parse error”
• “Uncaught Error”
• “Fatal error”
• “Class not found”
• “Failed opening required”

A memory error may require increasing the PHP memory limit, but that should not be treated as a permanent fix if the real issue is a bloated plugin, broken query, malware infection, or runaway process.

Common Causes After Updates, Plugins, Themes, and PHP Changes

Most WordPress critical errors are not random. They happen because something changed in the site’s software stack. WordPress sites depend on several moving parts: WordPress core, plugins, themes, PHP, the database, server configuration, caching, and sometimes third-party APIs.

When one layer changes, another layer may no longer behave as expected.

Plugin conflicts

Plugins are the most common place to start because many WordPress sites rely on several of them. A small business website may use plugins for forms, SEO, caching, redirects, security, analytics, backups, sliders, image optimization, custom fields, page building, reviews, popups, and ecommerce.

A plugin can trigger a critical error when it:

• Uses code that is not compatible with the current PHP version
• Conflicts with another plugin
• Depends on a missing extension or library
• Fails during an incomplete update
• Calls a function that has been removed or renamed
• Loads on a page where it should not be running
• Has a licensing or add-on mismatch

For example, a service business might update its form plugin and page builder on the same day. The homepage works, but the contact page crashes because the form module calls an outdated function. The fix is not to rebuild the whole site. The fix is to isolate the form plugin, check compatibility, roll back safely if needed, and test the contact flow.

Theme and child theme issues

Themes control more than design. Many themes also include templates, functions, scripts, shortcodes, page builder integrations, and custom post types. A theme issue can break the front end, admin area, or specific page templates.

Child themes can also cause problems if custom code was added without testing. One extra comma, missing bracket, or outdated function in functions.php can bring down the site.

This is especially common when a business has had several people work on the site over time. A marketing contractor adds tracking code. A developer adds a custom shortcode. A previous agency modifies templates. Years later, an update exposes the fragile part of the setup.

If your site has accumulated years of patches, a broader WordPress site maintenance review may be more useful than fixing only the current error.

Failed or incomplete updates

A WordPress critical error after update work can happen when the update process stops midway. This might be caused by a timeout, low server resources, file permission issues, caching conflicts, or a connection interruption.

Signs of a failed update may include:

• The site breaks immediately after updates
• A plugin folder looks incomplete
• The dashboard shows maintenance mode
• Files have unusual timestamps
• A plugin appears installed but not fully loaded
• The error log points to a missing file

When this happens, do not keep clicking update repeatedly. Confirm backups, check file integrity, and reinstall the affected plugin, theme, or WordPress core files carefully.

PHP compatibility problems

PHP is the server-side language WordPress runs on. When your hosting provider changes PHP versions, old plugins or themes may fail. The opposite can also happen: newer plugins may expect a newer PHP version and fail on an outdated server.

A PHP compatibility issue may show errors such as deprecated functions, missing classes, fatal type errors, or syntax errors. If your host recently changed PHP versions, temporarily switching back may restore access, but the better long-term solution is to update or replace incompatible code.

For business sites, PHP changes should be tested before being applied to production. This is one reason managed CMS updates and management can be valuable for sites that cannot afford surprise downtime.

Custom code snippets

Many WordPress sites use custom snippets added through a plugin, the theme’s functions.php file, the header/footer area, or a custom functionality plugin. These snippets may handle tracking, redirects, custom post types, shortcodes, checkout adjustments, schema, or form behavior.

Custom code is powerful, but it should be documented. If nobody knows why a snippet exists, troubleshooting becomes slower. A simple code inventory can save hours during an outage.

A Safer Recovery Workflow for Business Websites

A business website needs more than “try this random fix.” It needs a recovery workflow that protects the site while narrowing the cause. The goal is to restore the site without creating new damage.

Here is a practical process you can follow.

Critical error recovery checklist

Step	What to do	Why it matters
1	Note what changed before the error	Helps identify the likely cause faster
2	Check the recovery mode email	May point directly to the broken plugin or theme
3	Create or confirm a backup	Protects files, database, settings, and content
4	Check hosting error logs	Shows the actual fatal error details
5	Disable the likely plugin or theme	Restores access without deleting data
6	Turn on debug logging if needed	Gives more precise technical clues
7	Restore the site on staging if possible	Allows safe testing before live changes
8	Update, replace, or roll back the cause	Fixes the real issue, not just the symptom
9	Test key business actions	Confirms forms, checkout, calls, bookings, and pages work
10	Document the fix	Makes future support faster

Example: a service business site breaks after updates

Imagine a local remodeling company updates WordPress, its page builder, SEO plugin, caching plugin, and contact form plugin all at once. A few minutes later, the homepage loads, but the contact page shows “there has been a critical error on your website wordpress.”

The business owner checks the admin email and finds no recovery link. The host error log shows a fatal error inside the contact form plugin. Instead of deleting the plugin, they rename the plugin folder through File Manager. The site loads again, but the contact form is missing.

The next step is not to leave the form broken. A safer fix would be:

1. Restore the previous working plugin version from backup or install a compatible version.
2. Test the form on staging.
3. Send a test submission.
4. Confirm the email notification arrives.
5. Clear cache.
6. Test the live contact page from a private browser window.
7. Document the plugin version that caused the error.

That process solves the technical issue and protects the business function that matters most: lead capture.

When to restore from backup

Restoring a backup can be helpful, but it should not always be the first move. If you restore the whole site without understanding the cause, the same error may come back during the next update.

A backup restore is usually appropriate when:

• The site broke after a failed update and files are incomplete
• The error happened after accidental file deletion
• A theme or plugin change caused widespread damage
• The site was compromised and cleanup requires a known-good restore point
• The database was damaged or changed incorrectly
• A live store or lead site needs fast rollback while deeper testing happens elsewhere

For ecommerce sites, be careful with full database restores. A database rollback can remove recent orders, customer accounts, form entries, or bookings. In that case, you may need a more careful file-level rollback or professional help.

What to test after the site loads again

A site that “loads” is not automatically fixed. After a critical error, test the parts of the site that affect business outcomes.

Check:

• Homepage
• Main service pages
• Contact page
• Forms and notification emails
• Quote request flows
• Appointment booking
• Checkout and payment flow
• Login and account pages
• Search function
• Navigation menus
• Mobile layout
• Tracking scripts
• Redirects
• Caching behavior
• Sitemap and robots settings
• Important landing pages from ads or SEO

If the error affected a plugin tied to forms, ecommerce, SEO, security, caching, or redirects, test those features directly. Do not assume they are fine because the homepage loads.

How to Prevent Critical Errors From Happening Again

You cannot prevent every WordPress issue, but you can reduce the risk. Most repeat critical errors happen because updates are handled casually, backups are untested, plugins are added without review, or old themes stay in place too long.

A prevention plan does not have to be complicated. It needs to be consistent.

Use a staged update process

A safer update process looks like this:

1. Check current backups.
2. Review plugin, theme, WordPress, and PHP compatibility.
3. Update on staging first.
4. Test the most important pages and features.
5. Apply updates to production.
6. Clear cache.
7. Test again on the live site.
8. Monitor logs for new errors.

This is especially important for WooCommerce, membership, booking, learning management, directory, and lead generation websites. These sites often rely on multiple plugins working together.

If your website brings in leads or revenue, consider whether DIY updates are still worth the risk. A structured website maintenance service can help keep updates, backups, monitoring, and troubleshooting from becoming last-minute emergencies.

Keep plugins lean and reviewed

Every plugin adds code, update requirements, compatibility concerns, and potential conflict points. That does not mean plugins are bad. It means they should have a reason to exist.

Review your plugin list and ask:

• Is this plugin still active and maintained?
• Does the site still need it?
• Is there another plugin already doing the same job?
• Does it affect performance?
• Does it load scripts on every page?
• Is it compatible with the current WordPress and PHP versions?
• Does it handle sensitive data, payments, forms, or security?

Remove plugins that are inactive, abandoned, duplicated, or no longer needed. Before removing anything, confirm whether it stores data or powers a visible feature.

Maintain clean access and documentation

Many critical error recoveries take longer because nobody knows who has access to what. Keep a secure record of your hosting login, domain registrar, WordPress admin account, backup system, CDN, email provider, and key plugin licenses.

Also document:

• Active theme and child theme
• Critical plugins
• Custom code snippets
• Hosting PHP version
• Backup schedule
• Update process
• Staging site access
• Known plugin conflicts
• Emergency contact or support provider

This documentation does not need to be fancy. A simple private support document is better than guessing during an outage.

Watch for warning signs before the site fails

Critical errors sometimes appear suddenly, but many sites show warning signs first.

Look for:

• Frequent plugin update failures
• Random dashboard errors
• Slow admin screens
• Forms that sometimes fail
• Checkout errors
• PHP warnings in logs
• Site Health warnings
• Deprecated code notices
• White screens on specific pages
• Caching issues after updates
• Plugin conflicts after every maintenance cycle

If these problems keep returning, the site may need a deeper technical review. Repeated patching can cost more over time than cleaning up the theme, reducing plugin bloat, replacing abandoned tools, or rebuilding fragile sections properly.

Keep WordPress Recovery Calm and Methodical

A WordPress critical error looks alarming, but it is usually a technical failure that can be isolated with a careful process. Start with recovery mode, protect the site with a backup, check logs, disable the likely plugin or theme, and test the features that matter to the business.

The bigger lesson is that WordPress stability depends on maintenance habits. Updates, backups, plugin reviews, PHP compatibility checks, staging tests, and documentation all reduce the chance that one broken component takes the entire website offline.

FAQs