# Site Owner Guide

# What the plugin does

The Imunify Security plugin for WordPress shows the security status of your website directly in the WordPress dashboard. It reports what the Imunify security software on your hosting server found and cleaned, and it adds two protection layers that run inside WordPress itself.

You do not need to buy, download, or configure anything. The plugin works together with the Imunify product your hosting provider already runs on the server (ImunifyAV, ImunifyAV+, or Imunify360).

# Why the plugin is on your site

Your hosting provider installed the plugin for you, as part of the security service included with your hosting plan. This is why it appears in your plugin list without you installing it, and why you cannot find it in the WordPress.org plugin directory — it is delivered by the hosting server, not from the public repository.

# What it protects you from

• Malware. Infected files, injected code, and backdoors. The Imunify scanner on the server checks your files, and the plugin shows you what was detected and cleaned.
• Zero-day attacks and dangerous code execution. Attacks that use undisclosed vulnerabilities, and backdoors that are already on the site, run PHP code that no scanner has a signature for yet. Proactive Defense stops that code at the moment it tries to run.
• Exploits of known vulnerabilities in the plugins, themes, and WordPress core you use — including the time between a vulnerability becoming public and you installing the update. The Web Application Firewall (virtual patching) blocks the attempt without changing any of your files. See Web Application Firewall.
• Aggressive crawlers, scrapers, and AI bots that slow your site down, use up its resources, and copy its content. AI Bot Management limits them while leaving real visitors untouched. See AI Bot Management.

Which of these are available depends on the Imunify product your hosting provider runs. ImunifyAV and ImunifyAV+ users see a smaller set of features than Imunify360 users.

# Features

# Dashboard Widget

The plugin adds a dashboard widget that helps administrators keep track of their site's security status:

• Real-time security status
• Proactive Defense status
• Web Application Firewall status and recent WAF incidents (see Web Application Firewall)
• Bot Protection status and recent bot activity (see AI Bot Management)
• Timestamps for last and next scheduled scans
• Detailed list of detected and cleaned malware (file path, signature, detection or clean-up time)

Widget - no malware found

Widget - all malware cleaned

Widget - Imunify AV

Widget - Imunify not installed

# Notice

The plugin adds a notice to the WordPress admin dashboard for non-administrator users. This notice informs users about the security status of the website and provides a link to the Imunify360 dashboard for more information.

# Plugin Page

The plugin provides a dedicated page within the WordPress admin area where you can view more granular details about your website's security. Here, you can:

• See an overview of your site's protection status
• Access scan results and malware details
• Find recommendations for improving your site's security
• For ImunifyAV users, see information about upgrading to Imunify360 for additional features

Malware Scanner tab on the plugin page: view and manage detected threats.

Proactive Defense tab: monitor and configure proactive protection.

Malware Scanner as seen by ImunifyAV users.

# Upgrade Prompt

ImunifyAV users are shown a limited interface and prompted to upgrade to Imunify360 for full protection and advanced features.

Upgrade prompt encouraging users to switch to Imunify360 for more features.

# Web Application Firewall (Virtual Patching)

The Imunify Security plugin includes a Web Application Firewall (WAF) that provides virtual patching for WordPress. It protects your sites against known vulnerabilities (CVEs) in WordPress plugins, themes, and core — without modifying any of your site's files. When a plugin or theme you use has a known security flaw, the WAF blocks attempts to exploit it, giving you time to apply the real update.

# How it works

The Imunify agent regularly delivers an up-to-date set of virtual patches to each protected WordPress site. On every request, the plugin checks whether the request matches a rule for a component (plugin, theme, or core) that is actually installed on the site, and acts before the vulnerable code can run:

• In Imunify360, matching requests are blocked with an HTTP 403 response.
• In ImunifyAV and ImunifyAV+, matching requests are logged only — see Protection modes.

Every match is recorded as an incident. Because rules are matched only against the versions actually installed, protection adapts automatically as you install, update, or remove plugins and themes.

# Protection modes: Enabled vs Monitoring

The WAF works in one of two modes depending on your Imunify product. There is no manual switch — the mode follows the product:

In monitoring mode, the widget shows the message "Attacks are logged but not blocked. Upgrade to Imunify360 to enable full WAF protection." with an Upgrade now link.

# In the WordPress dashboard widget

The Imunify Security dashboard widget includes a Web Application Firewall row showing the current status (Enabled or Monitoring) and the number of recent incidents. Below it, a Latest incidents (7 days) table lists the most recent detections, together with the current ruleset version:

• Date — when the incident occurred
• Component — the vulnerable plugin, theme, or core
• CVE — the vulnerability the rule addresses
• Severity — severity of the rule
• Count — how many times it was triggered

Use Show more results to open the full incident list on the CMS WAF tab.

The Web Application Firewall row in the dashboard widget, showing Enabled with no recent detections (Imunify360).

When there are recent detections, the row shows the incident count (here, 34); expand it to see the Latest incidents (7 days) list.

In ImunifyAV and ImunifyAV+, the WAF runs in Monitoring mode with a prompt to upgrade.

# Managing WAF incidents

Open the Imunify Security page from the WordPress admin menu to review WAF activity and manage rules. Everything on this page applies to the site you are currently in.

# Incidents

The Incidents tab lists every request the WAF acted on:

You can filter incidents by date range, or search by rule, description, or IP. Click a row to expand it and see the Sensor, Rule, and Abuser (source IP) details.

The Incidents tab.

# Disabling a rule

If a WAF rule interferes with legitimate traffic, you can disable it. On the Incidents tab, click Disable rule for the incident, then click Yes, disable to confirm. The rule is turned off for your site. The change may take a few minutes to take effect.

Confirming that a WAF rule should be disabled.

# Disabled Rules

The Disabled Rules tab lists the rules you have turned off, showing the affected Component, Version, and Rule. To turn a rule back on, click Enable and confirm.

Re-enabling a previously disabled rule.

# Turning the WAF on or off

Your hosting provider decides whether the WAF runs on the server, and can turn it on or off for individual hosting accounts. If you need it changed for your site, contact your provider. See Web Application Firewall in the hosting provider guide.

# AI Bot Management

Imunify Security includes AI Bot Management — a layer that identifies automated traffic (search-engine crawlers, AI/LLM crawlers, scrapers, and malicious bots) before WordPress finishes loading and applies a per-minute request limit to each kind of bot, while leaving real visitors untouched. It protects sites from aggressive crawling and bot-driven resource abuse — increasingly from the wave of AI training and scraping crawlers — without slowing down legitimate users.

# How it works

The feature runs as a must-use plugin, so it evaluates each request before the rest of WordPress (and other plugins) load. For every request it:

1. Classifies the visitor into one category — a verified search engine, a verified AI crawler, an unknown automated client, an unverified bot, a malicious bot, or a human. Clients that claim to be a known crawler (for example, Googlebot) are confirmed by forward-confirmed reverse DNS, so a spoofed user-agent does not earn a crawler's higher limit.
2. Applies the category's limit. Each non-human category has a requests-per-minute allowance set by the active preset. Requests over the limit are refused with HTTP 429 (Too Many Requests) and a Retry-After hint; malicious bots are blocked outright with HTTP 403 (Forbidden). Clients that keep exceeding their limit can be escalated to a temporary block.

Human visitors are never rate-limited. The check is fail-open: if anything goes wrong (for example, the backing storage is unavailable), the request is allowed through, so the feature can never take a site down.

# Bot categories

# Protection presets

The active preset decides the per-minute limits. Balanced is the default.

• Balanced — sensible limits for a typical site. Recommended for most sites.
• Strict — tighter limits for sites under heavy bot pressure.
• Monitor only — classifies traffic but does not block or limit anything. Useful for trying the feature out before enforcing it.

# In the WordPress dashboard widget

Once your hosting provider has enabled AI Bot Management, the Imunify Security dashboard widget shows a Bot Protection row with the current status, the active preset, and the number of requests blocked in the last 24 hours.

The Imunify Security dashboard widget. The Bot Protection row shows the active preset and the number of requests blocked in the last 24 hours.

Click the row to open the detail pane, where you can:

• see the current Status and Blocked (24h) count;
• view the active preset and its live Rate limits (requests / minute) table, and switch preset with change → Save;
• turn protection off for this site — or back on.

The detail pane: status, the 24-hour blocked counter, the preset picker, and the per-category rate limits for the selected preset.

Only WordPress administrators (users who can manage options) can change these settings.

# Turning it on or off

AI Bot Management is controlled at three levels:

1. Hosting provider (server-wide). The provider enables the feature and sets the default preset. When it is off at the server level, the Bot Protection row does not appear. See AI Bot Management in the hosting provider guide.
2. Site owner (WordPress admin). Once the provider has enabled it, the WordPress administrator turns it on or off for their own site and chooses the preset from the Bot Protection widget.
3. wp-config.php (advanced). Definitions in wp-config.php override the widget:

// Force AI Bot Management off for this site (overrides the widget):
define( 'IMUNIFY_AI_BOT_PROTECTION', false );

// Force a specific preset (balanced | strict | monitor):
define( 'IMUNIFY_AI_BOT_PROTECTION_PRESET', 'strict' );

When AI Bot Management is disabled in wp-config.php, the widget shows Disabled in wp-config.php and the controls are locked.

# Frequently asked questions

# Why did the Imunify Security plugin appear on my site? I did not install it

Your hosting provider installed it for you. The Imunify security software on the server adds the plugin to the WordPress sites it protects, so you get the security information of your site inside the WordPress dashboard. It is part of your hosting plan, not something you bought or downloaded.

# Why is the plugin not in the WordPress.org plugin directory?

The plugin only works together with the Imunify software running on the hosting server, so it is delivered by that software instead of the public directory. This is also why it is updated automatically, without an update notice in WordPress.

# Do I have to pay extra for the plugin?

No. It is included in the Imunify security service your hosting provider already runs. Some features depend on which Imunify product your provider uses — see Protection modes.

# Can I deactivate or delete the plugin? Will it come back?

Yes, you can deactivate or delete it like any other WordPress plugin.

Deleting it also removes the data it stored for your site. A job on the server does this clean-up once a day, so it can take up to 24 hours. The same job records that you removed the plugin, so the server does not install it again by itself.

If you want the plugin back later, ask your hosting provider — they can restore it for your site.

Deactivating or deleting the plugin turns off the protection it provides inside WordPress — the Web Application Firewall and AI Bot Management stop working for your site. Malware scanning on the server continues, but you no longer see the results in your WordPress dashboard.

# Does the plugin slow down my website?

The plugin is built to keep the work inside WordPress small:

• Malware scanning runs on the server, not inside WordPress.
• The Web Application Firewall only loads rules for the plugins, themes, and WordPress version you actually have installed.
• The bot check runs before the rest of WordPress loads. It costs very little compared to building the page for that visitor, so every request it blocks saves your site far more work than the check itself uses.

# Do I still need my other security plugin?

Imunify Security does not replace a general-purpose security plugin, and it does not require you to remove one. It adds protection layers that run on the hosting server and inside WordPress. If you run another security plugin, both may report the same event, so check both before you decide something is wrong.

# Does the plugin work on a WordPress multisite network?

Multisite is only partly supported today, and it has not been fully tested. Some features may not behave as described on a multisite network, so do not rely on the plugin as your only protection there.

# Where do I manage the settings?

It depends on the setting:

• In the WordPress dashboard, the Imunify Security widget shows the security status, and lets WordPress administrators change AI Bot Management for the site.
• On the Imunify Security page in the WordPress admin menu, you review WAF incidents and disable individual rules for your site. See Managing WAF incidents.
• Some settings are controlled on the server and cannot be changed from WordPress. If a control is missing or locked, see Why do I not see the Web Application Firewall or Bot Protection in the widget?.

# What information does the plugin send?

The plugin reads the security information of your site from the Imunify software running on the same server, over a local connection that does not leave the machine. It does not send your site's files, database, or page content anywhere.

To keep protection current, it downloads updated data, such as the list of known crawlers used by AI Bot Management.

Imunify also collects security information from your site to improve protection:

• WAF incidents — the exploit attempts the Web Application Firewall acted on. A record includes the rule that matched, the IP address the request came from, and partial details of the request.
• Traffic classification summary — once a day, how much traffic fell into each bot category, together with the 50 most active IP addresses per category. This data is used only to make the classification more accurate and to identify sources that abuse sites.

If your hosting provider has enabled error reporting, technical error reports may also be sent to Imunify.

# A visitor to my site got an error page. What happened?

Two protections can refuse a request:

• HTTP 429 (Too Many Requests) — AI Bot Management refused a request from an automated client that went over its per-minute limit. Real visitors are never rate-limited.
• HTTP 403 (Forbidden) — either the Web Application Firewall matched the request against a known vulnerability in a plugin, theme, or WordPress core, or AI Bot Management blocked a client that kept sending requests after it was already refused with HTTP 429. See Managing WAF incidents to check what the WAF blocked and why.

# A WAF rule blocks legitimate traffic. How do I stop it?

Open the Imunify Security page in the WordPress admin menu, go to the Incidents tab, find the incident, and click Disable rule. The rule is turned off for your site — there is no list of domains to choose from, because the page only covers the site you are in. The change may take a few minutes to take effect.

If the traffic is still blocked, wait a few minutes and clear any page or object cache your site uses, then try again — the old response may still be cached. If it keeps being blocked after that, ask your hosting provider.

# Bot Protection blocks something I need. How do I stop it?

Real visitors are never rate-limited, but a tool that calls your site — an uptime monitor, a backup or SEO service, or a plugin that fetches pages — is an automated client, so it can be refused with HTTP 429.

Open the Bot Protection row in the Imunify Security dashboard widget and choose one of these:

• Switch to a softer preset. Click change, pick a preset, and click Save. Monitor only still classifies traffic but does not block or limit anything, which is the quickest way to confirm that Bot Protection is the cause.
• Turn protection off for this site. The row has a switch that disables Bot Protection for your site only. You can turn it back on at any time.

See Turning it on or off for the wp-config.php settings that override the widget, and Protection presets for what each preset allows.

If the Bot Protection row is missing, see the next question. If the controls are locked, the feature is set in wp-config.php — see Turning it on or off.

# Why do I not see the Web Application Firewall or Bot Protection in the widget?

A row is missing when the feature is not running for your site. There are two reasons for that:

• The software is older than the feature. Both features need recent versions of the plugin and of the Imunify software on the server. See Requirements for the exact versions.
• The feature is turned off for the server or for your hosting account.

Both are set on the server, so only your hosting provider can change them.

# The widget says my site cannot reach itself. What does it mean?

WordPress needs to be able to open its own address over HTTP to run scheduled tasks. When it cannot, scheduled tasks — including automatic updates of the bot data — may not run. This is usually caused by a local DNS or firewall setting on the server. Report it to your hosting provider, then click Re-check.

# Something is not working. What can I do?

Most of what site owners run into can be fixed from the WordPress dashboard, without any help:

• A visitor got an error page — see A visitor to my site got an error page.
• A WAF rule blocks legitimate traffic — you can disable that single rule for your site. See A WAF rule blocks legitimate traffic.
• Bot Protection blocks a tool you use — you can switch to a softer preset, or turn it off for your site. See Bot Protection blocks something I need.
• A feature is missing from the widget — see Why do I not see the Web Application Firewall or Bot Protection in the widget?.

A few things are set on the server, and only your hosting provider can change them: enabling a feature for your hosting account, restoring the plugin after you delete it, and anything about malware found outside your WordPress files.