Static site generators like Eleventy have gained popularity for their speed, security, and low hosting costs, but they pose a classic problem: there is no server‑side runtime to handle form submissions. When a visitor fills out a contact form, the browser needs somewhere to POST the data so it can be turned into an email or stored for later review. On platforms such as Netlify, a built‑in forms service removes this friction, but on Cloudflare Pages you must bring your own backend. This is where Cloudflare Workers (exposed via Pages Functions) become a lightweight, cost‑effective alternative. By deploying a tiny JavaScript endpoint at /api/contact, you keep the site fully static while gaining the ability to process form data, validate it, and trigger an email send—all without provisioning a traditional server. The worker runs on Cloudflare’s edge network, meaning low latency and automatic scaling, and because it lives inside the same account as your Pages site you avoid extra billing complexities or third‑party dependencies.
Choosing a serverless endpoint also aligns with modern DevOps practices: the function lives alongside your site’s code in Git, receives the same CI/CD pipeline, and can be versioned, reviewed, and rolled out with the same confidence as any other asset. Compared to third‑party form handlers like Formspree or Formspark, a self‑hosted Worker gives you full control over data residency, privacy policies, and the exact shape of the payload you send to your email provider. Moreover, you avoid the recurring costs that many SaaS form services impose at higher submission volumes. For a personal blog or a small business site, the free tier of Cloudflare Workers is often sufficient, making this approach both economical and technically satisfying. The trade‑off is a modest amount of initial setup—registering keys, writing validation logic, and configuring environment variables—but the payoff is a bespoke, auditable pipeline that matches the exact needs of your audience.
reCAPTCHA v3 offers an invisible challenge that evaluates the likelihood that a visitor is human without interrupting their experience. Instead of presenting distorted text or image grids, the script gathers a rich set of signals from the browser and sends them to Google’s risk analysis engine, which returns a score between 0.0 (almost certainly a bot) and 1.0 (almost certainly a human). This score is then interpreted by your backend to decide whether to accept, flag, or discard the submission. The beauty of this model is that legitimate users never see a puzzle, reducing friction and improving conversion rates, while bots are still challenged by the underlying analysis. For a contact form, where the goal is to collect genuine inquiries while keeping spam at bay, reCAPTCHA v3 provides a seamless first line of defense that works silently in the background.
The signals fed into reCAPTCHA v3’s scoring algorithm are diverse and continually refined. On the behavioral side, the script examines mouse movements: human users tend to produce curved, slightly jittery paths with natural pauses, whereas automated scripts often generate straight lines and uniformly timed clicks. Typing dynamics are similarly scrutinized—real humans exhibit variable key‑press latency, occasional hesitations, and a rhythm that differs from the machine‑like uniformity of bots. Beyond interaction patterns, reCAPTCHA also performs browser and device fingerprinting, collecting attributes such as user agent, screen resolution, installed fonts, WebGL capabilities, and even subtle hardware characteristics. Each attribute adds entropy, making it easier to distinguish a genuine device from a headless browser or a spoofed environment. While fingerprinting raises privacy concerns, Google argues that the data is used solely for abuse prevention and is not tied to personal identities for advertising purposes.
In addition to local signals, reCAPTCHA v3 taps into Google’s global reputation network. By observing billions of interactions across its services, the search giant can identify IP addresses, ASNs, or even specific user agents that have historically been associated with abusive traffic. This global view allows the system to boost the risk score for connections originating from known bad actors, even if their local behavior appears benign. Furthermore, reCAPTCHA v3 can predict the intent behind an action: developers supply an action name (e.g., “login” or “submit_contact”), and the service compares the observed behavior against baseline patterns for that action learned from trillions of historical events. For instance, a genuine contact form submission typically takes a few seconds to fill out, whereas a bot might attempt to send hundreds of requests per minute. The resulting score reflects both the immediate behavior and the broader contextual risk, giving developers a nuanced tool for tuning their spam thresholds.
Integrating reCAPTCHA v3 with a Cloudflare Worker involves a few straightforward steps. First, register your site in the Google reCAPTCHA admin console to obtain a site key (for the client) and a secret key (for the server). The site key is embedded in your HTML so that the browser can request a token when the user interacts with the form. The secret key must never be exposed client‑side; instead, store it as an environment variable in your Cloudflare Pages dashboard, where it is encrypted at rest and injected into the Worker’s runtime environment. In the Worker, upon receiving a POST request, you extract the token from the form data, then make a sub‑request to https://www.google.com/recaptcha/api/siteverify, passing the secret key and the token. Google’s response includes the score and a success flag; you then apply a threshold—for example, rejecting any score below 0.3—as the baseline for bot likelihood. This logic lives entirely within the Worker, keeping the verification step close to the edge and minimizing latency.
Beyond the invisible CAPTCHA, a solid contact form incorporates multiple layers of defense and accessibility. A honeypot field—an input hidden via CSS but still present in the markup—catches bots that indiscriminately fill every field they encounter; if that field contains a value, the request can be rejected immediately without bothering the user. On the accessibility front, semantic HTML is essential: use