Custom Website Development: Inquiry Form Receives Dozens of Garbled English Messages a Day—Should You Disable the Form First or Add a CAPTCHA First?

In custom website development, when a public inquiry form receives garbled English text or promotional links, it is usually not because the form code is broken, but because it has been targeted by automated submissions. Adding only a CAPTCHA can block some low-end scripts. Based on 2026 project delivery experience, a more reliable approach is the combination of “honeypot + timestamp + backend rate limiting + anomaly-triggered verification + manual fallback”. Do not rush to disable the form first; disabling it will lose real inquiries. You should first log submissions to assess the spam ratio, then add protection in order of increasing user disturbance. This applies to official websites with public inquiry or registration entry points, not to post-login forms or low-frequency contact pages.

Why is adding only a CAPTCHA usually not enough?

A CAPTCHA raises the cost of submission, but bots can change proxy IPs, simulate browsers, or use human CAPTCHA-solving services to bypass simple image verification. If a website relies only on CAPTCHA, it puts the pressure on real user experience; hard-to-read or frequently triggered CAPTCHAs can reduce inquiries. Based on delivery experience, CAPTCHAs are fairly effective against low-end scripts, limited against mid-tier bots, and basically ineffective against human spam.

• Low-end scripts: Direct POST, no page JS loaded; honeypots and timestamps can block some of them.
• Mid-tier bots: Simulate browsers, change IPs, randomize content; need backend rate limiting and behavior checks.
• Human spam: Filled manually by people; CAPTCHAs can be passed; only content review and blacklists can help.

What are common signals that a form has been targeted by bots?

Do not just look at “receiving spam emails.” A more reliable method is to look at submission patterns: multiple entries within seconds, concentrated IPs or same subnet, highly similar content, similar email domains, missing referrer and UTM. When multiple signals appear at the same time, automation can basically be determined. During acceptance, ask the developer to export recent logs, including time, IP, referrer, field length, and whether it was blocked. It is not rare for websites with public forms to receive dozens to hundreds of spam submissions per month; the typical range depends on the industry and promotion intensity.

• Time signals: Multiple submissions less than a few seconds apart, or concentrated in fixed early-morning periods.
• Content signals: Name and message contain many links, keyword stuffing, or mixed Chinese-English templates.
• Referrer signals: No referrer page, no UTM, direct access to the submission page.
• Field signals: Hidden fields are filled in, required fields have abnormal formats but still pass.

Three-layer protection framework: how to arrange from light to heavy

Based on delivery experience, you can rank by “low to high impact on real users” and do not need to start with heavy verification. This reduces spam without blocking normal inquiries. The following three layers can be combined as needed in most corporate website projects.

1. Layer 1: Lightweight front-end blocking. Add a honeypot field (invisible to users, easy for bots to fill), submission timestamp (less than 2-3 seconds from page load to submission is considered suspicious), and hidden token. It is almost imperceptible to real users and can filter simple scripts that do not load JS.
2. Layer 2: Submission behavior validation. The backend rate-limits the same IP and device identifier, for example, at most 1-2 times per minute and 3-5 times per hour (experience range). It also checks referrer, User-Agent, and field formats. When thresholds are triggered, then require a slider or invisible verification.
3. Layer 3: Backend and manual fallback. Suspicious submissions are not discarded directly; they are marked and enter a pending review queue. Normal submissions go through email or WeChat Work notifications, while suspicious submissions are archived separately. Regularly add high-frequency IPs or email domains to the blacklist.

Notes: Layer 1 cannot rely on front-end JS as the only judgment; Layer 2 rate limiting must give real users room to retry; Layer 3 requires someone to regularly check the archive, otherwise the suspicious queue becomes a spam box. If normal inquiries can receive notifications within 1-2 minutes, spam submissions do not crowd out the main notification channel, and blocking records can be checked in the backend, it is usually considered up to standard.

Comparison of common approaches: CAPTCHA, honeypot, rate limiting, manual review

Different approaches differ significantly in effectiveness and cost. The following compares them by common experience ranges; specifics fluctuate depending on form value, promotion channels, and attack intensity, so they should not be copied directly.

• Image/slider CAPTCHA: Can block low-end scripts and some mid-tier bots; cannot stop human CAPTCHA-solving or human spam; causes slight interruption to real users, and mobile abandonment rate may rise by a few percentage points. Suitable for public registration and inquiry forms; recommend triggering only on anomalies.
• Honeypot + timestamp: Can block simple scripts that do not render the page; cannot stop simulated browsers; almost imperceptible to real users, with development and debugging costs commonly half a day to 1 day. Suitable as the default foundation for most public forms.
• Backend rate limiting: Can block high-frequency repeated submissions and some proxy IP attacks; cannot stop low-frequency human spam; thresholds must be set reasonably to avoid false positives. Suitable for use together with logs.
• SMS verification code: Can block most automated submissions; but each message has a cost (experience range: a few cents to just over RMB 0.1), and it clearly adds steps, so it is suitable for high-value, low-frequency scenarios such as quote requests or large inquiries.
• Manual review: Can block suspicious content beyond automation; the cost is slower response, usually taking tens of minutes to several hours. Suitable for B2B high-ticket inquiries, not for campaign pages seeking immediate conversion.

Based on 2026 project delivery habits, a reasonable combination for most corporate websites is: honeypot + timestamp enabled by default, backend rate limiting as a fallback, CAPTCHA triggered only on anomalies, and manual review handling only the suspicious queue. This causes less disturbance to real users and prevents spam submissions from flooding the sales inbox.

Delivery scenario: disable the form first or add a CAPTCHA first?

In a paid landing page project, the form received dozens of garbled English messages every day, and sales asked to “disable the form first.” The constraint was that the ad campaign was running; disabling the form would directly lose inquiries, and the budget was limited, so heavy verification could not be added immediately. The approach was to export logs that day, confirming that spam accounted for about 70% of submissions, while real inquiries were still 30%; then enable honeypot and timestamp, rate-limit by IP on the backend, trigger CAPTCHA only on anomalies, and send suspicious submissions to a separate archive. As a result, three days after launch, spam submissions dropped to single digits per day, and real inquiry notifications returned to normal; the cost was about half a day to 1 day of extra development (experience range), and sales needed to spend a few minutes each day checking the archive to avoid false blocking. This project also shows that logging first and then adjusting thresholds is more reliable than blocking based on gut feeling.

Applicable scenarios and boundaries

Form anti-spam is suitable for websites with public submission entry points, such as inquiry forms, registration, whitepaper downloads, and event sign-ups. These entry points are easily scanned by automated tools. If a form is only used after login, or the website has very low traffic and no promotion campaigns, complex protection is usually unnecessary; basic honeypot and field validation are enough.

Conversely, in the following cases, it is not recommended to immediately add SMS verification codes or complex verification: when the form itself is the core conversion action, user patience is limited, and ad spend is high, overly heavy verification will directly reduce conversion. The boundary can be remembered in one sentence: the goal of anti-spam is not zero spam, but ensuring spam submissions do not affect the notification and follow-up efficiency of normal inquiries.

• Suitable for combined protection: Public inquiry, registration, download, and sign-up forms with promotion campaigns or SEO traffic.
• No need for heavy verification: Intranet forms, post-login forms, low-frequency contact pages, and very low-traffic brochure sites.
• Use SMS verification cautiously: Mobile-first landing pages and forms with low user decision cost.

FAQ

The form still receives spam submissions after adding a CAPTCHA. Is the code not written well?

Not necessarily. A CAPTCHA only raises the cost of submission; it cannot stop proxy IPs, simulated browsers, and human spam. It is advisable to first look at the IP and time patterns in the submission logs, then decide whether to add rate limiting or manual review.

Will honeypot fields accidentally affect normal users?

The normal practice is to hide them with CSS rather than display:none, and use reasonable naming. Real users cannot see them and will not fill them in. Browser autofill may occasionally fill them by mistake, so a field attribute check should be done before submission.

SMS verification code vs. slider CAPTCHA: which is more suitable for inquiry forms?

Inquiry forms usually prioritize slider or invisible verification. SMS verification codes are more suitable for high-value scenarios such as quotes and large inquiries. SMS has sending costs and lengthens the operation path, so conversion loss must be weighed.

What is a suitable backend rate limit setting?

A common experience range is 1-2 times per minute and 3-5 times per hour for the same IP, depending on real users’ retry habits. Setting it too strict will affect normal users; too loose will not stop high-frequency submissions. It is recommended to log first and then adjust thresholds.

Should blocked submissions still be stored?

Yes, it is recommended. Suspicious submissions should enter a separate archive, keeping IP, time, and content summary, to help determine whether attacks continue and whether false blocking occurs. The archive does not need long-term storage and can be cleaned up monthly.

If you are reviewing or taking over a website with a public form, you can handle it in this order: first export recent submission logs to confirm the spam ratio, then add honeypot and timestamp to the form, and finally configure backend rate limiting and anomaly-triggered CAPTCHA. SMS verification codes and manual review are used only in high-value scenarios. The applicable boundary is: public forms are worth protecting, post-login or low-frequency forms do not need over-design, and the final criterion is whether normal inquiries can reach sales in time.