This is the final part. The previous seven were about reducing incidents and preparing for them; this one is about the day it actually happens — strange pages appearing in search results, a visitor reporting they were redirected elsewhere, or a warning email from your host.
Decisions in that moment are made under pressure. Setting the order in advance is the whole purpose of this part.
First, what not to do
This half matters more than people expect. The instinctive reactions are frequently the ones that make recovery harder.
Deleting in haste removes any way of learning how they got in. Restore without knowing the route and the same thing happens again days later — by which point your backup generations may be compromised too.
Check especially that automatic backups are not overwriting clean generations with the compromised state. What you need right now is a backup from before the incident, and a short retention window may mean that point has already scrolled away.
The first thirty minutes — stop and preserve
Preserve comes first. Download the files and database exactly as they are and keep that copy aside. It is not for restoring; it is for investigating.
Containment means stopping the damage from spreading outward. If the site is redirecting visitors or sending mail, putting up a maintenance page for now is the right call — and if search engines keep crawling the compromised state, cleaning that up afterwards is considerably harder.
Cutting off access means changing every administrator password, plus the database, hosting and file transfer credentials. If there is an administrator account you do not recognise, record when it was created before deleting it — that timestamp tells you when they arrived.
The next thirty minutes — when and how
Server access records and file modification times are the evidence at this stage. A cluster of modification timestamps usually marks the point of entry, and the access records around that time narrow down the route used.
The common routes are the ones this series has already covered: a component left un-updated, a password leaked somewhere else, an extension whose development had stopped. In other words, the conclusion of this investigation almost always lands on an item from an earlier part.
An honest note here. This stage can be genuinely difficult to do alone. Reading server logs and telling a modified file from a legitimate one takes experience, and a wrong call erases the evidence that was left. If you are not confident, asking for help at this point is the cheapest decision available.
Recovery, and closing the same door
Only after the route is understood do you restore. Roll back to a pre-incident backup and apply every update immediately on top of it. The versions in that backup are the versions that were vulnerable, so until you update, the same door is standing open.
Afterwards, check the search side too. If a security warning remains in Search Console, resolve it and request a review; indexed pages you never created should be submitted for removal.
Closing the series
Across eight parts we have worked through accounts, updates, plugin selection, backups, certificates, logins and incident response. They share one property: every one of them can be done before anything goes wrong, and most take under a day.
The parts that are hard to do alone — version upgrades with verification, server-level hardening, checking for signs of compromise — are handled as one job in our optimization program. Exactly how we work, and what we measure before and after, is published step by step on the process page.