When a form, checkout or page stops working after a change, start by reproducing the fault and recording what changed. Then test components one at a time on a separate staging copy. If the fault disappears when a component is disabled and returns when it is enabled again, you have a useful lead; it may still be an interaction between two components rather than a fault in one plugin alone.
Avoid switching off every plugin on a live business website to see what happens. That can interrupt enquiries, payments, bookings or security functions while customers are using them. If the site is already down, establish who is handling the incident and use the recovery route appropriate to the error before conducting a wider test.
Describe a failure someone else can reproduce
Write down the exact page or task, the steps to reach the problem and what should have happened. Note the time, device and browser, whether the problem affects everyone or only signed-in users, and any error message. Remove customer details and secrets before sharing screenshots or logs.
“The website is broken” is hard to test. “On a phone, the booking button on the service page opens a blank panel; it should show available appointments” gives a maintainer a starting point. Record the installed WordPress, PHP, theme and relevant plugin versions, and recent changes if known. A change made shortly before a fault is a clue, not proof of the cause.
Prepare a safe copy and a repeatable test
Confirm that a current backup can be retrieved and agree who can restore it. Create an isolated staging copy that resembles the live site closely enough to reproduce the issue. The hosting environment, cache, external services and data can differ, so a clean staging result does not automatically clear the live site.
Protect personal information in the copy. Disable or replace live payment, booking and email connections according to the provider’s staging instructions. Use test accounts and a safe test transaction only where the service supports them. Do not overwrite the live database with an older staging database: orders, bookings and enquiries may have arrived since the copy was made.
Before changing anything, run the same steps on staging and record the result. If the fault cannot be reproduced, compare versions, configuration, cache and the affected account before drawing a conclusion. Our staging guide covers preparing and releasing changes in more detail. Before the next update, check the versions and dependencies.
Change one thing, then repeat the same steps
On the isolated copy, note which plugins and theme were active. If a recent plugin change is a plausible lead, disable that plugin and repeat the recorded task. Record both the result and any new missing functionality: a form plugin being off can explain why its form vanished.
If the problem remains, return to the baseline and test another component. A broader isolation test may use a default theme and only the essential plugin needed for the affected task, then re-enable other components one at a time. Keep a simple record: component and version, enabled or disabled, exact test, result. Repeat a promising change in both directions to check that the result is consistent.
Some faults require a combination. If the booking plugin works alone but fails when a caching plugin is also enabled, record both versions and settings. The next step may be a configuration change or vendor fix, not deletion of whichever plugin was enabled last. Must-use plugins and server or cache drop-ins can also affect behaviour without appearing in the ordinary active-plugin list.
What a conflict checker can and cannot tell you
WordPress’s Health Check plugin offers a troubleshooting mode that changes the plugin and theme setup for the logged-in user’s session. It can help isolate a problem without presenting that temporary setup to other visitors. It is a diagnostic aid, not a guarantee that all live effects are isolated: the test may still interact with external services or make persistent changes. Check its current instructions, obtain the site owner’s permission before adding software, and use staging where a transaction or data change is involved.
A test that succeeds with plugins disabled narrows the investigation; it does not automatically identify the faulty line of code. If the symptom depends on a customer account, payment gateway, scheduled task or server configuration, arrange a test that includes that condition safely. If you cannot reproduce it without affecting customers, ask the host or maintainer to investigate with the evidence collected.
Restore the intended setup and check the journey
After identifying a likely conflict, agree the remedy with the component suppliers or maintainer. Check that any replacement or configuration change preserves the data and functions the business needs. Then test the actual customer journey: for example, opening a booking page, selecting a slot, completing a provider-supported test and checking the confirmation. Include phone and desktop where relevant.
Apply an agreed, tested change to live through the normal release process; do not copy the whole staging database over recent customer activity. Record the final versions, change made, test results and any remaining risk. If your business needs help planning or improving a WordPress website in Formby, Freshfield or L37, contact Formby Web Design to discuss the scope.
Further reading: WooCommerce conflict testing and the WordPress Health Check guide.
