WP Security Ninja deal archive

The $69 lifetime deal recorded on this page is archived, and the checked offer source says it is sold out. That does not mean the product has disappeared. It means a historical promotion should not be presented as something a new buyer can necessarily purchase today. This review remains useful if you already hold a license, are evaluating the current product or want to understand whether the old bargain would have solved the problem you actually have.

WP Security Ninja is a WordPress plugin, not a general security layer for every website framework. Its documented jobs include checking software risks, inspecting files, filtering certain requests and recording relevant activity. Those jobs can help an owner or agency maintain a WordPress installation more deliberately. They do not replace the host's responsibilities, reliable backups or someone capable of investigating an incident when the evidence becomes uncomfortable.

The strongest buyer is a person with a maintenance process, even a modest one, who wants clearer information and fewer forgotten checks. A plugin can make an issue visible; it cannot ensure that someone updates an abandoned component, reviews an unexpected administrator account or restores a damaged store. Buying a security tool without assigning that work is rather like installing a smoke alarm and putting the batteries in a different department.

Our assessment uses current vendor documentation checked on October 24, 2026. It is not a penetration test, an independent malware-detection benchmark or a report from a purchased deployment. The practical scenarios are proposed evaluation steps for an authorized site. We separate published capability from our own operating advice so you can judge the product without mistaking a reassuring feature name for evidence that your particular installation is protected.

The current direct price is $119 per year for one site. The page also shows $259 for five sites, $599 for twenty-five and $1,699 for one hundred, billed annually. Its fourteen-day Pro trial requires a card or PayPal and becomes annual billing if not cancelled in time. These are current published terms, distinct from the archived lifetime promotion. Verify the final checkout and your actual site count before committing.

Start by inventorying existing protection. Your host may already provide some monitoring or request filtering; another plugin may already handle login controls. Identify the missing job before adding overlapping systems. Two tools attempting to manage the same access rule can create confusing behavior, and a larger collection of security badges does not automatically make the system easier to operate. The useful comparison is coverage, evidence and maintenance effort, not the number of shields in the administrator menu.

The current feature split gives Free users security tests, known-vulnerability checking, core integrity and basic filtering. Pro adds areas such as malware scanning, stronger access controls and scheduled monitoring. That makes the free version a reasonable way to examine the style of findings before deciding which paid capability is needed. Do not infer that a free scan is the same thing as continuous staffed monitoring or that a Pro license removes the need to review its results.

Agency branding deserves a separate entitlement check. Today's pricing places white label at twenty-five or more sites, while older offer material mentions a different threshold. Existing lifetime buyers should use their own license terms and support confirmation, not assume the current subscription page rewrites their purchase. New buyers should not borrow an old entitlement from an archived campaign. A careful licensing question is less expensive than building a client service around a feature your account cannot use.

Known-vulnerability checking asks whether installed software matches a published weakness. Integrity checking asks whether files differ from trusted originals. Malware scanning looks for patterns or structures that deserve investigation. These are complementary questions, not three names for the same certificate of cleanliness. Understanding the difference helps you respond correctly instead of treating every warning as proof of an active compromise or every clean result as permission to stop paying attention.

Imagine a hypothetical site with an outdated plugin that has a known issue but unchanged files. A vulnerability warning could be important even though integrity checks find no modifications. Now imagine an unexplained file change in otherwise current software. That deserves attention even if the version database reports no known weakness. Finally, legitimate custom code can resemble a suspicious pattern without being malicious. The right response depends on which evidence produced the finding.

Make the result actionable by recording the affected component, the type of evidence, its business role and the next owner. An available update, an unexpected modification and an uncertain custom file lead to different investigations. Do not collapse them into a single task called make the score green. A numerical summary can help organize attention, but it cannot decide whether deleting a file will remove an infection or remove the checkout your customers were using five minutes ago.

Our illustration separates these checks because the distinction is central to the buying decision. If your main need is awareness of vulnerable dependencies, compare the documented vulnerability workflow. If you need suspicious-file review, examine the scanner and the practical expertise required. If you need recovery from an existing incident, assess the whole response process. Buying the broadest feature list is less useful than knowing which question must be answered and what you will do with the answer.

Core Scanner compares the relevant WordPress files with official checksums for the installed version and locale. The guide covers modified, missing and unexpected files, with severity labels and a viewer for inspecting differences. That gives a maintainer a concrete starting point: a specific file differs from the expected distribution. It is considerably more useful than a vague warning that the site feels risky, but it still requires an explanation for the difference.

Some differences are expected. The documentation recognizes site-specific configuration and certain files that may legitimately be absent. It also distinguishes lower-risk notices from more significant findings. Do not assume every deviation has the same meaning or that the badge count describes the entire environment. Check the context, when the change appeared and whether a known maintenance action explains it. When the reason is unclear, preserve evidence and investigate rather than dismissing the item to improve the dashboard's appearance.

Restoring an altered core file from a trusted source can be an appropriate repair, but make that decision with a recoverable backup and an understanding of the site. If someone previously customized core directly, restoration may remove that customization as well as an unwanted change. That does not make direct core modification a good practice; it means the repair should include understanding why the modification existed and moving legitimate behavior to an appropriate supported extension point.

During evaluation, ask whether the findings are clear enough for the person who will maintain the site. Can they locate the relevant difference, identify the trusted source and record the chosen action? A scanner that produces technically accurate but operationally abandoned findings has limited practical value. The objective is a defensible explanation and a verified result, not simply clearing a list before a client sees it. Keep the distinction between a clean comparison and a complete security assessment explicit.

The malware guide describes different methods for different material. Repository plugins can be compared with official checksums, while custom or premium plugins without those checksums use other review methods. Structural warnings are distinguished from signature matches. That distinction matters for agencies running bespoke code: an unfamiliar folder structure is not automatically a confirmed infection, but the fact that a developer recognizes the project name does not automatically explain every file inside it either.

The vendor's false-positive guidance explicitly warns against deleting a file merely because it is flagged. Legitimate code can contain patterns a scanner is looking for. Our recommended review begins with provenance: where did the file come from, which trusted release should it match and what changed? Preserve a copy securely before a repair, and ask a qualified maintainer when the evidence is ambiguous. The cost of a mistaken deletion can be immediate even when the original warning was only tentative.

Do not evaluate a scanner by demanding that it either finds everything or never produces an uncertain result. A useful assessment examines whether findings are understandable, whether the review tools support a sensible decision and whether the operator can distinguish different confidence levels. This review provides no measured detection or false-positive rate. Without a controlled independent evaluation, numerical claims about catching attacks would be decoration rather than evidence.

For an ordinary buyer, the practical question is who handles the first difficult result. If the answer is nobody, budget for help or choose a service arrangement with an explicit response scope. A plugin license can provide valuable tools while leaving the hardest judgment to the site owner. That is not inherently a flaw, but it should be part of the purchase decision. Security software becomes much less mysterious once the responsibility for its output is written next to the feature list.

Security Ninja distinguishes an individual whitelisted file, stored with its path and hash, from a path pattern that excludes matching material from scans. The latter is broader: the documentation says excluded paths are neither scanned nor reported. That is an important tradeoff, not a harmless cosmetic preference. A quiet report after excluding a large folder may reflect less inspection rather than an improvement in the underlying site.

Use the narrowest justified exception and record why it exists. A reviewed file from a trusted release is a different case from an entire custom-plugin directory that will continue changing. Decide who will revisit the exception after updates or development work. Otherwise a temporary solution to a false positive can become a permanent blind spot that nobody remembers adding. The scanner cannot warn about material you have deliberately told it to stop examining.

For a hypothetical agency project, an exception record might name the component, the reviewed release, the reason for the match and the date of the next review. It should not contain public copies of sensitive code or credentials. Keep it with the maintenance record so the next technician understands the decision. This is our operating recommendation, not a claim that the plugin automatically manages an exception approval lifecycle for you.

Evaluate the workflow with the developer responsible for custom components. Can a suspicious result be compared with a known-good build? Can you remove an obsolete exception without losing the reason it was created? Avoid solving every warning by adding another broad pattern. A security report that is always empty because almost everything is excluded is wonderfully peaceful and not especially informative. The goal is a manageable set of meaningful findings, with the scope of the scan still honest and useful.

The vulnerability guide says installed software is compared locally against a downloaded list of known issues. It says this check does not send the site's vulnerability details back to the vendor. That is a specific description of this feature's data flow, not a blanket statement about every integration or AI feature in the product. It also makes the scope clear: matching known weaknesses is different from discovering every possible unknown defect in custom code.

When an alert appears, identify the affected version and whether a maintained fix is available. Plan a safe update with a backup and a check of the site's important behavior. If no suitable fix exists, the next decision may involve replacing the component or reducing exposure with qualified help. Do not assume enabling a firewall automatically removes the need to address the vulnerable software. A warning that remains open indefinitely is a maintenance decision, even when nobody formally made it.

Prioritize according to the actual component and business impact rather than treating every notification as equally urgent. A plugin used in checkout, an abandoned extension and a low-impact optional feature may require different migration planning. Record the owner and next review date for an unresolved item. This prevents the familiar situation in which everyone has seen the warning, everyone assumes someone else is handling it and the only reliably updated element is the notification count.

The useful buying test is whether this process makes dependencies easier to maintain. Can the team understand the alert, locate the relevant update and verify the repair? Can it identify components that should no longer be installed? A known-vulnerability scanner supports those decisions but does not perform the organizational work by itself. Keep a separate inventory of essential software and its maintenance owner so the next warning arrives in a system prepared to act, rather than in a dashboard prepared only to display it.

The firewall guide states that the Pro firewall is not automatically enabled merely by installing the plugin. It deliberately introduces a recovery step before activation. That is useful information for both sides of the evaluation: do not assume installation means the intended controls are active, and do not rush through activation without understanding how to regain access if a rule affects legitimate traffic. A security rollout is still a production change.

The documented stack combines request-pattern rules with downloaded IP intelligence and additional access controls. Treat those as specific mechanisms, not a promise that every malicious request will be recognized. In particular, the phrase Cloud Firewall should not be used to assume that the license includes an independently hosted traffic-absorption service or protection for every layer of the server. Clarify responsibilities with the host and retain whatever network-level controls the environment requires.

Before changing anything, record the current working paths: administrator login, customer login, contact forms, checkout, payment notifications and necessary integrations. Establish a recoverable backup and a maintenance window appropriate to the risk. Enable a limited set of controls, then test those paths. If a legitimate action fails, identify the responsible rule and use the narrowest appropriate correction with the maintainer, rather than disabling unrelated protections or blindly adding broad exceptions.

Evaluate the quality of the failure evidence as well as the happy path. Can you explain why a request was blocked and distinguish that from an application error or a host-level rejection? A clear explanation shortens support work and reduces the temptation to switch off the whole security layer. The objective is a functioning, maintainable site with meaningful protection, not a locked building whose impressive security statistics are mostly the result of nobody being able to enter.

The visitor-IP guide addresses a practical deployment issue: behind a reverse proxy or load balancer, the address initially visible to PHP may belong to the intermediary rather than the visitor. Security Ninja uses its resolved address for several controls and logs. If that resolution is wrong, the product can group unrelated people together or attribute events to the wrong source. That affects both blocking decisions and the evidence you use to investigate them.

The documented Automatic mode restricts when forwarded address information is trusted, using recognized Cloudflare proxies or configured trusted proxy ranges. The guide warns that explicit forwarded-header modes trust those headers on every request and should not be used where untrusted clients can reach PHP directly. Ask the host or system administrator to verify the actual network path instead of choosing a setting solely because its preview happens to display an expected-looking address.

For an authorized rollout, compare the resolved address and observed logs using a small set of legitimate test requests. Confirm that the configuration describes the proxy you control, not an enormous range of public visitors. Also consider shared networks: even a correctly identified public address may represent several legitimate users. Rate limits based on that address need to fit the site's audience and should not be tuned using the assumption that one address always equals one person.

This detail is an argument for careful setup, not a reason to avoid the product. It shows why security tools cannot be evaluated entirely from their menus. The same setting can be sensible in one hosting arrangement and inappropriate in another. Include proxy configuration in agency handovers and revisit it after hosting or CDN changes. A migration that preserves the pages but changes the request path can quietly invalidate assumptions that appeared settled when the firewall was first installed.

Security Ninja Pro documents authenticator-app and email-code methods, required roles and an enrollment grace period. Leaving all required roles unselected makes enrollment optional. That means an enabled feature is not proof that every administrator must use it. Decide which roles need the control, communicate the enrollment process and verify a representative account before enforcing the requirement broadly. A setting that nobody has completed is not the same thing as a working authentication policy.

Recovery deserves the same attention as enrollment. The secret access URL can whitelist the current visitor address and temporarily deactivate 2FA after a lockout. It is therefore sensitive access material, not an ordinary bookmark for a shared project document. Store it securely for each site, restrict who can retrieve it and keep access available outside the affected WordPress login. The guide says this secret is not included in settings import and export, so copying configuration does not copy the recovery plan.

Our recommendation is to establish an authorized recovery owner and document what must be checked after recovery is used. Restore the intended controls, inspect the relevant event evidence and confirm that normal access works again. Do not leave a temporary relaxation in place simply because the immediate support call has ended. Avoid putting recovery links into screenshots, broad email threads or unverified support conversations, where their convenience can turn into an unnecessary access risk.

For a client handover, explain the difference between an administrator's normal login, their second-factor method and the exceptional recovery route. Confirm who remains responsible when staff leave or devices change. None of that requires turning a small website into an enterprise identity project; it requires avoiding a single person's memory as the only recovery mechanism. A modest, tested process is more useful than strict settings accompanied by the hope that nobody will ever lose access.

The WooCommerce guide describes rate limits for checkout, cart actions and order placement, plus a limit on repeated invalid coupon attempts. It explicitly recommends testing a normal order and valid coupon after configuration. That is the right commercial perspective: abusive activity should become harder without making a legitimate customer's second attempt look suspicious merely because the first payment failed or they corrected an address.

Default limits are starting values, not a model of every store's customers. A busy sale, shared office network or mobile connection can create patterns different from a quiet demonstration site. Review real behavior with the person responsible for the store and adjust narrowly where justified. Do not automatically interpret more blocked requests as more money saved. Some blocks may be useful; some may be customers who were trying to give you money until the store decided they were too enthusiastic.

A sensible authorized test uses the payment provider's appropriate test mode or another agreed nonconsequential route. Check adding items, correcting quantities, applying a valid coupon, recovering from an ordinary form error and reaching the expected order state. Confirm that necessary payment notifications and integrations continue working. The point is to verify the purchase journey, not to perform real charges or stress a production account merely to see a counter increase.

Keep the resulting evidence tied to the configuration change. If support later reports a checkout problem, compare the timing and logs before blaming the customer or the payment provider. Establish a route for investigating mistaken blocks promptly, with appropriate authorization for any temporary change. The plugin can contribute to protecting a store, but the owner still needs a service process for legitimate users. Availability and security should be evaluated together because a store that cannot accept valid orders has not met its business purpose.

The Events documentation separates basic Free logging from broader Pro records and reporting. Pro webhooks can send selected new events to an approved destination, and the guide says older log rows are not replayed when the feature is enabled. That makes activation a starting point for future delivery, not a way to reconstruct a missing external history. Confirm what is being recorded and when the receiving process begins before relying on it for incident visibility.

Choose a small set of actionable alerts and name the person responsible for each. A new administrator, an unexpected configuration change and a routine blocked request should not necessarily produce the same response. Define what needs immediate attention, what belongs in a digest and what is retained mainly for investigation. Otherwise the team learns that every notification looks urgent, which is an efficient way to make none of them feel urgent after a week.

Verify delivery using a harmless authorized event. Check the source record, the receiving destination and the person or queue that should own the next step. Review the payload before sending operational information into a third-party chat or automation service, and keep destination credentials private. The absence of an email or message is ambiguous until you know whether there were no events, the rule excluded them or the delivery path failed.

Our illustration shows detection, review, repair and verification as separate stages. That is a proposed human-led response process, not a claim that the plugin automatically resolves every finding. A useful alert should make the next decision easier: what happened, what evidence supports it and who will act? Measure the monitoring feature by whether it improves that process, rather than by how successfully it fills a mailbox that everyone has learned to filter out of sight.

Scheduled Scanner is a Pro capability, with documented recurring checks and email reporting. The related scheduling guide explains an important WordPress dependency: ordinary WP-Cron is triggered through site activity rather than acting as an independent server clock. Low traffic, blocked loopback requests or resource limits can affect timely completion. A schedule selected in the interface is therefore an intention that should be checked against evidence of completed work.

Ask the host or maintainer how background tasks are triggered in the actual environment. Do not blindly disable WordPress's normal trigger without first establishing and verifying a suitable replacement. The correct arrangement depends on hosting access, existing jobs and other plugins that also rely on scheduling. A change made to improve security scans should not accidentally stop scheduled posts, order-related work or backups elsewhere on the site.

During a pilot, record when a scan is expected, when it finishes and whether the result reaches its intended owner. Include a quiet period rather than testing only while repeatedly visiting the administrator pages. Watch the site's resource use and important customer flows during scanning. This review makes no claim about measured performance overhead; the right evidence comes from representative workloads on a comparable installation, not from an attractive phrase such as lightweight.

Choose a cadence that the site can sustain and the team can act on. A high-frequency scan that repeatedly times out is not necessarily more protective than a completed routine with prompt follow-up. Likewise, a long gap may be unsuitable for a frequently changing store. Keep completion evidence and investigate stale results. The most useful monitoring question is often not whether the schedule is enabled, but when someone last verified that the promised work actually happened.

Events and visitor logs have separate retention controls. The current Events guide offers day-based or record-count choices and notes that selected security events may be kept longer. The visitor-log guide describes a shorter set of day choices with daily cleanup. Do not assume one setting governs every record. Decide what evidence the maintenance process needs and check the relevant module rather than treating retention as a single universal switch.

Longer retention can help an investigation, but it also increases stored data and database work. Restrict access to logs, understand what they contain and choose a period appropriate to the business and its obligations. This review is not legal advice or a compliance certification. If a customer has contractual retention requirements, confirm that the configured product and any exported copies meet them before promising a particular policy.

The Events settings warn that REST API error logging can create substantial noise on API-heavy sites and that event-count email reports can become frequent. Enable diagnostic detail for a purpose, with a plan for reviewing and adjusting it. A large table is not automatically a better audit trail if useful events become hard to find or the site spends excessive effort recording expected failures. Capture enough to explain meaningful behavior without treating every available switch as a requirement.

Preserve relevant evidence before destructive cleanup. Export only to an approved location and distinguish a routine retention cycle from deleting records during an unresolved incident. For an agency, include log ownership and access in the handover so the client knows what remains after the service relationship changes. The goal is evidence that supports decisions and recovery, not an ever-growing archive that nobody understands until the database becomes the next maintenance problem.

One optional setting disables WordPress's built-in sitemap. The vendor's guide frames this around an existing replacement, such as an SEO plugin or an external sitemap workflow. That is a specific configuration choice, not a universal rule that public sitemaps are bad. Before disabling the core version, identify the authoritative replacement, check that it serves the intended URLs and confirm that search tooling points to the working source.

The same principle applies to crawler access. Security Ninja documents recognition of legitimate crawlers, but a documented recognition mechanism is not proof that every relevant request reaches your site through your particular hosting stack. After changing access rules, check important pages, assets and the sitemap through appropriate search-engine diagnostics. Investigate mistaken blocks using actual evidence rather than simply allowing any request that claims a familiar crawler name.

For an ecommerce site, include product pages and their required images in that verification. A human administrator remaining logged in can see a healthy page while an unauthenticated visitor or crawler encounters a block. Test the audience that matters, not just the browser session that already has privileged access. Keep redirects, canonical choices and indexing directives conceptually separate from firewall decisions so a search problem can be traced to the correct layer.

Our recommendation is to treat each hardening suggestion as a decision with a purpose and a validation step. Do not apply a batch of changes solely to maximize a score, then discover that feeds, integrations or discovery routes were part of the collateral damage. Security and discoverability are not automatically opposing goals. A well-operated public site should expose the content intended for visitors while protecting the controls and data that are not intended to be public.

The MainWP guide describes copying an allowed set of settings from a synchronized Pro child to selected targets, with version requirements and a preview of differences. It also treats lockout-prone options separately. This is useful for an agency that wants a common baseline, but it is not an invitation to declare every client's hosting, authentication and checkout requirements identical. Central administration increases the reach of a correct decision and the reach of a mistaken one.

Start with a representative noncritical site and a limited group of changes. Review the differences, confirm target compatibility and verify the result after synchronization. The guide notes that newer settings require newer child versions and that some remote changes can affect scheduling or configuration. A successful dashboard action should therefore be followed by confirmation on the target, not interpreted as proof that every requested setting was understood by every installation.

Keep site-specific exceptions explicit: trusted proxies, customer geography, login arrangements, custom code and essential integrations can legitimately differ. Protect recovery material separately for each site. If you standardize a setting, record the reason and the assumptions behind it so a future host migration or client requirement can trigger a review. A copied configuration without those assumptions is an efficient way to distribute yesterday's answer to tomorrow's different problem.

For commercial care plans, separate the plugin license from the service promise. Who updates software, reads findings, handles a lockout and responds outside ordinary hours? What happens when a client leaves? White-label presentation can make a service feel cohesive, but it should not obscure who supplies the underlying tool or what work your agency actually performs. Sell a defined maintenance outcome supported by evidence, not the impression that purchasing enough licenses has created a fully staffed security department.

The documented AI Security Advisor requires WordPress 7 connectors and a configured provider. Its role is to turn existing security findings into a readable report, not to provide an independent penetration test. Treat it as a way to organize and explain evidence you already have. A fluent paragraph cannot establish that an unscanned area is clean, that a false positive is harmless or that an unfinished repair has somehow become complete.

The report-data guide describes a structured summary containing test statuses, feature flags and aggregate activity, with a preview before sending. It says identifying details such as domains, addresses and usernames are excluded from that input, and that generated reports remain in local history. Those are vendor-documented behaviors, not the result of an independent privacy audit here. Review the actual preview and provider arrangement before using the feature for a client's site.

Keep provider cost, data handling and permission separate from the plugin's feature entitlement. An available AI button does not mean external processing is free or automatically appropriate for every customer. Agree on the use case and the approved provider, then compare the report with the underlying findings. If a recommendation lacks enough context to act safely, use it as a question for the maintainer rather than as an instruction to change production settings immediately.

A useful report should help a nontechnical owner understand the next decision: what needs attention, why it matters and what remains uncertain. It should not convert every warning into a dramatic threat or every green result into a guarantee. Our preference is a short prioritized explanation tied to concrete evidence, with a human accountable for the repair. The site does not become safer because its risk has been described in more elegant sentences; the value arrives when the explanation leads to appropriate action.

Our editorial assessment is 79 out of 100: 18 for problem fit, 17 for capabilities, 15 for workflow, 14 for evidence and 15 for value. The documented tools address complementary WordPress maintenance jobs and expose useful operational details. The absence of hands-on performance or detection measurements limits what we can conclude. This is an independent buying assessment based on documented fit, not a converted customer-review average or a probability that a site will avoid an incident.

For an already compromised site, do not confuse installing the plugin with completing recovery. The vendor's cleanup guidance includes preserving the current state, investigating the entry point and examining more than isolated files. A qualified response may also need database review, account and credential work, trusted replacements and continued observation. Seek appropriate professional help when the incident exceeds your ability to investigate safely. A clean-looking report after removing one obvious file is not proof that the underlying cause has been resolved.

For an uninfected site evaluating maintenance, begin with a small authorized rollout and written acceptance criteria. Confirm essential customer flows, useful findings, completed scans and delivered alerts. Verify that recovery is available and that someone can explain what each warning means. Compare the annual license and maintenance effort with the gap in your current setup. Avoid claiming a return based on imaginary prevented attacks; use observable improvements such as fewer missed updates or clearer incident evidence.

Choose WP Security Ninja when its verified capabilities make that process easier and the responsible person will act on the results. Keep the free option in consideration when it covers the current need, and evaluate current Pro terms separately from this archived promotion. Look elsewhere or add a defined service when you need managed response, infrastructure protection or expertise the plugin cannot supply. The best outcome is not a dashboard that always looks calm. It is a site whose owners know what is happening, can respond proportionately and can recover when something goes wrong.