收录：访问量突增时先扩容还是先查配置
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /15c0f5e76973.html
📄
收录：访问量突增时先扩容还是先查配置
先给结论：如果突增同时伴随抓取频率上升、响应时间线性变长、错误率基本不变，更像资源压力；如果突增集中在少数 URL、响应时间正常但错误码或跳转异常升高，更像配置错误。两者的处理顺序不同，误判会让你在错误的层面消耗时间。
一个矛盾现象：收录相关请求涨了，结果却没变好
假设某天来自搜索引擎的请求量明显上升，但后台看到的有效收录页面数没有同步增长，甚至新页面依然停在“已发现未收录”。这时团队通常分成两派：一派主张立刻扩容，认为抓取机会来了，接不住就浪费；另一派主张先停手查配置，认为量涨而结果不动，说明入口本身有问题。
两种做法都成立，但成立条件不同。扩容解决的是“能接住更多请求”，配置修复解决的是“接住的请求是否指向正确内容”。判断错了，扩容只是让错误请求更快地被浪费掉，改配置则可能错过一次真实的抓取窗口。
两种解释各自长什么样
资源压力：瓶颈在承载能力
资源压力的典型特征是请求分布相对分散，覆盖多个目录和模板，响应时间随并发上升而变长，5xx 或超时开始出现。此时服务器、数据库连接、缓存命中率或带宽是限制项。它的代价是扩容需要成本和时间，而且如果抓取是短时脉冲，扩容后可能长期闲置。
配置错误：瓶颈在指令与入口
配置错误的典型特征是请求集中在少数 URL，或者反复请求同一批带参数的地址；响应时间正常，但返回的是 3xx 跳转链、软 404、错误规范标签，或 robots.txt 恰好挡住了关键路径。这类问题不会因为加机器而缓解，因为请求本身就没有落在该被收录的版本上。
需要提醒的是，抓取限制不等于可靠的索引移除，站点地图也不保证收录。请求量上升本身不能证明配置正确，请求量下降也不能单独证明配置错误——它可能只是抓取预算的正常波动。
能区分两种解释的证据
按下面的顺序取样，比凭感觉站队更可靠：
- 看请求分布：导出突增时段的访问日志，按 URL 聚合。若头部少数 URL 占据大部分请求，先怀疑配置；若请求均匀铺开，先怀疑资源。
- 看响应时间与错误码的关系：响应时间随并发上升且错误率同步上升，偏资源；响应时间平稳但 3xx、4xx 或软 404 比例升高，偏配置。
- 看返回内容与预期版本是否一致：抽查若干 URL，确认返回的是规范版本、状态码正确、没有被 robots.txt 或 meta 指令挡住。这一步能直接暴露指令冲突。
- 做一次小范围对照：只对突增涉及的目录放宽或收紧一项配置，观察后续请求是否转向正确 URL。动作结果会告诉你问题在哪一层。
假设一个短例子：突增期间 80% 请求集中在带排序参数的列表页，响应时间稳定在 200 毫秒以内。按上面的顺序，第 1 步就会把结论推向配置——此时扩容不会让这些参数页变成有效收录入口，应该先处理参数归一与规范指向；只有当请求分散、响应时间随并发恶化时，才把资源扩容排到前面。
取舍条件与代价
选择先扩容的条件是：请求分散、响应时间已成瓶颈、业务对可用性敏感，且你确认入口指令没有明显冲突。代价是成本上升，且如果抓取是短时脉冲，收益有限。
选择先查配置的条件是：请求集中、错误码或跳转异常、有效收录长期不动，且你有能力在短时间内完成指令核查与修正。代价是可能错过一次抓取窗口，所以核查要限时，不能无限期排查。
实际操作上，可以先做一件低成本的事：在突增时段保留一份完整日志样本，同时暂停非必要的批量变更。日志是后续区分两类原因的唯一依据，一旦丢失，就只能靠猜测决定下一步。
动作之后如何决定下一步
如果放宽某项抓取限制后，请求开始转向规范 URL 且有效收录出现变化，说明此前是配置层面的问题，下一步应固化这项配置并复查其他目录是否存在同类冲突。如果放宽后请求量继续上升但响应时间恶化，说明资源才是限制项，下一步应回到容量规划，而不是继续改指令。
无论走哪条路，都不要把请求量、抓取量或某一项统计的升降单独当作结论。它们同时受抓取预算、内容更新节奏和外部链接变化影响，只有结合请求分布、响应时间和返回内容三项证据，才能判断这次突增该先扩容还是先查配置。
