Finding out your WordPress site has been compromised is unsettling, and the instinct to fix everything immediately is understandable but often counterproductive. Deleting files in a panic, restoring a backup without understanding what happened first, or telling yourself changing one password solved the problem can all make recovery harder rather than easier. This guide walks through a calm, ordered response, and is honest about when this goes beyond what a general checklist, including this one, can safely handle alone.
Common signs of compromise
Compromises show up in different ways, and recognizing the pattern early matters.
Unexpected administrators and unusual server activity
An unfamiliar user with Administrator access, especially one you didn’t create, is one of the clearest signs something is wrong. Unusual outbound server activity, unexpected spikes in resource usage, or unfamiliar scheduled tasks can indicate a compromise even before anything is visibly broken on the front end.
Redirects, spam pages, and search-result warnings
Visitors being redirected to an unrelated site, spam pages appearing under your domain that you didn’t create, or a warning appearing in search results or a browser’s own safe-browsing check are all common, visible symptoms of an active compromise.
Modified files and unexpected plugins or themes
Core, theme, or plugin files that show unexpected modification dates, or a plugin or theme installed that nobody on your team added, both warrant immediate investigation.
Email or hosting-provider alerts
Take a hosting provider’s security alert seriously rather than dismissing it. Hosts often detect suspicious activity, unusual outbound email volume, known malware signatures, before a site owner notices anything themselves.
Avoiding panic-driven destructive changes
The immediate instinct to delete everything suspicious and start over is understandable, but it can destroy the evidence needed to understand how the compromise happened and whether it’s actually been fully resolved afterward. Slow down before making irreversible changes.
Preserving useful evidence
Before cleaning anything up, take a full backup of the site exactly as it currently is, clearly labeled as a snapshot of the compromised state rather than a clean backup to restore from. This preserves the ability to investigate later, compare against your cleanup, or hand off to a professional if needed.
Taking the site offline or restricting access when necessary
Depending on severity, restricting public access, via maintenance mode, a temporary password wall, or taking the site fully offline, limits further damage and stops the compromise from actively affecting visitors while you investigate. This is a judgment call based on what you’re seeing: active malicious redirects affecting every visitor generally warrant this; a single unfamiliar admin account discovered proactively may not require it immediately.
Contacting your hosting provider
Your host can often see things you can’t from the WordPress dashboard alone: server-level logs, other affected accounts on shared infrastructure, or known attack patterns they’ve already identified elsewhere. Contact them early in the process rather than only after you’ve already made changes.
Rotating every credential the compromise could have touched
Once you’ve preserved a labeled snapshot of the compromised state, rotate credentials broadly rather than narrowly, since you often can’t be certain which specific credential was actually exposed.
- WordPress user passwords, for every account, not just the one that looked suspicious
- Hosting account credentials
- Database credentials
- SFTP/SSH credentials
- Email account credentials associated with the site
- API keys used by any integration or plugin
Resetting WordPress salts
WordPress authentication salts and keys, defined in wp-config.php, should be regenerated as part of credential rotation, since they affect how existing login sessions and cookies are validated. Regenerating them invalidates existing sessions, including any an attacker may still hold.
Reviewing accounts and access
Administrator accounts and application passwords
Review every user account, particularly anyone with Administrator or Editor access, and remove anything unfamiliar or no longer needed. Also review Application Passwords, a WordPress feature intended for API access, since a compromised one grants programmatic access without needing the account’s main password. Our WordPress login security guide covers MFA and least-privilege practices that make this kind of review easier going forward.
Checking plugins, themes, and core files
Reinstalling from trusted sources
Rather than trying to manually identify every modified line in core, theme, or plugin files, it’s generally safer to reinstall WordPress core and every plugin and theme fresh from the official WordPress.org repository or the original, trusted commercial source, rather than assuming existing files are clean.
Removing abandoned or unknown components
Remove any plugin or theme you don’t recognize, don’t actively use, or that’s no longer maintained by its developer, since abandoned software is a common entry point and an unnecessary one to keep around after an incident.
Database inspection
Some compromises inject malicious content or administrator accounts directly into the database rather than into files. Review the database, particularly the users table and any options containing unexpected serialized data or injected script content, not just the file system.
Uploads-directory risks
The uploads directory is often writable and not typically expected to contain executable code, which makes it a common place for a hidden backdoor file to be planted. Check it specifically for PHP files that shouldn’t be there.
wp-config.php and .htaccess
Both files can be modified to redirect traffic, disable security measures, or maintain access. Compare against a known-good version if you have one, or review carefully for anything unfamiliar, particularly in .htaccess redirect rules.
Must-use plugins
Files placed in wp-content/mu-plugins load automatically on every request and don’t appear in the standard Plugins screen, making this directory a location worth specifically checking, since a backdoor placed here can persist even after every visible plugin is reinstalled clean.
Cron and scheduled tasks, and persistent backdoors
Review both WordPress’s own scheduled events and any server-level cron jobs for anything unfamiliar, since a persistent backdoor is sometimes designed to re-infect a cleaned site through a scheduled task that survives a surface-level cleanup.
External integrations, CDN, and DNS account security
Review any third-party integrations, API connections, and the account security of your CDN and DNS providers specifically, since these sit outside WordPress itself but can be leveraged as part of, or after, a website compromise, and are easy to overlook during a WordPress-focused cleanup.
Search Console Security Issues and search-engine warnings
If Google has flagged your site, check Search Console’s Security Issues report for specifics on what was detected. This report also provides the mechanism to request a review once you’ve genuinely resolved the issue.
Requesting a review only after the compromise is actually resolved
Request a security review only once you’re confident the underlying issue is genuinely fixed, not just that the visible symptom disappeared. Requesting a review prematurely, only to be flagged again, delays full removal of any search-result warning longer than doing it right the first time.
Restore-from-backup versus clean-in-place
If you have a verified, known-good backup from before the compromise, restoring it can be faster and more reliable than manually cleaning an infected installation in place, provided you understand what content or data was created since that backup and account for it separately. Cleaning in place is sometimes necessary when no clean backup exists, but it demands more thorough manual investigation to have real confidence nothing was missed.
WooCommerce and personal-data considerations
For a store, restoring an older backup can mean losing orders or customer data created after that backup point. Weigh this against the risk of cleaning in place, and consider whether order and customer data can be recovered separately, for example from the payment processor’s own records, when reverting to an earlier backup.
Potential privacy or legal obligations
If customer or personal data may have been exposed, you may have specific notification obligations depending on your jurisdiction and the type of data involved. This is a genuine point to involve legal advice, since the right notification requirements vary and getting them wrong carries its own consequences.
When professional incident response is appropriate
A generic recovery checklist, including this one, is not a substitute for professional incident response on a business-critical, high-traffic, or e-commerce site handling sensitive data, or in any case where you’re not confident the compromise has been fully understood and resolved. If you’re uncertain, treat that uncertainty itself as the signal to bring in a security professional rather than proceeding on assumption.
Post-cleanup hardening and monitoring
Once you’re confident the site is genuinely clean, apply preventive hardening so the same entry point isn’t used again. This is where our WordPress security hardening checklist becomes directly relevant, covering updates, access control, and backup practices in more depth than this incident-response guide does. Set up ongoing monitoring, file-integrity checks, login alerts, so any recurrence is caught early rather than discovered the same way this one was. If you don’t already have a security plugin in place, or the incident revealed your current one missed something important, our framework for choosing a WordPress security plugin can help you evaluate options against your actual needs.
Documenting the incident
Record what happened, how it was discovered, the likely entry point, and what you changed while it’s still fresh. This record is genuinely useful if a similar issue recurs, and if you ever need to explain the incident to a host, a customer, or a professional brought in later.
Confirming performance after recovery
Once cleanup and hardening are complete, it’s reasonable to re-establish your normal performance baseline as part of getting back to business as usual. You can test your WordPress website after the change to confirm Mobile and Desktop performance is back where it should be, particularly if you reinstalled core, themes, and plugins fresh as part of the cleanup. It’s worth being clear about what this step is and isn’t: a speed test is a performance check, not a security scan, and it does not detect malware or confirm a compromise has been resolved.
A recovery and prevention checklist
- Confirm the signs of compromise rather than reacting to a single ambiguous symptom.
- Take a labeled snapshot backup of the compromised state before cleaning anything up.
- Restrict access or take the site offline if visitors are actively affected.
- Contact your hosting provider early in the process.
- Rotate every credential the compromise could plausibly have touched, and reset WordPress salts.
- Review administrator accounts and Application Passwords for anything unfamiliar.
- Reinstall WordPress core, themes, and plugins from trusted sources rather than trusting existing files.
- Check the database, uploads directory, wp-config.php, .htaccess, and mu-plugins specifically.
- Review external integrations and your CDN/DNS account security.
- Resolve Search Console Security Issues and request a review only once genuinely fixed.
- Consider professional incident response for a business-critical or sensitive-data site, or when uncertain.
- Apply post-cleanup hardening and set up ongoing monitoring for recurrence.
- Document the incident while details are fresh.
Key Takeaways
- Avoid panic-driven destructive changes; preserve a labeled snapshot of the compromised state before cleaning anything up.
- Rotate every credential the compromise could plausibly have touched, including WordPress salts, rather than assuming one password change is sufficient.
- Check files, the database, mu-plugins, and scheduled tasks; a backdoor can persist in places a surface-level cleanup misses.
- Restoring a backup and cleaning in place both carry trade-offs; choose based on backup quality, data created since, and your confidence in a thorough manual investigation.
- A generic checklist is not a substitute for professional incident response on a business-critical or sensitive-data site, or whenever you’re genuinely uncertain the issue is fully resolved.
Frequently Asked Questions
Is changing my WordPress password enough to fix a hacked site?
No. A thorough response includes rotating every credential the compromise could have touched, resetting WordPress salts, reviewing for backdoors in files and the database, and confirming the actual entry point before considering the site clean.
Should I delete suspicious files immediately when I notice them?
Take a labeled backup of the current, compromised state first. Deleting immediately can destroy evidence needed to understand how the compromise happened and whether your cleanup was actually complete.
Is it better to restore a backup or clean the site in place?
It depends on whether you have a verified, known-good backup and what data was created since it was taken. Restoring is often faster and more reliable when a good backup exists; cleaning in place requires more thorough manual investigation when it doesn’t.
Can I use a speed-testing tool to check if malware is still present?
No. A speed test measures performance and is not a security scanner; it cannot detect malware or confirm a compromise has been resolved. Use it only after recovery, to confirm performance, not as part of the investigation itself.
When should I bring in a security professional instead of following a checklist myself?
For a business-critical, high-traffic, or e-commerce site handling sensitive customer data, or any time you’re not confident the compromise has been fully understood and resolved. Treat genuine uncertainty as the signal to get professional help rather than proceeding on assumption.
Conclusion
Responding well to a hacked WordPress site is less about any single dramatic fix and more about working through an ordered process calmly: preserve evidence, contain the damage, rotate credentials broadly, investigate thoroughly rather than superficially, and know when the situation genuinely calls for professional help. A checklist gets most site owners through most incidents; it isn’t a substitute for judgment when the stakes or your uncertainty are high.
