A site rescue is not a specific service with a fixed scope. It is a label that covers a wide range of situations. The common thread is that someone hands over a WordPress site in an unknown state and needs another developer to take responsibility for it.
That unknown state is what makes rescue work different from building or maintaining a site from the start. You are inheriting decisions you did not make, code you did not write and problems you have not seen yet.
The first step is always an audit, not a fix
Before touching anything on a rescued site, the priority is understanding what exists. That means a read-only pass through the site, the hosting setup, the database and the codebase. Nothing gets updated, deleted or changed until there is a clear picture of the current state.
The audit covers several areas.
Plugin inventory. Every active and inactive plugin is listed, along with the last update date and whether the plugin is still maintained.
Backup status. Whether automated backups exist, where they are stored and how recent the last backup is.
Hosting environment. PHP version, server software, whether the hosting plan is appropriate for the site.
Theme structure. Whether the active theme is a standard theme with a child theme, or whether the theme files have been directly modified.
Security review. File permissions, whether wp-config.php is accessible, whether any obvious signs of compromise exist.
Common findings on rescued sites
After reviewing a reasonable number of inherited sites, certain patterns appear consistently. None of them are surprising, but they are worth naming.
More than 40 plugins installed, many of them inactive or unused.
No automated backups, or backups stored only on the same server as the site itself.
Hardcoded credentials in theme files or functions.php.
PHP version several major releases behind, sometimes still on PHP 7.4.
Functionality built directly into the theme, such as custom post types, shortcodes and API integrations, that should have been a plugin, making it impossible to change themes without losing features.
No staging environment, meaning any change has always been made directly on the live site.
Updating everything first is usually the wrong move
The instinct when inheriting a neglected site is to run all available updates immediately. That instinct is understandable but often causes problems.
A site that has not been updated for two years may have plugins that depend on older versions of WordPress or PHP. Running a batch update on a fragile site without a staging environment and a verified backup in place is a reliable way to cause a white screen or a broken layout. The site was already struggling. An untested batch update can take it offline.
Updates on a rescued site happen in sequence, on a staging copy, after backups are confirmed. Each update is tested before the next one runs.
What a rescue engagement covers
A rescue engagement typically covers the following.
Full audit of current state with written findings.
Setting up or verifying offsite automated backups.
Staged, sequenced updates with testing.
Removing unused plugins and tidying the codebase.
Fixing security issues identified during the audit.
A written handover document describing what was found and what was done.
A rescue does not cover a full redesign, new feature development or content changes. The goal is a stable, maintainable site. Once the site is stable, ongoing work can be scoped separately.
If the state of the site is unclear before committing to a rescue, a site health report gives you a full written picture of what exists, what is broken and what needs addressing before any work begins.
Frequently asked questions
Can you take over a WordPress site mid-project?
Yes, though it depends on the state of the work. Mid-project takeovers are more straightforward than inheriting a long-neglected site, because there is usually some documentation and a clearer sense of what was intended. The main risk is discovering that earlier work needs to be redone rather than continued. An initial review of the codebase usually makes that clear within a few hours.
How long does a site rescue take?
It depends on the condition of the site. A site with a clear structure, reasonable plugin count and accessible hosting can be stabilised in a week. A site with significant technical debt, no backups, deprecated PHP and a heavily modified theme can take three weeks or more. The audit stage usually gives a clearer estimate within the first day or two of looking at the site.
WordPress site in an unknown state?
A site health report gives you a clear picture before committing to any work.
Get in touch
