WordPress plugin broke your website? What to do next

If your website stopped working right after you installed, activated or updated a plugin, it is natural to suspect that plugin. Very often you are right, but not always for the reason you think.

A plugin problem can affect:

the entire website
only the WordPress dashboard
a specific page or layout
the checkout, forms or login
something less visible, such as emails, search or background tasks

The good news is that a plugin problem rarely means that your content or data has been lost. In most cases the information is still in the database: the website simply cannot display it while the faulty code is running.

The important thing is to identify the plugin calmly, change one thing at a time and check what else depends on it before switching it off.

This guide explains how plugin problems usually happen, how to find out which plugin is involved, what you can safely try and when it is better to ask for technical support.

What does it mean when a plugin breaks a website?

A plugin adds code to your website. Every time a page loads, WordPress runs the code of all active plugins together with the theme and WordPress itself.

If one piece of that code fails, or two pieces try to do incompatible things, the result can be:

a message such as "There has been a critical error on this website"
a blank white page
a page that loads without its layout or styling
buttons, menus or forms that stop responding
a dashboard that becomes slow or inaccessible
errors only for logged-in users, or only for visitors

The plugin you suspect is not necessarily badly made. It may work perfectly on thousands of other websites and still fail on yours because of the specific combination of tools, settings and server you use.

Why do plugins break websites?

Most plugin problems fall into one of three categories. Knowing which one applies helps you choose the right next step.

A conflict with another plugin or the theme

Two plugins may try to change the same thing, load different versions of the same library or depend on each other in ways their developers did not anticipate.

A conflict often appears when:

a new plugin is installed on a website that already has many plugins
two plugins offer similar functions, such as caching, security or SEO
the theme includes features that overlap with a plugin

In this case, neither plugin is broken on its own. The problem only exists when both are active.

A faulty or incomplete update

A new version of a plugin may contain a bug, remove a feature you relied on or change how it stores settings.

An update can also be interrupted halfway, for example because of a timeout or a lack of disk space. The plugin is then left with missing or mismatched files.

If the problem started immediately after an update, the update is the first thing to look at. Our guide on what to do when WordPress breaks after an update covers this situation in more detail.

Incompatibility with PHP or WordPress

Plugins are written for specific versions of PHP, the programming language your server uses, and of WordPress.

A problem may appear when:

the hosting provider upgrades the PHP version
a plugin update requires a newer PHP version than your server offers
an old plugin has not been updated for recent versions of WordPress or PHP
custom code built around a plugin depends on functions that no longer exist

This type of problem can appear suddenly, even if nobody touched the plugin, because something around it changed.

How can you tell which plugin is involved?

You do not need to read code to collect useful clues. Start with the simplest ones.

Timing

Think about what happened just before the problem appeared:

Was a plugin installed, activated or updated?
Were automatic updates enabled?
Did someone change a plugin setting?
Did the hosting provider make changes to the server?
Did the problem start while you were using a specific feature?

If the website broke within minutes of a specific change, that change is your strongest lead. Note the time and the plugin name.

The WordPress recovery email

When WordPress detects certain fatal errors, it may send an email to the site administrator address. The subject usually mentions that your site is experiencing a technical issue.

This email often names the plugin or theme that caused the error. It may also include a link to Recovery Mode, which lets an administrator log in to the dashboard while WordPress pauses the problematic plugin.

Check:

the administrator inbox
spam and junk folders
any shared address used to manage the website

From Recovery Mode you can deactivate the paused plugin properly. It helps you get in, but it does not fix the underlying problem.

Treat the Recovery Mode link as sensitive. Do not forward it to people who do not need it and do not post it publicly.

The error message itself

Sometimes the error shown on screen, in the recovery email or in a log includes a file path. If that path contains something like:

wp-content/plugins/plugin-folder-name/

the folder name usually tells you which plugin was running when the error happened.

Keep in mind that the plugin named in the error is where the problem became visible. It is not always the plugin that caused it. In a conflict, a second plugin may have changed something that the first one did not expect.

Where the problem appears

If only the checkout is broken, look first at plugins related to payments, shipping or the shop. If only the contact form fails, look at form, spam protection and email plugins. The affected area is often a good hint.

First checks anyone can do safely

Before switching anything off, take a few minutes to understand the situation:

Open the website in a private or incognito browser window.
Check the homepage, an internal page and the login page.
Try to access the WordPress dashboard.
Test any important business function: checkout, forms, bookings, member areas.
Take screenshots of any error message.
Write down the time you first noticed the problem.

These steps change nothing on the website, but they give you, or whoever helps you, a clear picture of what is working and what is not.

Should you deactivate plugins one at a time or all at once?

This is the most important decision in plugin troubleshooting, and both approaches carry risks.

Deactivating one plugin at a time

This is usually the safest approach when you have a clear suspect. You switch off one plugin, test the website and decide what to do next.

It takes longer if you have no idea which plugin is responsible, but it gives you a clear answer and limits the side effects.

Deactivating all plugins at once

This is a common suggestion in forums, and it can quickly confirm whether a plugin is involved at all. On a live business website, however, it can cause new problems.

Plugins may control:

forms: enquiries may be lost or not delivered while the plugin is off
payments and subscriptions: the checkout may stop working or renewals may fail
security: firewall rules, login protection and two-factor authentication may stop working
multilingual content: translated pages may disappear or show the wrong language
caching: visitors may see outdated pages, or the website may become much slower
redirects and SEO: important URLs may stop redirecting correctly

Some plugins also run tasks when they are deactivated or reactivated, such as clearing settings or rebuilding data. Reactivating twenty plugins in the right order is not always as simple as switching them off.

If you must test all plugins at once, prefer a method that does not affect visitors, such as the troubleshooting mode described below, or a staging copy of the website.

What can you safely try?

The right option depends on whether you can access the dashboard and how important the website is to your business.

Option 1: use the Health Check troubleshooting mode

The free Health Check & Troubleshooting plugin, maintained by WordPress contributors, includes a troubleshooting mode.

When enabled, it disables all plugins and switches to a default theme only for your logged-in administrator session. Visitors continue to see the website as it normally is.

You can then re-enable plugins one by one within your session and see when the problem returns. This is one of the safest ways to test for conflicts on a live website.

A few things to keep in mind:

you need access to the dashboard to use it
installing a new plugin is itself a change, so do it when the website is otherwise stable enough
some problems only appear for visitors or during background tasks, and may not show up in your session
remember to disable troubleshooting mode when you have finished

Option 2: deactivate the suspected plugin from the dashboard

If you can access WordPress and have a strong suspect, go to:

Plugins → Installed Plugins

Deactivate only that plugin, then test the affected page and the important functions of the website.

If the problem disappears, you have found a strong lead. Leave the plugin deactivated for now rather than deleting it: deleting a plugin may also remove its settings and data.

Option 3: roll back to the previous version

If the problem started after a plugin update, going back to the previous version may restore the website while the developer fixes the issue.

This should be done carefully:

the new version may have changed the database, and the old version may not work correctly with it
the update may have included a security fix, and rolling back could reintroduce a vulnerability
you should only use versions downloaded from the official source or the plugin developer

If you are unsure, it is better to ask for help before rolling back a plugin that handles payments, users or security.

Option 4: restore a backup

A backup can return the whole website to a known working state. On an ecommerce, membership or booking website, however, it may also overwrite orders, registrations and messages received after the backup was taken.

Check the backup date and think about what has happened since then before restoring.

What should you avoid doing?

When a website is broken, it is tempting to try everything quickly. Avoid:

updating every plugin at once in the hope that one update fixes it
deleting plugins instead of deactivating them
deactivating security, payment or form plugins without checking the consequences
installing several replacement plugins to see which one works
downloading plugin versions from unofficial websites
editing plugin files directly, since changes are lost at the next update
publishing error logs, screenshots with personal data or access details in public forums
making several changes before testing the result

Change one thing at a time and keep a short record of what you did and what happened.

Should you report the problem to the plugin developer?

Yes, if you can identify the plugin and the problem appears to come from it. Many developers rely on reports to discover bugs in new versions.

A useful report includes:

the plugin version and the version that worked before, if known
your WordPress and PHP versions
a clear description of what happens and how to reproduce it
the relevant error message, with any personal or sensitive information removed

Use the official support channel, such as the plugin's support forum on WordPress.org or the developer's own support system for premium plugins.

Do not share login details, full logs or customer data in a public forum. If the developer needs access to your website, agree on a secure method and remove that access when the investigation is finished.

Keep the plugin deactivated or find an alternative?

Once the website works again, you need to decide what to do with the plugin.

Keeping it deactivated for a short time can be reasonable when:

the developer has acknowledged the problem and a fix is expected
the function it provides is not essential for a few days
you can work around the missing feature

Looking for an alternative may be better when:

the plugin has not been updated for a long time
the developer does not respond to support requests
the same plugin has caused problems more than once
it duplicates features already provided by another plugin or the theme

Replacing a plugin is not always simple. Settings, content, shortcodes and data may need to be migrated, and the new plugin should be tested before it goes live. Plan the replacement instead of doing it under pressure.

If the problem is a conflict between two plugins, the solution may be a configuration change rather than removing either of them.

When should you ask for technical support?

Technical support is recommended when:

the entire website or the dashboard is inaccessible
the problem affects checkout, payments or subscriptions
you cannot identify which plugin is involved
the problem returns after a temporary fix
the plugin involved handles security, users or payments
custom code depends on the plugin
you suspect a PHP compatibility issue
you do not have a recent, verified backup
you are not comfortable working with files or the hosting panel

You do not need to diagnose the problem before asking for help. Explaining what changed and what no longer works is enough to start.

What information should you collect?

Useful details include:

the website URL
the name of the suspected plugin and, if known, its version
what changed just before the problem started
the approximate time the problem started
screenshots of any error message
any email received from WordPress
which pages or functions are affected
whether the dashboard is accessible
what you have already tried, in order
whether a recent backup is available

Do not worry if you cannot collect everything. D4Hub can help you understand what additional information or access is needed. Do not send passwords by ordinary email.

How D4Hub can help

The goal is not only to make the website load again, but to understand why the plugin failed and make sure the fix does not break something else.

Depending on the situation, D4Hub can help with:

identifying the plugin, theme or custom code involved
telling a plugin conflict apart from a faulty update or a PHP incompatibility
reviewing error logs and recovery emails
safely deactivating or rolling back the plugin
testing conflicts on a staging copy instead of the live website
checking forms, checkout, login and other key functions after the fix
reporting the issue to the plugin developer with the right technical details
evaluating and configuring an alternative plugin
reducing overlapping plugins to lower the risk of future conflicts

You can ask for support at any stage. D4Hub can guide you through a simple check, confirm whether an action is safe, take over when the dashboard is inaccessible or review the website after a temporary fix.

Open a support ticket

For hands-on users: isolating a plugin from the command line

The following checks are intended for users who are comfortable with SFTP, SSH and WP-CLI.

Make a full backup of files and database before you start. Make sure you are working on the right WordPress installation, and change one thing at a time.

List the active plugins

With WP-CLI, run this from the WordPress root folder:

wp plugin list --status=active

Save the output. It gives you a record of what was active before you made any change, which is useful if you need to reactivate plugins later.

You can also check your WordPress and PHP environment with:

wp --info

Note that the PHP version used by the command line can differ from the one used by the website. Check the hosting panel for the PHP version that serves the website.

Run WP-CLI without loading plugins

If WP-CLI itself fails because a plugin causes a fatal error, you can tell it to skip plugins:

wp plugin list --skip-plugins

You can also skip only a specific plugin:

wp plugin list --skip-plugins=plugin-slug

If the problem may be in the theme as well, --skip-themes works in the same way. These flags only affect that command: they do not deactivate anything on the website.

Deactivate a single plugin

Once you have identified a suspect:

wp plugin deactivate plugin-slug

Replace plugin-slug with the folder name shown in wp plugin list. Then test the website and the functions that depend on that plugin.

To reactivate it later:

wp plugin activate plugin-slug

Rename the plugin folder via SFTP

If you do not have WP-CLI or dashboard access:

Connect through SFTP or the hosting file manager.
Navigate to wp-content/plugins/.
Rename the suspected plugin folder, for example from plugin-name to plugin-name-disabled.
Reload the website.

WordPress can no longer load the plugin and will treat it as deactivated. When you rename the folder back, the plugin will normally need to be activated again from the dashboard.

Do not delete the folder. Avoid renaming the entire plugins folder on a live business website: it disables every plugin at once, with all the risks described above.

Check for must-use plugins

Plugins in wp-content/mu-plugins/ load automatically and cannot be deactivated from the dashboard. Some hosting providers and developers use this folder for custom code.

If the error mentions a file in that folder, do not remove it without understanding what it does. It may be required by the hosting environment or by custom functionality.

Look for the error in the logs

Check the PHP error log in your hosting panel, or enable the WordPress debug log temporarily as described in our guide on WordPress critical errors. Look for an entry at the time the problem occurred that mentions a path under wp-content/plugins/.

Logs can contain sensitive information. Review them before sharing and never publish them in full.

D4Hub can help you interpret the output and decide on the next step.

FAQFrequently asked questions

Usually not. Deactivating a plugin stops its code from running, while its settings normally remain in the database.

Deleting a plugin is different: some plugins remove their data when they are deleted. That is why deactivating is the safer first step.

Not necessarily. The function provided by that plugin is now unavailable, and the underlying cause may still be there.

Test forms, checkout, login and other key functions, then decide whether to wait for a fix, roll back or find an alternative.

Something around it probably changed: an update to WordPress, another plugin, the theme or the PHP version on the server. The plugin may not have changed at all.

Not always. The error shows where the problem became visible. In a conflict, another plugin or the theme may be the real cause.

Generally yes, because it only affects the logged-in administrator who enables it. Visitors keep seeing the normal website. Still, make a backup first and disable troubleshooting mode when you have finished.

No. Updates often include security fixes, and skipping them creates other risks. It is safer to update with a recent backup, ideally test important updates on a staging copy first and check the website after each update.

Yes. Explain which plugins you deactivated, updated or removed, and in what order. This helps reconstruct what happened and identify the next safe step.

A WordPress plugin broke my website: what should I do?