How to Restore WordPress After a Failed Plugin or Theme Update

WordPress updates are usually simple. You click Update, wait for the process to finish, and continue working.

But sometimes an update breaks something.

A plugin update can cause a fatal PHP error, a white screen, broken functionality, JavaScript errors, or an inaccessible WordPress dashboard. A theme update can break layouts, templates, custom functionality, WooCommerce pages, or page builder elements.

The important thing is not to panic and start changing everything at once.

A failed plugin or theme update is usually a troubleshooting problem. The goal is to identify exactly what changed, isolate the component responsible, restore the last known working state, and then determine why the update failed.

This guide explains how to recover WordPress after a failed plugin or theme update, whether you still have access to the dashboard or the entire website has gone offline.

What Can Happen After a Failed WordPress Update?

A failed update can produce very different symptoms.

You might see:

• A completely blank page.
• “There has been a critical error on this website.”
• A PHP fatal error.
• The frontend works but the WordPress dashboard is broken.
• The dashboard works but the frontend is broken.
• A theme layout suddenly changes.
• Elementor or another page builder stops working.
• Forms stop submitting.
• WooCommerce cart or checkout stops working.
• JavaScript functionality disappears.
• The website enters maintenance mode and stays there.
• Images, CSS, or JavaScript files stop loading.
• A plugin appears active but one of its features no longer works.
• The website becomes significantly slower.
• Multiple plugins begin showing compatibility errors.

These symptoms can come from very different causes.

The update itself may be incompatible with another plugin, theme, PHP version, WordPress version, or custom code.

It can also fail because of server resources, file permissions, disk space, an interrupted download, or an incomplete replacement of the plugin or theme files.

That is why the first step is diagnosis rather than immediately reinstalling everything.

Why You Should Not Immediately Update Everything Again

One of the worst things you can do after a failed update is start clicking Update on every available plugin and theme.

You need to preserve the information about what changed.

If Plugin A was updated and the website broke immediately afterward, Plugin A is the first thing you should investigate.

If you then update five additional plugins, change PHP, clear every cache, and switch themes, you have changed too many variables at once.

You might eventually fix the website without ever discovering what caused the original problem.

Instead, establish:

• What was updated.
• Which version was installed before.
• Which version is installed now.
• When the problem started.
• Which part of the website is broken.
• Whether the dashboard is accessible.
• Whether the frontend is accessible.
• Whether the problem affects all visitors or only certain pages.

If you can still access WordPress, create a backup before making significant additional changes.

For more serious WordPress problems, the same principle applies as with other troubleshooting work: preserve the current state, isolate the cause, and change one meaningful variable at a time.

Step 1: Identify the Last Change

Start with the timeline.

Ask:

What happened immediately before the website broke?

For example:

You update a contact form plugin.

The update finishes.

You refresh the homepage.

The form no longer works.

Then the plugin is your primary suspect.

Another example:

You update the active theme.

The homepage loads, but the header and page layouts are broken.

The theme update becomes the primary suspect.

This does not automatically prove that the component is defective.

The new version may simply expose a compatibility problem elsewhere.

For example, a plugin may require a newer PHP version, depend on another plugin, or use functionality that changed in a newer WordPress release.

The purpose of identifying the last change is to narrow the investigation.

Step 2: Check WordPress Recovery Mode

If a plugin or theme causes a serious PHP fatal error, WordPress may provide Recovery Mode.

Recovery Mode can allow an administrator to access WordPress even when a plugin or theme is causing a fatal error during normal requests.

If you receive a WordPress Recovery Mode email, open the provided login link and examine the error carefully.

Look for:

• Plugin name.
• Theme name.
• File path.
• PHP function.
• Class name.
• Error type.

If the error clearly identifies the recently updated plugin, deactivate it and test the website again.

Do not start disabling unrelated plugins simply because they are installed.

The more precisely you isolate the component, the easier the recovery becomes.

Step 3: If You Can Access the Dashboard, Deactivate the Suspected Plugin

Go to:

Plugins → Installed Plugins

Find the plugin that was updated immediately before the problem appeared.

Deactivate it.

Then test the website.

Check more than the homepage.

Test:

• Homepage.
• Several internal pages.
• WordPress dashboard.
• Forms.
• Login.
• Search.
• Important custom functionality.
• WooCommerce pages if applicable.

If the website immediately starts working after the plugin is deactivated, you have strong evidence that the plugin or its interaction with another component is responsible.

Do not immediately reinstall the newest version.

First determine whether you should roll back, wait for a corrected release, replace the plugin, or resolve another compatibility issue.

Step 4: What If the WordPress Dashboard Is Inaccessible?

If the plugin update prevents WordPress from loading correctly, you may not be able to reach the Plugins screen.

You can deactivate a plugin manually through:

• Hosting File Manager.
• FTP.
• SFTP.

Navigate to:

wp-content/plugins/

Find the plugin folder.

For example:

wp-content/plugins/example-plugin/

Rename it:

example-plugin-disabled

WordPress will no longer find the plugin at its normal location and will deactivate it.

Then try loading the website again.

If the website works after the folder is renamed, you have isolated the plugin sufficiently to continue troubleshooting.

Do not leave the folder renamed permanently without understanding what happened.

The next step is to determine whether the plugin needs to be rolled back, replaced, or updated again after the compatibility problem is resolved.

Step 5: If the Theme Caused the Problem

Themes require slightly different troubleshooting because the active theme controls a large part of the frontend.

If the updated theme is suspected, temporarily switch to a default WordPress theme.

If the website immediately starts working, the theme becomes the primary suspect.

This is a diagnostic test, not necessarily the final solution.

The original theme may contain:

• Custom templates.
• Header and footer functionality.
• WooCommerce templates.
• Custom hooks.
• Page builder integration.
• Custom CSS.
• Theme-specific settings.
• Custom PHP.

If the site uses Elementor or another builder, switching themes can also affect templates and global styling.

The goal is to determine whether the theme is responsible, not simply to replace it permanently.

Step 6: Check the Exact PHP Error

A fatal error usually contains valuable information.

Depending on your hosting setup, check:

• WordPress Recovery Mode.
• PHP error logs.
• Hosting control panel logs.
• WordPress debug logs.
• Server logs.

A useful error may identify a path such as:

wp-content/plugins/example-plugin/

or:

wp-content/themes/example-theme/functions.php

It may also identify:

• An undefined function.
• An undefined class.
• A syntax error.
• An incompatible method.
• A missing file.
• A PHP compatibility issue.

Do not automatically edit the file mentioned in the error.

The file may simply be where the problem becomes visible.

For example, a plugin may call a function that another dependency no longer provides.

Editing the affected PHP file would only hide the symptom or create another problem.

Step 7: Enable Debug Logging When Necessary

If the normal error message is not enough, WordPress debugging can provide additional information.

For a production website, avoid displaying raw PHP errors to visitors.

Instead, use controlled logging so that errors are recorded without exposing technical information publicly.

Useful debugging information can reveal:

• Plugin conflicts.
• Theme errors.
• Deprecated functions.
• PHP warnings.
• Fatal errors.
• Database problems.
• AJAX failures.
• Incorrect function calls.

For more advanced debugging, tools such as Query Monitor can also help identify database queries, hooks, PHP errors, and other WordPress internals.

The important principle is to use debugging to identify the cause, not to leave debugging output publicly visible on a live website.

Step 8: Check Whether the Update Was Partial

Not every failed update is a compatibility problem.

Sometimes the update itself did not complete correctly.

Possible causes include:

• Server timeout.
• Insufficient disk space.
• PHP memory limitations.
• File permission problems.
• Interrupted connection.
• Failed extraction.
• Hosting security rules.
• Resource limits.
• Broken update package.

This can leave a plugin or theme in an inconsistent state.

For example, some new files may have been copied while others were not.

The result can be a plugin that is neither completely equivalent to the previous version nor correctly installed as the new version.

If the update repeatedly fails, check the hosting environment before simply trying the same update again.

Step 9: Check PHP Memory and Server Resources

A failed update can sometimes expose resource problems that were already present.

Check:

• PHP memory limit.
• Available disk space.
• Inode usage.
• CPU usage.
• PHP workers.
• File permissions.
• Hosting resource limits.

If the website is also producing memory errors, use the dedicated guide:

How to Fix WordPress Memory Limit Errors

That article explains the difference between WordPress memory settings and the PHP/server limits that actually control how much memory a request can use.

Do not automatically increase every limit you can find.

If the server is running out of resources because of a poorly behaving plugin, increasing the limit may only hide the underlying problem temporarily.

Step 10: Check the PHP Version

Plugin and theme compatibility can depend heavily on the PHP version.

A new plugin release may require a newer PHP version.

An old plugin may contain code that behaves differently under a newer PHP version.

Check the current PHP version through:

Tools → Site Health → Info

or through your hosting control panel.

Then compare it with the plugin or theme’s documented requirements.

Do not change PHP on a production website simply because a plugin update failed.

If PHP compatibility is suspected, staging is the safer environment for testing the change.

Changing PHP can affect many plugins and themes simultaneously, whereas rolling back one plugin limits the scope of the change.

Step 11: Roll Back the Plugin

If the new version clearly caused the problem and the previous version worked correctly, rolling back can restore the website.

The process is generally:

• Confirm the previous version.
• Create or verify a current backup.
• Deactivate the broken plugin.
• Obtain the previous version from a trustworthy source.
• Replace the plugin files.
• Reactivate the plugin.
• Test the website.

For plugins hosted on WordPress.org, use a trusted source.

For premium plugins, use the developer’s official account or support system whenever possible.

Do not download old plugin ZIP files from random websites.

The goal is to restore the last known working state, not simply to install an arbitrary older version.

Step 12: Be More Careful When Rolling Back a Theme

Theme rollbacks can be more complicated because theme files may contain customizations.

Before replacing the theme, determine whether custom code was added directly to the parent theme.

If you replace the theme files, those modifications may disappear.

This is one reason child themes are useful when modifying a parent theme.

Also check whether the website uses:

• WooCommerce template overrides.
• Elementor templates.
• Custom functions.
• Custom CSS.
• Theme-specific settings.
• Custom JavaScript.
• Theme hooks.

A rollback that restores the old theme version but removes custom functionality is not a successful recovery.

Step 13: Check Plugin and Theme Conflicts

Sometimes the updated component works perfectly on its own.

The problem appears because another plugin or theme is incompatible with the new version.

This is particularly common when the website contains many interconnected systems.

For example:

• A page builder depends on theme functionality.
• A WooCommerce extension depends on WooCommerce hooks.
• A form plugin interacts with another integration.
• A security plugin modifies requests.
• A caching plugin modifies JavaScript or CSS.
• Custom code depends on a plugin function.

When a plugin update breaks the website, do not only ask:

“Is this plugin broken?”

Also ask:

“What does this plugin interact with?”

For a more structured approach to compatibility problems, your plugin and theme conflict troubleshooting content can be used alongside this recovery process rather than repeatedly reinstalling components at random.

Step 14: Check Caching After the Underlying Problem Is Fixed

Cache can make troubleshooting confusing.

You may fix a plugin or theme problem but continue seeing the old error because a cached page, JavaScript file, CSS file, or CDN response is still being served.

First fix the underlying problem.

Then clear the appropriate cache layers:

• WordPress cache.
• Plugin cache.
• Hosting cache.
• CDN cache.
• Browser cache.
• CSS/JavaScript optimization cache.

If WordPress changes are still not appearing after you have confirmed that the underlying files are correct, see:

WordPress Changes Not Showing: Fix Cache & CSS Issues

Do not repeatedly clear every cache while the actual PHP problem is still present.

Caching cannot repair broken PHP code.

Step 15: Check Whether the Update Changed Performance

Sometimes the website still works after an update but becomes significantly slower.

Do not automatically assume the update is harmless simply because there is no visible error.

Compare:

• TTFB.
• PHP execution.
• Database queries.
• CPU usage.
• Memory usage.
• Number of requests.
• JavaScript execution.
• CSS loading.
• External API requests.

If server response time became worse, see:

How to Fix High TTFB in WordPress: Complete Server Response Time Guide

For broader performance troubleshooting, use:

How to Speed Up a WordPress Website: Complete Optimization Guide

You can also investigate whether the update introduced additional CSS or JavaScript.

How to Reduce CSS in WordPress and Improve Page Speed

This is especially useful when the update did not completely break the website but introduced additional frontend assets or changed how resources are loaded.

Step 16: Check the Database After a Major Plugin Update

Some plugins store substantial amounts of data in the WordPress database.

A failed update can sometimes leave behind:

• Temporary data.
• Options.
• Transients.
• Custom tables.
• Metadata.
• Logs.
• Scheduled actions.

Do not immediately start deleting database entries.

First establish whether the plugin actually changed the database and whether those changes are expected.

The important rule is:

Do not use database cleanup as a generic response to a failed plugin update.

Only remove data when you understand what it is and why it is no longer needed.

Step 17: Test WooCommerce Thoroughly

If the failed update happened on a WooCommerce website, the homepage loading successfully does not mean the recovery is complete.

Test:

• Product pages.
• Product variations.
• Cart.
• Checkout.
• Shipping.
• Taxes.
• Payment methods.
• Coupons.
• Customer accounts.
• Order creation.
• Emails.
• Order management.
• Refunds.

A plugin update may leave the public frontend looking normal while breaking one of the dynamic parts of the store.

For example, a payment gateway extension may load normally but fail when a customer actually submits checkout.

If checkout itself becomes slow after an update, see:

Why Is WooCommerce Checkout So Slow? Causes, Tests & Fixes

Step 18: Test Forms and Email Delivery

A plugin update can also break email functionality without producing a visible error.

Test:

• Contact forms.
• Password reset emails.
• WooCommerce order emails.
• Administrator notifications.
• Form integrations.
• SMTP delivery.

If emails stopped working after an update, the problem may be related to the form plugin, an integration, or the site’s mail configuration rather than the WordPress core itself.

For a deeper look at WordPress email delivery:

How to Setup Free SMTP Email Delivery in WordPress

This is another example of why post-update testing should follow the actual functionality of the website rather than stopping once the homepage loads.

Step 19: Check JavaScript and Network Errors

Not every update failure is a PHP failure.

A plugin or theme can load successfully but introduce JavaScript problems.

Open your browser’s Developer Tools and check the Console.

Look for:

• JavaScript errors.
• Missing files.
• Failed AJAX requests.
• 404 errors.
• 403 errors.
• CORS errors.
• Broken dependencies.
• Deprecated functionality.

Then check the Network panel.

Look for resources that fail to load or requests that suddenly take much longer than before.

This is particularly important for:

• Page builders.
• Forms.
• Menus.
• Popups.
• Checkout.
• AJAX filters.
• Dynamic search.
• Custom admin interfaces.

A website can therefore be technically “online” while a major part of its functionality is broken.

Step 20: Check the Plugin or Theme Changelog

Before deciding to stay permanently on an older version, read the changelog.

Look for:

• PHP compatibility changes.
• WordPress compatibility changes.
• WooCommerce compatibility changes.
• Security fixes.
• Deprecated functionality.
• Removed features.
• API changes.
• Bug fixes.
• Required dependencies.

A rollback can restore the website, but it may leave you running an outdated version with a known security or compatibility problem.

The goal should therefore be:

restore first, understand second, update safely later.

Step 21: Restore a Full Backup When Necessary

Sometimes rollback is not enough.

If multiple plugins were updated, the database changed, or the website was significantly damaged, restoring a known-good backup may be the cleanest solution.

A complete WordPress backup normally includes:

Website files

Including:

• WordPress core.
• Plugins.
• Themes.
• Media uploads.
• Configuration files.

Database

Including:

• Pages.
• Posts.
• Users.
• Settings.
• Plugin data.
• WooCommerce data.
• Theme settings.

Restoring only the files does not necessarily restore the previous database state.

Likewise, restoring only the database does not restore changed plugin or theme files.

Before restoring, determine exactly what the backup contains.

Step 22: Consider What Happened After the Backup

A backup is only useful if you understand what restoring it will remove.

For example, suppose the backup was created yesterday.

Since then the website received:

• New WooCommerce orders.
• New contact form submissions.
• New user registrations.
• New comments.
• New content.

Restoring the old database could remove those changes.

For an active ecommerce website, this is particularly important.

Before restoring a backup, determine whether newer data can be preserved separately or whether the hosting provider has a more granular recovery option.

Step 23: Test the Recovery on Staging When Possible

If your hosting provides staging, use it.

A staging environment lets you test:

• Plugin updates.
• Theme updates.
• PHP changes.
• Custom code.
• Database changes.
• WooCommerce changes.
• Performance changes.
• Compatibility.

This is especially valuable after a failed update because you can reproduce the problem without breaking the live website again.

The same principle applies before future updates:

test first, update second.

Your existing staging-focused content can fit naturally into this workflow because staging is not only for development; it is also a recovery and testing layer.

Step 24: Do Not Forget Security After Recovery

A failed update does not automatically mean that the website was hacked.

However, if you discovered unexpected files, modified code, unauthorized users, or suspicious redirects while troubleshooting, stop treating the incident as a simple failed update.

Use the investigation process in:

WordPress Malware Cleanup: How to Investigate a Compromised Website

A compromised website requires a different recovery process because simply restoring a plugin or theme may leave the original access method intact.

Step 25: Test the Entire Website Before Calling It Fixed

Once the suspected plugin or theme has been restored, do not stop after seeing the homepage.

Test:

• Homepage.
• Internal pages.
• Navigation.
• Login.
• WordPress dashboard.
• Forms.
• Search.
• Important integrations.
• Mobile layouts.
• JavaScript interactions.
• CSS.
• Images.
• Performance.

For WooCommerce, also test:

• Product pages.
• Cart.
• Checkout.
• Payment.
• Customer account.
• Order creation.
• Emails.

For membership websites:

• Registration.
• Login.
• Account pages.
• Protected content.

The recovery is complete only when the important workflows are working again.

Common Mistakes After a Failed Update

Updating everything at once

This removes the ability to identify the original cause.

Deleting the plugin immediately

Deleting a plugin can have consequences depending on how it handles its data during uninstall.

Preserve the current state when possible.

Editing WordPress core files

Do not modify core files simply to hide an error.

Changing PHP without testing

A PHP version change can affect many other components.

Clearing every cache repeatedly

Cache clearing does not repair a PHP compatibility problem.

Restoring an old backup without checking newer data

This can cause data loss.

Downloading old plugin versions from unknown websites

Use official or trustworthy sources.

Assuming a working homepage means the website is fixed

Forms, checkout, email, AJAX, and integrations may still be broken.

Ignoring the changelog

You may miss an important compatibility or security change.

Staying on an old version indefinitely

A rollback can be an effective emergency recovery step, but it should not automatically become the permanent solution.

How to Prevent Failed Updates in the Future

The best recovery process begins before the update.

Before updating an important plugin or theme:

• Create a current backup.
• Know how to restore it.
• Check the plugin or theme changelog.
• Check PHP compatibility.
• Check WordPress compatibility.
• Check available hosting resources.
• Test major updates on staging.
• Update important components individually when practical.
• Avoid combining several major changes.
• Monitor important pages immediately after the update.
• Keep track of custom theme modifications.
• Use a child theme when appropriate.
• Have a rollback procedure ready.

This turns updates from a blind “click and hope” process into a controlled maintenance workflow.

A Practical Recovery Workflow

When a WordPress update breaks the website, follow this order:

1. Stop making random changes.

Identify what changed immediately before the problem.

2. Create or verify a backup.

Preserve the current state whenever possible.

3. Check Recovery Mode.

If WordPress provides a Recovery Mode email, use it.

4. Read the error.

Look for the plugin, theme, file, function, or PHP problem.

5. Deactivate the suspected component.

Use the dashboard if available.

6. If the dashboard is unavailable, deactivate the plugin manually.

Use File Manager, FTP, or SFTP.

7. Test the website.

Determine whether the original problem disappears.

8. Check PHP and hosting resources.

Look for memory, disk, permissions, PHP version, and resource problems.

9. Check compatibility and dependencies.

The plugin may be interacting with another component.

10. Roll back if necessary.

Restore the last known working version.

11. Restore a complete backup if rollback is insufficient.

Be careful about newer database data.

12. Clear relevant caches.

Only after fixing the underlying issue.

13. Test the complete website.

Do not stop at the homepage.

14. Investigate why the update failed.

Check the changelog, logs, PHP version, dependencies, and custom code.

15. Test the next update on staging.

Do not repeat the same production failure without understanding the cause.

Final Checklist

Before considering the recovery complete:

• The homepage loads.
• Internal pages load.
• WordPress login works.
• The dashboard works.
• The affected plugin or theme is stable.
• No new fatal PHP errors appear.
• PHP logs do not show related errors.
• JavaScript functionality works.
• CSS and layouts are correct.
• Forms work.
• Emails are delivered.
• WooCommerce checkout works if applicable.
• Payment processing works if applicable.
• Important integrations work.
• Mobile layouts work.
• Relevant caches have been cleared.
• A current backup exists.
• The reason for the failed update has been investigated.
• The next update can be tested safely.

Final Thoughts

A failed WordPress plugin or theme update does not automatically mean that the website needs to be rebuilt.

In many cases, the recovery process is straightforward once you stop treating the problem as a general WordPress failure.

Find what changed.

Isolate the component.

Read the error.

Deactivate or roll back the suspected plugin or theme.

Test the website.

Then investigate why the update failed.

The most important distinction is between restoring the website and solving the underlying problem.

A rollback may bring the website back online, but if the new version failed because of an outdated PHP version, another plugin conflict, insufficient server resources, incompatible custom code, or a theme customization, the same problem can happen again.

A good WordPress maintenance workflow therefore looks like this:

Backup → Update → Test → Isolate → Restore if necessary → Investigate → Test again.

That process gives you a much safer way to maintain WordPress websites without turning every failed update into a major recovery project.

Learn More

If you regularly work with WordPress websites, deeper troubleshooting knowledge can save significant time when something goes wrong.

You can also explore:

How to Fix WordPress 500 Internal Server Error

For a broader technical workflow covering WordPress performance, security, SEO, WooCommerce, development, and maintenance, get the WP Flow Mastery WordPress eBook.

Written by Nemanja Stosic

WordPress Developer & Website Optimization Specialist

Nemanja has worked on more than 200 websites and focuses on WordPress development, performance optimization, SEO, security, WooCommerce, and practical website improvements.