The Signs Your WordPress Site Has Malware (Before Google Tells You)

Why "wait for the warning" is the wrong strategy

By the time Google shows a Security Issues report or a browser flags your domain, an infection has usually been live for days or weeks. Automated detection is reactive by design — it has to observe the bad behavior first. Everything in this checklist is something you can check yourself, right now, without waiting for a third party to notice on your behalf. None of it requires guessing; each item below is a specific, verifiable thing to look for.

Accounts that shouldn't exist

Open Users in wp-admin and actually read the list, not just the count. An attacker who gets any level of write access will frequently create a new administrator account as a durable foothold — it survives a plugin cleanup, and it doesn't depend on whatever vulnerability got them in originally. Look specifically for:

• Any administrator you and your team didn't create
• A username that mimics a real one (an extra character, a different case, a look-alike like "admln")
• A registration date that doesn't line up with anything you remember doing

Don't just demote a suspicious account — delete it, after confirming with your team it isn't legitimate. A demoted account can often be re-elevated by the same access that created it.

Files that have no reason to be executable

wp-content/uploads exists to hold media — images, PDFs, videos. It is not supposed to contain .php files, and most hosts don't need it to. A .php file sitting in your uploads folder, especially one with a random-looking name or a double extension like image.jpg.php, is one of the more reliable single signs of compromise you can check. If you have shell or FTP access, it's worth scanning specifically for this:

find wp-content/uploads -name "*.php"

A legitimate plugin will occasionally place a small index.php stub in uploads subfolders purely to block directory listing — those are typically empty or near-empty files. Anything with real logic in it, sitting in a media folder, deserves a closer look.

Server behavior that doesn't match your actual traffic

Two related patterns are worth watching in your hosting dashboard or server logs:

• A spike in outbound requests or bandwidth that doesn't correspond to anything you published or any traffic increase you can explain. Compromised sites are frequently used to send spam email, participate in DDoS traffic, or scrape other sites — all of which show up as outbound activity that has nothing to do with visitors reading your content.
• Site slowness tied to background or scheduled processes rather than page views. If your host's process list or resource graphs show sustained CPU or database load happening on a schedule, independent of actual visitor traffic, that pattern is consistent with a rogue cron job running malicious code on a timer — sending spam, re-infecting cleaned files, or scanning for further access.

What shows up in Google, and what that specific wording means

Google surfaces two genuinely different flags, and conflating them leads people to the wrong fix. It's worth being precise about which one you're actually seeing:

• "This site may be hacked" is a subline that appears only inside Google's own search results, next to your listing — never as a full-page browser warning. Google's documentation describes it as a signal that automated systems found content resembling known hacking patterns: injected spam links, pages in a language you don't publish in, or text stuffed with unrelated keywords that isn't visible when you look at the page normally in your own browser. That last detail matters — the injected content is often served selectively to search crawlers, so your own casual glance at the page can look completely clean.
• "Deceptive site ahead" is a different thing entirely — a full-page red interstitial from Google Safe Browsing covering active phishing or harmful-redirect content. We cover that one, and exactly how it differs, in our "Deceptive site ahead" guide.

If you want to check for the search-results version yourself before Search Console flags it, search site:yourdomain.com and read the actual snippet text Google is showing for your own pages — spammy titles or descriptions that don't match your real content are the tell, even if the page looks fine when you open it directly.

Warnings your visitors see that you don't

Browser-level antivirus extensions and some ad blockers run their own reputation and content checks independent of Google Safe Browsing. If visitors mention seeing a security warning, an "unsafe site" notice from their antivirus software, or unexpected ad injections that you don't see yourself, don't dismiss it as a false positive without checking. These tools sometimes catch injected ad-fraud scripts or malicious redirects before Safe Browsing's own crawl gets around to your site.

The redirect that only happens on your phone

This is the one people miss longest, because it's specifically designed to be missed. A well-known WordPress redirect infection checks the visitor's device, referrer, and login state before deciding whether to redirect at all — and mobile-only, non-logged-in visitors coming from a search result are the most common target profile, since that combination is the least likely to include the site owner. The result: you open your own site in your normal desktop browser, everything looks fine, and you conclude there's no problem — while a visitor arriving on their phone from a Google search gets bounced to spam, ads, or a scam page.

To actually check for this, don't rely on your everyday browsing session. Use an incognito or private window, or a mobile device simulator in your browser's developer tools, and specifically try visiting as if you were a new mobile visitor arriving from search rather than typing your URL directly.

Files with modification dates that don't match anyone's work

If you or your host can list files by modification time, look for anything inside wp-admin, wp-includes, or your active theme with a timestamp that doesn't correspond to a plugin update, a theme edit, or anything your team did. Core files in particular should only change when WordPress itself updates — a core file with an unexplained recent timestamp is a strong indicator, and we go into exactly what to do with one in our guide to a silently altered core file.

What to do once you've confirmed a few of these

One item on its own — say, a slightly odd file timestamp — might have an innocent explanation. But two or more together (an unfamiliar admin account plus outbound traffic you can't account for, or a mobile-only redirect plus a spammy search snippet) is enough to stop treating this as speculative. At that point, move to actually confirming and removing the infection rather than continuing to just look for more symptoms — our step-by-step malware removal guide covers the full process, in the right order, so cleanup actually sticks instead of reappearing within days.