Confirm It Is Actually a Hack
Before panicking, verify. The common symptoms are a browser or Google warning that the site is dangerous, redirects to unrelated sites (often only on mobile, or only for visitors arriving from search), pharmaceutical or gambling pages appearing under your domain, admin users you did not create, or your host suspending the account.
Two quick checks: run your domain through Google's Safe Browsing status page, and open Search Console where security issues are reported explicitly. Also try loading your site in an incognito window from a phone on mobile data — many injections deliberately hide from logged-in administrators and desktop browsers.
The First Hour: Contain It
- Take a full backup anyway. Yes, of the infected site. You need forensic evidence and you may need files from it. Label it clearly as infected.
- Put the site into maintenance mode or take it offline temporarily. Every hour a compromised site is live is more damage to visitors and to your search standing.
- Change every password. Hosting, WordPress admin, database, FTP or SFTP, and the email account tied to admin. Use new, unique passwords, not variations of the old ones.
- Force all users to log out by invalidating sessions, so stolen session cookies stop working.
- Check the user list in WordPress and delete any administrator you do not recognise. Note them first — they are a clue to entry point and timing.
- Tell your host. Most Indian hosts have dealt with this hundreds of times, some will scan for you, and they can tell you whether other accounts on the server were affected.
The First Day: Clean It
Option A: Restore from a clean backup — fastest and most reliable
If you have a backup from before the compromise, restore it, then immediately update everything and close the vulnerability before the site goes public again. Restoring without patching means you are reinfected within days by the same automated scan.
The difficulty is knowing when the compromise started. Check file modification dates, your host's access logs, and the creation date of any rogue admin user. Go back further than you think you need to.
Option B: Clean the existing installation
- Replace WordPress core with a fresh download of the same version. Core files should never be modified, so wholesale replacement is safe.
- Reinstall every theme and plugin from official sources rather than trying to repair them. Delete anything not actively used.
- Scan the uploads directory for PHP files. There is no legitimate reason for executable code to live in your media folder, and it is a favourite hiding place for backdoors.
- Inspect wp-config.php, .htaccess, and any file with a recent modification date for injected code. Look particularly for long base64-encoded strings and eval calls.
- Check the database for injected content — spam links in post content, unexpected entries in the options table, unauthorised admin users.
- Run at least two independent malware scanners, because each misses different things.
The critical part is finding the backdoor. Attackers routinely leave a second access route so that cleaning the visible damage does not lock them out. A site that gets reinfected days after cleanup had a backdoor that was never found — which is exactly the situation where rebuilding beats cleaning.
The First Week: Restore Search Visibility
- In Search Console, open the Security Issues report and request a review once you are confident the site is clean. Premature requests that fail add delay.
- Check the index for spam pages injected under your domain. Remove them and request removal so they stop appearing in results.
- Watch your 404 report — cleaned spam URLs will generate errors, which is fine and expected.
- Verify your legitimate pages are still indexed and that no noindex tag was injected.
- If a browser warning was applied, expect a few days after review approval before it clears fully.
Traffic recovery after a flagged compromise typically takes two to six weeks. Cleaning within 48 hours substantially limits the damage; a month-long compromise does not fully recover for a quarter.
How It Happened, In Order of Likelihood
| Entry route | Why it happens | Prevention |
|---|---|---|
| Outdated plugin or theme | Vulnerabilities are published publicly and scanned for automatically within hours | Update weekly; delete unused extensions entirely |
| Nulled / pirated premium plugin | Backdoors are commonly bundled deliberately | Buy licences or use free alternatives |
| Weak or reused admin password | Credential stuffing and brute force at scale | Unique passwords plus two-factor authentication |
| Shared hosting cross-contamination | Another compromised account on the same server | Move to isolated or managed hosting |
| Compromised developer machine | Stolen FTP or hosting credentials | Rotate credentials; use SFTP and key-based access |
| Abandoned staging or old install | Forgotten WordPress copy in a subdirectory, never updated | Delete unused installations |
Notice how many of these are about things you are not using. The single most effective security measure available to most WordPress sites is deleting the eleven plugins and three themes that nobody has touched in two years.
Hardening: The Practical List
- Update on a schedule. Weekly, with a staging environment for anything transactional.
- Delete rather than deactivate. A deactivated plugin still has files on the server and can still be exploited.
- Two-factor authentication on every admin account. Free, and it neutralises password theft.
- Least-privilege roles. The person writing blog posts needs Author, not Administrator.
- Off-site automated backups. Daily, stored somewhere other than the web server, and tested by actually restoring one occasionally.
- Disable file editing in the admin panel so a compromised login cannot edit theme code directly.
- A web application firewall, either at the host or through a service in front of the site.
- Rate-limit the login page to blunt brute-force attempts.
- Remove abandoned installations in subdirectories — old sites, test copies, forgotten microsites.
Budget realistically for this. Ongoing maintenance is not optional on WordPress, and we have costed it out in our annual website running cost guide.
The Structural Question Worth Asking
WordPress is compromised more often than other platforms for an unglamorous reason: it powers a large share of the web, and its plugin ecosystem is enormous and unevenly maintained. Every plugin is third-party code with server-side execution rights on your site.
A statically generated site — a build produced ahead of time and served as plain files — has no database to inject, no PHP to execute, and no plugin surface to exploit. That is not a marketing claim; it is a structural difference in what can be attacked. For content-heavy sites where a CMS is genuinely needed, a headless setup keeps the editing interface separate from the public site entirely.
This does not mean everyone should abandon WordPress. It does mean that if you have been compromised twice, the platform choice deserves reconsideration alongside the security checklist. Our comparison of custom builds versus template platforms covers the trade-offs.
Cleanup Costs in India
| Scenario | Typical cost | Timeline |
|---|---|---|
| Restore from clean backup and patch | ₹3,000 – ₹10,000 | Same day |
| Standard malware cleanup | ₹8,000 – ₹25,000 | 1–3 days |
| Complex cleanup with backdoor hunting and reindexing | ₹25,000 – ₹75,000 | 3–10 days |
| Rebuild on a clean installation | ₹40,000 upward | 1–3 weeks |
Set against that, an off-site backup service costs a few hundred rupees a month and converts the top row into your default outcome.
If your site is currently compromised and you want it assessed and cleaned properly — or rebuilt on something with a smaller attack surface — get in touch with Kalex Studio.