This will need some consideration. Do we really want to exclude web crawlers? Or do we want to follow the philosophy that a web crawler that triggers spam detection is a poorly-made web crawler and "gets what it deserves"?

It's difficult because any request can easily have a 'spoofed' (if you can even call it that) user-agent.

I've moved to a feature request. I doubt this is happening on default settings. If it is, please mention such. I actually would like to know the settings it is happening for anyway.

TBH the importance of search engines are declining. Personally I rarely Google stuff nowadays because I either use ChatGPT, or some kind of walled garden (e.g. Reddit). That's sad, but it does lower the criticality of this kind of thing, especially if the crawlers are faulty in some way.

Possibly the health check should use different wording then... instead of saying "accidentally banned a web crawler", implying it should be unbanned, maybe it should say "Banned a potential web crawler... (IP). If you believe this to be a false-positive, unban the IP address."

Changed back to bug. Reviewing the code, it is working by IP, not by UA. Hackattack banning already does:
if ((!is_our_server($ip)) && (!is_unbannable_bot_dns($ip)) && (!is_unbannable_bot_ip($ip))) {
And we should do the same for antispam.

Automated response: 5472: Perhaps spam detection should not ban web crawlers

Some web crawlers get banned by the antispam if they match enough criteria to cause their score to reach the ban limit. But when this happens, health check fails saying accidentally banned a web crawler.

This hotfix adds checks to be sure we're not trying to ban the server or a known / trusted bot. A hack attack will still be logged regardless if the IP gets banned (though advanced_banning by default stops logs).

A hotfix (a TAR of files to upload) has been uploaded to this issue. Only apply this hotfix if you absolutely need it and cannot wait until the next release of Composr (releases are more reliable and strictly tested). As of Composr version 11, the recommended way to apply a hotfix is by following the same steps as an upgrade (https://baseurl/upgrader.php, use the hotfix on the step “Transfer across new/updated files”). The upgrader will automatically skip files belonging to addons you do not have installed or that are newer on disk than in the hotfix. Otherwise, you can manually extract and replace these files (do not replace if your on-disk file is newer than the one in the hotfix). Always take backups of your site or at least files you are replacing before applying a hotfix. Not sure how to extract TAR files to your Windows computer? Try 7-zip (http://www.7-zip.org/).