表單不是技術细节，是运营的最後一公里
大多數站点运营的精力都花在内容、结构和抓取上，表單往往被当成開發阶段一次性做完就結束了的東西。但真實情况是：訪客從搜尋進来，讀完内容，想咨询、想留言、想订阅，最後能不能走完這一步，取决于表單有没有被正确摆放、正确响應、正确送達。
更麻烦的是，表單出問题通常不會报错。頁面照样打開，按钮照样能点，只是提交後没有回音，或者提示信息让人一头雾水，而你可能几周之後才發現信箱里安静得反常。所以表單值得像導航、像 404 一样，定期拉出来检查一遍。
入口是否真的能被找到
先解决“找得到”的問题。常见的毛病包括：
- 联系入口只在頁脚最底部出現一次，且文字是“联系我們”之外的自造词；
- 移動端把联系按钮塞進折叠菜單深處，需要展開两层才能看到；
- 表單頁本身被誤加 noindex，或者在 robots 里被挡住，導致訪客搜品牌名时找不到官方入口。
联系頁、留言頁這類以人工服務為目的的頁面，通常希望被抓取到，让訪客能直接搜到；而後台表單、提交结果頁、带驗證參數的地址，則應该明确排除在抓取范围之外。這两類要分清楚，不要一刀切。
提交前後發生了什么
提交成功之後
理想狀態是：提交按钮给出即时反馈（禁用、加载中），成功後跳到獨立的感谢頁，頁面里寫清楚“我們會在几個工作日内回复”，並顺带给出备用的信箱或电话。千萬別做的是——提交後停在原頁面什么都不變，或者跳轉到一個白屏地址。前者让訪客反复点击、重复提交，後者让人以為站点坏了。
提交失敗之後
失敗分两種：一種是校驗没過，一種是服務端出错。
- 校驗失敗时，错誤提示要贴在對應字段旁邊，说清楚怎么改，比如“信箱格式看起来不對，請检查 @ 前後的内容”；
- 不要因為一個字段出错就清空整張表單，這是最劝退的行為之一；
- 服務端出错时，给一句人话加一個备用联系方式，而不是把错誤碼直接甩给訪客。
另外，提交结果的感谢頁建议加上 noindex，避免它被当成普通内容頁抓取和收錄。
垃圾提交與真實体驗的平衡
表單一旦被机器人盯上，信箱很快會被灌满。常见的防護手段有驗證碼、蜜罐字段、提交時間戳、频率限制。這里的原則是：防護要對机器人隐形，對真人無感。让用戶辨認扭曲字符、反复滑動拼图的方案，往往拦掉的真人比机器人還多。
優先考虑蜜罐字段和時間戳這類無感方案，把驗證碼留给風險确實很高的场景。同时给表單加上長度限制和基本格式過滤，避免有人用超長文本把資料库撑坏。
地址與參數：別让表單生成一堆無用頁面
有些老式表單用 GET 方式提交，结果每提交一次就产生一個带參數的地址，這些地址一旦被蜘蛛抓到，會迅速堆积成大量内容几乎一样的頁面。處理思路很简單：
- 提交行為尽量使用 POST，不要用 GET 拼參數；
- 已经有參數地址的，用 canonical 指向干净的原始頁，並在 robots 里屏蔽掉參數组合；
- 带會话标识、追踪标识的連結不要出現在内鏈和站点地图里。
一份可以照着走的自查清單
- 從首頁出發，三步之内能否找到联系入口？移動端也走一遍。
- 联系頁本身可被抓取，提交结果頁明确排除。
- 提交後是否有明确反馈，是否會自動跳轉到感谢頁。
- 故意填错一個字段，看错誤提示是否具体、是否保留已填内容。
- 在手机上用真實键盘走一遍，輸入類型是否匹配（信箱、电话、數字）。
- 连續提交两三次，確認是否有防重复提交机制。
- 检查提交记錄是否真的進到了收件箱或後台，而不是只寫了日誌。
- 確認表單頁的參數地址不會進入内鏈與站点地图。
表單的問题往往是“静默故障”：頁面不报错，訪客却已经走掉了。把它和日誌、监控一样当成常規巡检項，比事後翻邮件记錄要省力得多。
如果站点有多個表單，建议整理一張清單，寫清每個表單的用途、接收人、提交後的去向，以及出現問题时的备用联系方式。這份清單不需要多漂亮，但能让你在收到“我提交了没回复”的反馈时，几分钟内定位到是哪一环掉了鏈子。