现象内容上百页搜索引擎收录恒定 2 页我们的一个站点内容早就过了百页sitemap 提交齐全可搜索索引里翻来覆去只有 2 页。团队最初的归因走了两个方向有人说是内容质量问题有人说是新站考核期。讨论了几轮谁也拿不出证据——直到有人提议别猜了去看服务器日志。这一看问题的形状完全变了。## 归因蜘蛛来访数据摆在那nginx 的访问日志里按 User-Agent 把搜索引擎蜘蛛拆开统计数据是这样的某家引擎的蜘蛛半年累计来访一百多次另一家两百多次还有一家两千多次。差异悬殊还在其次关键是分布——来访少的那家抓的几乎全是首页内页约等于零。这就把问题从收录为什么少变成了蜘蛛为什么不来、为什么只看首页。收录是抓取的结果抓取没发生收录页面数量自然是低值。之前所有关于内容质量的讨论都建立在蜘蛛来过了、但不收录这个错误前提上。前提错了讨论再久也是空转。顺着数据再挖又发现一个容易被自己人坑的点我们有一套自动推送任务每天定时把新链接推给搜索引擎。有人手工执行推送时收到超出当日配额的报错差点得出配额是零、推送通道坏了的结论。真相是定时任务每天早上已经把当天的推送额度用完了手工再推自然报超额。先看自己的自动化干了什么再对平台下结论——这句话值得写在每个运维的显示器边上。## 修法把该做的逐项做实而不是发明新动作定位到蜘蛛不来之后排查清单其实很标准化站点是否在站长平台验证过主体、sitemap 是否可正常拉取、备案信息是否在页面上正确展示、页面返回码是否干净、移动端适配是否正常。逐项检查发现有几项确实欠账备案号与站点的关联在平台侧没完成部分页面对蜘蛛的返回不够友好。修的过程没有奇迹就是把清单逐项落实补全平台侧的验证与关联修掉对蜘蛛不友好的返回保证 sitemap 拉取顺畅把推送任务的额度机制理顺。做完之后能做的就是等——抓取行为是对方的资源调度你把门槛修平之后剩下的变量在平台手里。这次修复还留下一个副产品把蜘蛛来访量做成了每周例检的指标。来访量的变化比收录量的变化敏感得多——收录是滞后指标来访是先行指标。等收录数字变化再行动通常已经晚了两三周。## 泛化性能与增长问题的排查永远从事实采集开始这件事的教训不在 SEO 技巧在排查方法论。收录少这类问题团队的直觉反应永远是归因游戏——质量、考核期、算法调整每个说法听起来都有道理谁也无法证伪。打破僵局的动作只有一个去看一手数据。一手数据有三个来源按优先级排自己的服务器日志最诚实请求级的真相、平台的官方工具面板半滞后但权威、第三方推测文章只有启发价值没有证据价值。归因争论每持续一天修复就晚一天开始而绝大多数归因争论一份原始日志就能终结。还有一个反直觉的经验自动化任务会造成观测污染。定时推送吃掉配额、脚本访问污染统计这类自家自动化造成的假象和真正的平台问题混在一起极难分辨。排查前先把我自己每天都自动干了什么列一遍常常能省掉一次对平台的误判。## 先行指标与自查清单那次之后搜索侧的观测体系重新组织了一遍核心变化是把指标分成先行和滞后两层。滞后层是收录量、排名这些结果指标它们由平台决定变化慢波动解释空间大。先行层是我们自己日志里的蜘蛛来访量、来访深度抓了首页还是内页、sitemap 拉取成功率这些指标反映的是门槛状态变化快解释空间小。周报里两层并列先看先行层再看滞后层先行层健康而滞后层疲软是平台侧的调度问题继续等先行层恶化是我们自己的门槛出了问题立即排查。两层混着看永远分不清该谁着急。自查清单也模板化了平台验证状态、主体与备案关联、sitemap 可拉取性、对蜘蛛的返回码抽样、移动端适配抽查、推送任务执行记录。每项都有客观判据检查结果只有通过与不通过不接受看起来还行。顺带修正了一个长期误判用 site 查询语法看到的收录数字并不可靠它和平台后台的数据口径不一致波动也大。此前几次收录焦虑一半是被这个失真数字吓出来的。现在只以平台后台数据为准site 查询降级为粗略参考。回看整个事件最有价值的动作是把团队从归因讨论拉回了数据采集。互联网上关于流量的猜测太多而答案往往在自己服务器上躺了半年。平台反馈通道的使用也有些经验。反馈门槛是有的备案要满一定期限、站点数据要齐全、问题描述要有证据。带着先行指标数据去提反馈和处理效率直接相关——附上蜘蛛来访量统计、sitemap 拉取记录、返回码抽样的反馈平台侧能快速定位是门槛问题还是调度问题只写收录为什么少的反馈大概率石沉大海。数据不仅是自己排查的依据也是跨组织沟通的通用语言。日志的留存周期也值得注意。蜘蛛来访这类低频信号时间窗口拉得越长越有说服力——半年的曲线一眼分清趋势与噪声一周的数据只能看出波动。把访问日志里蜘蛛 UA 的聚合统计做成按月归档的小表查询成本极低回看价值极高。这次能快速定位靠的正是半年长度的历史日志还在。## 参考文章-微信自动回复怎么和人工接待配合什么情况必须转人工- 下班后微信自动回复怎么做企微官方方案 vs 个人微信 7×24