百度产品介绍：网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b2a13ba974a4.html
📄
百度产品介绍：网站规模扩大后哪些工作不适合继续手工做
当页面从几十个涨到几百上千个，最先出问题的往往不是排名，而是同一件事在不同人嘴里说法不一样：运营说链接都提交了，技术说日志里根本没来抓。手工做不是做不好，而是它无法稳定地产出可核对的记录，规模一大，分歧就代替了结论。
矛盾现象：提交动作还在做，抓取证据却对不上
小站阶段，靠人工在后台逐条提交、靠表格记录哪些页面改过，通常够用。规模扩大后常见的情形是：动作照旧执行，但没人能说清上周新增的那批页面里，哪些真的被百度发现过。此时有两种解释都成立。
- 解释一：工作量问题。页面数量超过了人工能覆盖的节奏，提交和检查被漏掉，属于执行密度不足。
- 解释二：口径问题。动作没漏，但各方看的是不同环节的数据——有人看提交记录，有人看抓取日志，有人看索引结果，三者本就不该相等。
这两种解释对应的处理方向完全相反：前者要加人加工具，后者要先统一口径。分不清就动手，通常白做。
能区分两种解释的证据
关键证据是同一批页面的完整链路记录。挑一批新页面，按时间顺序记录三件事：是否被提交、是否在服务端日志里出现抓取、是否进入索引。假设一批一百个页面，其中九十个有提交记录、六十个有抓取记录、三十个进入索引，这个漏斗本身不能证明谁对谁错，但能回答问题出在哪一段。
如果提交记录就残缺不全，属于解释一，先解决覆盖密度；如果提交齐全而抓取缺失，属于解释二里的环节错位，需要先确认日志是否完整、抓取是否被其他规则挡住，而不是继续加提交量。抓取、索引、排名是不同环节，任何一段的数字变化都不能单独当成另一段的结论。
哪些工作到了这个阶段就不该再手工做
判断标准不是“累不累”，而是这项工作是否需要逐条判断、是否能被批量核对。以下几类在规模扩大后继续手工，代价会迅速超过收益。
- 批量提交与状态回查。逐个页面手动提交、手动记录结果，无法形成可比对的时间序列。应改为按批次操作并保留批次标识，让后续核对能定位到具体一批。
- 页面改动与上线记录。靠聊天记录和记忆追溯“这个标题什么时候改的”，在分歧出现时无法当证据。应让改动记录跟着页面走，而不是跟着人走。
- 站内链接与死链巡检。手工抽查只能覆盖抽样，规模大后漏掉的往往正是流量集中的那部分。应改为周期性全量扫描，人工只处理扫描结果。
- 重复内容与近似页面的比对。人眼在几百个页面上判断相似度不可靠，容易把正常的分页、筛选页误判为重复，也容易漏掉真正重复的模板页。
反过来，内容选题、页面结构设计、对某个异常页面的单独排查，这些需要判断力的工作仍适合人工主导，工具只负责把候选和证据摆出来。
一个可核对的短例子
假设某站发现“新页面收录变慢”，两个角色各执一词。做法是把争议转成一个可核对的项目：取最近三批各五十个页面，列出提交时间、日志中首次抓取时间、进入索引时间三列，由一方填、另一方核对，差异处标注原因。填完之后通常会看到，分歧集中在某一列的定义上，而不是事实本身。这一步的实际结果是：后续讨论不再围绕“到底做没做”，而是围绕“哪一列缺数据、补哪一段”。
把分歧转成项目时要注意的适用条件
这套做法成立的前提是日志可获取、页面有稳定标识、批次能对应上。如果日志本身不完整，先补日志，否则任何比对都会得出错误结论。另外要注意，请求量、抓取量或某项统计归零，不能单独证明处理正确——可能是日志采集中断、可能是抓取被临时限制、也可能是统计口径变了，需要结合其他证据排除。规模扩大后真正要放弃的不是手工本身，而是没有留痕的手工；只要动作能被批量核对，人工判断仍然是最有价值的那一环。
