WordPress Site Hacked: The First 24 Hours in Ontario

Do not start deleting files. In the first 24 hours: take a full snapshot of the site exactly as it is, open Search Console and read Security issues plus index coverage, confirm what your host's backups actually contain and how far back they go, rotate every credential, and only then decide how to clean. Deletion first destroys the evidence you need to stop it happening twice.

Order matters more than speed. Working the list out of sequence is how businesses end up cleaning the same site three times. A hacked install is a crime scene and a backup at the same time — the moment you start deleting, you lose the ability to answer the only question that matters afterwards: how did it get in?

1. Snapshot everything before you touch it. Nothing else happens first.
   • Take a full copy — all files plus a database dump — and store it somewhere the live site can't reach. Label it clearly as infected so nobody restores it by accident later.
   • Save the file timestamps. The modified dates on injected files are frequently the clearest timeline you'll ever get of when the door opened.
   • Grab your server logs for the widest window your host retains. Most hosts rotate them out in days. Once they're gone, they're gone.
   • Screenshot what Google is showing. Search site:yourdomain.ca and capture it. Injected pages disappear from view during cleanup, and you'll want the list.
2. Search Console → Security & Manual Actions. Two separate reports live here: Security issues tells you whether Google has flagged the site and what category it filed the problem under; Manual actions tells you whether a human at Google has penalized it. Read both. If you don't have Search Console verified, verify it now — you'll need it for every later step.
3. Search Console → Pages (index coverage). Sort through indexed URLs and look for anything you never created. This is where the real scale of an infestation shows up — injected URLs are frequently indexed in volumes that never appear anywhere in your own navigation. The Pages report only samples, so pair it with a site:yourdomain.ca search and, if you still have them, your server logs, to get the full list. The audit line in the method below is this step done properly.
4. Confirm what your backups actually contain. Not that they exist — what's in them, and how far back they go. Nightly backups with a 7-day retention window are worthless against an intrusion that started five weeks ago; you'd just be restoring the compromise. Check the oldest restore point you have and check whether the injected files are already in it.
5. Rotate every credential. Hosting control panel, SFTP/SSH, database user, every WordPress admin account, the DNS registrar, and the email account those password resets land in. Regenerate the auth keys and salts in wp-config.php — that is what actually force-logs-out every existing session, including theirs. Rotate any API keys and licence keys the site holds. Delete admin users you don't recognize. If you're not certain who currently holds access to your domain and hosting, fix that in the same pass — owning your domain, DNS, and hosting is a prerequisite for controlling any of this.
6. Now decide how to clean. Not before. The decision depends on what steps 2 through 4 told you.

Two things people do in hour one that make hour forty harder: restoring an old backup immediately (you overwrite the evidence and often reintroduce the entry point), and taking the site fully offline for days (you convert a security problem into a crawl problem). If you must go dark, serve a 503 with a Retry-After header rather than letting requests fail — that tells Google this is temporary and to come back, instead of banking a site-wide outage.

Search "remove WordPress malware" and the results belong to Sucuri and Wordfence. That's correct. Scanning infrastructure, signature databases, incident teams who have seen your payload a thousand times — that's their category, not ours, and we're not going to sell you a worse version of it.

Where we're useful is the layer above that decision. Cleaning removes the payload. It does not remove the attack surface. An install that got injected once through a plugin layer is a candidate again — same plugins, same update cadence, same person responsible for patching them, usually the owner, who has a business to run.

So the honest framing is: clean the site, then decide whether that site is the one you want to keep defending. Those are two separate calls, and most panic-hour advice collapses them into one.

This is the part almost nothing written about hacked sites separates properly. When someone says the site is "clean," ask which of these three they mean, because they resolve on completely different schedules.

The gap between the first row and the third is where business owners lose faith in whoever cleaned the site. The cleaner did their job. The other two jobs were nobody's.

Once the files are clean, thousands of spam URLs can still sit in the index pointing at pages that no longer exist. How you answer requests for them changes how fast they clear.

• 410 Gone — the strongest honest signal for injected URLs. It says the page existed and is permanently gone, and Google processes it marginally faster than a 404. The real reason to prefer it is that it's the honest status code for pages that were never yours.
• 404 Not Found — works, just slower. Perfectly acceptable if your stack makes bulk 410s awkward. Do not agonize over the difference on a small number of URLs.
• 301 redirect to your homepage — the tempting move, and the wrong one. Mass-redirecting thousands of unrelated spam URLs to one page reads as a soft 404 at best and as a manipulation pattern at worst. It also hides the problem from your own reporting.

Two more things that matter:

• The removals tool hides, it doesn't deindex. Search Console's removals request suppresses a URL from results temporarily — roughly six months — while the underlying signal is still whatever your server returns. Use it for anything genuinely embarrassing that's visible right now. Don't use it as your deindexing strategy; when it expires, whatever you didn't fix comes back.
• Clean your sitemap and resubmit. A sitemap listing only your real URLs, resubmitted, gives Google an unambiguous statement of what the site actually is. Combine that with 410s on the injected paths and the index catches up on its own.

Then wait. Recrawl of a few thousand junk URLs is not instant, and hammering the inspect-and-request-indexing button on each one is not a strategy.

A manual action for hacked content shows in Search Console under Manual actions. It clears when a human at Google reviews your reconsideration request and agrees the problem is fixed — which means the request has to read like a report, not a plea.

• What happened, in plain terms, without speculation you can't support.
• What you fixed — the specific remediation, the entry point closed, the credentials rotated.
• Evidence it's clean — scan results, dates, what you're now serving on the injected paths.
• What prevents recurrence — the section most requests skip, and the one a reviewer actually cares about.

Submit once, complete. Repeated thin requests slow the queue for you specifically. And do not file it until the files are genuinely clean; a rejected request costs you days you don't have.

If your organic traffic fell off a cliff and you're not sure whether it was the hack, the cleanup, or something you changed while panicking, the diagnostic sequence in why traffic drops after a relaunch applies almost unchanged.

We rescued a business from a spam infestation of roughly 1,200 injected pages. Cleaned it. Rebuilt it. Got it re-ranked. Then moved it onto an architecture with no database and no plugins to reinfect.

We're not going to tell you who it was. Not the name, not the industry, not the city, not the size. When a business gets hacked, the intrusion is often the least damaging part — the reputational tail is worse, and it lasts longer than any payload. We do not name clients in sensitive situations. If we named that one to win your trust, you'd have every reason to assume we'd name you.

What we can give you is the method, which is the part that transfers anyway:

snapshot  → evidence preserved before any deletion
audit     → every indexed URL enumerated, ours vs theirs
clean     → payload out, entry point closed, creds rotated
deindex   → 410 on injected paths, sitemap rebuilt, resubmitted
rebuild   → static architecture: no database, no plugins
re-rank   → real pages back to earning

The last two lines are the ones that changed the shape of the problem. Everything before them is remediation; those two removed the database and the plugin layer that made reinfection possible in the first place.

After the fire is out, there's a real decision, and it isn't automatic. Some sites should be cleaned, hardened, and kept. Some shouldn't.

• Lean toward cleaning and keeping if the entry point is identified and closed, the plugin surface is small, someone is genuinely accountable for patching on a schedule, and the site is otherwise doing its job.
• Lean toward rebuilding if you can't establish how they got in, the install carries years of accumulated plugins nobody can account for, this isn't the first incident, or the site was already slow, dated, and underperforming before any of this. A roofing or wildlife-removal outfit running a decade-old install with thirty plugins nobody can account for is not going to win a patching schedule against someone whose day is on a ladder. In that case you're not buying a rebuild — you're buying out of the patch treadmill: no plugin layer to keep current, no database to inject into.

The rebuild we ship is static: pages rendered ahead of time and served from an edge network, with no database to inject into and no plugin layer to exploit. That's the whole security argument, and it's the same reason the maintenance retainer disappears. You can check the result yourself — thecritterguy.ca came off WordPress, cottagehero.ca was built on the stack from day one. Open either one and run Lighthouse. That click is the receipt.

Rankings are the part people fear losing in a move, which is fair, and it's an execution problem with a known answer: preserve or 301 every URL that earned anything. The full sequence is in migrating off WordPress without losing rankings, and what we build is on the Websites page. Cost, if you're wondering, is driven by page count, how much content has to be rewritten versus ported, how tangled the redirect map is, and how much of the index needs cleaning up behind it — not by a plan tier.

Snapshot the site. Open Search Console. Rotate your credentials. Then, when the immediate panic is handled and you're deciding whether to clean this install again or stop having the problem, tell us what you want to rank for. We're in Mississauga and we work across Ontario. One form, a real reply from the people who'd do the work — not a sales rep. You can see what we've built on the case studies first; the sites are live and the scores are real.