TLDR: I recovered a hacked WordPress site by isolating it, taking a safe backup, scanning and cleaning infected files and the database, rotating credentials, hardening the site, and monitoring for reinfection. This guide shows practical steps you can follow now, plus what to avoid so you don’t make the situation worse.
How I Recovered My Hacked WordPress Site
I still remember the morning my site went down: strange redirects, unfamiliar admin users, and search engines flagging malware. I felt panic, but I also knew the right sequence of actions would save my content and reputation. In this article I’ll walk you through the precise steps I used, explain why each step matters, and point out common mistakes to avoid. You can treat this as a checklist to recover a hacked WordPress site with confidence.
What is a hacked WordPress site?
A hacked WordPress site means an attacker has gained unauthorized access to parts of your website — themes, plugins, uploads, or the database — and can modify content, inject malware, or steal data. Hacks range from subtle SEO spam injections to full site defacement. As you know, the sooner you act the less damage the attacker can cause.
Why does cleaning a hacked site matter?
Beyond the immediate embarrassment, a compromised site can: damage your SEO rankings, blacklist your domain, infect visitors, and expose user data. In my case, search traffic dropped by half overnight and Google flagged my site as unsafe. To recover trust and traffic, you must remove the payload, close the vulnerability, and prove the site is clean.
How to diagnose a hack: quick checks
Start with simple signals that told me something was wrong:
- Unexpected redirects or popup ads on pages
- New admin users you didn’t create
- Modified or unfamiliar files in wp-content
- Google Search Console malware warnings
- Login failures or password reset emails you didn’t request
Step 1 — Isolate the site
Immediately put the site into maintenance or offline mode to stop further damage while you investigate. If you host the site on a managed platform, contact support and ask them to temporarily disable public access or IP-restrict admin access. As you know, isolation prevents the attacker from continuing automated tasks while you clean the site.
Step 2 — Take a full backup (and keep it offline)
Before changing anything, create a full backup of files and the database and store it offline. This might feel counterintuitive because the backup contains the infection, but it’s essential for forensic analysis and for a fallback. I archived my backup and kept a copy on an isolated machine.
Step 3 — Scan files and database
Use a combination of server-side scans and plugins to identify malicious code. I ran these checks:
- Server malware scanner from my host
- WordPress security plugin scans (Sucuri, Wordfence, or similar)
- Manual inspection of recently modified files in wp-content, themes, and plugins
- Search the database for suspicious content and unauthorized admin users
During scanning I discovered injected PHP files and malicious entries in wp_options and wp_posts. That told me both files and the database were compromised, which is common when an attacker wants persistent control.
Step 4 — Clean files safely
My file-cleaning approach followed two principles: replace or remove. I replaced all core WordPress files with fresh copies from WordPress.org, and I deleted and reinstalled plugins and themes from trusted sources. For custom themes or child themes I manually removed injected code and compared clean file hashes where possible.
If you prefer a full reset you can also perform a controlled reset WordPress site and then restore only known-good content. That was one option I considered when custom files looked irretrievable.
Step 5 — Clean the database
Database infection often shows as spammy content, new admin rows, or malicious scripts stored in options. I exported the database and searched for common attack vectors: base64 strings, eval(), iframe injections, and unfamiliar admin users. For complex injections I restored the database from a clean backup and then applied only necessary content updates.
When you need to remove junk safely, use tools that help you clean WordPress database entries without breaking serialized data. That saved me from corrupting widget settings or plugin options.
Step 6 — Rotate everything: passwords, keys, and salts
After removing malware files and database payloads, change every credential: WordPress admin accounts, FTP/SFTP, database user password, hosting control panel, and any connected third-party keys. Update the WordPress salts in wp-config.php to invalidate old sessions. I treated this step as mandatory — attackers often keep valid sessions active unless credentials and salts change.
Step 7 — Purge caches
Cached pages can continue to serve malicious content even after cleanup. I cleared server caches, CDN caches, and plugin caches. If you use a caching plugin, go to its settings and perform a full purge. In my situation purging the cache removed lingering spam content immediately. You can follow this same step to purge cache WordPress after cleaning so visitors see the clean site.
Step 8 — Harden your WordPress site
After recovery, focus on prevention. Here are the hardening steps I applied:
- Updated WordPress core, themes, and plugins to the latest versions
- Removed unused plugins and themes entirely
- Enabled two-factor authentication for all administrator accounts
- Limited admin login attempts and changed the admin username if it was obvious
- Configured a Web Application Firewall (WAF) via my host or a service like Cloudflare
- Set secure file permissions and disabled file editing in wp-config.php
These steps close the common entry points attackers use and drastically reduce reinfection risk.
Step 9 — Consider migration if host is compromised
If you suspect the hosting environment itself is compromised, plan to migrate to a clean server. In my recovery I once moved to a different host to be sure there were no hidden backdoors. When you choose to migrate WordPress site, do it after completing the cleanup so you transfer only clean files and databases.
Step 10 — Rebuild trust and monitor
Once the site was clean and hardened, I requested a malware review from Google Search Console and submitted a reconsideration request where necessary. I also enabled continuous monitoring with a security plugin and set up uptime alerts. Daily or weekly scans and log reviews help catch attempts early.
What should you avoid during recovery?
- Do not immediately delete backups without keeping at least one offline copy for analysis
- Don’t ignore the database — many cleanups only fix files and miss malicious DB entries
- Avoid reusing the same passwords or API keys after cleanup
- Don’t restore from an old backup before you know the backup is clean
- Avoid installing outdated plugins or nulled themes — they are frequent attack vectors
Frequently Asked Questions
How do I know the site is fully clean?
You’ll see normal content served without redirects, no new unauthorized users, and clean scan reports from multiple security tools. Additionally, Google Search Console should stop showing malware warnings after you request a review. Keep monitoring for at least a few weeks to be confident.
Can I clean a hacked site myself or should I hire a pro?
If you’re comfortable with backups, FTP, and database queries you can handle many cleanups. However, complex infections or repeated attacks justify hiring experienced security professionals who can perform deep forensic analysis and ensure no backdoors remain.
Will changing themes or resetting WordPress remove malware?
Changing to a fresh theme or performing a controlled reset can remove infected theme files, but the database or uploaded files might still contain malware. Resetting is useful, but pair it with database checks and credential rotation. A targeted reset WordPress site can be part of a safe recovery plan if executed carefully.
How can I prevent future hacks?
Maintain strong passwords, keep WordPress updated, remove unused plugins, use two-factor authentication, deploy a WAF, and schedule regular security scans. I also recommend regular backups stored offsite and a staged environment to test updates before deploying to production.
What if the host says there is no breach on their side?
Hosts sometimes miss subtle compromises. If you still see problems after following recovery steps, escalate with detailed logs and timestamps. Consider migrating if evidence suggests unexplained file modifications or repeated breaches tied to the server environment.
Final thoughts
Recovering a hacked WordPress site feels overwhelming, but following a calm, structured process — isolate, back up, scan, clean, rotate credentials, harden, and monitor — will get you back to business. I learned that acting quickly, preserving evidence, and fixing root causes prevents repeat incidents. If you follow the steps above, you’ll greatly reduce the chance of another attack and restore user trust.