When a site breaks the moment a plugin is activated, the culprit is not in doubt — the useful question is why. Usually it is a conflict with something already installed, a PHP version mismatch, or a missing dependency the plugin assumed was present. That distinction decides whether the plugin can stay.
Before you buy, one quick check
Diagnostic and fully reversible.
Over SFTP go to wp-content/plugins and rename the folder of the plugin you just activated, adding -off to the end. Load the site.
Site comes back — confirmed, it is that plugin. Leave it renamed and tell us the name when you order. You are safe until we look.
A few plugins clear temporary data while inactive, so don’t leave it renamed for longer than it takes to order — if you won’t be ordering right away, rename it back and just note the plugin name for later.
Still broken — the activation was coincidental and something else is wrong. Rename it back and run the free scan.
Blank page after plugin activation
A plugin you just activated took the site down. We identify the conflict, get the site back, and tell you whether the plugin can be made to work or should be replaced.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Broke the instant a plugin was activated | This fix covers it |
| Broke after an update, not an activation | Fatal PHP error after update |
| Blank page with no recent change | White screen of death |
| Two plugins that each work alone | Plugin conflict diagnosis |
| You just want it deactivated and gone | Failed update rollback |
What you are seeing
- The site went down at the exact moment of activation
- You may not be able to reach the admin to deactivate it again
- The error may name the new plugin, or something else entirely
- Deactivating it restores the site, which confirms the cause but not the reason
Common causes
- A conflict with a plugin already installed, often over a shared library
- A PHP version requirement the site does not meet
- A missing dependency the plugin expected to be present
- A licence check failing and the plugin handling that badly
- Two plugins registering the same function name
What we do
- Take a full backup before touching anything
- Restore the site by isolating the new plugin
- Capture the actual error rather than assuming the plugin is simply incompatible
- Identify whether the conflict is with another plugin, the theme, or the environment
- Resolve it where resolvable, or advise a replacement where it is not
- Verify the site and the intended functionality both work
What is included
- A working site with a clear answer on the plugin
- A note naming what it conflicted with and why
- A recommendation on whether to keep, configure differently, or replace it
- The pre-fix backup, kept for 30 days
Not included
- Building the functionality yourself if the plugin has to go — quoted separately
- Buying licences on your behalf, though we say what is needed
- Making two fundamentally incompatible plugins coexist
- Design changes or content work
Questions about this fix
I already know which plugin. Do I still need diagnosis?
Knowing which is half of it. Whether it can be made to work is the other half, and that is what decides whether you keep the functionality you bought it for or start looking for a replacement.
Can two plugins always be made to work together?
No, and we will tell you when the answer is no rather than spending your money finding out slowly. Some conflicts are architectural, and the honest answer is to pick one.
The plugin works on my other site. Why not this one?
Something differs between them — PHP version, another plugin, the theme, or a server setting. That difference is exactly what the diagnosis finds, and it is usually a single specific thing.
Will I lose the plugin's settings while it is deactivated?
No. Settings live in the database and survive deactivation. The only exception is a plugin that deliberately clears its own data on deactivation, which is rare and which we check for.
Does this happen with theme activation too, not just plugins?
Yes, the same conflict pattern applies to themes, though it's rarer since most sites change plugins far more often than themes. If it happened right after a theme switch, tell us that instead — the diagnosis is the same idea.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.