I Built a WordPress Security Scanner. Today I Am Making It Public.

A few years ago, I got a call from a client at 11pm. His online store had been down for six hours. Customers could not checkout. Revenue was going to zero by the minute. When I finally got into the site, it was a mess – someone had injected code that was silently redirecting visitors to a pharmacy scam. The worst part? The site had been compromised for three weeks before anyone noticed.

That call changed how I think about website security. Not because it was the first time I had seen something like that – it was not. But because I realized something uncomfortable: most site owners have no idea what is happening on their own website right now. Not a rough idea. No idea at all.

I have carried that thought with me for years. It eventually became WP Vanguard – a free security scanner anyone can use in about a minute. Here is the honest story of why I built it, what problem I was actually trying to solve, the technical decisions that shaped it, and what I learned from the first real users.

---

The problem nobody talks about

Here is what I have noticed after years of working with WordPress sites: security problems rarely announce themselves. A hacked site usually keeps working. Pages load. The contact form still submits. Nothing looks wrong on the surface.

Meanwhile, in the background, something might be collecting your visitors’ data. Or quietly redirecting some of your traffic to spam sites. Or using your server to send thousands of phishing emails to strangers – none of which you would ever know about unless you went looking.

Most site owners find out about a compromise one of three ways. A customer emails them saying their browser flagged the site as dangerous. Google Search Console sends a notification. Or their hosting provider suspends the account. By then, the damage is already done. Rankings drop. Customer trust erodes. Cleanup takes days, sometimes weeks.

I kept thinking: what if there was a way for anyone to check their site in 30 seconds, without needing to hire someone or understand security?

I have helped clean up a lot of hacked sites over the years. Each time, the story is roughly the same. The site had obvious vulnerabilities that could have been caught months earlier. But the owner had no way of knowing. They were not negligent – there just was not a simple tool for people who are not security experts.

The client call that made it concrete

That 11pm call was not a one-off. In the two years before I started building WP Vanguard, I can count at least eight similar situations. Clients calling in a panic. Sites down or compromised. The immediate problem was always fixable – get in, remove the malicious code, restore from backup, harden the configuration. The cleanup itself is not the hard part.

The hard part is the conversation afterward. Sitting with someone who runs a legitimate business, who trusted you to help them build their online presence, and explaining that their site was compromised for weeks or months while everything looked normal. That they may have been sending their customers to scam sites. That Google may have flagged them. That they might lose rankings it took two years to build.

In almost every one of those cases, the underlying vulnerability was something that could have been found with a basic external check. An outdated plugin with a known critical vulnerability. A security header that had never been configured. An SSL certificate that had expired or was misconfigured. These are not exotic attack vectors. They are the things that show up in any standard security audit. They were not found because the site owners had no tool that would surface them before an attacker did.

---

Why existing tools did not cut it

There are security tools out there. I have used most of them. But they all have one thing in common: they are built for developers or security professionals. They give you raw output, technical jargon, and a long list of findings you need expertise to interpret.

If you are running a small business and you have ten minutes between meetings, you do not want to read a 40-page security report. You want a straight answer. Is my site okay or not? What should I do about it?

The paid tools that do give clear answers often cost a significant amount per month, per site. That is fine for a large agency managing dozens of client sites. It is not realistic for someone running a local bakery, a freelance portfolio, or a community organization website. These are exactly the kinds of sites that attackers love to go after – because the owners are less likely to be watching.

I started thinking about what a tool would look like if you designed it from scratch for the person who just wants their site to be safe – not for the security expert who already knows what to look for. What would you keep? What would you cut? How do you explain a problem in plain language without dumbing it down so much that it becomes useless?

The answer I kept coming back to was simple: most site owners need a grade, not a report. Something they could glance at and immediately understand. Green means you are okay. Red means there is something to fix. The details are there if you want them, but the headline answer should not require a security background to read.

---

The technical decisions that shaped what gets checked

When I started building it, I made a list of everything that matters for a typical WordPress site. Not everything that could theoretically go wrong – just the things that are most likely to be a real problem for a real site owner right now. Getting to that list took longer than I expected because the obvious first draft was about sixty items, and most of them were things that mattered to a security researcher, not to a site owner.

The filter I applied: if a problem shows up here, can the site owner actually do something about it? And is it the kind of thing that attackers routinely exploit in the wild, not just in theory? That cut the list significantly. What remained was the stuff that consistently appeared in the compromised sites I had cleaned up over the years.

Here is what the free scan checks:

• Security headers – These are invisible settings that tell browsers how to handle your site. Most sites are missing several of them. Attackers know this and use it to run certain types of attacks that would otherwise be blocked automatically.
• SSL certificate – Your padlock icon. Whether it is properly configured, not expired, and not pointing to the wrong domain. A misconfigured SSL can create a false sense of security.
• Known vulnerabilities – Checking against a database of security issues that have been publicly documented. If your site is running something with a known flaw, the scan will surface it so you know what needs updating.
• Blacklist status – Whether your domain or IP has been flagged by Google, security organizations, or spam filters. Being blacklisted can tank your search rankings overnight and warn away visitors before they ever see your site.
• External scripts – Scripts loaded from outside your site. A common way attackers stay hidden is by injecting a script from an external server. The scan looks for anything suspicious loading on your pages that should not be there.

None of these require you to install anything or give us access to your site. You put in your URL and the scanner does the work from the outside. Results come back in under a minute.

Why I did not check certain things

The decisions about what not to check were as important as the ones about what to include, and they were harder to make because leaving something out always feels like a gap.

File integrity checking was on my original list. Scanning site files to detect modified core files is a legitimate security technique. Wordfence does it, Sucuri does it, and it catches real threats. But it requires plugin-level access to the site. The moment you require an installation step, you have lost a significant portion of the people who most need the tool. Someone running a hacked site who does not know it probably does not have a security plugin installed. If I required one as a prerequisite for the scan, I would be screening out exactly the people I was trying to help. Removed from the list.

Database scanning was another one I considered and dropped. Checking the database for injected malicious content is technically possible but requires credentials and direct database access. Anything that requires credentials that the site owner has to hand over to a tool they just found creates a legitimate trust problem. A security scanner that asks for your database password is a hard sell, and rightfully so. Removed.

PHP version checking almost made it in. Running an outdated PHP version is a real security issue and something many WordPress site owners do not think about. But reliably detecting PHP version from an external scan is not straightforward – most servers do not expose this in a reliable way. I did not want to include a check that returned unreliable results and created false confidence. Deferred until I can do it accurately.

The hardest thing about building a security tool is that incomplete information can be worse than no information. If the scanner says everything looks fine when it does not, the site owner is now more confident that they are protected than they were before the scan. That false confidence is actively dangerous. Every check I included had to be accurate enough that a passing result actually meant something.

The goal was simple: give anyone with a website an honest picture of their security posture in one minute or less.

---

What was technically hardest to build

The scanning itself was not the hardest part, though it took longer than I expected to get right. The hardest technical problem was rate limiting and abuse prevention.

A free tool with no login and no friction is also a free tool that can be scripted to scan arbitrary URLs at high volume. That creates two problems. The first is the obvious one: server costs and availability if someone runs a lot of scans in a short time. The second is more subtle: a scanner that can be weaponized to probe sites at volume could itself become a tool for reconnaissance. I did not want to build something that helped attackers gather information faster.

Getting the rate limiting right – aggressive enough to prevent abuse, permissive enough that a legitimate user who wants to scan a few different URLs without signing up can do that – involved a lot of tuning. The final system combines IP-based rate limiting, scan result caching so the same URL does not trigger a fresh scan every time it is requested, and some behavioral signals that I am not going to describe in detail for obvious reasons. It took about three weeks of iteration to get to something I was comfortable with.

The second hard problem was the accuracy of the vulnerability check. Checking against a database of known vulnerabilities sounds straightforward. In practice, it requires identifying what plugins and themes a site is running from the outside, matching version numbers to the vulnerability database, and then presenting findings that are accurate – not just “this plugin has had vulnerabilities” but “this specific version of this plugin has this specific vulnerability.”

Version detection from outside the site is imperfect. Plugins do not always expose version numbers in a consistent way. Some sites deliberately obscure them as a basic security measure. My approach was to be conservative: only surface vulnerability findings when the version detection is reliable enough that I am confident the finding is accurate. A false positive – telling someone they have a vulnerability when they do not – wastes their time and erodes trust in the tool. I would rather miss some findings than generate false alarms.

The external script detection was the most interesting technical problem. Loading a page and checking every script that gets loaded sounds simple. In practice, single-page application frameworks, lazy-loading patterns, and JavaScript that injects more JavaScript make it genuinely tricky to get a complete picture of what is running on a page from a single load. The scanner handles this reasonably well now. It did not handle it well in the first version.

---

The decision to keep it free

I debated this for a while. Building and running a scanning tool costs money. Servers, databases, third-party data sources – none of it is free.

But I kept coming back to who actually needs this most. The site owners who are most at risk are often the ones least likely to spend money on security tools. They are running tight margins. They are wearing five hats already. They do not have a dedicated IT person or a security budget.

The free scan gives anyone a starting point. A way to know if there is something obviously wrong right now. No credit card, no signup required – just a URL. I did not want there to be any friction between someone wondering if their site is safe and getting an actual answer.

For people who want more – deeper scanning, ongoing monitoring, or help fixing what is found – there are paid options. But I wanted the baseline to be genuinely useful on its own, not a watered-down teaser designed to frustrate you into paying.

This thinking comes from a broader belief I have about building products: if you are solving a real problem for real people, there is a version of the solution that should be accessible to everyone, and a premium version for people who need more. The free tier is not marketing. It is the actual product for the majority of users who just need to know their site is okay.

---

What I learned building it

The technical side took time. Building a scanner that is accurate without being slow, that handles the edge cases, that does not flag legitimate things as threats – that is harder than it sounds. I rewrote significant parts of it multiple times as I found things that did not work the way I expected.

But the more interesting challenge was the presentation. How do you explain a security finding to someone who does not know what a security header is? How do you give a risk score that is honest without being alarmist? How do you distinguish between “this is a serious problem you should fix today” and “this is something worth being aware of but not urgent”?

I ran early versions past people who are not technical. Watched where they got confused. Rewrote the copy. Simplified the scoring. Removed the jargon. The product that exists now is dramatically different from the first version I built – mostly because of that feedback. Non-technical users are the most honest testers you can find, because they have no patience for things that do not make sense.

One thing I kept from the start: the scan has to give you something useful to do with the results. Knowing your site has a problem is only half the picture. Knowing what to do about it is what actually moves things forward. So every finding comes with context – what it means, why it matters, and roughly what is involved in fixing it.

The grading system I almost cut

There was one feature I almost removed during development: the overall letter grade, A through F. It felt too simple. I worried that reducing a complex security picture to a single letter was misleading – that a site could have a B grade but still have a serious specific problem, and the letter would give false reassurance.

When I tested it with real users, the opposite happened. The letter grade was the thing that oriented everything else. Without it, people looked at the list of findings and did not know how to weight them. Was four yellow findings worse than two red ones? Hard to know at a glance. With the grade as an anchor, they immediately knew whether to be concerned and could then look at the details to understand why.

I kept the grade. It is now one of the things I hear about most from users. The simplest feature turned out to be the most valuable one.

---

What the first real users showed me

The early reactions from people using the tool in the real world were not what I expected, in a few specific ways.

The first surprise was how many people shared their results. Not people with A grades – people with C and D grades. They would scan their site, see a mediocre score, and immediately forward the results to their developer or IT person. I had built the sharing feature assuming it would mostly be used by people showing off a good grade. Instead, it became a communication tool for site owners to show their technical team “here is the problem, here is what a tool says about it, fix this please.” That use case – the non-technical owner using the scanner as a bridge to a technical conversation – is now something I think about actively when I make product decisions.

The second surprise was the number of people who came back after making changes. I had assumed the primary use pattern would be scan once, read the results, maybe take action, never think about it again. Instead, a meaningful portion of users came back within a week of their first scan to re-scan after fixing something. They wanted to see the grade go up. That feedback loop – fix something, check your work, see improvement – is how tools build habits. I had not designed for it explicitly, but it emerged from the grade system anyway.

The third thing was harder to hear: several users told me the recommendations were not specific enough. “You need to add the X-Frame-Options header” is accurate but not immediately actionable for someone who does not know what a header is or where to set it. Early users were finishing the scan, reading the findings, and then going to Google to figure out what to actually do. That is a gap in the product, and I have been working on closing it by adding step-by-step guidance for the most common fixes.

One user specifically told me they had been wanting to check their site for months but kept putting it off because every security tool they had tried required creating an account first. They scanned with WP Vanguard, found two issues, fixed one of them, and came back the next day to rescan. That is exactly the pattern I was trying to enable. The no-signup requirement that felt like a risk from a business model perspective turned out to be the thing that made the tool actually get used.

---

Who it is for

Honestly? Anyone with a WordPress site who wants to know if it is in good shape.

I have had developers use it as a quick sanity check before handing a site off to a client. I have had small business owners use it after reading a news story about website hacks and wondering about their own site. I have had people use it on competitor sites just to understand what good security practices look like in the wild.

The scanner does not require any WordPress access. It works from the outside in – the same way an attacker would approach your site. Which means the results reflect what the real world actually sees when it looks at your site, not just what you can see from the inside.

For agencies and freelancers, there is also a partner tier with API access and bulk scanning. If you are managing ten or fifty client sites and you want a fast way to know which ones need attention, that is what the partner dashboard is built for. Running a check on every site you manage takes minutes instead of hours.

If you have not checked your site recently – or ever – it takes about a minute. You might find everything is fine, which is a genuinely good thing to know. Or you might find something worth fixing before it becomes a real problem. Either way, you will know.

---

What is coming next

The free scanner is not finished – no product is. There are three directions I am working on that I think will make it meaningfully more useful.

The first is better actionability. As I mentioned, early users found the findings clear but the next steps vague. I am working on a “fix guide” for each finding – not a link to generic documentation, but specific steps for the most common WordPress configurations. If you are on a cPanel host, here is where to set this header. If you are using a caching plugin, here is where the setting lives. Concrete, specific, written for the person who is not a developer.

The second is scheduled monitoring. Right now, WP Vanguard is a point-in-time check. You run it when you think of it. But security changes over time – a new vulnerability gets discovered, a plugin you installed last month has a known issue now, your SSL certificate is going to expire next week. The monitoring tier will run checks automatically and notify you when something changes, so you are not relying on remembering to check. This is where the paid version becomes compelling for site owners who want ongoing visibility, not just occasional awareness.

The third is better coverage of the vulnerability database. The current integration covers a substantial portion of known WordPress plugin and theme vulnerabilities, but the matching is imperfect for reasons I described earlier. I have been working on improving the version detection logic so that vulnerability findings are more reliable. This is mostly invisible infrastructure work, but it matters because a missed critical vulnerability is a real failure of what the tool is supposed to do.

There is also a feature I have been thinking about for a while but have not committed to yet: a plain-language summary of what a site’s current security posture actually means in practical terms. Not just a list of findings, but a narrative. “Your site is probably fine for now, but you have one issue that should be fixed before it becomes a problem, and here is why.” Writing that accurately without being either alarmist or falsely reassuring is hard. I am still working out how to do it well.

---

The connection to a broader approach

WP Vanguard sits alongside everything else I work on at Wbcom Designs. The agency work, the plugins, the client sites – all of it runs on the same open source stack, and all of it is subject to the same security realities that prompted me to build this tool.

I have written before about why I still bet on open source after 10+ years. One of the honest tradeoffs in that bet is that security is more distributed – you are responsible for understanding and managing it, rather than having a vendor handle it for you. WP Vanguard is, in part, my attempt to make that responsibility easier to carry for anyone building on WordPress.

This is not a replacement for professional security work. There are situations that genuinely need an expert, and I am not pretending otherwise. But I want to close the gap between “no visibility” and “I know what is going on with my site.” That gap is where most of the damage happens – not in the cases where people know there is a problem, but in the cases where they never knew there was one.

---

One thing I wish I had known earlier

If there is one thing I would go back and tell myself when I first started working on WordPress sites professionally, it is this: security is not a one-time setup. It is more like maintenance. Things change. New vulnerabilities get discovered. Software that was fine last month might have a known issue this month.

The sites that get into trouble are almost always the ones that have not had anyone looking at them for months. Not because the owners do not care – usually they care a lot. But because there was never a simple, low-friction way to stay on top of it without dedicating real time or money to it.

The other thing I wish I had understood earlier: most compromised WordPress sites are not targeted. They are opportunistic. Automated scanners crawl the web looking for sites running known vulnerable software, then attack them at scale. It does not matter how small your site is or how little traffic it gets. If you are running a plugin with a known vulnerability, there are automated systems that will find it and exploit it. The assumption that “I am too small to be a target” is consistently wrong.

That reality is actually the reason the free scan model makes sense. If attacks are automated and opportunistic, the defense needs to be low-friction enough that regular people actually do it. A security practice that requires significant time, money, or expertise will be adopted by the people who can afford it. Everyone else stays exposed. That is the wrong outcome.

It started with that 11pm phone call. It took a few years to turn into something real. I think it is useful – but the best way to find out is to try it on your own site.