爬行覆盖率 = 搜索引擎蜘蛛在你的站点上实际抓取的 URL 去重数量 ÷ 站点允许被抓取的 URL 总数。分析它的核心动作只有三步：从服务器日志里提取真蜘蛛请求、拿到全站 URL 清单、两者做差集并按目录聚合定位缺口。
爬行覆盖率怎么算才准确？
结论：分母要用「站点可爬 URL 总数」，而不是 sitemap 里提交的数量，否则会把未提交但通过内链可到达的页面算漏。实操上建议同时算两个口径：覆盖率A = 已爬 URL / sitemap URL 数、覆盖率B = 已爬 URL / 站内可爬 URL 总数（首页出发零屏蔽、可返回 200 的页面）。A 反映 sitemap 提交质量，B 反映真实抓取缺口，B 低于 60% 就说明存在结构性问题。
时间窗口别取太短。Google Search Console 的「抓取统计信息」保留 90 天数据，建议用最近 30 天日志做一次统计，用最近 7 天做异常波动对比。
怎么从服务器日志里提取蜘蛛的爬取记录？
结论：用 UA 字段筛选 + URL 去重即可，但必须做反向 DNS 验证，否则会把冒充蜘蛛的采集器算进去。Nginx/Apache 默认 combined 日志格式下，UA 在第 6 个双引号字段，请求路径在空格分隔的第 7 个字段：
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20
# 提取 Googlebot 抓取的 URL 并去重
grep -i "Googlebot" access.log | awk '{print $7}' | sort -u > crawled_google.txt
# 提取百度蜘蛛
grep -i "Baiduspider" access.log | awk '{print $7}' | sort -u > crawled_baidu.txt
验证真伪：Googlebot 的官方做法是对来源 IP 做反向 DNS，解析结果必须以 googlebot.com 或 google.com 结尾，再正向解析回去核对；百度蜘蛛的 IP 段在百度搜索资源平台的「抓取诊断」里有官方公布列表。第三方采集器（如各种 Python-requests、Scrapy 打上假 UA）如果混入统计，覆盖率会被系统性高估。
全站 URL 清单怎么拿到？
结论：优先从数据库或 CMS 导出，其次用 sitemap，最后用站内爬虫跑一遍，三条来源取并集。sitemap 单文件上限是 50,000 个 URL 且不超过 50MB（未压缩），超过要拆分成索引文件，很多站点覆盖率低正是因为 sitemap 被截断。用 Screaming Frog（免费版可爬 500 个 URL）或 wget --spider -r 跑一遍全站，能捞出没进 sitemap 的内链页面。
怎么做差集，找出没被爬的页面？
结论：用 comm -23 求差集，再按目录聚合，就能看出是整站问题还是局部问题。两个文件都必须先 sort -u 排好序：
# 全站路径归一化（去掉域名）
cat all_urls.txt | sed 's#^https\?://[^/]*##' | sort -u > all_paths.txt
# 未被 Google 抓取的路径
comm -23 all_paths.txt crawled_google.txt > not_crawled.txt
# 按一级目录聚合，看哪个板块最严重
cut -d/ -f2 not_crawled.txt | sort | uniq -c | sort -rn | head -20
如果差集集中在 /tag/ /search/ 这类参数或聚合页，属于正常现象，蜘蛛在主动节省抓取预算；如果集中在商品详情页或文章详情页，就是真问题。
覆盖率低有哪些常见原因，怎么排查？
结论：按「先封禁、后结构、再性能」的顺序排查，80% 的缺口出在前两项。逐条核对：
- robots.txt 误屏蔽：用
curl -A "Googlebot" https://example.com/robots.txt 拉取实际生效内容，再在 GSC 的 robots.txt 测试工具里验证某条 URL 是否被拦。
- noindex 或 X-Robots-Tag 误加：会导致「抓取了但不索引」，在日志里表现为抓取量正常但索引量为零。
- 内链孤岛：Google 官方建议重要页面的点击深度不超过 3 层。用 Screaming Frog 的「爬取深度」报告筛出深度为 0（无内链指向）的页面。
- JS 渲染依赖：Googlebot 能渲染 JS 但有排队延迟，百度对 JS 渲染的支持有限，内容靠前端异步加载的页面建议改 SSR 或首屏直出。
- 服务器拖慢抓取：GSC 抓取统计里有「抓取响应时间」，服务器平均响应超过 500ms 时蜘蛛会主动降频。日志中 5xx、429、超时请求占比超过 1% 就要先修服务端。
- 抓取预算被稀释：分页、筛选、排序参数会生成海量近似 URL。用 canonical 指向主 URL，或在 robots.txt 里直接屏蔽参数路径。
优化后怎么验证有效？
结论：观察 14-30 天的抓取频次趋势，而不是看单日数据。在 GSC「设置 → 抓取统计信息」里看按响应类型（200/301/404/5xx）分组的折线图，在百度搜索资源平台看「抓取频次」和「抓取异常」两个报表。判断标准：目标目录的日均抓取 URL 去重数上升，且 5xx 占比下降，两个指标同时改善才算修复成功。
整体思路就是：日志提数 → 验证蜘蛛真伪 → 全站清单求差集 → 按目录定位缺口 → 逐条排查封禁/结构/性能 → 用 14 天以上的趋势数据验收。覆盖率是结果指标，真正的抓手永远是内链结构、robots 规则和服务器响应速度这三件事。
