My WordPress Site Was Hacked — What Do I Do Now?

The moment you realize your WordPress site is compromised, most people make two mistakes immediately: they panic, and then they start clicking. Both make things worse.

A hacked WordPress site is not a catastrophe you can undo by refreshing the dashboard or deactivating plugins one by one. It's an active forensic problem. The malware is already embedded — probably across multiple files, maybe inside the database, possibly inside themes you haven't touched in two years. The infection vector is almost never what you think it is.

Here's what actually happens, what you should do in the first 60 minutes, and why most DIY cleanup attempts leave the backdoor wide open.

How WordPress Sites Get Hacked (The Real Patterns)

Most people assume hacks happen because someone "targeted" their site. They didn't. Automated scanners crawl millions of WordPress installs daily, probing for known plugin vulnerabilities, exposed REST API endpoints, weak credentials, and outdated PHP versions running known exploits.

WordPress powers 43% of the web. That scale makes it the highest-return target for automated attack infrastructure — not because your site is special, but because you're in the pool.

Across dozens of WordPress security audits and malware recovery cases, the root cause almost always falls into one of these categories:

• Abandoned or unpatched plugins with publicly disclosed CVEs
• PHP versions below 8.0 that no longer receive security patches
• wp-config.php permissions set too loosely, exposing database credentials
• Brute-forced admin credentials through xmlrpc.php or wp-login.php with no rate limiting
• Compromised themes sourced from unofficial repositories (nulled themes are a distribution vehicle for malware, not a savings strategy)

The infection rarely enters through where you're looking. And it almost never stays where it entered.

What's Actually Happening Inside Your Site Right Now

If you're reading this mid-crisis, here's the cold truth about what your site is likely doing at this moment.

Redirecting visitors silently. One of the most common malware behaviors injects redirect logic into .htaccess or into WordPress core files — typically wp-includes/functions.php or inside theme template files. You won't see the redirect when you're logged in as admin. Your visitors see it on every page.

Sending spam. PHP mailer functions embedded in uploaded files or modified core files are using your server's mail infrastructure to send thousands of phishing emails per hour. Your domain is now on spam blacklists. That's going to affect your deliverability long after cleanup.

Mining data or credentials. Some injections sit dormant — harvesting form submissions, WooCommerce checkout data, or admin credentials — without triggering obvious symptoms. These are the dangerous ones because you don't know how long they've been active.

Hosting phishing pages. Attackers upload entire fake login pages — mimicking banks, PayPal, or popular SaaS tools — into subdirectories of your WordPress installation. You have no visibility unless you're watching your file system.

Reporting back to C2 servers. Sophisticated injections maintain a persistent connection to command-and-control infrastructure. The malware isn't static. It receives instructions, downloads additional payloads, and reinstalls itself if you delete the visible files without addressing the core entry point.

This is why deleting suspicious files and calling it clean is dangerous. You've removed a symptom. The mechanism is still intact.

The First 60 Minutes: What to Do and What Not to Do

Do Immediately

1. Take your site offline or enable maintenance mode. Don't let visitors continue hitting infected pages. Use your host's control panel to temporarily suspend the site or push a static maintenance page. Every minute your site serves malware is another minute your domain reputation deteriorates.

2. Change all credentials — from a clean device. Admin passwords, FTP/SFTP credentials, database password (update wp-config.php after changing it in your host's database panel), hosting control panel login, and any email accounts tied to admin roles. Do this from a device that hasn't been used to log into the site recently.

3. Disable xmlrpc.php if you're not using it. This is a high-value attack vector. Add Deny from all inside a <Files xmlrpc.php> block in your .htaccess. If you're using Jetpack or another service that requires XML-RPC, that conversation is for after cleanup.

4. Pull a file listing with timestamps. Via WP-CLI or your host's file manager, look at recently modified files. Run: find /your-wp-root -name "*.php" -newer /your-wp-root/wp-config.php — any PHP files modified after your last known-clean date are candidates for inspection. This won't catch everything, but it narrows the field fast.

5. Check wp_options for injected values. Malware frequently stores payload data or redirect rules inside the wp_options table — specifically in siteurl, home, and serialized option values tied to active plugins. Export your database and scan it. Look for base64-encoded strings, eval() calls, and external URLs in places they don't belong.

Do NOT Do

• Do not just run a free plugin scanner and call it fixed. Most surface-level scanners miss database injections and obfuscated code.
• Do not restore from backup without understanding when the infection started. Restoring an already-infected backup undoes your work and reintroduces the payload.
• Do not update plugins mid-compromise without first isolating the infection. Updates can overwrite files you need to forensically examine.
• Do not contact your host's generic support expecting a cleanup. Hosts manage infrastructure. Your application layer is your problem.

The Backup Restore Trap

Backups feel like a safety net. They are — but only if you know when the infection started and your backup predates it.

In most malware recovery scenarios, the infection has been present for days or weeks before detection. Search Console starts flagging deceptive pages. Visitors report redirects. Or worse — Google blacklists the domain and your organic traffic drops overnight.

If your most recent clean backup is from three months ago, you're looking at significant data loss. If you don't have reliable backups at all — which is common in sites without a structured maintenance approach — your options narrow fast.

Restoring without knowing the infection date also resets your site to a state that may already include the initial vulnerability. You restore the backup. The attacker uses the same entry point. You're compromised again within hours.

This is the cycle most site owners fall into when they try to manage recovery without a structured methodology. For situations this critical, you need emergency WordPress support — not a forum thread.

Why DIY Malware Removal Fails

Here's what a proper WordPress malware cleanup actually involves — not what a plugin scan covers:

• File integrity checking against WordPress core checksums via WP-CLI (wp core verify-checksums) and against a known-clean version of each plugin and theme
• Database-level scanning for injected SQL, obfuscated PHP, and serialized payloads in wp_options, wp_posts, and wp_postmeta
• Server log analysis to identify the attack vector, entry timestamps, and affected endpoints
• Backdoor identification — uploaded shells, modified functions.php blocks, and injected includes that reinstall the malware after surface-level deletion
• Post-cleanup hardening — fixing file permissions, adding .htaccess rules, disabling unnecessary REST API endpoints, enforcing object cache flushing to clear contaminated transients

Most DIY attempts get through file deletion and maybe a database scan. They miss the backdoor. They skip log analysis. And they don't address the entry point — which means the site gets reinfected, sometimes within 24 hours.

That's not a cleanup. That's a temporary cosmetic fix on an open wound.

Getting Your Site Off Google's Blacklist

If Google has flagged your site, cleanup is only half the battle. You need to submit a reconsideration request through Google Search Console after the infection is fully removed and verified.

The steps:

1. Verify the site in Search Console if you haven't already
2. Navigate to Security & Manual Actions → Security Issues
3. Review the specific URLs Google flagged
4. After confirmed cleanup, click "Request Review" with a clear explanation of what was found and remediated
5. Expect 1–3 days for Google's review; manual actions can take longer

Until Google removes the warning, visitors using Chrome will see a full-screen "This site may be harmful" interstitial. That's not a traffic dip — that's a full stop. Every day that warning sits costs you visitors, revenue, and brand credibility.

If your site was generating meaningful revenue, model this simply: a store averaging $2,000/day loses roughly $83/hour while that warning is live. Forty-eight hours of Google blacklisting at that traffic level isn't a maintenance problem. It's a revenue emergency.

What a Professional Cleanup Actually Looks Like

At our firm, we handle this through two service tracks depending on severity:

Malware Medic — For sites with active infections that are still operational. Full file and database scanning, backdoor removal, hardening, and blacklist clearance. Structured, methodical, no corners cut.

Site SOS — For complete emergencies: site down, blacklisted, or fully compromised with no safe recovery path. This is triage-level response. We assess the damage, identify whether a clean restore is viable, and execute a recovery plan with minimal downtime.

Both services include post-cleanup hardening so the entry point doesn't become a revolving door.

After Cleanup: The Prevention Architecture

Once your site is clean, the work isn't done. The attack surface that got you compromised needs to be closed permanently.

The minimum viable security stack for any WordPress site:

• PHP 8.1 or higher — not just for performance, but because older versions have known, unpatched exploits
• Automated plugin and theme updates with a staging workflow to catch compatibility breaks before they hit production
• wp-config.php hardening — DISALLOW_FILE_EDIT set to true, database table prefix changed from default, file permissions locked to 440
• Object cache with Redis or Memcached — limits database exposure and reduces attack surface on high-traffic endpoints
• Weekly database optimization — clearing expired transients, cleaning wp_options autoloaded data, preventing the table bloat that slows admin and increases recovery complexity
• Offsite backups with 30-day retention — tested restores, not just scheduled jobs you've never verified

This isn't a checklist you run once. It's an operational discipline. Sites that get reinfected almost always had patched the surface issue and ignored the underlying posture.

The Real Cost of Waiting

Most site owners discover a hack because something obvious breaks — a visitor complains, traffic craters, or the host suspends the account. By that point, the infection has already been active for days to weeks.

Every hour of delay after detection extends the blacklist damage window, increases the number of visitors served malware, compounds the reputational cost with search engines, and raises the complexity and cost of cleanup.

Speed is not optional here. A contained infection is a cleanup problem. A prolonged one is a reputation rebuild.