IniLerm

Hi @cousineddie,

Thanks for reaching out! That is unusual, as we test extensively with Site Kit, but valid requests can sometimes be flagged depending on strictness levels and server variables.

If disabling the plugin fixes the connection instantly, it confirms that one of our security modules (likely the WAF, Bot Protection, or REST API hardening) is blocking the background requests Site Kit makes to Google.

The Solution (Safe & Quick): Instead of disabling security checks globally, the best practice is to create a specific “Allow” rule for Site Kit traffic. This keeps your site secure while letting Google do its job.

Go to Security > Blocking Rules > Advanced Rules.
Click Add New Rule.
Configure it as follows:
Name: Allow Site Kit
Condition 1: Request URI CONTAINS google-site-kit
Condition 2: ASN EQUALS AS15169 (This is Google’s unique network identifier)
Action: Allow (Bypass Security)
Click Save Rule.
This tells the firewall: “If a request comes from Google’s network AND is specifically for Site Kit, let it pass.”

Diagnosis (Optional): If you want to know exactly what triggered the block:

Re-enable Advanced IP Blocker.
Trigger the Site Kit error again.
Go to Security > Logs & Sessions > Security Log.
Look for a “Blocked” entry at that exact time. The “Reason” column (e.g., WAF: SQL Injection, Fake Crawler, Protocol Violation) will reveal exactly why the plugin stopped the request.
Let us know if the Advanced Rule solves it for you!

Best regards,

Advanced IP Blocker Team

Sorry, perhaps the last answer wasn’t correct and they are two different services.
You need to verify the service you want to whitelist and identify the firewall rules on its official website.
Once identified, add the correct rules: User Agent, IPs, ASNS, etc. Apologies for the confusing answer.

Hi @thewatchman3,

Good catch on the monitoring service. These services often trigger security rules because they behave like bots (frequent checks, automated requests).

Regarding the User-Agent:
If adding “UptimeDoctor” to the UA whitelist didn’t work, it’s likely they use a generic User-Agent (like Chrome/Mozilla) or a variation you haven’t guessed. The most reliable method is always IP Whitelisting.

Great News (New Feature):
We are releasing version 8.8.3 within the next few hours specifically to solve this problem!

We have added a new “Bulk Import / Export” feature directly in the Whitelist tab.

How to fix it (Once updated):

1. Find the official list of IPs from your provider (e.g., UptimeRobot publishes a .txt file, UpTimeDoctor should have a help page with theirs).
2. Go to Security > IP Management > Whitelist.
3. Click the new “Bulk Import” button.
4. Paste the full list of IPs (one per line).
5. Add a note (e.g., “UptimeRobot Europe”) and click Import.

This will instantly whitelist their entire infrastructure without you having to add them one by one.

Pro Tip: If they offer IPs by region, try adding only the regions you use to keep your whitelist clean.

Let me know if this helps once the update is live!

Best regards,

Advanced IP Bolcked Team

Hi @theboina,

That is a brilliant workaround! Using the Import/Export feature to inject a custom JSON list is a very creative and valid solution. I am impressed.

You are absolutely right about ASNs—not every provider has a clean one, so having a way to bulk import IPs is essential. We will still work on a dedicated UI for bulk pasting to make it easier for everyone, but your method is perfect for power users in the meantime.

Thanks for sharing this tip! It might help others reading this thread.

Best regards,

IniLerm

Hi @tedraortega,

This is excellent detective work. The fact that “Pausing Cloudflare” fixes it confirms 100% that it is an IP Detection issue.

Even though the System Status says “Green”, the plugin is likely failing to extract your real IP address from the Cloudflare headers in your specific server environment, so it sees Cloudflare’s IP as “Your IP”.

The Test:

1. Enable Cloudflare again.
2. Log in (since you said you stay logged in).
3. Go to Security > Dashboard > System Status.
4. Look at “Your Detected IP Address”.
   • Does it show your real home IP (check whatsmyip.com)?
   • Or does it show a Cloudflare IP (usually starts with 162., 172., 104.)?

The Solution:
If it shows a Cloudflare IP, it means the “Trusted Proxy” setting (AS13335) isn’t enough for your server configuration.
Please try adding the Cloudflare IP Ranges explicitly to the “Trusted Proxies” list (Settings > IP Detection). Sometimes servers don’t resolve the ASN correctly.

You can find the list here: https://www.cloudflare.com/ips/ (Copy/paste the IPv4 list into the Trusted Proxies box).

Also, please double-check that “Whitelist Login Access” is definitely UNCHECKED. That setting is incompatible with dynamic setups like this.

Hi @theboina,

That is a great question. Adding 200 IPs manually is definitely not efficient!

We are planning to add a “Bulk Import” feature (CSV/Text area) in a future version (v8.9+), but right now, you have two much faster and smarter ways to handle this:

1. Use ASN Whitelisting (Recommended)
Instead of whitelisting 200 individual IPs, you can often whitelist the entire network provider of the service.

• Go to Security > Blocking Rules > ASN Blocking.
• In the “ASN Whitelist” box, add the ASN of the service.
  • Example: If StatusCake uses a specific ASN (you can check one of their IPs on bgp.he.net), adding that single line allows all their current and future IPs instantly.

2. Use CIDR Ranges
Services like ManageWP often publish their IPs in “CIDR format” (e.g., 192.168.0.0/24).

• Our “Add to Whitelist” input supports CIDR ranges.
• Instead of adding 256 individual IPs, you just add 192.168.0.0/24 once, and it covers the whole block.

Pro Tip: Check the support documentation of StatusCake/ManageWP. They usually provide a list of CIDR ranges or their ASN to make firewall configuration easier.

We will work on the bulk paste feature for the next release to make this even easier!

Best regards,

Advanced Ip Blocker Team

If you have a moment, we would really appreciate a 5-star review to help other users find the plugin.

 Rate Advanced IP Blocker here

Thanks again, and enjoy using your site securely!

Hi @wassi007,

Great news! We have just released version 8.8.2 with the feature you requested.

You now have granular control over the Site Scanner.

How to solve your SSL alert issue:

1. Update to v8.8.2.
2. Go to Security > Settings > Notifications.
3. Scroll down to the new “Site Scanner Settings” section.
4. Uncheck “Check SSL Certificate”.
5. Save changes.

The Result:

• The SSL check will now show as “Skipped” in manual scans (Grey status).
• It will be completely ignored during automated background scans.
• Since the “Critical” error is gone, you will stop receiving the daily alert emails (unless a new, real issue is found).

Note on your Plesk environment:
Since you are the only user reporting this persistent false positive, it strongly suggests a specific configuration in your Plesk loopback interface where WordPress cannot verify its own SSL certificate internally. By disabling this specific check, you align the plugin with your server’s reality without losing the other security benefits.

I hope this provides the perfect balance for your 30+ sites!

Best regards,

Advanced IP Blocker Team