Real 84EM email is only @84em.com

Rescuing a Failing WordPress Project

The professional playbook for a broken, hacked, inherited, or stalled WordPress project: assess, stabilize, remediate, then repair or rebuild.

> ls ./guides/wordpress-project-rescue/

> Inheriting a Site

> Hacked Site

> Repair vs. Rebuild

> Stalled Project

> Post-Rescue

A WordPress project on fire (hacked, inherited from a developer who disappeared, stalled mid-build, or just broken) needs the same discipline regardless of which situation it is: assess before touching anything, stabilize, remediate whatever’s actually wrong, then decide repair or rebuild.

What do you do first when a WordPress project is broken?

Assess before you touch anything, and don’t delete evidence while you’re figuring out what happened, especially if the site was hacked. Stabilize next: stop active damage without destroying the information you’ll need to understand what actually went wrong and fix it correctly instead of guessing.

Inheriting a broken or legacy site

Taking over a build you didn’t create starts with access (hosting, domain, admin), then an honest audit of what’s actually there: outdated software, undocumented custom code, and whatever’s quietly broken underneath.

See inheriting a broken or legacy WordPress site for what to check first.

Fixing a hacked site

Contain, investigate, then clean, in that order. Deleting suspicious files before understanding how the attacker got in just means the same entry point is still open once you’re done.

See fixing a hacked WordPress site for the professional remediation path.

Repair vs rebuild

Repair when the foundation is sound and the damage is contained. Rebuild when the foundation itself, the architecture, the code debt, the security posture, is what’s actually broken.

See WordPress repair vs rebuild for how to make that call honestly.

Rescuing a stalled project

When a build stalls or a previous team walks away, the first job is honest triage: what’s done, what’s worth keeping, and what a real path to finished actually looks like.

See rescuing a stalled WordPress project for that triage process.

Keeping it stable after

A rescue that isn’t followed by real maintenance just resets the clock until the next incident. Hardening, monitoring, and backups are what keep a recovered site recovered.

See keeping a WordPress site stable after a rescue for what that ongoing discipline looks like.

How 84EM runs a rescue

Every rescue follows the same sequence: assess honestly, stabilize without destroying evidence, remediate what’s actually wrong, then repair or rebuild based on what the assessment actually found, not a default answer picked in advance. See project rescue services to talk about what’s happening with your project.

Inheriting a Broken or Legacy WordPress Site

What to audit first when you take over someone else's WordPress build: access, backups, plugins, custom code, and what is broken.

Read

Fixing a Hacked WordPress Site

The professional remediation path for a hacked WordPress site: contain, investigate before deleting, clean, close the entry point, and harden.

Read

WordPress Repair vs Rebuild: How to Decide

Repair when the foundation is sound; rebuild when code debt and security make fixing cost more than starting clean. How to decide.

Read

Rescuing a Stalled WordPress Project

When a build stalls or the previous team walked: honest triage of what works, what is worth keeping, and a path to finished.

Read

Keeping a WordPress Site Stable After a Rescue

A rescue without maintenance invites the next incident. The hardening, monitoring, and updates that keep a recovered site stable.

Read

Let's Talk

Direct access to the senior engineer who scopes, builds, and ships your project. No one in between.

Folks We've Helped