Recommended Free Tools
When Google or a browser flags your WordPress site for malware, treat it as a security incident—not an SEO warning to hide. Record the warning, preserve a copy, contain the site, remove malicious code and persistence, rotate every exposed credential, close the vulnerability, and request a review only after you can show the installation is clean.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The fastest safe recovery depends on what was compromised and what access and evidence you have. The steps below take you from the first warning through cleanup, verification, review, and the separate problem of spam URLs that remain in search.
As an Amazon Associate I earn from qualifying purchases.
What the warning actually means
Google can label a site dangerous when it suspects the site is hosting harmful or spammy downloads, engaging in behavior that could harm visitors, or has been hacked. Search may show messages such as “This site may harm your computer” or “This site may be hacked.” A browser can also display a full-page interstitial before allowing a visitor to continue.
WordPress.org identifies several other compromise signals: Google or Bing blacklisting, a host disabling the account, antivirus alerts from visitors, reports that the site is attacking other sites, unexpected administrator accounts, and other unauthorized behavior. A warning may therefore indicate more than an altered homepage. The attacker could have planted a backdoor, changed database content, created users, scheduled reinfection, or modified hosting settings.
#1 Best Overall
Start by identifying the category shown in Google Search Console. Open the property’s Security Issues report and note every listed issue and affected URL. Check the Manual Actions report as well; a manual action and a security issue are different systems and may require different remediation.
Separate an infection from an indexing-only problem
Malware, phishing, hacked content, unwanted software, and spam pages are related but not identical findings. A site can be clean while old spam URLs remain indexed, or it can appear normal while a hidden PHP file, database injection, or compromised account continues to serve harmful content. Do not choose a cleanup method until you know which condition you are addressing.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhat to do in the first hour
- Capture the evidence. Save screenshots of the browser interstitial and Search Console messages. Record the date and time, affected URLs, redirects, new users, suspicious files, scanner results, and any changes visitors report. Preserve the exact warning text; categories can change after a subsequent crawl.
- Take a snapshot before editing. Make a copy of the files, database, web-server configuration, logs that are still available, and relevant account information. WordPress.org recommends keeping a snapshot even when the environment is infected because it may be needed to understand the intrusion or recover from a failed repair. Label it clearly as potentially compromised and store it where it cannot be overwritten.
- Reduce exposure. Ask the host about temporary isolation, maintenance mode, or account suspension. If the site processes payments or personal data, activate the organization’s incident-response and legal-notification procedures before deleting evidence or restoring service.
- Work from a clean device. Use a trusted computer and connection for administrator, hosting, database, and email access. A keylogger or other malware on the administrator’s computer can capture new passwords and defeat otherwise sound server controls.
- Do not trust a single scan. A scanner can miss a database payload, scheduled task, rogue account, or hosting-level change. Plan to inspect each layer that could contain code or credentials.
Choose a recovery path
Use the option that matches your access, evidence, technical ability, and business risk. A quick overwrite is not automatically a clean recovery.
| Option | Best fit | What it requires | Main risk or limitation |
|---|---|---|---|
| Self-service investigation and cleanup | You have reliable SFTP or FTP, database and hosting access, a known-good reference, and the ability to inspect code and logs. | Identify the entry point, remove malicious files and content, replace compromised components, rotate credentials, and verify every layer. | Hidden backdoors or persistence can survive a superficial file replacement. |
| Restore a trusted backup | A dated backup clearly predates the compromise and its integrity is known. | Confirm the vulnerability is closed, restore files and database, then rotate credentials and recheck the restored installation. | The backup may contain compromised passwords, tokens, users, or the same unpatched weakness. |
| Professional incident response | The site repeatedly reinfects, files and database are both affected, access is incomplete, or downtime and evidence preservation have high business consequences. | A qualified malware-removal or incident-response provider with authority to work on the host and preserve evidence. | You still need to supply access, approve changes, and verify that the underlying vulnerability was fixed. |
Professional services can be appropriate when the cost of prolonged downtime, lost revenue, regulated data exposure, or an incomplete investigation exceeds the cost of specialist work. A provider should explain what it will inspect, how it preserves evidence, what “clean” means, and how reinfection will be prevented. A cleanup that only removes visible spam while leaving the entry point open is not a completed response.
How to clean a compromised WordPress installation
1. Map the installation and establish a clean reference
List the WordPress core version, active and inactive plugins, themes, must-use plugins, upload directories, scheduled jobs, hosting users, database users, administrator accounts, and connected services. Compare files with the matching official WordPress release and with clean copies of every plugin and theme obtained from its trusted source. Keep the original snapshot untouched so you can compare timestamps, hashes, and suspicious additions.
Rank #2
2. Inspect files, database, and persistence
Look beyond the homepage. Review recently changed PHP, JavaScript, and configuration files; unfamiliar files in upload directories; modified core files; web-server rules; and templates that output unexpected links or scripts. In the database, inspect users, options, widgets, posts, pages, and metadata for injected code, redirects, hidden administrators, or spam content. Check scheduled tasks, cron jobs, deployment hooks, hosting-panel settings, and SSH keys for mechanisms that can recreate deleted files.
3. Replace compromised components completely
Replace affected WordPress core files with the exact clean release that matches the site. Reinstall clean copies of every plugin and theme rather than trusting an infected copy. WordPress.org specifically advises replacing components through FTP or SFTP instead of relying only on dashboard overwrites, because an attacker may have added new files that an overwrite does not remove. Remove abandoned, unused, or unauthorized plugins and themes.
4. Remove malicious content and accounts
Delete backdoors, web shells, injected scripts, rogue administrator accounts, and unauthorized database entries after documenting them. Review legitimate accounts for changed roles, email addresses, application passwords, and recovery details. Remove unknown users and invalidate sessions so a stolen login cannot continue operating.
5. Close the exploited entry point
Determine how the attacker entered: an outdated plugin or theme, stolen credentials, a vulnerable hosting service, an insecure upload path, or another configuration weakness. Updating software without addressing the original route leaves the site exposed. If the entry point cannot be established, treat all credentials and connected services as potentially exposed and increase monitoring after restoration.
Rotate credentials in the right order
Change passwords from the clean device, beginning with the hosting control panel and server-level accounts, then database, SFTP or FTP, SSH, WordPress administrators, deployment systems, API keys, email, CDN, backups, and any third-party service connected to the site. Rotate unknown or compromised user accounts rather than merely editing a display name. Revoke active sessions, application passwords, tokens, and SSH keys that may have been copied.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchUse unique passwords stored in a reputable password manager. Remove accounts that no longer have a business purpose and assign the least-privilege WordPress role needed for each remaining user. Record the rotation so another administrator knows which systems were changed and when.
Harden the site after cleanup
Keep every component current
Update WordPress core, every active theme, and every plugin from a trusted source. WordPress documentation notes that updates improve security and performance and recommends making a current backup before updating. Do not reinstall software from an unknown archive just because its name matches a legitimate plugin.
Require stronger administrator authentication
Enable two-step authentication for administrators and other privileged users. WordPress documentation describes security keys, time-based one-time-password applications, passkeys, and recovery codes. A FIDO2 hardware security key is a physical, phishing-resistant option; keep recovery codes offline and test the recovery process before an emergency.
Reduce the blast radius
- Use least-privilege roles and separate administrator accounts from everyday publishing accounts.
- Protect configuration files and database credentials, and use HTTPS for the entire administrative and visitor experience.
- Set secure file permissions appropriate to the host and prevent execution in directories intended only for uploads where the hosting environment supports that control.
- Enable useful server, authentication, and application logging and retain logs long enough to investigate a recurrence.
- Maintain regular whole-installation and database backups in trusted off-site storage. Use encryption and independent integrity checks, such as hashes, so a damaged or tampered backup is not mistaken for a recovery point.
Security is risk reduction, not a promise of perfect safety. WordPress summarizes the principle this way: “Security is not about perfectly secure systems. Such a thing might well be impractical, or impossible to find and/or maintain.”
Verify that the site is clean before asking Google to recheck it
Verification should cover the same layers an attacker could use. Confirm that only expected files remain, core and extensions match clean releases, database content contains no injected scripts or spam, scheduled tasks and hosting settings are known, privileged accounts are authorized, and all credentials have been rotated. Browse representative pages while logged out, test forms and downloads, and check that redirects do not vary by device, referrer, or geography.
Rank #4
Review server and authentication logs for continuing access attempts. Run more than one independent check when possible, including an external scan and a host-level review. A clean front page is not proof that the database, cron system, or account layer is clean.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Request removal of the Google warning
- Return to Google Search Console for the verified property.
- Open Security Issues and read every category and example URL again.
- Fix all listed problems, including issues that were not visible during ordinary browsing.
- Select Request a review.
- Describe the actual work performed: for example, removal of injected content, replacement of outdated software, deletion of unauthorized users, credential rotation, and closure of the exploited vulnerability.
Google asks owners to fix the problem completely before requesting a review. Repeated requests while the issue remains can prolong the period during which the site is flagged. After submission, continue watching Search Console, browser behavior, logs, and independent scans while Google recrawls and reevaluates the site. The warning may not disappear immediately after a successful repair.
When spam URLs remain in search after cleanup
Residual spam results are an indexing problem only after you have confirmed that the URLs are genuinely gone and that the site is not still generating them. Test the exact URLs, inspect server responses, and ensure the old content cannot be recreated by a compromised account, database rule, or scheduled task. Configure the site to return an appropriate not-found or gone response for pages that no longer exist.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Only then consider Search Console’s removal tools for urgent visibility control. A removal request can hide a result temporarily; it does not remove malware, repair a page, or close an exploited vulnerability. Using it while the infection is active can conceal evidence and leave visitors at risk.
Troubleshooting common recovery failures
The warning returns after review
Assume reinfection until proven otherwise. Recheck administrator and hosting accounts, database content, scheduled jobs, upload directories, and server configuration. Compare the restored files with a clean release and review logs around the time the warning returned. Rotate credentials again if the first rotation was performed from a potentially infected device.
The site looks clean but scanners disagree
Do not choose the most convenient result. Identify what each scanner examined: public pages, files, database, DNS, redirects, or server configuration. Investigate the discrepancy and preserve both reports. A tool that cannot access the database or hosting layer cannot certify those layers.
You cannot access SFTP, the database, or logs
Ask the host to preserve a copy, isolate the account, and provide the access needed for a complete investigation. If the host cannot provide adequate evidence or controls, professional incident response is safer than deleting random files through the dashboard.
A backup restores the warning
Stop treating that backup as trusted. Identify its creation date and integrity, test an older known-good point if available, close the vulnerability before reconnecting the site, and rotate every credential and token stored in or reachable from the restored installation.
Keep the recovery record
Maintain a dated incident log containing warnings, affected URLs, snapshots, account and credential changes, software versions, files or database records removed, host communications, scan results, and the review request. This record helps explain decisions, supports legal or customer notifications when required, and gives the next administrator a precise baseline if suspicious behavior reappears.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
