Before changing a broken WordPress site, write down what failed

Dongtao Jiang — Fri, 30 Oct 2026 08:28:49 +0000

A WordPress site loads normally one day and shows a blank page the next. Disabling plugins, switching themes and restoring a backup may each help in the right circumstances. Trying them all at once makes it harder to tell which change mattered. A database restore can also overwrite newer records.

Before making changes, put together a short incident note. It gives whoever investigates a place to start.

This blank record is a place to begin. Include the time zone, and keep passwords, complete orders and customer details out of shared screenshots.

First observed failure and time zone:
Last known working time:
Affected URL and steps to reproduce:
Results while signed out and in the admin area:
Impact on enquiries, orders or account activity:
Recent updates, configuration changes or deployments:
Backup time and what it includes:
Changes already tried, their times and results:

Record the affected requests

Check the home page, an ordinary inner page and the admin login separately. Repeat the check while signed out. Record what appears: a blank response, a critical error, a timeout or a database connection error.

Include the URL and steps if a particular action triggers the failure. “The product page loads, but adding an item to the cart fails” is more useful than “the shop is broken.” Establish whether enquiries, orders or account activity are still being recorded.

Make a timeline

Note the last known working time, then list updates, theme changes, code snippets, PHP changes, cache settings and migrations. If nobody made a manual change, check automatic updates, hosting notices and deployment records.

Have one person coordinate further work. Keep a note of each change and result, including unsuccessful attempts, so another person can take over without repeating every test.

Preserve current data

Confirm that backups include files and the database. Where possible, preserve a copy of the current failed state and relevant logs. An older backup may help with recovery; the current copy may contain newer orders, content and evidence.

Restoring files and restoring a database are separate decisions. For shops, membership sites and connected systems, account for records created after the backup before deciding what to restore.

An isolated copy can help with testing. Prevent it from sending real email, triggering payments or repeating external synchronisation before using it to investigate.

Match logs to the request

WordPress, PHP and server logs may provide evidence. Match entries to the request and time rather than treating every historical warning as part of the incident. A plugin path is a lead, not a complete diagnosis.

The WordPress debugging documentation explains logging and error-display options. These tools are intended for local testing and staging; WordPress does not recommend using them on live sites. Start with the host’s existing PHP and server logs where available. If more evidence is needed, have someone familiar with the environment choose a logging approach in an isolated copy. Prepare an appropriate backup before modifications, keep detailed errors away from visitors and check logs for sensitive data before sharing them.

The official troubleshooting reference describes options when the admin area is unavailable. File and database changes still require care; ask the host or maintenance provider for help if these operations are unfamiliar.

Change one factor at a time

If the failure followed an update, investigate the relationship before making unrelated changes. Where practical, test plugin, theme or environment changes in an isolated copy. Change one factor at a time and record the before-and-after result. Disabling every plugin on a live shop may also disable payments, forms and accounts; a home page that loads afterward is not enough to establish recovery.

When an adjustment removes the symptom, record what you can reproduce and what remains unexplained. Clearing a cache or reverting a version can change the symptom without establishing the cause.

Verify the business flow

A process illustration, not a record of a particular incident.

Check affected pages as an ordinary visitor, then test the relevant function. For an enquiry site, verify submission and receipt. For a shop, check the cart, checkout and order state. For a membership site, check sign-in and permissions. Use controlled tests that avoid real charges and unnecessary customer notifications.

Leave a record of the symptoms, confirmed findings, changes, checks and unresolved questions. If the cause remains unclear, say so. A temporary recovery should not be described as a permanent repair.

Adapted from the WPShieldPro troubleshooting article. AI assistance was used to prepare and edit this adaptation. Technical points were checked against the sources linked above.