WordPress 询盘反垃圾应采用分层处理：先在服务端验证字段和提交状态，用蜜罐、时间与频率信号拦截明显机器人；再让 reCAPTCHA、Turnstile 或风险评分处理可疑请求；最后把边界案例放入可复核的隔离队列。不要用单个关键词、公共邮箱或国家直接删除线索，也不要只装验证码就认为问题解决。
风险越高，验证越强；证据不足的提交进入复核，而不是直接消失。
先确认垃圾询盘从哪里进来
销售收到“像表单邮件”的内容，不代表请求一定经过当前表单。常见来源有：
- 当前公开表单的自动化提交；
- 已停用但接口仍可访问的旧表单；
- WordPress REST、AJAX 或第三方表单端点；
- 评论、注册、找回密码等其他入口；
- 邮箱地址被公开抓取后的直接邮件；
- 被伪造的发件人或邮件模板；
- CRM、聊天工具或广告线索同步。
先为每次表单提交生成记录 ID，并在数据库或表单系统中保存状态。收到垃圾邮件后，用 ID、时间和原始记录核对。如果邮件里没有对应记录，问题可能在邮件层或其他入口，继续调 WordPress 表单验证码不会解决。
第一层：更新、停用旧入口并做服务端校验
WordPress 核心、主题和表单插件应保持受支持版本；不用的表单、插件和接口要停用。仅把页面从菜单删除不等于关闭提交端点。
服务端至少验证：
- 必填字段真实存在；
- 邮箱、数字、日期和枚举值符合允许格式；
- 产品 ID、页面来源和表单状态有效；
- nonce、会话或表单状态没有过期或被篡改；
- 上传文件的类型、大小和内容检查；
- 请求不能绕过前端验证直接写入或发信。
前端验证用于帮助用户纠错，不能作为安全边界。攻击脚本可以直接请求后端地址，所以 CAPTCHA token、字段规则和频率限制都必须在服务器端执行。
涉及 WordPress 模板、插件与技术配置时，可从WordPress SEO 与技术优化统一梳理表单和性能影响。
第二层：用低摩擦信号拦截明显机器人
低摩擦信号不会要求真实买家做额外动作，适合先启用：
- 蜜罐字段：正常用户不可见，自动脚本填写后触发风险；
- 表单状态或一次性 token：确认请求来自当前表单流程；
- 提交速度：页面刚加载就完成长表单属于风险信号；
- 字段一致性：产品、数量、国家、邮箱等值是否合规；
- 重复特征：短时间内相同内容、邮箱或指纹反复提交；
- 链接与内容模式：与业务无关的推广词、异常链接和机械文本。
Gravity Forms 的官方文档说明，其 Advanced Honeypot 同时检查隐藏字段、站点特定状态和可选提交速度。无论使用哪款插件，都应确认“启用”后实际请求会在服务端验证，不能只看后台开关。
蜜罐也不是万能。针对网站定制的脚本可能识别隐藏字段；浏览器自动填充或无障碍实现不当，也可能制造误报。因此它适合作为一层信号，不应独自承担全部拦截。
第三层：只对可疑提交增加 CAPTCHA 或风险验证
Google reCAPTCHA v3返回风险分数，官方要求在后端验证 token、hostname 和 action；token 有时效，提交动作发生时再生成。Cloudflare Turnstile同样要求服务器调用 Siteverify，只有前端显示组件而没有后端校验，保护并不完整。
一个更稳妥的处理方式是：
- 低风险：正常提交；
- 中等风险：增加 Turnstile、验证码或邮箱确认；
- 高风险且证据明确：拒绝或限速；
- 信号冲突：接收但标记为待复核。
不要照搬公开的固定阈值。reCAPTCHA 文档给出起始参考，但明确建议按站点真实流量调整。新部署和测试环境中的评分可能与生产流量不同，先观察分布，再决定动作。
验证码还要测试目标市场的可用性、加载速度、键盘操作、读屏和网络条件。验证服务加载失败时，应提供重试或备用提交方式，不能让真实买家面对一个永远不能点击的按钮。
第四层：频率限制应限速，不要粗暴封掉整个市场
频率限制可针对 IP、会话、邮箱、表单、设备特征或组合信号。它擅长处理同一来源的短时洪泛，但分布式机器人、企业共享网络和移动运营商 NAT 会让单一 IP 判断失真。
不要因为一段时间垃圾来自某个国家，就永久封掉整个国家；外贸业务尤其容易误伤目标客户、采购代理、VPN 和海外分公司。更合理的方式是：
- 对异常频率先延迟、挑战或进入隔离；
- 对连续命中多个高风险信号的来源短时限制；
- 为已知客户、合作伙伴或内部测试提供受控白名单；
- 记录规则、持续时间和解除方式；
- 监测目标国家的正常提交是否突然下降。
第五层：内容和身份信号用于评分，不宜单点删除
以下信号可以帮助分流，但单独使用时都可能误伤：
| 信号 | 可以做什么 | 不应怎么做 | 误伤场景 |
|---|---|---|---|
| 公共邮箱 | 降低身份置信度，要求更多公司信息 | 全部拒绝 | 小企业、初创、出差采购 |
| 免费或临时邮箱 | 增加验证或隔离 | 仅凭域名删除 | 域名数据库过期 |
| 大量链接 | 提高垃圾风险 | 一条链接就拒绝 | 买家发送图纸或参考产品 |
| 非目标国家 | 调整销售路由 | 全国封锁 | 代理、分公司、VPN |
| 极短内容 | 结合产品页来源判断 | 自动当垃圾 | 买家只提交型号和数量 |
| 重复内容 | 限速或合并记录 | 永久拉黑 | 网络失败后的重复提交 |
| 关键词命中 | 进入复核 | 命中一个词即删除 | 产品名与垃圾词重合 |
| 提交很快 | 增加风险分 | 单独阻止 | 浏览器自动填充、回访客户 |
规则应面向“异常组合”，而不是寻找一个万能关键词。销售发现新的垃圾模式后，先回看近期香港或目标市场的真实询盘，确认不会同时命中，再上线。
信号用于决定下一步动作，不等于提交本身就是垃圾。
隔离队列是避免误伤的关键
直接删除让团队无法知道丢了什么，也无法调整规则。至少在规则观察期，把高风险提交放入隔离区并保留：
- 提交时间、表单与来源页面；
- 命中的规则和风险原因；
- 非敏感的技术诊断信息；
- 销售或运营的“垃圾 / 有效 / 不确定”复核结果；
- 恢复和重新通知销售的操作；
- 按隐私与安全政策执行的保留期限。
可先用 14 天作为一次内部观察周期，而不是永久阈值：前 7 天只标记不自动删除，后 7 天根据复核结果启用分级动作。这个周期只是落地示例；真实流量低的站点应延长到获得足够样本。
真正需要优化的是两类错误：
- 假阴性：垃圾通过，消耗销售时间；
- 假阳性：真实客户被拦，造成商机损失。
后者通常更难被发现，所以必须有隔离记录、恢复入口和定期抽查。
邮件通知和表单存储要分开验证
表单成功写入不等于销售收到邮件，邮件未到也不等于提交失败。至少分开监控：
- 请求是否通过服务端校验；
- 是否生成数据库或 CRM 记录；
- 是否分配到正确队列；
- 通知邮件是否发送；
- 邮件服务是否投递；
- 销售是否在约定时间内处理。
发件域名的 SPF、DKIM、DMARC 和邮件服务配置会影响投递，但它们不是网页反垃圾规则。若数据库有记录而销售没收到，应排查邮件链路；若数据库根本没有记录，才回到表单端点和风控。
表单、通知与 CRM 要一起设计，可参考外贸询盘型网站建设。
一套可落地的 6 层配置
下面的优先级用于实施排序，不是特定插件清单。
| 层级 | 控制 | 失败时的动作 | 必须监测 |
|---|---|---|---|
| 1 | 关闭旧表单、更新核心与插件 | 阻止不可用入口 | 端点与版本 |
| 2 | 服务端字段、状态、附件验证 | 返回可理解错误 | 验证错误率 |
| 3 | 蜜罐、速度、重复与内容信号 | 标记或低风险拦截 | 命中与误伤 |
| 4 | Turnstile / reCAPTCHA 等风险验证 | 追加挑战或隔离 | token 验证失败 |
| 5 | 频率限制和 WAF | 临时限速 | 来源与解除 |
| 6 | 隔离复核与 CRM 反馈 | 恢复或确认垃圾 | 假阳性、假阴性 |
每次只改变一到两层，并记录上线时间。若同一天同时更换表单插件、验证码、WAF 和邮件服务，垃圾量下降后也无法知道哪一项有效，真实询盘下降时更难定位。
每一层都要有对应日志和恢复方式，才能持续调准。
需要做整站表单、脚本、日志和索引核查时，可使用网站 SEO 审计建立跨团队问题表。
FAQ
装了 reCAPTCHA 为什么还有垃圾询盘？
可能是前端 token 没有在服务器验证，也可能是人工垃圾、低风险机器人或其他端点绕过了表单。先核对原始记录、验证响应和 action，再增加其他层。
蜜罐会不会影响真实客户？
实现正确时通常无感，但浏览器自动填充、无障碍标签或 CSS 错误可能触发误判。启用后必须检查隔离记录，并用多种浏览器和辅助技术测试。
能不能禁止 Gmail、Outlook 等公共邮箱？
不建议全部禁止。它们可以作为低置信度信号，配合公司名、产品、数量和验证使用。很多真实小企业和早期项目会使用公共邮箱。
封锁垃圾来源国家是否有效？
可能短期减少数量，但容易误伤代理、VPN、跨国公司和真实目标客户。优先使用频率、行为和内容组合，国家只作为路由或风险信号。
垃圾询盘应该直接删除吗？
明确恶意且证据充分的可按政策删除；新规则和边界案例应先进入隔离区。保留有限期复核能发现误伤并支持规则调整。
反垃圾会拖慢 WordPress 吗？
额外脚本、远程验证和数据库日志可能增加开销。应异步加载适用脚本、只在有表单的页面启用组件，并监测移动端性能和验证服务故障。
下一步
先为所有询盘入口建立统一 ID 和可查记录，用一周数据确认垃圾真正来自哪些端点。随后按“服务端校验—无感信号—风险验证—隔离复核”的顺序上线，每次调整都同时观察垃圾通过率和真实询盘误伤率。
