Onsite Spam Guard

No. Every check runs on your own server. Nothing about a submission is sent anywhere outside your site.

No. All protection is invisible. The honeypot field is hidden, and the timing and behavioral checks happen in the background.

When a submission is blocked (and logging is enabled), the plugin records the guard that blocked it, the form context, the reason, a short excerpt of the content, the visitor IP address, and the browser user-agent. Entries older than the retention window (default 30 days, configurable; set to 0 to keep them indefinitely) are pruned automatically. The plugin also registers suggested privacy-policy text you can add to your site's policy.

By default the plugin uses the direct connection IP, because forwarded headers can be spoofed to bypass the allowlist. If your site sits behind a trusted reverse proxy, enable Trust proxy headers for IP detection under Spam Guard → Settings → Allowlist.

By default a blocked comment or review is placed in the spam queue (Comments → Spam) rather than being rejected outright, so you can restore a false positive with one click — nothing is lost. Open Spam Guard → Spam Logs to see which guard blocked it and why, then loosen that guard on the settings page — for example, raise the link limit, lower the behavioral threshold, or add the sender to the allowlist. If you would rather reject blocked comments with an error message, enable that option under Spam Guard → Settings → General.

Yes. Enable Rate limit on the Guards tab, then set the maximum number of submissions and the window they are counted over — 20 per hour and 5 per minute are both expressible. It counts per sender — the logged-in user where there is one, otherwise the connection IP — and each form type is counted separately. It is off by default, because on sites where many visitors share an address (an office, a school, or mobile carrier NAT) an IP-based limit can catch people who are not doing anything wrong. Set the maximum to 0 to disable it without turning the guard off.

No — it complements it. Onsite Spam Guard's guards run before WordPress's own comment checks, and those built-ins still run underneath: the duplicate-comment check, the comment flood throttle, the Disallowed Comment Keys blocklist, and the "hold a comment with this many links" setting (all under Settings → Discussion). Its Keyword, Link limit, and Duplicate guards overlap those, so you can rely on either or both. What it adds on top is the honeypot, timing, signature, and behavioral checks core has no equivalent for, one settings screen with logging, and protection for WooCommerce reviews and Jetpack contact forms — not just comments. You can also go the other way and put WordPress's list to work everywhere: enable Also apply WordPress's Disallowed Comment Keys on the Guards tab and the plugin runs every protected submission through core's own blocklist — so the list you already maintain under Settings → Discussion starts covering reviews, Jetpack forms, and any form added through the plugin's API, not only comments.

Yes. The timing and authenticity checks use a token whose signature does not expire (unlike a WordPress nonce, which would go stale on a cached page and block legitimate visitors), so full-page caching does not produce false positives.

By default, yes — deleting the plugin (not just deactivating it) drops its database table, removes all of its options, clears its scheduled task, and purges its transients, on every site of a multisite network. If you would rather keep your settings and logs (for example, before reinstalling), turn off Delete all plugin data when this plugin is deleted under Spam Guard → Settings → Logging first.