Production-safe diagnosis
A white screen, failed checkout, compromised account, slow page, and damaged database may all be described as “the site is broken.” They do not share the same first move. This matrix helps an owner capture evidence, protect recoverability, and choose the smallest useful diagnostic step.
Triage matrix
| Observed condition | Protect first | Narrow test | Avoid |
|---|---|---|---|
| Public pages return errors or blanks | Response codes, logs, current files, database, DNS and hosting state | Compare one known URL, admin, static asset, and origin response | Bulk updates or cache purges before recording evidence |
| Admin works but visitors cannot complete a form or checkout | Failed request, browser console, payment or form provider response, affected order or lead identifiers | Reproduce one controlled transaction without real secrets | Assuming the theme is responsible because the page looks wrong |
| Admin access is lost | Account ownership, hosting access, audit trail, current administrator list | Verify identity, reset only the intended account, and review unexpected users | Sharing a universal administrator credential |
| Malware or an unexpected redirect is suspected | Traffic, files, logs, database, DNS, users, and a clean evidence copy | Contain access and compare known-good checksums or backups | Deleting suspicious files before understanding persistence |
| Data appears missing or inconsistent | Database snapshot, storage, order records, uploads, and the exact missing examples | Read-only comparison between current data and a candidate backup | Restoring over production without proving the restore point |
| The site is slow or intermittently unavailable | Time window, affected paths, server metrics, upstream calls, cache state | Separate origin, database, asset, and third-party latency | Installing another optimization plugin as the first test |
Write down when the problem began, who is affected, the exact path, the expected result, and the observed result. Add the last known good time and every recent release, plugin update, DNS change, account change, campaign, import, or provider incident. This timeline is often more useful than a screenshot alone.
A backup is only useful when its source, time, database, uploads, configuration, and restoration path are known. Preserve current production evidence separately from any rollback candidate. Do not call a backup “verified” until it can be inspected or restored in an isolated environment.
“Fix WordPress” is not an acceptance test. A first recovery target might be: the homepage and key landing page return correctly, an authorized editor can sign in, a controlled form reaches the expected destination, or a test checkout reaches the provider without creating a real order. Broader cleanup can follow after the critical path is stable.
A successful symptom fix does not prove the root cause is gone. Document unresolved access, outdated components, unsupported custom code, security findings, data questions, provider dependencies, monitoring gaps, and the observation window needed before declaring the incident closed.
Bring the evidence
Faith Forge Labs can review the affected path, authority, recent-change timeline, available recovery points, and the smallest safe validation target.