Reduce spam in your landing-page contact form

Separate spam from delivery and qualification problems

Not every unhelpful enquiry is a bot. An irrelevant human request, a repeated test, an automated flood, and a form that never delivers require different fixes. Before changing your form, record what you observe: repeated text, bursts from one source, empty fields, suspicious links, or genuine people asking for a service you do not offer.

If expected enquiries are missing, begin with form troubleshooting. Adding friction to a broken delivery path will not recover those messages. If the problem is poor fit, clarify the offer and qualification questions before adding friction for every visitor.

Keep the honeypot in the form contract

A honeypot is a field that ordinary visitors do not fill but some automated scripts do. Pageree’s current form contract requires an off-screen text input named _hp. Its edge handler silently drops a submission when that field contains a non-empty value. The response can appear successful even though no lead is delivered; this avoids teaching a simple bot which field triggered the filter.

The snippet below illustrates only the honeypot element, not a complete publishable form:

<input type="text" name="_hp" tabindex="-1" autocomplete="off"
       style="position:absolute;left:-9999px" aria-hidden="true">

Ask your assistant to follow the full current page, form, and privacy skills, including labels, named fields, validation, and consent controls. Do not remove the honeypot during a visual cleanup just because it is absent from the screenshot. Other platforms also document this technique; Webflow’s honeypot guide is one example, with its own implementation rules.

Know the built-in check a normal visitor never sees

Since October 23, 2026, every Pageree form also carries a proof-of-work captcha, built on the open-source ALTCHA widget. Pageree inserts it when the page is served, on live pages and private previews alike, and issues and checks it from the page’s own address; no third-party captcha service is involved. Your assistant does not add any markup for it.

When a visitor first focuses a field, their browser starts a small computing task and finishes it while they type; on a desktop computer that took about a second in our tests. The solution travels with the submission. A submission without a valid solution is refused before it becomes a lead, and each solution works once, so a script cannot replay one solved form a thousand times. If the visitor presses send before the task is done, the form waits for it and then sends once.

A request that looks automated, for example one from a hosting provider’s network, from a tool’s user agent, or from an address asking for many checks a minute, gets a task several times harder and a visible checkbox that shows “Verifying…” and then a tick. Nobody is refused the check; a shared office or mobile network only slows down.

Proof of work makes every faked submission cost computing time. It does not prove a person: a bot that runs the page in a real browser can still pay the cost and submit, and so can a human spammer. Do not stack a second CAPTCHA on top of it; that adds friction for real visitors without closing the gap.

Understand what validation can prove

Pageree validates submissions against the published form schema. Required fields, email format, length restrictions, and supported option values can reject malformed input. Unknown fields are dropped. This makes a typed form more dependable, but it cannot prove a syntactically valid email belongs to a person interested in your service.

Use realistic limits. A short enquiry does not need unlimited message length; a quotation request may need enough space to explain an unusual job. Avoid mandatory questions that merely restate what the page already knows. The form-field guide helps choose useful qualification without turning an enquiry into a questionnaire.

Rate limits reduce bursts, not every unwanted message

The current Pageree page-router configuration, reviewed September 15, 2026, includes per-IP and per-page edge limits: five requests per IP and sixty per page within sixty seconds. These are operational controls, not promised global submission allowances. Edge counters operate per Cloudflare location, and additional shared account/page controls can affect acceptance.

The handler checks limits before parsing the form. A JSON request that exceeds a limit can receive HTTP 429; a plain form flow is redirected with an error state. Limiter failures can also reject temporarily. Do not claim “the message was sent” when the request was rejected.

These limits reduce rapid abuse. A slow bot that leaves the honeypot empty and pays the proof of work, or a human spammer, can still submit plausible data. No form setup keeps out every unwanted message; the next section handles what still arrives.

Hold back the plausible submissions that get through

Some unwanted submissions look like real ones: a sales pitch typed by a person, a repeat sign-up, an address at a throwaway mailbox, or a domain with a typo that can never receive your reply. Since October 2026, a Pageree form can carry submission rules for these. Your assistant sets them with set_form_rules, or you add them in the console’s Submission rules tab.

Rule	Holds back
Duplicate email	An address already accepted on this form, or on any form in the account, in the last 90 days
Disposable email	Addresses at mailinator.com and about ten thousand other throwaway domains
Mail server	Domains that cannot receive email, such as a typo like gmial.con
Country, email domain	Visitors or addresses outside your allow list, or on your block list
Content check	Messages that are spam, contain swearing, or are not in a language you accept, judged by an AI model
Email and phone verification	Addresses and numbers that your own verification provider says are not real

A rule never refuses a submission. The visitor sees the usual success message, and the held-back submission is stored with its reason in the page’s Invalid folder for 30 days. It is not delivered and not counted as a conversion, and you can release it in one click if it was real. A morning email lists what was held back the day before.

Choose rules from what you observed. A flood of pitches calls for the content check, and repeated test sign-ups for the duplicate rule. A strict country list will catch a few real visitors on a VPN, so look through the Invalid folder in the first weeks. Checks that call another service get four seconds in all; one that cannot answer is skipped and the submission is delivered.

Ask for a focused inspection

Inspect the form on my existing Pageree page [URL or page ID].
Read its current source and published form schema before proposing changes.
Check the required _hp field, field names, validation, privacy controls,
and success/error behavior. Identify observed defects separately from suggestions.
Preserve legitimate visitor access and the current delivery destination.
Keep Pageree's built-in check; do not add another CAPTCHA or promise to eliminate all spam.
Suggest submission rules that match what we observed, but add none until I approve.
Show a revised private preview if markup changes are needed; wait for approval.

Test a normal submission with controlled details and a missing required field, in a real browser: a script that posts straight to the form address, without running the page, is refused by the captcha, so its failure says nothing about your form. If inspecting honeypot behavior in a safe test setup, remember that its apparent success intentionally differs from normal delivery. Do not stress-test a live endpoint or send a burst of messages to establish the rate limit.

Keep a usable recovery and response process

Accepted Pageree enquiries have a 30-day recovery backup. That helps investigate delivery failures; a request rejected by validation or the captcha, or silently dropped as honeypot spam, is not an accepted lead to recover. A submission held back by a submission rule is different: it was accepted, and it waits in the Invalid folder until you release it or the 30 days run out. Owner email fallback also does not certify that a CRM received the record.

Keep a few redacted examples and approximate timestamps when reporting recurring abuse through support. Use those observations to choose the next change. Review the email-delivery guide when the issue is receipt, and improve offer clarity when real visitors consistently ask for the wrong service.