CAPTCHA and spam protection: first local, then external
A CAPTCHA is not an end in itself. For many forms, local checks that do not establish a connection to another provider are sufficient.
Requirements
Access to form and spam protection configuration; check in advance whether local protective measures are already sufficient.
Stage 1: local procedures
Combine honeypot field, minimum fill time, server-side validation, simple rate limits and content plausibility checks. Several weak signals can be effective together without recognizing the normal visitor.
Level 2: only if actually needed
If local protection is not enough, only then add an external CAPTCHA/challenge service. Check when the script is loaded, which requests arise before an interaction and which data is sent to the provider.
Test
A provider name simply existing in HTML is not sufficient for the evaluation. The actual browser communication is crucial: Is a third-party connection already established when a normal page is accessed or only after a specific action?
Dismantling
If changes occur, restore the previous configuration and then check again.
Related guides
Sources and verification
This guide is based on multiple current sources. Vendor documentation is not treated as proof that every concrete installation automatically follows the same privacy characteristics.
Important: IP processing is not IP storage
An IP address has to be processed to establish and deliver a network connection. Hosting providers, firewalls or DDoS protection may also process or retain it for a limited time for security purposes. No Logging distinguishes this security layer from unnecessary persistent visitor logging by the website, application and ordinary access logs.