抓取量高，不代表重要页面抓得好。一份匿名大型电商技术复盘显示：在 18 天的日志窗口里，74% 的搜索爬虫请求落在带查询字符串的 URL 或非 200 响应上，只有 25.7% 进入干净且返回 200 的 URL。更值得注意的是，类目/列表页每千次抓取带来的点击，约为商品详情页的 20 倍，但这类页面的日抓取量却下降了 32%。
先记住五个结论
- 先看抓取有没有到达规范、可索引、有业务价值的页面，不要先庆祝总请求量上涨。
- 按页面类型拆数据。这次样本中，列表页每千次抓取约带来 747 次点击，商品详情页约为 38 次。
- 参数 URL 和错误响应要分开诊断。带参数的 URL 可能返回 200，干净 URL 也可能返回错误。
- 分母不完整时，不要把局部结果写成全站结论。这份复盘的站点爬取触发了固定上限，服务器日志也只覆盖了部分国际站点。
- 上线后要证明“抓取去向变了”，再看重点页的首抓时间、展示和点击。
Google 对抓取预算的定义包含两个部分：主机可承受的抓取容量，以及搜索引擎对 URL 的抓取需求。这个问题主要出现在大型、高频更新或 URL 库存快速膨胀的站点。如果你的重要页通常在发布当天就会被抓，更应该先查索引、canonical、内容质量和内链。
| 匿名样本里的观察 | 实际含义 | 第一个动作 |
|---|---|---|
| 74% 的请求落在参数 URL 或非 200 响应 | 大部分抓取没有进入干净 200 URL | 先把参数浪费和状态码问题拆开 |
| 67.8% 的请求带查询字符串 | 追踪、投放、筛选、排序等变体占据了大部分发现路径 | 查清是哪些模板和链接在持续生成它们 |
| 10.7% 的请求返回非 200 | 跳转、4xx 和服务器错误又占用了一层资源 | 按页面类型拆 3xx、4xx、410 和 5xx |
| 列表页的抓取转点击效率约为商品页的 20 倍 | 高价值页面可能没拿到匹配的抓取 | 保住列表页的内链、sitemap、速度和可索引性 |
| 被测主站中，87.2% 的合规列表页未在窗口内被抓 | 优质库存没被看见，低价值 URL 却反复被请求 | 先重新分配发现路径，再谈增加抓取量 |
这些数字来自一个大型国际电商站的有限观察窗口，不是行业基准，也不能证明修改某一条规则就会带来流量增长。它的价值在于给出了清晰的诊断顺序：先分类请求，再量化去向，然后按页面类型排优先级，修改 URL 生成源，最后用同一批样本复测。
要先整理 canonical、可索引性和状态码，可以从 Convertos SEO 审查流程开始。
什么时候抓取预算才是电商网站的真问题
> SEO 负责人联合开发与运维看三件事：抓取是否打到低价值 URL、服务器是否因 Googlebot 变慢、重要页是否长期“已发现未收录”。用 Search Console 抓取统计加日志先看 14–28 天，修复后按同口径复测。
Google 对“抓取预算”的官方定义，不是一个固定配额，而是抓取容量上限与抓取需求的交集。前者可理解为 Googlebot 愿意对你的主机施加多大抓取负载，受响应速度、错误率影响；后者是 Google 觉得哪些 URL 值得更频繁抓，受页面热度、更新频率、重复度影响。官方也明确说，大多数小站不用担心抓取预算。
这也是它和普通收录问题的分界线：如果页面已经被抓到，但仍不收录，通常先查内容质量、重复、规范化和搜索需求，而不是把锅甩给电商网站 抓取预算。真正的问题，往往出现在大型或高频更新站点，尤其是筛选、排序、站内搜索、参数 URL 很多的电商。
举个常见场景：一个商品库很大的商城，颜色、价格、库存、排序都能拼出参数 URL。新品详情页上线后 3 天还没有抓取记录，但日志里 Googlebot 大量请求 ?sort=、?page=、?color= 组合页；同时高峰时段 TTFB 变慢，偶发 5xx。这里就不是单纯“收录慢”，而是低价值 URL 抢走了抓取需求，服务器表现又压低了抓取容量。Google 也专门提醒过参数 URL 会带来抓取问题。
定义表
| 概念 | Google 官方含义 | 你该看什么 | 常见误判 |
|---|---|---|---|
| 抓取容量上限 | Google 为避免压垮站点而控制的抓取强度 | TTFB、5xx/429、抓取统计中的响应情况、日志峰值 | 以为多提交链接就能提高抓取量 |
| 抓取需求 | Google 认为 URL 值不值得抓、多久抓一次 | 新品/类目页抓取频次、更新后再抓取速度、低价值 URL 占比 | 把“已抓取未收录”都当成需求不足 |
| 普通收录问题 | 页面被发现甚至被抓取，但未进入索引 | 重复内容、canonical、noindex、内容薄弱、内链弱 | 误判成抓取预算不够 |
判断规则
- 站点规模不大，且新页面通常当天或很快被抓取：先别做抓取预算专项。
- Search Console 长期有大量“已发现 – 尚未编入索引”，且重要页无抓取记录：进入专项排查。
- 日志显示 Googlebot 主要在抓参数页、分页、搜索页，而不是商品页和类目页：大概率存在预算浪费。
- 抓取高峰伴随响应变慢、5xx 或 429：先处理容量问题。
- 页面已频繁被抓仍不收录：优先查页面价值与重复，不要只谈预算。
实务上，先把 URL 库存分成“应抓、可抓但低优先级、不应抓”三层，再用日志验证 Googlebot 是否把时间花在对的地方。需要系统化排查时，可直接用 Convertos 审核流程 把症状、证据和复测口径统一起来。
哪些结构最容易制造无效 URL
这个匿名样本中，最大的浪费不是“页面太多”这么简单，而是同一份内容被不断换成新地址。带查询字符串的 URL 占到被测站点爬虫请求的 67.8%。其中很多是追踪、商品投放、活动、筛选或排序参数，去掉参数后，对应的干净页面早已存在。
诊断时要把“地址低价值”和“响应低价值”分开。前者由 URL 规则制造，例如参数、重复路径和分页；后者由服务器响应产生，例如跳转、4xx、410 和 5xx。两者会重叠，但负责人和修法不一样。
| 浪费源 | 常见现象 | 日志需要证明什么 | 应从哪里修 |
|---|---|---|---|
| 追踪/投放参数 | 同一商品出现大量活动地址 | 请求占比高，去掉查询字符串后都落到同一干净页 | 不再从内链和数据源生成这些变体，保留一个规范目标 |
| 筛选/排序 | 一个列表页被放大成成千上万个组合 | 大量返回 200 的近似列表，却没有独立搜索需求 | 只保留经过需求验证的落地页，减少其他组合的可发现入口 |
| 深分页 | 列表抓取被分散到很多翻页状态 | 抓取和展示是否分散到过深页码 | 保留真正需要的发现路径，停止制造无限或重复序列 |
| 旧路径跳转 | 爬虫反复经过旧 URL 和跳转链 | 3xx 是否长期集中在少数路径规则 | 把内链直接改到最终目标，合并跳转链 |
| 永久下架商品 | 旧商品 URL 长期占据 4xx/410 请求 | 站内是否还在链接或提交这些 URL | 保留真实的 404/410，移除内部入口，只在确有替代时才转向 |
| 重复商品路由 | 两套 URL 表示同一个商品 | 共享商品标识，两边却都自指 canonical | 选一套主路由，同步收口内链、canonical 和 sitemap |
最新观察窗口里，非 200 响应占爬虫请求的 10.7%，其中 4xx 约占全部活动的 8.1%。永久下架商品返回 410 本身可能完全正确，但爬虫仍频繁回访，说明站内、站外或历史抓取记录还在持续提醒搜索引擎。
Google 的分面导航文档建议控制筛选和参数组合制造的抓取空间。不过，不能因为 URL 里都有 ? 就一刀切。有独立搜索需求的筛选落地页，和纯追踪参数，不应用同一套规则。
比较稳的做法是，修 robots.txt 之前先建一张 URL 规则清单：谁生成它，为什么存在，爬虫请求多少，返回什么，最后再决定保留发现、合并、移除内链，还是返回正确的终止状态。
用服务器日志看爬虫实际抓了什么
先保留经过验证的搜索爬虫请求，再给每次请求标注 URL 形态、状态码、页面类型、canonical 状态和站点。这一步能避免一个大数字掩盖两个不同问题。匿名样本中，67.8% 的请求带查询字符串，10.7% 返回非 200，但两类会重叠，所以合并占比是 74%，不是 78.5%。
| 字段 | 示例分类 | 能支持什么决策 |
|---|---|---|
| 验证后的爬虫 | Googlebot Smartphone | 排除伪装 UA 和其他爬虫 |
| URL 形态 | 干净、追踪参数、筛选、排序、分页、替代路由 | 把抓取活动对回具体生成源 |
| 响应 | 200、3xx、404、410、5xx | 分清重复、跳转、终止页和容量故障 |
| 页面类型 | 商品、列表、文章、搜索、店铺 | 把抓取分配和搜索价值放在一起比 |
| canonical | 自指、指向他页、缺失 | 判断抓到的地址是不是规范版本 |
| 可索引性 | 可索引、noindex、被阻止、重复 | 避免把所有 200 都算成有效抓取 |
| 站点/市场 | 被测站点 A、被测站点 B | 暴露采集缺口和市场差异 |
| 搜索结果 | 展示、点击、暂无观察结果 | 按页面类型计算抓取转搜索产出 |
然后把三个比率放在同一张表里：
- 干净 200 占比 = 无查询字符串且返回 200 的请求 / 全部验证后爬虫请求。
- 有效抓取占比 = 到达规范、可索引、高优先级 URL 的请求 / 全部验证后爬虫请求。
- 每千次抓取点击 = 同一批页面的 Search Console 点击 / 该批页面的爬虫请求 × 1,000。
第一个比率最好算，但它只是技术底线。一个干净 200 URL，仍可能重复、canonical 指向他页、noindex，或没有什么业务价值。第二个比率需要把日志和站点爬取/URL 库存合并。第三个比率把搜索产出加进优先级，但不应该被写成“一次抓取直接造成一次点击”。
还要把限制和结果放在一起。这份复盘中，两次站点爬取都在固定 URL 上限停止，没有进入第五层深度；服务器日志又只覆盖部分国际站。因此，绝对 URL 数只能当下限。日志里没有某个站点，首先说明采集缺口，不能说明爬虫没去。
修复发现与重复问题，又不误伤有价值页面
SEO 负责定义规范页，产品与研发负责路由、状态码和 robots 落地；先查日志里的 Googlebot 命中、Search Console 的“已发现/已抓取未收录”、以及参数页占比，再用两周对比复测抓取是否回到商品页与类目页。
处理电商网站 抓取预算，关键不是“多拦”，而是把发现路径和规范信号对齐。Google 明确把抓取预算理解为抓取容量与抓取需求的交集，大型且高频更新网站才更需要专项优化。所以修复顺序应是：先保留有价值 URL 的可发现性，再压缩重复 URL 库存。
例如，一个商品库每天新增上千个 SKU，但站内筛选会生成 ?color=black&sort=price_asc&page=4 这类参数页。日志里 Googlebot 大量请求这些 URL，真正新品详情页却抓得慢。此时不要直接全站封 robots。更稳妥的做法是：商品页、核心类目页继续放在 HTML 内链和 XML Sitemap；筛选页若仅是重复集合，保留可访问但指向规范类目 canonical；无搜索价值的站内搜索结果页可用 noindex，且不要再放进 Sitemap。若某批旧活动页已永久下线且无替代，返回 404/410，比软 404 或跳首页更清晰。Google 对抓取预算的说明也强调，低价值和重复 URL 会分散抓取需求。
| 问题类型 | 典型信号 | 首选动作 | 配套控制 | 复测指标 | 风险提醒 |
|---|---|---|---|---|---|
| 参数筛选重复页 | 日志中参数 URL 命中高，规范页抓取低 | 保留少量高价值筛选页，其余设 canonical 到规范类目 | 从主导航移除无价值筛选链接；Sitemap 仅留规范页 | Googlebot 命中参数页占比下降，类目页抓取上升 | canonical 不是强制指令，若内容差异大可能不生效 |
| 站内搜索结果页 | /search?q= 被频繁抓取 |
noindex，必要时限制内链入口 |
不提交 Sitemap；避免分页无限扩展 | 搜索结果页抓取下降 | 若 robots 先屏蔽，搜索引擎可能看不到 noindex |
| 已下线商品/活动页 | 大量 200 空页、跳首页 | 无替代则 404/410；有替代则单跳 301 | 更新内链与 Sitemap | 4xx 合理上升，软 404 下降 | 不要把所有失效页都 301 到首页 |
| 重复分页/排序页 | ?sort=、?page= 组合爆炸 |
仅保留必要分页；排序页降权处理 | 减少模板内链暴露 | 抓取更集中到前几层列表和商品页 | 粗暴封禁可能切断商品发现路径 |
站点抓取器可以核对 canonical、robots、状态码和内链暴露面，但不能替代服务器日志与 Search Console。社区经验适合提供排查线索，不应被当成平台规则本身。
最后，修复后别只看收录量。至少复测两轮：一轮看日志里 Googlebot 是否从重复 URL 转向商品页；一轮看 Sitemap 中新增页是否更快被抓到。若还不稳，继续从模板内链和 URL 生成规则回查。需要系统梳理时，可先用 SEO 审核清单 把发现、规范化和状态码放到同一张表里。
用“每千次抓取点击”排页面类型的优先级
抓取优先级不该脱离页面类型。这个观察窗口中，类目/列表页每千次爬虫请求约带来 747 次点击，商品详情页约为 38 次，相差约 20 倍。同一时期，列表页的日抓取量下降了 32%，而被测站点的爬虫总量上升了 32%。
这不等于每个列表页都该获得 20 倍抓取，也不等于商品页不重要。这是观察数据，而且两类页面的任务不同。商品页承接长尾需求和库存细节，列表页承接品类需求，还要把内链分配给商品。这个比率的作用，是暴露一个值得查的错配。
每千次抓取点击 = 同一批页面的 Search Console 点击 / 验证后爬虫请求 × 1,000| 页面类型 | 样本中每千次抓取点击 | 其他证据 | 应该先问什么 |
|---|---|---|---|
| 类目/列表页 | 约 747 | 技术合规率高，但被测主站大部分合规 URL 没在窗口内被抓 | 参数和错误正在消耗请求时，高价值列表是不是被饿死了？ |
| 商品详情页 | 约 38 | 合规性改善，但平均内链数下降，响应时间变慢 | 哪些商品有需求、有库存，值得加强内链？ |
| 重复商品路由层 | 约 116 | 部分 URL 与另一套商品路由共享同一商品标识，跳转也在恶化 | 它应该被推广，还是应该被合并？ |
列表页的情况很典型：价值高，但抓取注意力低。样本中，约 94.8% 的已抓列表页符合复盘里的技术合规定义，但被测主站仍有约 87.2% 的合规列表页没有在日志窗口内被抓。它们的响应时间也慢于其他主要模板，合法 hreflang 在被测主站的覆盖还不到 1%。高产出不会抹掉这些问题，只会让它们更值得先修。
商品页则不要均匀分内链。两次爬取之间，每个商品页获得的平均唯一内链数下降了 17%，而有展示的长尾商品页反而增多了。可以把在售状态、搜索需求、毛利/战略价值、新鲜度、技术可索引性和现有展示放在同一批样本中，只对真正能受益的商品加强链接。
一句话的判断规则是：用“每千次抓取点击”找到搜索产出高的页面类型，再确认具体 URL 是否规范、可索引、响应足够快、有合理内链，且位于干净 sitemap 中。这个指标用来排查优先级，不会替代技术合规。
先证明抓取去向变了，再看搜索结果
一次成功的修复，不一定会让爬虫请求总数上升。它应该让更多请求进入干净、规范、可索引的高优先级页面，同时不制造新的发现缺口。日志先验证抓取是否转移，索引和搜索结果再用同一批页面复测。
| 验收层 | 指标 | 匿名复盘基线 | 改善是什么样 |
|---|---|---|---|
| 抓取分配 | 干净 200 占比 | 25.7% | 持续上升，且不是因为日志漏采或错误被隐藏 |
| 参数 | 带查询字符串的请求占比 | 67.8% | 无必要的追踪、投放、排序和筛选变体下降 |
| 错误 | 4xx 占爬虫请求的比例 | 最新部分月份窗口为 8.1% | 爬虫减少访问站内仍被引用的死 URL，正确 404/410 仍然保留 |
| 列表覆盖 | 被抓的合规列表页占比 | 被测主站为 12.8% | 被选中列表页的首抓更快，覆盖更高 |
| 效率 | 列表页每千次抓取点击 | 约 747 | 抓取扩展到更多优先列表时，搜索产出保持稳定或改善 |
| 商品内链 | 每个商品页的平均唯一内链 | 两次爬取间下降 17% | 经过需求筛选的商品样本获得更强内链 |
上线 7 天先做运行检查，28 天再做结果复盘。前者用来抓 URL 路由异常、错误上涨、服务器压力和参数继续被生成等问题。后者留出更多时间，观察重抓、索引、展示和点击。两次比较要保持窗口、爬虫验证规则、站点覆盖和页面样本一致。
发布记录也很重要。这份复盘中，4xx 占比一度升到单月 14.8% 的高点，后来在部分月份窗口降到 8.1%。这是明显改善，但还不能知道是哪次发布造成的。应该把拐点对回发布记录，再查怀疑的改动是不是真的影响了对应 URL 规则和日志。不能只因为时间靠近，就写成因果。
如果一种浪费下降，另一种却上升，就先停止扩大。例如，封禁一组参数可能让日志里的请求减少，但内链仍在制造同一批 URL；也可能让搜索引擎在看见 canonical 或 noindex 之前就无法抓取。robots.txt 控制的是抓取，本身不是删除索引的指令。先用一组参数或一批页面做小范围验证，确认实际响应和渲染后内链，再扩大。
最后把证据固定在同一份 SEO 审查里：日期窗口、爬虫验证规则、站点范围、URL 分类版本、页面样本、发布记录和上面的指标。这样下一次复盘是同口径比较，不是另一次凭感觉清理。
声明
本文数据来自 2026 年的一次非公开技术复盘，经授权后以匿名、聚合形式使用。公司、平台、域名、市场、人员、URL 规则和实施细节均已删除，原始幻灯片没有公开。数字对应 18 天日志窗口和设有抓取上限的站点扫描，且日志只覆盖部分站点，因此绝对数量只能视为下限。这些数据说明观察关联，不是行业基准，也不是因果实验。
常见问题
这些问题来自本次研究中反复出现的 SERP 问题信号、搜索相关问题、视频主题和社区讨论；回答以官方文档和本文的测量框架为准。
robots.txt 屏蔽参数 URL，就能省下抓取预算吗？
有时能，但也可能让 Google 看不到 canonical 或 noindex。先从内链和 sitemap 停止制造这些地址，再用一组参数小范围验证。
canonical 能阻止重复 URL 被抓吗？
不能。canonical 是合并信号，不是抓取禁令；它要和干净内链、sitemap 以及 URL 生成规则一起收口。
“有效抓取占比”怎么算？
用进入规范、可索引、高优先级 URL 的验证后爬虫请求，除以全部验证后请求。它应和“干净 200 占比”一起看，避免把技术正常但低价值的页面算成成功。
抓取预算改动多久复测一次？
上线 7 天先查路由、错误、延迟和参数是否继续生成；第 28 天再看重抓、索引、展示和点击。两次比较必须保持页面样本和计算口径一致。