This article was originally written in Spanish. The English version was translated with Claude Opus 4.8 and reviewed by me personally.
It’s increasingly common to run into infections and hacks on WordPress sites. Over the last few months I’ve come across several affected sites, and not long ago I was asked to run a diagnosis on a website because there were suspicions it might be infected. That’s where this article comes from.
What I want to share is where I start looking when I suspect a WordPress site is compromised, so that you too can get a first idea of whether your site has a problem or not. I’m writing it with someone who has basic technical knowledge in mind, so you don’t need to be a developer to follow along.
Before getting into it, I want to make one idea clear that will run through the whole article: not every alert is a hack. Systems sometimes fail, run slow or go down for software, human or infrastructure reasons. It’s a bit like when traffic slows down because of roadworks or a busy day, and we don’t immediately assume there’s been an accident. In fact, many automatic detections of a “malicious file” end up being false positives. So the first thing, before touching anything, is always the same: stay calm, review with judgment and follow an order.
The bots don’t hate you, they scan you
There’s a very widespread, and very mistaken, idea: thinking that if you get hacked it’s because someone has it in for you. In the vast majority of cases there’s nobody on the other side picking you out specifically. What there is are automated bots scanning millions of websites a day, always looking for the same signals: an old version of a plugin, an exposed login route, a file that gives away what you have installed.
And the data backs this up. The WordPress core is very secure; according to Patchstack’s security report , in all of 2025 only two vulnerabilities were found in it. The problem is almost never there, but in what surrounds it, and very especially in plugins, which account for the vast majority of vulnerabilities (industry analyses put it at around 97%). The most dangerous ones are abandoned plugins, the ones that have gone two or more years without receiving an update.
The pattern almost always repeats in the same way. A developer discovers a vulnerability in a popular plugin and publishes it. That same announcement, which is meant to get people to update, also tells attackers exactly what they need to look for. From there, the bots start scanning en masse for sites that haven’t applied the update yet, and the window between the flaw being published and exploitation beginning can be just a few hours.
That’s why the sites that fall are almost always the ones that are out of date or outright abandoned. It’s not a matter of bad luck, it’s being the easiest target on the list.
And what are they after once they’re in?
In my experience, the two most common goals rarely have anything to do with you specifically.
The first is SEO spam. Here the attacker uses your site, and above all your reputation with Google, to rank junk content that usually redirects to Chinese ecommerce stores or shady sites. It’s the case I’ve come across most often. A quick way to spot it is to search Google for site:yourdomain.com and check whether pages in Chinese, Japanese or English appear that you never created. If you see them, you have a problem.
The second is data theft for spam or phishing. If your site stores customer data or a user base, for example the submissions from your contact forms, that data can be stolen to send fraudulent email campaigns. In these cases there’s usually a bit more human involvement behind the bot, but the origin is still the same as always: they found an open door, they weren’t looking for you.
And from this comes a conclusion that is both reassuring and demanding: most of these attacks are prevented with basic hygiene. You don’t need to turn your site into a fortress, you just need to not be the easiest site on the bot’s list.
Where I start looking
When I review a site I don’t go in blind. I follow a layered order, from the most visible to the deepest, and I’ll walk you through it in the same order I do it.
1. Google Search Console
It’s my first look, and the reason is simple: Google has been crawling your site constantly for a long time, so it already has a formed opinion about it. What I check here is, above all, three things.
First, the Manual actions and Security issues sections. They’re the two places where Google directly warns you if it has detected malware, hacking or spam on your site. It’s the most direct check there is, and a lot of people don’t even know they’re there.
Second, performance and indexing. Here I look for odd spikes in clicks or indexed pages, and very especially pages I haven’t created. A new sitemap or URLs I don’t recognize are an immediate red flag.
And third, the crawl stats. If I see the server taking much longer than usual to respond, I note it to keep an eye on over the following days.
An important point of judgment: a traffic spike almost always has a boring explanation before a malicious one. A campaign, an event, something seasonal. Before thinking about an attack, it’s worth ruling out the mundane. Only if that spike comes from URLs or languages that don’t fit your site do I start to really worry.
After Search Console, the logical next step is to take a look at Google Analytics, or whatever analytics tool you use. Sometimes the behavior of that traffic (where it comes from, how it moves, whether it looks human or automated) gives you clues that aren’t as clear in Search Console.
2. A clean WordPress
This is the layer where the game is won or lost, so it’s the one I review most carefully.
The first thing is the admin users. The question is simple: is there any admin nobody recognizes? A new, unexpected user is one of the clearest signs that something is wrong, and it’s worth confirming them one by one rather than taking them at face value.
Then I check the versions, that is, that the core, plugins and themes are up to date. It’s no small detail, because keeping everything updated is probably the best defense there is against the mass scans we talked about earlier.
And then there’s file integrity, which is the part I most enjoy explaining because it’s the one most often misunderstood. An integrity scan compares the files of your installation against the original files from WordPress’s official repository, and warns you when something doesn’t match. Plugins like NinjaScanner, Wordfence or Health Check & Troubleshooting perform this kind of check, and some also verify plugin code against their repository versions.
Here’s the important part: a warning doesn’t automatically mean you have an infected file. There are several perfectly normal reasons a file can show up flagged.
One is premium plugins and themes. Products like WPML or Elementor Pro don’t have their code in the public WordPress repository, so the scanner finds nothing to compare them against and flags them as an unknown file, warning you that they don’t officially exist. It’s a textbook false positive. The other reason is minimal changes: sometimes a single line break or one line modified by a translation is enough for a core file to be flagged as modified, when in reality there’s nothing malicious, just a trivial difference.
That’s why an integrity warning isn’t a verdict, but a starting point. Before getting alarmed, what I do is check which file it is exactly and what actually changed.
It’s worth knowing that there are deeper scanners, like those based on YARA rules, which instead of comparing against the repository analyze the contents of files looking for known malicious code patterns. They’re more powerful at catching backdoors, but also less common day to day. And there’s one detail common to all these scanners worth keeping in mind: they consume server resources, sometimes quite a lot. It’s not a good idea to fire them off carelessly, so I recommend using them sensibly and, if possible, scheduling them during off-peak hours so as not to penalize anyone browsing at that moment.
Finally, a simple trick worth checking: there should never be PHP files in the uploads folder (wp-content/uploads/). If you find any there, that’s a bad sign.
3. The server
This layer gets overlooked a lot, and that’s a mistake, because there’s a risk that doesn’t depend on how well you look after your own site. If your site shares a server with other websites, something very common with many hosting plans, there’s what’s known as cross-contamination.
The idea is that, sometimes, all an attacker needs is to infect a single one of the server’s websites to end up reaching the rest. This means that an old, abandoned site, or a testing environment someone left forgotten, can become the entry point that ends up affecting your site, no matter how updated and clean you keep it.
From this come a couple of recommendations I always give. The first is to review which sites live on your server and remove the ones you no longer use, because a site nobody maintains isn’t just wasted space, it’s an open door. The second, along the same lines, is to delete any staging or old version that’s no longer in use, instead of leaving it there “just in case.” And the third has to do with SFTP or SSH access accounts: it’s very common for a developer or an agency to have been given access at some point, and for nobody to have closed that account afterwards. Every forgotten access is one more door into the site, especially if that password ends up leaked in someone else’s breach, so it’s worth looking at which accounts exist, checking whether they’re still in use and deleting the ones that aren’t.
All of this, moreover, explains something that baffles many of the people who go through it: why sometimes a site is cleaned, backups are restored and all the passwords are changed, and yet it gets reinfected within a few days. If the source of the problem is outside your WordPress, whether on another site on the server or at some point of persistence the cleanup didn’t reach, the problem comes back again and again. Cleaning only the surface isn’t enough.
If by this point you haven’t found anything, that’s a good sign. In the best case, an audit ends with no findings, and that’s exactly what we want. Even so, it’s still worth reviewing the web server logs, which often hold the trace of strange accesses or requests that don’t show up anywhere else.
4. DNS
I won’t go on at length here, but it deserves at least a mention. There are also hacks that affect your domain’s DNS configuration, with a goal fairly similar to SEO spam: above all, creating subdomains or records that redirect to shady sites. It’s less frequent than the rest, but it’s worth knowing that this layer exists too and that it can also be reviewed.
Judgment over perfection
If I had to keep a single idea from all of this, it would be that maintaining and preventing is, by far, the best tool you have. Reviewing your site with some regularity is far cheaper, and hurts a lot less, than having to recover it after a hack.
And alongside that, another thing I repeat a lot: you don’t need to have everything perfect. A security analysis almost never comes out spotless, and chasing 100% is usually a way to throw away time and resources. The healthy approach is to find a balance between convenience and security, closing what really matters, knowingly accepting the minor risks and, above all, not obsessing over it.
Within that, there are two habits worth their weight in gold. The first is questioning your plugins every so often: asking yourself whether you really still use all of them, and whether any has stopped being developed. It happens more than we think, that we end up dragging along plugins we installed one day and that today only add attack surface without giving us anything. The fewer you have, the better. The second habit is remembering that no plugin is immune: vulnerabilities are always going to appear, in one or another. What makes the difference isn’t choosing the perfect plugin, which doesn’t exist, but choosing plugins with active support that get patched quickly when a problem comes up.
A checklist to save for yourself
To sum up, this is the basic order I follow when I review a site:
- Google Search Console: manual actions, security issues, and pages or sitemaps I don’t recognize.
- Google Analytics: check where the traffic comes from and whether its behavior looks human or automated.
site:yourdomain.comsearch: check whether pages appear in other languages that I didn’t create.- WordPress users: look for any admin nobody recognizes.
- Versions: core, plugins and themes up to date.
- File integrity: with judgment, distinguishing the false positives (premium, minimal changes) from what’s real.
- PHP where it shouldn’t be: make sure there are no PHP files in
uploads/. - The server: abandoned neighboring sites, forgotten staging, unclosed SFTP/SSH accounts and web server logs.
- Calm and order: don’t touch anything in the heat of the moment; look, understand and only then act.
This is just the tip of the iceberg
Everything I’ve covered here is basic guidance so you can get a first idea of whether your site is compromised or not. But I want to be honest: there’s quite a bit more to look at. The web server logs in more detail, problems in the PHP configuration, hardening the site, or obfuscation techniques to make it harder for bots to discover versions and access points. Each of those layers could easily fill its own article.
If after going through all this you think you’ve been hacked, or you simply want a thorough cybersecurity audit of your WordPress, write to me and we’ll take a look. I’ll be happy to give you a hand. My details are below.
And if what you’re after is to keep learning about these topics, bookmark this page and drop by every now and then, as I keep publishing things like this as I come across them in the real world.