iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The reliable way to check a WordPress site for malware is to combine four kinds of evidence: visible symptoms and search results, a WordPress-aware application scan, an external remote scan, and—when indicated—a database or server-side review. A clean-looking homepage is not proof that the database, files, or hosting account are clean. If any check produces a positive signal, preserve the current site, investigate before restoring a backup, clean from known-good files, rotate every relevant credential, and request blocklist review only after the infection is fixed.
What a proper WordPress malware check covers
Malware can live in PHP files, plugin or theme directories, scheduled tasks, administrator accounts, database content, or another site sharing the same hosting account. No single scan sees every layer. Use the checks below as a chain of evidence rather than treating one green result as a verdict.
| Check | What it can reveal | What it may miss | When to use it |
|---|---|---|---|
| Rendered site and browser behavior | Redirects, injected links, pop-ups, changed pages, broken features, unusual slowness or crashes | Payloads that activate only for certain visitors, devices, referrers, or logged-out users | Always; test in a private browser window and from a second network or device |
| Search-engine results and warnings | Google’s “This site may be hacked” notice, spam pages indexed under your domain, or security warnings | Infections that search engines have not crawled yet | Always, especially when traffic or rankings change unexpectedly |
| WordPress-aware application scanner | Modified core files, suspicious plugins or themes, known malware signatures, unfamiliar users, and some database indicators | Server-level compromise, infections outside the WordPress directory, or database content beyond the scanner’s coverage | After symptom checks and whenever a compromise is suspected |
| External remote scanner | What an outside visitor receives, including some blocklist and injected-content signals | Backdoors that do not appear in the public response, protected areas, and many server-side files | Use as an independent second opinion |
| Server, file, and database review | Hidden PHP files, altered timestamps, persistence mechanisms, malicious rows, cron jobs, or neighboring-account contamination | Requires hosting or database access and technical judgment | When scans disagree, symptoms continue, or the site is business-critical |
Wordfence founder and CTO Mark Maunder puts the first principle plainly: “If you suspect you have been hacked, first make sure that you have actually been hacked.” That means confirming a signal with more than one layer before deleting files or declaring the site safe.
Warning signs that deserve immediate investigation
Any one of these signs is enough to start the workflow; several together indicate a high-priority incident:
#1 Best Overall
- Visitors are redirected to an unfamiliar domain, a different page, or a download.
- Google displays “This site may be hacked” or another security warning for your domain.
- An administrator account appears that nobody on your team created.
- PHP files, WordPress core files, plugins, or themes are unfamiliar or have unexpected modifications.
- Spam posts, pages, links, comments, users, or email messages appear without authorization.
- The site becomes inexplicably slow, crashes, sends unusual server traffic, or consumes abnormal resources.
- A legitimate administrator can no longer log in, or passwords change without an authorized action.
- A security scanner reports malware, a backdoor, a modified file, or a blocklist listing.
Do not dismiss a warning because only visitors in one country, on one device, or while logged out can reproduce it. Attackers often serve different content to administrators and scanners to avoid detection.
Before scanning: preserve evidence and avoid making the incident worse
- Record what you see. Save screenshots of redirects, warnings, suspicious users, spam pages, error messages, and scanner findings. Note the time, URL, account involved, and whether the behavior changes when logged in.
- Keep a copy of the current state. Preserve a full backup or hosting snapshot, including files and the database, before deleting anything. Label it as potentially infected so nobody later mistakes it for a clean restore point.
- Do not immediately restore an old backup. The backup may contain the same backdoor or a vulnerable plugin. Check it before using it, and retain the current copy for investigation.
- Limit risky changes. Avoid editing suspicious files in place, running unverified “cleanup” scripts, or installing multiple security plugins that overwrite evidence. If the site handles payments or sensitive data, involve your host or an incident-response professional.
- Use a safe account for investigation. Work from a trusted device and network. Do not reuse a password that may have been exposed on the WordPress site.
Step-by-step: check a WordPress site for malware
1. Inspect the public site as a visitor
Open the home page and several important URLs in a private or incognito window while logged out. Test the navigation, forms, search, checkout or login flow, media files, and any pages named in complaints. Repeat from a second browser, device, or network. Look for redirects, injected text, unfamiliar ads, downloads, pop-ups, certificate errors, and sudden performance changes.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Then search for your domain in a search engine. Check the normal result, image results, recently indexed pages, and unusual URL patterns such as long strings of words unrelated to your business. A search-engine warning is actionable evidence even when the homepage appears normal.
2. Review Google’s security reports
In Google Search Console, open Security issues and Manual actions for the verified property. Read the sample URLs and issue type; save them before changing the site. A security issue report can identify hacked content that is not visible from the home page. Do not request a review yet—the review belongs after cleanup and verification.
3. Run a WordPress-aware application scan
Use a reputable scanner that understands WordPress core, plugins, themes, users, and common malware patterns. Let it complete rather than stopping at the first result. For every finding, record the file path, database object, user, or URL and whether the scanner classifies it as malicious, modified, suspicious, or a possible false positive.
Wordfence’s guidance warns that the longer a compromised site remains infected, the greater the risk of data loss, SEO penalties, or further spread. Treat a positive result as a reason to preserve evidence and investigate scope, not as permission to delete every flagged file blindly.
4. Run an independent external scan
Submit the public site to an external remote scanner from a clean device. This tests what an outside visitor receives and may reveal injected scripts, redirects, or blocklist status that an administrator-side scan does not. Compare the URLs and payloads it reports with your application scan. A remote scan that says “clean” cannot rule out a dormant backdoor, a database-only infection, or a file that requires a particular trigger.
5. Check files, accounts, and the database when the evidence warrants it
Use your host’s file manager, secure shell access, or a professional service to review files outside the normal WordPress paths, recently changed PHP files, upload directories containing executable code, and other sites or applications under the same account. Compare WordPress core, theme, and plugin files with clean originals from their official sources. Unexpected differences need an explanation; a changed timestamp alone is not proof of malware.
In the WordPress dashboard, review Users > All Users for unknown administrators and editors. Check Plugins > Installed Plugins and Appearance > Themes for additions, inactive components, abandoned versions, and duplicate installations. Review posts, pages, comments, widgets, menus, and settings for injected links or accounts.
When symptoms continue despite clean-looking files, inspect the database or ask the host to do so. Search for unfamiliar administrator records, injected options, malicious shortcodes, scheduled tasks, and spam content. A file-focused scan may not cover database infections, and a public scanner cannot inspect private rows.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →6. Decide whether the incident is real and how far it extends
Classify each finding as confirmed malicious, suspicious and needing review, or explained by a legitimate change. Corroborating evidence—such as an unknown administrator plus modified core files and a redirect—should be treated as a confirmed compromise. Scope the review to every WordPress installation, subdomain, staging copy, and hosting account that shared credentials or writable directories.
False positives are possible: custom code, a licensed premium component, a recently updated file, or an unusual server configuration can resemble malware. Preserve the flagged item, compare it with a clean vendor copy, and use the scanner’s explanation or support channel before removing it.
7. Choose a clean recovery point
Use a backup only after checking its creation date, files, database, and installed versions. If no known-clean backup exists, build from clean vendor packages and a reviewed database. Keep the infected snapshot offline for comparison. Do not overwrite the only copy of evidence.
8. Clean the installation and update every component
- Put the site in maintenance mode or temporarily restrict access if doing so will not create a greater business or safety problem.
- Replace compromised WordPress core files with clean copies from the official WordPress source, rather than trying to repair every altered line manually. This is the replacement approach recommended in Sucuri’s WordPress cleanup guidance.
- Reinstall affected plugins and themes from their official, current packages. Remove components that are unused, unsupported, or obtained from an untrusted source.
- Delete malicious files, code, scheduled tasks, administrator accounts, posts, pages, comments, and settings after recording them for the incident record.
- Clean database injections and verify that legitimate content, media, orders, and user records still work.
- Update WordPress core, all active themes, all active plugins, and the server software that supports them. Unsupported software can allow reinfection even after the visible payload is gone.
Have a second person or an independent scanner review the cleaned installation. If you cannot establish a trustworthy baseline, professional remediation is safer than repeated ad-hoc deletion.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →9. Rotate credentials and close the entry point
Change passwords from a clean device for WordPress administrators, hosting control panels, FTP or SFTP, SSH, the database, email accounts used for recovery, domain management, and any third-party service connected to the site. Use unique passwords and invalidate old sessions where the service supports it. Enable two-factor authentication for WordPress, hosting, email, and domain accounts. Remove unfamiliar users, old employees, unused API keys, and dormant installations.
10. Verify the cleaned site from every layer
Repeat the public-site tests, Search Console checks, WordPress-aware scan, external scan, file comparison, and database review. Confirm that redirects, spam, unknown accounts, modified files, unusual resource use, and suspicious outbound email are gone. Monitor logs and server load for several days; a recurring change after cleanup suggests a surviving backdoor or an unpatched entry point.
11. Request warning and blocklist reviews only after cleanup
Once the site is demonstrably clean, use Search Console’s review request for the reported security issue or manual action. If an antivirus vendor, browser, or other blocklist operator still warns visitors, follow that operator’s review process. Sucuri explains that diagnostic tools can be used to check a hacked site’s status before requesting removal from Google or other security authorities. A review submitted before remediation is complete can be rejected and does not remove the underlying infection.
Which type of scanner should you use?
Tools cover different layers, so “best” depends on your hosting access, database access, technical skill, and the site’s business risk. The available guidance does not establish a neutral accuracy benchmark, current price comparison, or universal speed ranking.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute| Option | Primary coverage | Useful for | Important limitation | Cost or support information |
|---|---|---|---|---|
| WordPress-aware plugin scanner | Core, plugin, theme, user, and selected database indicators | Routine checks and identifying modified WordPress files | May not see server-level files, neighboring sites, or every database infection | Not stated in the cited guidance; features and support vary by edition |
| External remote scanner | Public pages, responses, redirects, injected scripts, and some blocklist signals | Independent confirmation of what visitors receive | Cannot inspect private files, dormant backdoors, or protected database rows | Not stated in the cited guidance |
| Host or server-side scanner | Account files, processes, logs, and sometimes databases | Shared hosting incidents, persistent reinfection, and infections outside WordPress | Quality and access depend on the host; findings may require technical review | Not stated in the cited guidance |
| Manual file and database review | Custom comparison of code, rows, users, scheduled tasks, and account scope | Disputed findings, high-value sites, and cases where scans disagree | Slow, technically demanding, and vulnerable to human error | Not stated in the cited guidance |
Sucuri reported that 1.15% of 108,122,130 sites scanned by its SiteCheck service in 2023 were identified as infected. That is a vendor-reported SiteCheck result, not a neutral estimate of the prevalence of malware on all WordPress sites or a measure of scanner accuracy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to do when the checks disagree
The site looks normal, but a scanner finds malware
Assume the finding is important until verified. Check the exact file, hash or code fragment, database object, and modification history against a clean vendor copy. Run a second scanner and ask the host to inspect the account. Hidden payloads often wait for a specific URL, referrer, cookie, or time before appearing.
The remote scanner is clean, but visitors see redirects
Capture the redirect chain from an affected device and compare logged-in and logged-out behavior. Check conditional code, caching layers, DNS, JavaScript supplied by third parties, and compromised browser or network equipment. Ask the host to review server responses and logs; a remote scan may have reached a clean cache or a non-triggering URL.
The application scan is clean, but Google still shows a warning
Read the sample URLs in Search Console and test those exact pages. Search engines may retain a warning after the payload is removed, or they may have found hacked content in a database, subdomain, or old installation that your scan skipped. Expand the scope, clean every affected property, then submit the review.
Recommended Free Tools
An unknown administrator reappears after removal
Change all credentials and invalidate sessions first. Inspect database users, application passwords, API keys, cron jobs, writable upload directories, other sites on the account, and outdated plugins or server software. Reinstall clean core, themes, and plugins if you cannot identify the persistence mechanism.
The site is offline or you cannot log in
Contact the host immediately and preserve the current snapshot. Ask for a malware scan, access-log review, isolation of the account, and a list of recently changed files. Restore only a verified clean backup or rebuild from clean packages; restoring an unchecked backup can reintroduce the same compromise.
A scanner flags a legitimate custom file
Do not delete it solely because of a signature. Compare it with your source repository or a known-good deployment, inspect the flagged code in context, and obtain a second opinion. Record the exception so future scans do not conceal a real change.
Preventing a second infection
- Keep WordPress, themes, plugins, and server software supported and current.
- Remove unused plugins, themes, old test sites, abandoned subdomains, and duplicate WordPress installations.
- Use unique administrator and hosting passwords, two-factor authentication, and the fewest possible administrator accounts.
- Maintain automated backups that include files and databases, keep copies isolated from the production account, and test restoration regularly.
- Monitor for new users, unexpected file changes, redirects, spam, resource spikes, and outbound email. Alerts are useful only when someone reviews them.
- Ask the host whether account isolation, web-application firewall rules, malware monitoring, and server patching are included, especially on shared hosting.
- Document the clean baseline: WordPress version, active extensions, administrator list, scheduled tasks, domains, and backup locations. Future changes can then be compared with something known.
Bottom line
A trustworthy WordPress malware check is layered: observe the site and search results, scan the application, test it externally, and inspect the database or server when the evidence calls for it. Preserve the infected state before changing anything, recover from verified clean files or backups, update every component, remove persistence, rotate all credentials, and request Google or blocklist review only after repeat checks show the infection is gone.
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.
