WordPress Hacked? A Step-by-Step Recovery + Prevention Checklist for Site Owners

If you’re reading this because you suspect your site is wordpress hacked, you’re not being dramatic. Most WordPress compromises don’t look like a movie scene. They’re quiet and annoying: a weird redirect that only happens on mobile, spam pages showing up in Google, a sudden drop in rankings, a new admin user you didn’t create, or a security warning that scares off real customers.

The frustrating part is that a wordpress hacked situation can start out looking like “random WordPress problems.” A plugin update fails. Your site gets slow. Your homepage looks normal, but visitors landing from Google get sent somewhere sketchy. Or everything seems fine until you notice dozens (sometimes hundreds) of junk URLs indexed under your domain.

This guide is built for that exact moment. Not theory. Not panic. A practical, step-by-step response you can follow even if you’re not technical.

Here’s what you’ll do:

• Confirm whether the issue is actually a hack (and not caching, a plugin conflict, or a false alarm)
• Contain the damage fast, so the problem doesn’t spread or keep harming visitors
• Back up the right way before you change anything, so you don’t lose evidence or make cleanup harder
• Remove common malware entry points and clean safely without breaking your site
• Verify the site is truly clean and not about to get reinfected
• Lock it down with simple hardening steps that prevent a repeat

If your site is wordpress hacked, the goal isn’t to “try random fixes” until it stops acting weird. The goal is control: confirm, contain, clean, and prevent, with a checklist you can reuse anytime.

WordPress Hacked? Signs, Quick Tests, and What Counts as a Hack

If you’re trying to figure out whether your site is wordpress hacked, start with symptoms (what visitors see) and then move to confirmation (what the site is actually doing behind the scenes). A “hack” usually means unauthorized changes: new users, injected code, malicious redirects, spam content, or altered files/settings you didn’t approve.

Fast symptoms checklist (what you’ll notice first)

Look for any of these patterns (one alone can be a fluke, several together is a red flag):

• Redirects to gambling/pharmacy/“prize” pages (often only on mobile or only from Google traffic)
• Spam pages indexed in Google (random URLs you never created)
• New admin users you don’t recognize, or existing users suddenly upgraded to Administrator
• Browser/security warnings (“Deceptive site,” malware alerts, hosting suspension notices)
• Strange popups or ads injected into your pages
• Emails sent from your site that you didn’t trigger (password resets, contact form floods)
• Site speed drop + random 500 errors that come and go
• Homepage looks normal but specific pages behave oddly (common with conditional malware)

Quick confirmation tests (fast, high-signal checks)

These checks take minutes and give you real evidence:

• Users audit: In WordPress, go to Users and sort by role. Look for unknown admins. If you have database access (phpMyAdmin), check the wp_users table for new entries and recent changes.
• File timestamps: In your file manager/SFTP, sort wp-content/ by “modified date.” Pay attention to sudden bursts of changes, especially in plugins, themes, mu-plugins, and uploads.
• Security scan: Run a reputable scanner (plugin-based or server-side) to flag known malware signatures and suspicious PHP files.
• Google Search Console: Check Security issues and Manual actions, and review the Indexing/Pages report for junk URLs or spikes.

If multiple checks line up, that’s strong confirmation something is wrong beyond “WordPress being weird.”

“Not a hack” lookalikes (common false alarms)

Even when it’s not wordpress hacked, these can mimic the same symptoms:

• Caching issues (stale assets, broken images, weird layout) after updates
• Plugin conflicts causing redirects, errors, or admin lockouts
• CDN/WAF misconfigurations (Cloudflare rules, bot protection, mixed content rewrites)
• DNS propagation changes that make the site look different in different locations

Rule of thumb: if you see unauthorized changes (users, files, injected content), treat it as a security incident—not just troubleshooting.

WordPress Hacked: First 60 Minutes Triage Checklist

When a site is wordpress hacked, your first job is not “clean everything.” Your first job is to stop the bleeding, preserve evidence, and prevent reinfection while you get organized. Use this checklist in order. If you do nothing else, do the first two steps.

Contain damage (maintenance mode, block admin access if needed)

• Put the site in maintenance mode (or temporarily show a static “We’ll be right back” page). This reduces risk to visitors and limits automated attacks from continuing to run.
• If redirects or malware are active, consider temporarily restricting access:
  • Block /wp-admin/ and /wp-login.php at the server level (or limit by IP if possible).
  • If you can’t safely lock it down, take the site offline briefly rather than letting it keep infecting users.
• Pause outgoing email if your site might be sending spam (contact form abuse or compromised mail). This protects your domain reputation.
• Do not start deleting random files yet. That can remove clues and make reinfection harder to diagnose.

Snapshot backup before changes (files + database)

Before you touch plugins, themes, or core files, make a snapshot you can roll back to.

• Create a full files backup (entire WordPress directory, especially wp-content/).
• Create a database export (via your host backup tool, phpMyAdmin, or CLI).
• Save backups off-server (local drive or cloud) so you still have them if hosting access gets restricted.
• Label the backup clearly: incident-backup-YYYY-MM-DD so you don’t confuse it with clean backups later.

This is your safety net and your evidence bundle.

Rotate credentials (WP admins, hosting, SFTP/SSH, DB, API keys)

Credential theft is a common cause and a common reinfection path. Rotate these in a controlled order:

• WordPress admin passwords (all admins), and remove any suspicious admin users immediately after you have the backup.
• Hosting control panel login (cPanel/ISPConfig/etc.) + primary email tied to the host account.
• SFTP/SSH passwords/keys, and disable any users you don’t recognize.
• Database user password (update it in wp-config.php right after changing it).
• API keys & integrations: SMTP, payment gateways, reCAPTCHA, Google Maps, analytics tags, webhook endpoints, and any third-party services connected to the site.

Tip: If multiple people have access, assume all credentials may be exposed until proven otherwise.

Disable likely entry points (plugins/themes) safely

Most compromises enter through vulnerable or “nulled” plugins/themes.

• Disable all plugins quickly by renaming the /wp-content/plugins/ folder (fastest when you can’t access wp-admin).
• Switch to a default theme (like Twenty Twenty-Four) if you suspect the theme is compromised.
• If the site is business-critical, re-enable plugins one at a time after scanning and only from trusted sources.
• Flag and plan to remove anything that’s:
  • Abandoned (no updates)
  • Not from a reputable marketplace
  • “Pro” versions obtained outside official licensing (high reinfection risk)

At the end of this first hour, your goal is simple: the site is contained, you have a snapshot, credentials are rotated, and the biggest entry points are paused. Then you move to cleanup with a clear head.

Preserve Evidence + Prevent Reinfection

Once you’ve contained the incident, the next priority is to preserve evidence and block the most common reinfection paths. When a site is wordpress hacked, the worst outcome is “it looks clean” for 48 hours… and then the redirects come back because the real backdoor was never removed.

What not to delete (logs, suspicious files for review)

It’s tempting to start deleting anything that looks weird. Don’t—at least not yet. Save proof first.

• Do not wipe logs immediately. If available, export:
  • Web server access/error logs (Apache/Nginx)
  • PHP error logs
  • Security/WAF logs (Cloudflare, Wordfence, etc.)
• Do not delete suspicious files without copying them first.
  • Download the file (or zip the suspicious directory) so you can analyze it later or share it with a security pro.
• Do not overwrite everything blindly from a backup until you know the backup is clean. Restoring an infected backup is a fast way to reinfect yourself.

Your goal is to keep enough context to answer: How did they get in, what did they change, and what keeps re-triggering it?

Where hacks hide (high-probability hiding spots)

When WordPress malware is persistent, it usually hides in places people don’t check:

• mu-plugins (/wp-content/mu-plugins/) — must-use plugins load automatically and are a favorite hiding spot.
• wp-config.php edits — look for strange eval(), base64_decode(), unexpected includes, or remote calls.
• Cron jobs / scheduled tasks — WordPress cron can be used to re-inject malware. Check for unfamiliar scheduled events.
• Uploads folder (/wp-content/uploads/) — attackers often stash PHP files where you expect only images/PDFs.
• Database injections — malicious code can live in wp_options (siteurl/home rewrites, injected scripts), post content, or widgets.

If you only clean plugins/themes and ignore these areas, reinfection is common.

If you’re on shared hosting vs VPS (what changes)

• Shared hosting: You may have limited access to server logs and system processes. Focus on: WordPress user audit, file integrity, permissions, and eliminating vulnerable plugins/themes. Ask your host for log exports and malware reports if possible.
• VPS (or dedicated): You have more control—and more responsibility. In addition to WordPress cleanup, check server users, SSH keys, running processes, crontab at the system level, and web server config for malicious rewrites.

Bottom line: evidence + the right “hiding spot” checks is what turns a cleanup into a true fix, not a temporary pause.

Clean + Restore Safely (a Repeatable Malware Removal Workflow)

If you’ve confirmed the site is wordpress hacked, the safest approach is a repeatable workflow that assumes three things: (1) you may not know the entry point yet, (2) attackers often leave backdoors, and (3) “looks normal” is not the same as “clean.” The steps below are designed to clean without breaking your site or restoring an infected backup.

Replace core safely (reinstall WordPress core, integrity checks)

Core files should match official WordPress releases. If core is modified, you can’t trust what’s running.

• Back up first (you already did a snapshot in triage).
• Download a fresh copy of WordPress from WordPress.org.
• Replace only core folders/files (commonly: wp-admin/ and wp-includes/, plus loose core files in the root).
  • Do not overwrite wp-config.php or wp-content/.
• If you use WP-CLI, running a core re-download (without touching config/content) can be a clean method.
• After replacement, do a quick integrity check: compare timestamps, look for unexpected PHP files in /wp-content/uploads/, and confirm no unknown files appeared in the root.

Goal: get WordPress core back to a known-good baseline.

Clean themes/plugins (remove nulled/abandoned, reinstall from trusted source)

Most real-world infections come through plugins/themes.

• Delete (don’t just disable) anything nulled or obtained outside official licensing. Nulled software is a reinfection magnet.
• Remove abandoned plugins/themes (no updates, poor reviews, unknown vendors).
• For the plugins/themes you keep:
  • Delete the existing folder completely.
  • Reinstall the same version from a trusted source (WordPress repo or the vendor’s official download).
• Check for “lookalike” plugin folders (attackers sometimes create folders named similar to legit plugins).
• If the site is mission-critical, re-enable plugins one at a time and retest key flows (forms, checkout, booking).

Goal: eliminate the most common entry points and remove tainted code rather than trying to “edit it clean.”

Database cleanup (rogue admins, injected content, suspicious options)

A clean file system can still run malicious behavior if the database is injected.

• Users / admins: Remove unknown users. Also check for legitimate users that were elevated to Administrator.
• Injected content: Search posts/pages for strange scripts, hidden links, or spam blocks. Common places:
  • Footer widgets
  • Page builders/global templates
  • Reusable blocks
• Suspicious options: Review wp_options for:
  • Unexpected siteurl / home changes
  • Unknown autoloaded options with long, encoded strings
  • Settings that reference external domains you don’t recognize
• If you see heavy obfuscation (random characters, base64 blobs), preserve a copy for review before deleting.

Goal: remove persistence mechanisms that reinject spam or redirects from inside the database.

File permissions + wp-config hardening basics

You don’t need extreme lockdown, just sane defaults:

• Ensure folders are not world-writable. Use standard permissions for files vs directories (your host may recommend exact values).
• Disable PHP execution in uploads (common best practice) if your environment supports it.
• Review wp-config.php for unexpected:
  • New includes
  • Remote URLs
  • Strange constants you didn’t set
• Confirm your admin area is served over HTTPS, and consider:
  • Strong admin passwords + 2FA
  • Limiting login attempts
  • Disabling XML-RPC if you don’t need it (or restricting it)

Goal: reduce the chance that the same vector works again.

Validation steps (prove it’s clean)

Don’t stop at “the site loads.” Prove the infection is gone.

• Scan again with a reputable security tool after cleanup (and re-scan after re-enabling plugins).
• Check redirects: test from an incognito window, mobile, and from Google results if possible.
• Search results: Look for spam URLs indexed under your domain and request removals/validation after cleanup.
• Uptime + performance: Watch for sudden CPU spikes, recurring 500 errors, or unexplained slowdowns.
• Re-check users and file changes 24–48 hours later. If new files appear or users reappear, you likely still have a backdoor.

A successful cleanup is boring: no new unknown admins, no surprise file edits, no weird scheduled tasks, and no sketchy redirects—especially after a day or two of normal traffic.

Hardening After Cleanup (Make It Hard to Get Hacked Again)

Cleaning a compromised site is only half the job. The real win is preventing the next incident, because most repeat cases happen for the same reasons: old software, reused passwords, too many admins, and no early warning system. If your site was wordpress hacked, use this hardening pass as your new baseline.

Updates + least privilege (roles, strong passwords, 2FA)

• Update everything: WordPress core, themes, plugins, and PHP (through your host). Outdated software is the #1 easy entry point.
• Reduce admin accounts: Keep admin access to only the people who truly need it. Everyone else should be Editor/Author or custom roles.
• Use strong, unique passwords everywhere (WordPress, hosting, email, database, SFTP/SSH). A password manager makes this realistic.
• Enable 2FA for all admin users. This one change blocks a huge percentage of credential-based attacks.
• Remove unused plugins/themes (not just deactivate). Less code = less attack surface.
• Lock down your “recovery” channels: secure the email accounts used for password resets and hosting access (2FA + strong password).

Security layers (WAF/CDN, rate limiting, login protection)

Think in layers: if one layer fails, another catches it.

• Use a WAF (web application firewall) via a security plugin or a service/CDN. This helps block known bad traffic and common exploit patterns.
• Add rate limiting + bot protection:
  • Limit login attempts
  • Block brute force IPs
  • Challenge suspicious traffic
• Protect login endpoints:
  • Consider restricting /wp-login.php access (by IP or additional authentication) if your workflow allows it.
  • Disable or restrict XML-RPC if you don’t need it.
• Harden file access:
  • Disable PHP execution in uploads (where feasible).
  • Avoid leaving backup zips or old site copies in public directories.

Backups that actually work (frequency, offsite, restore test)

Backups aren’t real until you’ve restored one.

• Frequency: daily for most sites; more often for ecommerce or high-change sites.
• Offsite storage: store backups somewhere separate from your server (cloud bucket, Google Drive, etc.). If the server is compromised, local backups can be compromised too.
• Multiple restore points: keep at least 7–30 days of versions.
• Restore test: do a quarterly restore test to a staging site or local environment so you know the process works under pressure.

Monitoring plan (alerts, file change detection, vulnerability tracking)

Monitoring turns “surprise hacks” into “caught early” incidents.

• Alerts: uptime monitoring + SSL expiry alerts + critical error notifications.
• File change detection: get notified when core files or sensitive directories change unexpectedly.
• Vulnerability tracking: keep a simple monthly routine to review plugin/theme updates and remove anything abandoned.
• Search Console checks: review Security issues and look for new spam URLs periodically.
• Log review: even a quick weekly scan of security/WAF logs can surface repeated attack attempts.

Hardening isn’t about being perfect. It’s about making your site a harder target than the next one—and catching problems before customers do.

Ongoing Maintenance + When to Hire a Pro

After a cleanup, the biggest risk isn’t “getting hacked again someday.” It’s getting reinfected because something was missed, or because the original entry point is still open. Ongoing maintenance is what keeps a one-time incident from turning into a monthly fire drill.

What a pro will ask for, typical timelines, and what “done” looks like

If you bring in a security pro (or a WordPress cleanup service), they’ll usually ask for:

• Admin access (or a temporary admin user)
• Hosting control panel access (and sometimes SFTP/SSH)
• A recent backup and the incident snapshot (files + database)
• Security plugin logs, server logs, and any WAF/CDN details (Cloudflare, etc.)
• Google Search Console access (to review Security Issues and spam indexing)

Typical timelines vary: a simple site can often be stabilized the same day, while deeper infections or large sites can take longer—especially if reinfection is happening. “Done” should mean more than “site loads.” It should mean:

• No unexpected admins
• No suspicious file changes after 24–48 hours
• Redirects/spam injections are gone
• Vulnerable components are removed or replaced
• A prevention plan is in place (updates, backups, monitoring)

Decision triggers (when DIY becomes risky)

Consider hiring a pro immediately if:

• You run ecommerce, collect payments, or store PII (customer data)
• The site is reinfecting after you “cleaned” it once
• You can’t identify the entry point (unknown cause = higher recurrence risk)
• Your host flags your account for malware or outbound spam
• Rankings tank or Google shows widespread spam URLs
• You’re losing leads/revenue and need the fastest safe recovery

If the incident is costing you money daily, professional cleanup plus monitoring is usually cheaper than repeated downtime.

FAQ

How do I know if my site is wordpress hacked or just broken?

If you see unauthorized changes (new admin users, injected scripts, spam pages, or hidden redirects), treat it as a hack. If symptoms only started after an update and there are no unknown users/files, it may be a conflict or cache issue.

What should I do first if visitors are being redirected?

Contain it immediately: enable maintenance mode, restrict wp-admin/wp-login access if you can, and take a full snapshot backup before deleting anything. Redirect malware often escalates if you keep the site live.

Should I restore from a backup or clean the current site?

Restore can be faster, but only if you’re confident the backup predates the infection. If you’re not sure when it started, you may restore malware and reinfect the site.

Do I need to change passwords if I reinstall WordPress core?

Yes. Reinstalling core doesn’t fix stolen credentials. Rotate WordPress admin passwords, hosting logins, SFTP/SSH, database credentials, and any connected API keys.

Can a security plugin scan fully remove malware?

Sometimes it can catch obvious infections, but it won’t always find backdoors, database injections, or server-level persistence. Use scans as a detection tool, not the only cleanup method.

Why does my site keep getting reinfected?

Common causes include: nulled plugins/themes, an outdated vulnerable plugin, hidden backdoors in mu-plugins or uploads, compromised hosting credentials, or restoring from an infected backup.

What evidence should I save before cleaning?

Export server logs (if available), security plugin logs, and copies of suspicious files. This helps identify the entry point and prevents repeat infections.

What does “clean” actually mean after a hack?

Clean means no malicious redirects, no injected spam, no unknown admins, and no unexpected file changes for at least 24–48 hours after normal traffic returns—plus hardening, backups, and monitoring in place.

Conclusion

A hacked site doesn’t need panic, it needs a process: confirm the compromise, contain the damage, back up before changes, clean using a repeatable workflow, then harden and monitor so it doesn’t come back. Use the checklists in this guide to move fast without making the problem worse. If you’re dealing with reinfections, ecommerce data, or you can’t find the entry point, consider professional cleanup plus ongoing monitoring.