Most compromised WordPress sites do not announce themselves with a defaced homepage. The common failure mode is quieter: the site looks normal to the owner, especially while logged in, but search engines, customers, and hosting providers are seeing something very different.
That detection gap is the real problem. Attackers often hide redirects from administrators, inject spam pages that only search engines see, or keep persistence in scheduled tasks and writable directories that never appear on the frontend. If you only check your site from one browser and one admin account, you can miss the compromise for weeks. SEO poisoning incidents are a good example: the site can look normal in routine admin checks while search visibility continues to degrade.
These are the signs that are actually worth checking, starting with the obvious ones and moving into the signals that require a deeper audit.
1. Google or browsers are showing a security warning
If visitors are seeing warnings such as “Deceptive site ahead,” “This site may harm your computer,” or “This site may be hacked,” treat that as an active incident, not a false alarm to ignore.
How to verify: Check Google Search Console > Security & Manual Actions > Security Issues. If Google has sample URLs, review those first. Also check the Google Safe Browsing status for your domain. A warning here usually means the compromise is already visible outside your own dashboard.
2. Visitors from Google or mobile devices are redirected, but you are not
This is one of the most common real-world patterns. The site loads normally for the owner, but visitors arriving from search results or on mobile are sent to scam pages, fake update prompts, gambling sites, or SEO spam.
How to verify: Test while logged out, in a private browser window, from a phone, and from a different network if possible. Search site:yourdomain.com, open a few results, and compare what you see with what an administrator sees. If the behavior changes based on referrer, device, or login state, the site is compromised or misconfigured and needs investigation. This is a common redirect-malware pattern, and it aligns with what is shown in this guide to WordPress redirect hacks and injected scripts.
3. There are admin users, role changes, or capabilities you did not create
Unexpected administrator accounts are a strong compromise signal. So are legitimate users whose role was silently elevated, or users whose capabilities no longer match what they should have.
How to verify: Review all administrator accounts in Users > All Users. Check recent user creation times, email addresses, password reset activity, and role assignments. If you are comfortable with the database, compare the expected admin list against entries in wp_users and capability metadata in wp_usermeta. The goal is to confirm that every privileged account and capability assignment is legitimate.
4. PHP or other executable files appear in uploads or other writable paths
The uploads directory should primarily contain media files and generated assets. A PHP backdoor in a writable directory is a classic persistence mechanism because attackers can often place it there through a vulnerable plugin or compromised admin session.
How to verify: Inspect wp-content/uploads/ and other writable directories for files such as .php, .phtml, .phar, or suspicious double extensions like image.jpg.php. Some plugins create unusual files, so do not assume every non-image is malicious, but every executable file in a public uploads path deserves explanation. For a deeper look at how persistence is commonly hidden, see this breakdown of WordPress backdoor scripts. From a hardening perspective, this is also one of the clearest reasons to use a plugin that can block PHP execution in uploads and monitor those paths continuously.
5. Google is indexing pages, titles, or descriptions you never published
SEO spam infections often stay invisible to normal visitors. Instead of breaking the homepage, they create spam landing pages, inject hidden links, or alter how search engines see your site.
How to verify: Search site:yourdomain.com and review the titles, descriptions, and URLs carefully. Look for pharmacy terms, gambling terms, foreign-language pages you did not publish, fake product pages, or strange query-string URLs. Then compare those URLs against your actual WordPress content and sitemap. If Google is already indexing injected spam pages, this tutorial on removing spam pages from Google search is a practical next step.
6. WordPress core files, theme files, or plugin files changed without a deployment
Unexpected file modification is one of the strongest technical indicators of compromise. Attackers often add a few lines to a core bootstrap file, theme template, or plugin loader so their code runs on every request.
How to verify: Use your deployment history, WordPress checksum validation for core files, or a security plugin that includes file integrity monitoring. If a core file differs from the official release and you did not patch it intentionally, investigate immediately. For themes and plugins, compare the current file state with version control, vendor releases, or a known-good backup. The value of the plugin here is not branding; it is repeatability. Integrity checks are most useful when they are part of ongoing monitoring, not a one-time manual review after something already looks wrong.
7. Scheduled tasks or cron hooks exist that nobody on your team recognizes
Persistence is what turns a one-time compromise into a recurring one. Attackers use scheduled tasks to re-download malware, recreate users, or call remote payloads after you think the site is clean.
How to verify: Review WordPress cron events with a tool such as WP Crontrol or wp cron event list. Look for unfamiliar hook names, unexpected frequencies, or callbacks tied to files you do not recognize. Also review system cron jobs if you manage the server directly.
8. wp-config.php, theme functions.php, mu-plugins, or server rewrite rules changed unexpectedly
Not every compromise lives in a standalone malware file. Attackers frequently hide code in places that already execute on every request: wp-config.php, a must-use plugin, a snippets plugin, the active theme, or web server rewrite rules.
How to verify: Inspect wp-config.php, active theme files, wp-content/mu-plugins/, and any code-snippet plugins for unfamiliar includes, remote fetches, obfuscated strings, or redirect logic. On Apache or LiteSpeed, review .htaccess. On Nginx, review the site configuration or include files that control redirects and PHP handling. Anything added outside your normal deployment path needs explanation.
9. Plugins, themes, or code-snippet entries appeared or changed without approval
Attackers do not always upload obvious malware filenames. Sometimes they install a plugin with an innocuous name, add a code snippet that injects spam or redirects, or modify a dormant theme so it becomes the persistence layer.
How to verify: Audit installed plugins, themes, and snippet managers against your deployment records. Check activation dates, last modified times, and administrator activity. If your team did not approve the change, do not treat it as harmless just because it looks like a normal WordPress component.
10. The site becomes slower, resource usage spikes, or the host reports abnormal process activity
Performance issues are not proof of compromise by themselves, but unexplained CPU, memory, or PHP worker spikes can be a useful signal when they appear with other indicators. Spam mailers, bot traffic handlers, and poorly hidden malware all leave operational traces.
How to verify: Compare current resource usage against your normal baseline. Check host dashboards, PHP-FPM metrics, process lists, and error logs. If the slowdown began without a known traffic event, deployment, or plugin update, include security in the root-cause analysis instead of assuming it is just a hosting problem. This case study on high CPU usage caused by malicious crawlers is a useful example of what that investigation can look like.
11. Transactional email starts failing, or your host reports outbound spam or abuse
Compromised sites are often used to send spam, phishing mail, or abusive outbound traffic. The first visible symptom may be operational, not visual: password reset emails stop arriving, order confirmations land in spam, or the hosting provider sends an abuse notice.
How to verify: Review mail logs, SMTP provider alerts, host abuse notices, and IP reputation checks. A blocklisted IP does not prove WordPress malware on its own, especially on shared hosting, but if email failure appears alongside suspicious users, file changes, or redirects, treat it as part of the same incident until proven otherwise.
12. Malware returns after you remove a file or clean a single symptom
If suspicious files reappear, redirects come back, or spam pages return after a partial cleanup, the problem was never the one file you deleted. The root cause is a missed persistence layer, an unpatched vulnerability, or stolen credentials that are still valid.
How to verify: Re-scan the site after cleanup and compare file changes over time. Review scheduled tasks, privileged accounts, writable directories, and the vulnerable component that allowed the initial access. Reinfection is evidence that the upstream compromise path is still open. That is why incident response has to include backdoor and persistence review, not just deletion of the first suspicious file, and why repeatable scans and file monitoring matter after cleanup.
What to do if one of these signs is present
Do not treat a single malicious file or a single redirect as the whole incident. In WordPress compromises, the downstream symptom is rarely the root cause.
- Preserve a known state first. Take a backup or snapshot before making destructive changes so you can compare files, investigate entry points, and recover safely if needed.
- Audit all persistence layers. Check files, database content, users, roles, cron events, plugins, themes, mu-plugins, and server rules. If you only remove the visible symptom, the compromise usually returns.
- Run an inside-the-site scan, not just an external check. An outside-in scan is useful for confirming visible symptoms, but it cannot inspect everything inside the installation. A WordPress security plugin can help you review file changes, integrity drift, and other signs of persistence from inside the site.
- Patch the entry point. Update or remove the vulnerable plugin, theme, or custom code. If credentials may have been exposed, rotate WordPress, hosting, database, SSH, and SFTP credentials.
- Verify from outside the admin session. Test as a logged-out visitor, from mobile, and through search results. What matters is what customers and crawlers see, not only what administrators see. An external security check is useful here because it evaluates the site from the outside in.
- Harden the environment. Restrict executable files in writable directories, enable least privilege for users, use file integrity monitoring, and keep a clean deployment trail so future changes are attributable. In practice, that usually means blocking PHP execution in uploads, disabling risky defaults such as XML-RPC where not needed, restricting access to sensitive files, enforcing
DISALLOW_FILE_EDIT, and reducing unnecessary admin exposure. If you are standardizing your stack after cleanup, this is where a security plugin with ongoing monitoring and hardening controls earns its place.
The practical takeaway
The most dangerous WordPress compromises are the ones that stay plausible. The homepage still loads. Admin login still works. Nothing looks obviously broken. Meanwhile, the attacker is using a cron hook, a writable directory, a modified theme file, or search-engine cloaking to stay hidden.
If you want early detection, stop relying on a single point of view. Check the site the way Google sees it, the way a customer sees it, and the way the server sees it. When those three views do not match, you usually have your answer. In practice, that means combining an external security check with a plugin that can scan the installation from inside WordPress, monitor file integrity, and apply hardening controls.
