Four Recovery Workflows, Step by Step

1. Removing malware from a business site

Illustrative workflow, fictional site

The situation. Harbour Glass, a fictional glazing business at harbourglass.example, hears from two customers that its site sent them to a prize page when they tapped a Google result on their phones. On the office computer, the site looks normal.

How we would work through it:

1. Take a full copy of files and database before changing anything.
2. Reproduce the problem the way customers saw it: a phone-sized browser arriving from a search result. A redirect that only targets mobile visitors arriving from search would explain why the office never saw it.
3. Compare core files with the official release for the installed version, and plugins with fresh copies. In this scenario, an injected script turns up in the theme's header file and a modified .htaccess rule checks the visitor's referrer.
4. Search the database for the same script and for unfamiliar administrator accounts. A second administrator with a plausible name, created three weeks earlier, is removed after its creation date is recorded.
5. Look for the entry point. Logs show the new account was created soon after an outdated form plugin was probed. The plugin is updated, and every password and security key is changed.
6. Switch off dashboard file editing and tighten file permissions, as the WordPress hardening guide recommends ^[3].
7. Test on a phone from a search result again, then check Search Console for any listed issues.

What the owner would receive: a report listing the infected files, the removed account, the likely entry point and the hardening applied, plus the pre-cleanup copy for their records.

2. Clearing a Google warning on an online shop

Illustrative workflow, fictional site

The situation. Saltbush Supply, a fictional online store at saltbushsupply.example, sees a red warning page in Chrome and a sharp drop in orders. Search Console's Security Issues report lists malware with several sample addresses.

How we would work through it:

1. Put up a maintenance page so visitors are not exposed, and pause paid ads.
2. Copy the site, then read every issue in the Security Issues report, keeping in mind that Google's sample list may be incomplete ^[1].
3. Clean the whole site, not just the sample pages. Google states that fixing some pages will not earn a partial return ^[1].
4. Because this is a shop, check the checkout templates closely for scripts that capture card details. In this scenario none are found, but if they were, the owner would need to consider whether a data breach assessment is required ^[4] and tell their payment provider.
5. Test key pages with command-line tools such as cURL, as Google's guide suggests, so hidden content is not missed ^[2].
6. Bring the shop back online, then send one review request describing the problem, the steps taken and the result ^[1].
7. Wait without resubmitting, then check the Security Issues report until the issue clears. Google publishes its expected review times for malware ^[2], which the owner is told up front.

3. Full recovery from backups

Illustrative workflow, fictional site

The situation. Kestrel Freight, a fictional logistics company at kestrelfreight.example, finds its home page replaced and the admin area returning errors. Its host has suspended the account. File dates suggest the attacker had access for at least six weeks.

Why not clean in place: with weeks of access, custom code written for the company, and changes throughout the database, there is no reliable way to confirm everything has been found. A restore is safer.

How we would work through it:

1. Ask the host for file access and a copy of the suspended account, and preserve it as evidence.
2. Build a timeline from file dates and account creation times to estimate when the break-in began.
3. Check the off-site backup history. In this scenario, a copy from eight weeks earlier is clean, so it is restored to a private location.
4. Export the content added since then, such as a few news posts and quote requests, from the preserved copy, check it for injected code, and import it.
5. Update everything, change every password and key, remove unused plugins, and apply the hardening guide ^[3].
6. Test the quote form, login and key pages, then send the host a cleanup report so the account can be reinstated.

Had there been no clean backup, the same steps would apply with a fresh WordPress install in place of step 3.

4. Hardening a site after cleanup

Illustrative workflow, fictional site

The situation. Gumleaf Notes, a fictional community blog at gumleafnotes.example, has just been cleaned of a spam injection. The volunteers who run it want to make a repeat less likely without a large ongoing cost.

How we would work through it:

1. Review every user account. Five former volunteers still have administrator access; they are removed, and current editors are given the editor role rather than administrator.
2. Switch on two-step sign-in for the remaining administrators, and require strong, unique passwords ^[3].
3. Delete eleven inactive plugins and two old themes. Switch on automatic updates for the low-risk plugins that remain.
4. Set up off-site backups and carry out a test restore.
5. Switch on logging and file change alerts, sending them to a shared inbox someone checks weekly, in line with the guide's advice on logging and monitoring ^[3].
6. Connect Search Console alerts so any future security issue reaches a person the same day.

The result is not a promise that the blog cannot be hacked again. It is a site with fewer ways in, faster warning if something changes, and a tested way back.

The common thread

All four follow the same order: protect visitors, copy the site, find the full extent, remove it, close the way in, harden, test, and only then reopen and ask Google to review. That order is the core of our process. If your situation looks like one of these, our incident checklist is a good way to collect the facts before you get in touch.