询盘丢在哪一环，多数站长并不知道。表单通知是一条链路：前台提交、服务器处理、投递到邮箱或即时通讯、有人真的看到。任何一环断了，前台依然显示"提交成功"。搜索侧的问题只在这条链路的末端，而且往往是最容易被发现的一环。
把链路拆成四段，每段设一个检查点
| 环节 | 常见断点 | 怎么测 | 出问题先做什么 |
|---|---|---|---|
| 前台提交 | 脚本校验拦下、按钮被遮挡、移动端点不动、重复提交被吞 | 手机与桌面各提交一次，用一个不常用的邮箱 | 先确认请求有没有发出去 |
| 服务器处理 | 处理超时、内存不足、队列积压 | 查错误日志与处理耗时 | 先在日志里找这一条提交 |
| 投递 | 发信通道认证失败、被限流、进了对方垃圾箱 | 用两个不同服务商的外部邮箱各收一次 | 先看主机端报的是成功还是失败 |
| 有人看到 | 通知发到没人值守的邮箱、值班中断 | 定期看通知邮箱与队列残留 | 加备用通道并设值班 |
四段里最容易漏的是第三段和第四段：主机显示发送成功，只说明程序把邮件交给了通道，不代表它进了收件箱。WordPress 网站换托管商，企业邮箱和询盘通知会跟着迁吗讲的就是换主机时这一段最常见的断法。还有一个常见误区是把"提交成功"的提示当成通知已送达——那个提示通常只代表浏览器把请求发出去了，和后面三段都没有关系。
前台侧：联系方式本身要写成链接
页面上的电话和邮箱，如果只是纯文本或者靠脚本触发，Google 就无法把它当作可解析的链接。Google 关于可抓取链接与锚文本的说明给出的判据是：能稳定解析的只有带 href 的 a 元素，并且地址要能解析成一个真实可请求的地址。这条对外贸站尤其实际——询盘入口的点击率和被外部引用次数，和它是不是可点击的链接直接相关。不同渠道留的联系方式也要一致，本地商家信息怎样被 Google 采用讲的是这类信息一致性怎么被采纳。
提交后不要留下一堆参数地址
表单如果用 GET 提交，会在地址栏生成带参数的新地址。Google 关于 URL 结构的建议提醒复杂 URL、过多参数和会话 ID 会造成索引问题，并建议简化 URL 结构。表单提交后请直接跳到固定的感谢页地址，不要让参数地址成为可访问的页面。同样要检查的是筛选类参数：它们在商品页上往往能生成大量地址，属于"看起来是同一个页面、实际是很多个地址"的情况，排查时按 URL 而不是按页面来看。
感谢页与结果页怎么处理索引
感谢页通常是空的，Google 关于 robots meta 标签的规范给了两种写法：head 里的 robots 标签，或 HTTP 响应头里的 X-Robots-Tag。要点是确认它真的随每个请求发出去——后台勾了某个选项，不等于抓到的页面里就有这条指令。空页面留着通常无害，参数地址被索引才是真问题。
什么时候不用套这套流程
- 纯前端收集再转交第三方。服务器侧没有记录，排查只能靠第三方的后台，你无法自证"收到过"。
- 内部或后台专用表单。不必走对外流程，也不用考虑索引处理。
- 收集个人信息的表单有各自的合规要求，属于法务范畴，不在 SEO 讨论范围内。
- 官方没有公布表单数量、字段多少与搜索表现之间的关系，也没有公布"表单页会不会被特殊对待"。
怎么验证这套链路真的通了
- 从外部网络真实提交一次，用一个不常用的邮箱，确认收到的是这一条而不是旧缓存。
- 在服务器日志里找到这次提交，确认处理完成、没有超时。
- 查备用通道是否也收到。备用通道不通，等于没有备用。
- 临时让主通道失败一次，看是否有重试或告警；很多站的失败是静默的。
- 一周后回看队列里有没有未处理项。这一步最容易省，也最容易出事。
询盘通知的可靠性不来自任何插件的宣传，而来自你给每一段都留了一个能自己验证的检查点。