Most of what my team handles is WordPress maintenance and security for client sites, somewhere in the range of several dozen installs at any given time, and the reason WP Security Ninja stuck is that it behaves like a tool designed by people who have actually managed more than one site at once. A lot of security plugins are built around the assumption that you log into a single dashboard, look at a single score, and move on. That assumption falls apart the moment you are responsible for forty sites with forty logins and forty maintenance windows. WP Security Ninja treats the multi-site reality as the default case rather than an afterthought, and that single decision is what earned it a place in our standard stack. The MainWP integration is the part I would point to first. We already run MainWP as the hub for updates and backups across the client base, so anything that plugs into it without adding friction is worth real money to us. Security Ninja's MainWP support is built directly into both the free and the premium versions of the plugin, which means there is no separate child plugin to install on every site, no extra moving part to keep updated, and no additional failure point. Once the plugin is on a child site, it simply shows up in the MainWP dashboard. The split between the free and premium MainWP add-ons is worth being precise about, because it decides which one an agency actually needs: - The free add-on, available in the WordPress.org repository, surfaces the security test results from each child site, flags any known vulnerabilities, and lets you start scans remotely. For a lot of smaller setups that is genuinely enough. - The premium add-on adds the combined events log across every connected site, search and filtering on those events, and remote control of white label mode on Pro installs. This is the tier that earns its place once you are managing client sites at volume. What pushed us to the premium add-on specifically was that combined events log. Instead of opening each site to see what its firewall and login activity looked like, it pulls a synchronized log from every connected install into one searchable view. When a client emails to ask why they got locked out, or when I want to confirm whether a particular site saw a spike in failed logins last week, I answer it from the MainWP dashboard in about a minute. The combined log and the remote white label control only report meaningfully on sites running the Pro version, since the free plugin does not register events, but for our paid client tier that is the configuration we run anyway. Remote scans and bulk actions deserve their own mention because they change the rhythm of routine work. From the MainWP column I can kick off the security tests on a single site or on a hundred sites with one bulk action, then come back later and pull fresh results once the sites have synced. We built a monthly security pass into our maintenance retainer, and before this it meant a person clicking through every site individually. Now it is one action, a coffee break, and a review of whatever came back yellow or red. The overview column shows the security score and any detected vulnerabilities per site at a glance, so the triage step happens before anyone opens a single site. The per-site security score is more useful than a single number has any right to be, and it has quietly become the first thing I look at. It rolls up the test results, the vulnerability findings, and the state of the core file checks into one figure, and across a fleet that gives me a fast way to sort attention: the sites sitting low get looked at first, the ones sitting high can wait. It is also a number a client understands without any security background, which matters more than it sounds. When I am explaining why a particular site needs work this month, pointing at a score that has dropped is far more persuasive than a paragraph of jargon the client will nod along to and not absorb. I treat the score as a triage signal rather than gospel, because no single figure captures everything that matters about a site's security, but as a way to decide where the next hour of work should go it does its job well, and it does it across every connected site at once from the MainWP overview. White label is the feature that quietly justifies the agency bundle for us. On Pro licenses at the agency tier you can replace the plugin name, its description, the author details, the icon, and the associated URLs with your own branding, and optionally hide it from the standard Plugins screen entirely. When a client logs into their own WordPress admin, they do not see a third-party product called Security Ninja sitting in their plugin list. They see a security tool that carries our agency's name, which is precisely the impression we are paid to create. It is a small piece of polish on paper and a meaningful one in practice, because a client who sees a stack of unfamiliar third-party plugins starts wondering what they are paying us for. The white label module ships with every tier of the agency bundle rather than sitting behind a separate fee, and on a MainWP setup you can flip client branding on or off across the fleet without visiting each site. Day to day, the cloud firewall does the heaviest lifting, and it works in a few layers that stack well together: - The IP database blocks traffic from a continuously updated list of known malicious addresses, in the range of 600 million entries, refreshed every few hours, so a large share of automated attacks never gets a useful response. - Country blocking, built on the well known 8G firewall ruleset, lets you restrict access by region and choose whether a blocked country sees a custom message or gets redirected somewhere harmless. For client sites that only ever serve one or two regions, this cuts an enormous amount of automated nonsense. - The advanced firewall controls let you decide how blocked visitors are handled rather than forcing a single behavior, which matters when a client has an unusual setup and you need the firewall assertive without being clumsy. One thing that matters with any firewall this assertive is what happens when it gets something wrong, and Security Ninja gives you the controls to handle that without weakening the whole site. A firewall working off a database this large will occasionally catch a legitimate visitor, especially on sites with custom setups or unusual traffic. You can allow trusted IP addresses, review exactly what got blocked, and adjust the firewall's behavior rather than living with an all-or-nothing toggle. For client work that distinction is important, because the call I least want to take is a client telling me a real customer cannot reach the site. Being able to whitelist the address, confirm it against the log, and move on, with protection still fully active everywhere else, is the difference between a two-minute fix and an awkward afternoon. The 404 Guard is one of those features I did not expect to care about and now would not turn off. Bad bots spend their day probing sites for files that do not exist, hunting for an old backup, an exposed config, a vulnerable plugin path, and every one of those requests costs the server something. 404 Guard watches for that probing pattern and cuts the offender off, so the site stops spending resources answering scanners. On smaller client sites with modest hosting, the reduction in junk traffic is genuinely noticeable in the logs, and it keeps the firewall and the malware scanner focused on real signal instead of background noise. The malware scanner has clearly had attention put into it, and it is one of the areas where the product has moved forward rather than stood still. It runs deep inspections of the plugins, themes, uploads, and other key directories, checking files against known malware patterns and looking for code that does not belong. It is heuristic rather than a pure version check, so it is looking at what the code actually does, not just whether a plugin claims to be a particular release. When it flags something, you can review the file safely, whitelist it if it is a false positive, or remove it. The whitelist piece matters more than it sounds, because on real client sites you will hit false positives eventually, and a scanner that lets you acknowledge and dismiss them keeps the next scan clean instead of nagging you about the same file forever. Scheduled scanning is what makes all of that checking actually happen instead of depending on someone remembering to run it. You set a cadence, the plugin runs the malware scan, the core check, and the tests in the background, and it emails when something has changed rather than when everything is fine. That last detail is the one that keeps it useful, because a tool that mails you a clean bill of health every single day quickly becomes a tool you filter into a folder and stop reading. Security Ninja's alerts arrive when there is a reason to look, so they keep their weight. On the agency side, a scheduled scan running quietly on every client site means the baseline monitoring is automatic, and the manual passes we still do become a confirmation step rather than the only line of defense. Two checks cover file integrity, and between them they answer most of the question of whether a site has been tampered with: - The core scanner compares the WordPress core files on the site, well over a thousand of them, against the official versions from WordPress.org, flagging anything modified, missing, or unexpectedly added. When a site comes to us already misbehaving, it tells me within a couple of minutes whether the core itself was altered, and I can restore the clean files from the official source rather than guessing. - The plugin integrity check validates plugins sourced from WordPress.org against their official released versions and lets you inspect the differences when files do not match. A modified plugin file is one of the more common ways a compromise hides, because it sits inside something legitimate rather than announcing itself. Both give me something specific to act on, a named file with a real difference, instead of a hunch I then have to spend an afternoon confirming. The core scanner is available in the free version too, which makes it a reasonable first-response tool even on a site we have not fully onboarded yet. Vulnerability monitoring is handled well, and the fact that it is a free feature rather than a paywalled one says something about how the product is positioned. The plugin keeps a list of known vulnerabilities, drawn from curated public sources including the National Vulnerability Database, with CVE identifiers and fixed-version information, and it compares that list against the plugins, themes, and WordPress version actually installed on the site. The detail I appreciate as someone responsible for other people's sites is that the comparison happens locally. The vulnerability list is downloaded to the site and the matching runs there, so the plugin is not shipping an inventory of every site's software back to a third-party server. For client work, where I would rather not be quietly building a remote database of what every client runs, that local-first design is the right call. The practical payoff is simple: when a plugin a client depends on gets a disclosed vulnerability, the plugin tells me, and it tells me before someone else finds it the hard way. The 50-plus security tests are the part of the product I used first, years ago, and they still earn their place. The plugin runs through a long checklist of common WordPress mistakes and risky settings, including: - File and folder permissions that are looser than they should be - Version disclosure that hands attackers free reconnaissance - Dangerous PHP configuration, and debug or auto-update settings left in the wrong state - An insecure default database table prefix - Exposed APIs and application-password settings - Leftover deactivated plugins and outdated software The free version explains each finding and tells you how to fix it manually. The Pro version adds one-click fixes for many of those findings, and it creates a backup before it touches anything sensitive. That backup-before-fix behavior is the reason I am comfortable letting it apply changes on a client site rather than insisting on doing every fix by hand. It turns a security audit, the kind of thing that used to mean a slow manual checklist or an expensive consultant, into a pass that takes a few minutes per site. Auto-fixing routine issues deserves its own mention, because it covers a long list of hardening steps that are tedious to do by hand and nearly impossible to do consistently across many sites. With a backup taken before each sensitive change, it will: - Change an insecure database prefix to something attackers cannot assume - Disable directory browsing so the file structure is not on display - Clear out unused themes and inactive plugins that only widen the attack surface - Adjust file permissions to safer values - Close off a number of known attack vectors On a single site, working through that list manually is a half hour of fiddly work that is easy to get slightly wrong, and a slightly wrong file permission can break a site as effectively as an attacker would. Across a client base it is the kind of task that simply does not get done the same way twice. Letting the plugin apply the routine fixes, while still showing me exactly what it changed and keeping a backup if I need to step it back, means the boring part of hardening actually gets finished. Login protection is solid and covers the area attackers hammer hardest. The pieces that matter most in our day-to-day work: - Rate limiting on failed logins with configurable thresholds, and automatic banning of addresses that keep guessing - Reduced username enumeration, so bots cannot easily harvest valid usernames to attack - Protection on the lost-password flow, another route that often gets ignored - Two-factor authentication using an authenticator app or email codes - The option to rename the login URL away from the default, so automated traffic mostly never finds the door For client sites where the client insists on a weak password despite our advice, the combination of 2FA and a renamed login URL is what lets me sleep, because the brute-force attempts mostly end before they begin. Onboarding a new client site is faster than I expected, and that comes down to three things working together: 1. The setup wizard walks a fresh install through running the tests, enabling the recommended fixes, and turning on the key protections, so you are not hunting through every settings screen on a site you just took over. 2. Import and export of settings means that once we have a security configuration we like, we apply the same policy to the next site instead of rebuilding it from memory. 3. For larger rollouts, dropping a license_key.txt file into the plugin package lets the license activate itself on install and then delete the file, so the copy-paste license routine disappears entirely. For an agency, consistency across sites is a security property in its own right, and these three things together are what make consistency cheap. The events logger is the tool I reach for when something has already happened and I need to reconstruct it. It records logins, both successful and failed, firewall events, scan activity, updates, file actions, and more, into a filterable log. When a client asks who changed a setting, or when I am trying to work out the sequence of events around a suspicious login, the log is where the answer lives. Filtered through the MainWP combined view it becomes an audit trail across the whole client base rather than a per-site curiosity, which is the version of it that actually saves time. When we want security events to leave the plugin and land somewhere the team already watches, the webhook support handles it. Security Ninja can fire webhook events for things like blocked visitors and login activity, and because they are standard webhooks they drop straight into Zapier or any system that accepts an incoming hook. We route certain events into the channel the team already monitors through the day, so a notable login or a sudden wave of blocked traffic shows up where a person will actually see it rather than sitting in a log waiting to be checked. It is not a feature every client site needs, and on the simpler accounts we leave it off, but for the higher-touch clients it closes the gap between the plugin noticing something and a human knowing about it. For the clients who run a shop, the WooCommerce protection is a smaller but welcome piece. It adds protection around the areas bots abuse on a store, the login and registration flows, abusive checkout and add-to-cart activity, and coupon brute forcing. It is not the headline reason to choose the plugin, but for an agency with a handful of ecommerce clients it means one less specialized plugin to source and maintain. And because it lives in the same plugin as the firewall and the scanner, the protection on the store and the protection on the rest of the site are configured and monitored in one place rather than across two separate tools. A more recent addition is the AI security advisor, which condenses the plugin's findings into a single readable security report. What I appreciate about how it was built is the restraint around data. It is designed as a privacy-conscious report that does not ship personal information off the site, and it can run through standard AI connectors or the plugin's own option, so you are not forced into one pipeline. For client communication it gives me a plain-language summary I can adapt into a maintenance update, rather than handing a client a wall of raw test output they will skim and forget. It is a good example of a newer feature being added in a measured way, solving a genuine communication problem. The pace of development is something I weigh heavily when I am deciding whether to standardize on a tool, and WP Security Ninja passes that test. The changelog moves at a real pace, there is a public roadmap and feedback portal where I can see what is being worked on and add requests, and the plugin has been maintained continuously for well over a decade. Support comes from the small team that actually builds the product, so when I have raised something specific it has been answered by someone who understands the plugin rather than a first-line script. More than one item on the roadmap, including deeper MainWP integration and the ability to push security reports to clients, is aimed squarely at the agency use case. Licensing is built for the way agencies actually buy. Rather than forcing per-site purchases, there are bulk packs at three sizes: - 25 sites, which suits a smaller studio or a freelancer with a steady client base - 100 sites, the tier most established agencies will land on - 500 sites, for larger operations managing a serious fleet Every bundle tier folds in the MainWP add-on and the white label module rather than charging separately for them, and one license key covers staging, production, and future migrations, so spinning up a client's staging copy does not eat into a separate allowance. For budgeting a maintenance practice, predictable per-site cost at volume is exactly what I want, and the bundle pricing makes the math easy to defend to whoever signs off on tools. One last thing worth saying is that none of this comes wrapped in an interface that fights you. The dashboard surfaces firewall status, pending updates, the security score, and vulnerability findings without making you dig, and the plugin stays light enough that it has not been a performance complaint on any client site we run it on. I have handed it to less technical colleagues and to clients who manage their own content, and they find their way around it without a training session. For a product that packs in this many modules, staying approachable is not a given, and Security Ninja manages it. The free version is considerably more than a teaser, and that shapes how we work more than I expected. The security tests, the vulnerability scanner, and the core scanner all run without paying anything, which means when a prospective client asks us to take a look at a site we do not yet manage, we can install the free plugin, get a real assessment in a few minutes, and base our recommendation on evidence rather than a polite guess. By the time that site moves onto a Pro license we already know what we are dealing with, and we have priced the work accordingly. A security plugin that gives you a genuine read on a site before any money changes hands is unusual, and it has quietly become a legitimate part of how we run intake rather than a locked demo we have to talk around.