The First 24 Hours: What a Hacked WordPress Site Looks Like From the Owner’s Chair
Quieter than you’d expect
A modern WordPress compromise rarely announces itself. Nobody swaps your homepage for a skull anymore; there’s no money in it. Instead the first signal tends to arrive sideways. A customer writes in asking why your site sent them to a fake courier-payment page. Search Console flags a security issue. Organic traffic slides for two weeks with no explanation you can find. Or the hosting provider suspends the account, and you learn about the infection from the outage it caused.
The quiet is engineered. Current infection campaigns are built to hide from the owner specifically. Parrot TDS, one of the biggest traffic-redirection operations of recent years, serves clean pages to search engine bots, to security scanners, and lately to AI training crawlers too, while sending actual human visitors to phishing pages and fake shops. You open your own site and everything looks fine; a scanner reports the same. Meanwhile real visitors are being robbed on your domain, and the first hard evidence usually arrives as a drop in rankings weeks later.
What the first day looks like when it goes well
Hours 0–2. Stop the bleeding. Maintenance mode, or access restrictions at the server level. Then credentials: every WordPress admin, hosting panel, SFTP, database. Change them from a machine you trust, because if the passwords were stolen off your own laptop, rotating them from that same laptop achieves nothing. Application passwords and API keys get revoked too.
Hours 2–6. Look before you clean. The urge to start deleting suspicious files right away is strong and worth resisting for an hour. First, preserve a copy of the infected state — files, database, server logs. That copy is how you find the entry point, and a cleanup that never identifies the entry point is a cleanup you’ll be repeating in three weeks. Then read: file modification times, admin users nobody recognizes, plugins nobody installed, odd cron entries, and what the access logs show around the timestamps of the earliest changed files.
Hours 6–12. Restore or scrub. If your backup history reaches back past the infection (this is why retention matters — see our backups piece), restoring a known-clean version and immediately closing the entry point is usually faster than surgery on a live infection, and easier to trust afterwards. Without a clean backup it becomes methodical work: core reinstalled from scratch, every plugin and theme refetched from original sources, and a manual pass through uploads and the database for executable code sitting where executable code has no business being.
Hours 12–24. The unglamorous part. Request a review in Search Console if the site was flagged. Check what the spam pages did to your index and start cleaning up the search presence. And if customer data may have been exposed and you serve EU users, GDPR gives you 72 hours to notify your supervisory authority. That clock starts when you become aware of the breach, not when the cleanup is finished.
The uncomfortable arithmetic
Everything above costs a multiple of what prevention would have. Fast updates, a firewall, offsite backups with history, monitoring that catches redirects and file changes before customers do. If you’d rather not find out how the first 24 hours feel from the inside, that short list is where the money goes furthest.
