How to Fix a Hacked WordPress Site
If you need to know how to fix a hacked WordPress site, the priority is to stop further damage, identify what was changed, and restore the site without reintroducing malware.
The process is less about one quick cleanup and more about methodically removing backdoors, resetting access, and hardening every weak point.
WordPress compromises often involve infected plugins, stolen admin credentials, malicious file uploads, or hidden code in the database, so a complete recovery requires checking each layer.
The good news is that with the right sequence, most sites can be cleaned, restored, and secured again.
First, contain the breach
Before you start cleaning, limit the attacker’s access and protect users.
If the site is actively redirecting visitors, sending spam, or serving malicious downloads, take it offline or place it in maintenance mode while you investigate.
- Change the hosting account password immediately.
- Reset all WordPress admin, editor, and FTP/SFTP credentials.
- Update the database password in your hosting panel and wp-config.php if needed.
- Log out all sessions and revoke API keys or application passwords.
- Notify your hosting provider if you suspect server-level compromise.
If you have a full backup from before the infection, keep it safe.
Do not restore it blindly until you confirm it is clean.
Check for obvious signs of compromise
A hacked WordPress site often shows symptoms that reveal where the attack started.
Look for unfamiliar admin users, new plugin or theme files, modified homepage content, injected links, strange redirects, and server errors that began suddenly.
Also inspect SEO-related damage.
Hackers frequently inject spam pages, cloaking scripts, or Japanese keyword spam to exploit search traffic.
Search engine warnings in Google Search Console or browser blacklists are strong indicators that malicious code is present.
Common infection patterns
- Unknown PHP files in wp-content/uploads
- Recently modified files in wp-includes or wp-admin
- Base64-encoded or obfuscated code in theme files
- Unauthorized administrator accounts
- Spam comments, fake pages, or hidden outbound links
- Injected JavaScript in header, footer, or database content
Scan the site with multiple tools
Use more than one scanner because no single tool catches everything.
A security plugin such as Wordfence, Sucuri Security, or iThemes Security can flag altered core files, malware signatures, and suspicious behavior.
Server-side malware scanners from your host can also detect hidden files and suspicious processes.
For a deeper review, compare your WordPress core files against the official WordPress.org package.
Core files should match known checksums.
If a core file has been edited, replace it with a clean copy rather than trying to manually remove a few lines of suspicious code.
Where to inspect closely
- wp-config.php
- .htaccess
- wp-content/themes/your-active-theme/
- wp-content/plugins/
- wp-content/uploads/
- mu-plugins directory, if present
Malware often hides in places that look harmless, including image folders, cache directories, and files with names that resemble legitimate WordPress components.
Restore clean core files, plugins, and themes
If you know the compromise involved file tampering, replace WordPress core files with fresh copies from the official release.
Keep wp-content intact only after verifying its contents.
Reinstall every plugin and theme from a trusted source, and delete any extension you no longer use.
This is one of the most effective steps in learning how to fix a hacked WordPress site because many infections survive inside outdated or abandoned extensions.
If a plugin or theme was nulled, pirated, or downloaded from an unofficial source, assume it is unsafe and remove it.
Best practice for replacements
- Download clean copies from WordPress.org or the vendor.
- Delete the compromised version before uploading the replacement.
- Update everything to the latest stable release.
- Remove inactive plugins and unused themes entirely.
Clean the database carefully
WordPress malware frequently stores malicious scripts in the database, especially in posts, widgets, options, and page builders.
Check the wp_options table for suspicious sitewide scripts, fake admin notices, or strange redirects.
Review posts and pages for injected iframes, spam links, or hidden content.
Search for common malware patterns such as long encoded strings, unusual JavaScript snippets, or content inserted into footer and header options.
If you are not comfortable editing the database directly, export it first and work from a local copy or a staging environment.
Database locations to review
- wp_options for injected scripts or rogue settings
- wp_posts for spam pages and hidden links
- wp_users for unauthorized accounts
- wp_usermeta for privilege escalations
Reset every credential and secret
Cleaning files is not enough if the attacker still has valid credentials.
Reset all WordPress passwords, including administrators, editors, hosting users, database users, FTP/SFTP accounts, and email accounts tied to the site.
Replace security salts in wp-config.php so old login sessions become invalid.
Also rotate any third-party tokens connected to the site, such as cloud storage credentials, SMTP keys, analytics integrations, or payment gateway secrets.
A compromised API key can let an attacker reinfect the site after cleanup.
Harden the site after cleanup
Once the site is clean, reduce the likelihood of a repeat incident by removing weak points and tightening access.
Most WordPress hacks succeed because of outdated software, weak passwords, vulnerable extensions, or poor file permissions.
- Enable automatic updates for WordPress core where appropriate.
- Keep plugins and themes updated on a regular schedule.
- Use strong, unique passwords and two-factor authentication.
- Limit login attempts and monitor failed logins.
- Disable file editing in the WordPress dashboard.
- Set correct file permissions on the server.
- Use a Web Application Firewall such as Cloudflare, Sucuri, or a managed host firewall.
Security headers, HTTPS, and malware scanning help too, but they work best as part of a layered defense rather than as standalone fixes.
Check search engines and blacklist status
If the hack affected SEO or trust signals, review Google Search Console for security issues, manual actions, and indexing anomalies.
Submit a clean sitemap after you finish remediation, and request a review if Google flagged the site as compromised.
Browser vendors and antivirus services may also blacklist infected domains.
If this happened, verify the cleanup first, then follow the relevant delisting or review process.
Persistent warnings usually mean a hidden file or injected page still remains somewhere on the site or server.
When should you restore from backup?
Restoring from backup is often the fastest route, but only if the backup predates the compromise and was stored securely.
If you restore a contaminated backup, the infection will return.
A clean backup is especially useful after ransomware-style defacement, mass file corruption, or database tampering.
Even then, you should still change passwords, update software, and scan the restored site before bringing it back online.
How to prevent reinfection
Prevention matters because many hacked sites are reinfected within days when the original entry point is left open.
The most common entry points are outdated plugins, reused passwords, and exposed admin panels.
- Remove unused themes, plugins, and admin accounts.
- Audit file uploads and disable PHP execution where possible.
- Use least-privilege roles for contributors and editors.
- Monitor file changes with integrity checks.
- Back up the site automatically and store backups offsite.
For business-critical sites, consider managed WordPress hosting with malware scanning, server-level isolation, and emergency support.
These controls do not replace good hygiene, but they can shorten recovery time and reduce the blast radius of future attacks.
What to document during recovery
Keep a record of what you changed while cleaning the site.
Note the time of the compromise, suspicious files discovered, passwords reset, plugins removed, and any alerts from your host or security tools.
This documentation helps if you need to brief a developer, support team, insurer, or incident response provider.
It also helps you identify patterns.
If the same plugin, shared password, or insecure upload path appears in multiple incidents, you have found a real structural weakness rather than a one-off event.