收录掉了一个季度没人发现用 GSC 覆盖率报告和访问日志对账的排查记录适用读者负责制造业 B2B 官网的技术同学、兼管 SEOSearch Engine Optimization搜索引擎优化的后端开发、需要向老板解释收录为什么掉了的人。阅读前提网站已在 Google Search Console以下简称 GSC验证服务器保留访问日志。事情是怎么被发现的今年 3 月 11 日我去一家做精密蜗轮减速机的工厂化名「恒达传动」驻场。市场部的小周把我拉到工位前语气里带着点委屈“领导说咱官网在 Google 上搜不到了你是搞技术的你给看看。”我先在 Google 上用site:hengda-example.com查了一下返回结果少得可怜。然后打开他们 GSC 后台一看「网页索引编制」报告里的已编入索引数量2025 年 11 月还有 1180 页到 3 月初只剩 412 页。掉收录这件事不是哪天突然发生的是过去三个多月慢慢漏光的中间没有任何人看后台。这不是个例。做工业品官网的团队大多没有专职 SEO网站打不开吗能打开啊于是没人管收录。等销售在海外展会上被客户问到你们网站上怎么找不到这个型号问题已经攒了一个季度。GSC 覆盖率报告先看什么GSC 的「网页索引编制」报告旧版叫覆盖率报告Coverage Report把所有已提交的 URL 分成两大类返回了 200 且已编入索引的和未编入索引的。后者才是重点里面每一行排除原因都值得点进去看数量。恒达官网当时的排除原因分布是这样的3 月 12 日导出的数字仅代表该站当时状态排除原因GSC 原文页面数初步判断已编入索引412正常存量重复网页Google 选择的规范网页与用户指定的不同486详情页带 session 参数导致重复已编入索引但被 robots.txt 屏蔽0见下文此处反而是线索找不到40457老型号下线正常软 404soft 40423搜索结果空页被抓已抓取 - 尚未编入索引31抓取预算不足或质量存疑看到这份表第一反应是那个 486 的重复网页数字。但真正让我后背发凉的是另一件事已编入索引但被 robots.txt 屏蔽是 0——而他们 1 月中旬刚换过 CDN运营顺手改了 robots.txt。我立刻去翻了改版记录果然新的 robots.txt 里多了一行Disallow: /products/本意是想屏蔽一个内网测试目录路径写串了。也就是说1 月 14 日上线的新 robots.txt 把整个产品目录封了。Google 的处理方式很温和——已索引的页面不会立刻消失而是在接下来几周里随着重新抓取陆续从索引里退出同时因为被封了 robotsGSC 里连被屏蔽的记录都看不到被 robots 封锁的 URL 抓都抓不了自然不进覆盖率报告的正常统计。这就是为什么掉得悄无声息。访问日志对账GSC 说的和爬虫做的是不是一回事GSC 报告是 Google 的一面之词而且数据延迟好几天。要确认Googlebot 到底来没来、来了抓的是哪些 URL得回到服务器自己的访问日志。这是我最推荐的对账手段GSC 说某类 URL 被排除日志能告诉你爬虫是不是真的来过、来了多少次、拿到什么状态码。恒达用的是 nginx日志按天切分保留 90 天。环境Python 3.12 / nginx 1.24 标准日志格式。下面这段小脚本我改了三四处之后基本可以在任何 nginx 日志上复用importrefromcollectionsimportCounterfrompathlibimportPath# nginx 默认 combined 格式的一行日志# 正则只抓用得到的字段写太长在日志量大时会很慢LINEre.compile(r(?Pip\S) .*?(?Pua[^]*).*?(?Preq\S) (?Purl\S)[^]* (?Pstatus\d{3}))defis_googlebot(ua:str)-bool:# 真实校验应做反向 DNS工程上先用 UA 粗筛returnGooglebotinua countsCounter()# 逐天逐行扫nginx 按天切分的日志直接丢进来就行forfinPath(logs/2026-03).glob(*.log):forlineinf.open(encodingutf-8,errorsignore):mLINE.search(line)# 粗筛UA 带 Googlebot 的行才进入统计ifnotmornotis_googlebot(m[ua]):continueurlm[url].split(?)[0]# 归并到目录级看抓取都花在哪个目录上prefix/.join(url.split(/)[:3])counts[prefix]1# 对照组把 202603 换成 202601 再跑一遍就能对比改版前后的抓取分布forprefix,nincounts.most_common(10):# 输出目录级抓取次数和 GSC 覆盖率数据交叉对账print(f{prefix}\t{n})跑 3 月 1 日到 10 日的日志结果很能说明问题/products/目录的 Googlebot 请求是0 次而/根路径和/news/加起来每天还有一两百次。作为对照我又拉了 1 月 10 日改 robots 之前的日志/products/每天有 60 到 90 次抓取。两边一对照时间线就锁死了1 月 14 日之后Google 对产品目录的抓取彻底停了。顺带在日志里还发现一个次要问题URL 分析里?sid开头的会话参数占了抓取量的三成多这些页面内容完全一样白白消耗抓取预算Crawl Budget抓取预算。断点在哪抓取、索引与排序的机制差异排查到这里有必要把搜索引擎的流水线捋一遍不然很容易把掉收录和排名掉了混为一谈。搜索引擎对网页的处理分三步抓取Crawl→ 索引Index→ 排序Ranking三个环节各自可能断掉断的位置不同现象和解法完全不一样。拦截放行是否是否提交 / 发现 URLrobots.txt 放行?不抓取, 页面进不了任何报告抓取 拿到 HTML 与状态码noindex / 404 / 软404?不索引, 进覆盖率报告排除项内容分析与去重 规范化 canonical判定为重复或低质?重复网页省略, 不占索引进入索引排序 面向具体查询恒达的断点在第一步和第三步之间robots 封禁让/products/直接停在抓取之前?sid参数页面则卡在去重环节被归并掉。很多人以为页面只要能访问就会收录实际上从可访问到进入索引中间隔着 robots 放行、状态码健康、内容去重三道闸门任何一道关了都会掉收录而且 GSC 里未必有醒目提示。robots 这道闸门尤其阴险它发生在抓取之前所以 GSC 的抓取统计里根本不会出现这些 URL覆盖率报告也不会把它们列进被屏蔽——你只能从已索引数量持续下降 日志里抓取归零这两个反向信号推出来。对账的固定流程后来我把这套排查固化成了一个流程图团队里谁遇到收录异常都照着走一遍抓取为零抓取正常但不索引发现收录异常GSC 已索引数量导出 与 3 个月前对比覆盖率报告排除原因分类计数服务器日志统计 Googlebot 抓取分布日志抓取 与 GSC 数据对得上吗?查 robots.txt / noindex / CDN 防火墙查状态码 / 软404 / 重复内容与 canonical修复后用 URL 检查工具请求编入索引每周对账一次, 观察恢复曲线这里面有两个细节值得强调。一是对账要比对两个口径GSC 记录的是Google 认为它对你的站做了什么日志记录的是你的服务器实际看到了什么两者对不上的时候日志是更可信的那份。二是 URL 检查工具URL Inspection里的请求编入索引有配额限制只对关键页面用别拿来全站推。修复与恢复过程修复动作本身不复杂1 月埋的雷 3 月拆robots.txt 撤掉Disallow: /products/线上用 curl 确认生效详情页加 canonical 指向无参数的干净 URL并在响应头里关掉会话写死进链接的逻辑给 GSC 提交了一份新的站点地图只含 600 个真实产品页软 404 的 23 个页面改造成正常的无结果页返回明确的 404。验证 robots 是否真的放行用 curl 就够了环境任意带 curl 7.x 的终端# 确认 robots.txt 已经不再屏蔽产品目录curl-shttps://www.hengda-example.com/robots.txt|grep-nproducts||echoOK: 无 products 规则# 看产品详情页响应头里有没有意外出现的 X-Robots-Tagnoindex 会藏在响应头里curl-sIhttps://www.hengda-example.com/products/worm-gear-50.html|grep-ix-robots-tag||echoOK: 响应头无 noindex如果站点页面较多光靠 curl 抽查不够建议再跑一段 Python 脚本把 robots.txt 里的 Disallow 规则和站点地图里的 URL 全量比对一遍确认没有误伤正常路径。环境Python 3.12需要urllib标准库和xml.etree.ElementTree标准库无需第三方依赖importreimporturllib.robotparserimporturllib.requestimportxml.etree.ElementTreeasETfromurllib.parseimporturlparse,urljoin SITEMAP_URLhttps://www.hengda-example.com/sitemap.xmlROBOTS_URLhttps://www.hengda-example.com/robots.txtUSER_AGENTMySiteAuditBot/1.0deffetch(url:str)-str:requrllib.request.Request(url,headers{User-Agent:USER_AGENT})withurllib.request.urlopen(req,timeout15)asresp:returnresp.read().decode(utf-8,errorsignore)defextract_sitemap_urls(sitemap_xml:str)-list[str]:rootET.fromstring(sitemap_xml)ns{sm:http://www.sitemaps.org/schemas/sitemap/0.9}urls[]# 站点地图可能是索引文件里面再套子地图forlocinroot.findall(.//sm:loc,ns):textloc.text.strip()iftext.endswith(.xml):urls.extend(extract_sitemap_urls(fetch(text)))else:urls.append(text)returnurlsdefmain()-None:rpurllib.robotparser.RobotFileParser()rp.set_url(ROBOTS_URL)rp.read()sitemap_urlsextract_sitemap_urls(fetch(SITEMAP_URL))blocked[]forurlinsitemap_urls:# 用 Googlebot 身份判断和线上实际抓取保持一致ifnotrp.can_fetch(Googlebot,url):blocked.append(url)print(f站点地图共{len(sitemap_urls)}个 URL被 robots.txt 屏蔽{len(blocked)}个)forurlinblocked:print(f -{url})if__name____main__:main()脚本逻辑分三步先用urllib.robotparser读取并解析线上 robots.txt再用xml.etree.ElementTree解析站点地图支持索引型站点地图递归展开最后逐个 URL 用can_fetch(Googlebot, url)判断是否被 Disallow 拦截。跑完如果输出里出现/products/这类正常路径说明 robots 规则仍有误伤需要回到 curl 那一步继续核对。恢复不是线性的。按我们自建监测口径每周三用site:查询和 GSC 后台各记一次非任何第三方工具数据3 月 19 日索引数还在 4054 月 2 日回到 6204 月 23 日到 9805 月中旬基本回到 1150 附近前后花了两个多月。前两周最煎熬因为修复后日志里 Googlebot 对/products/的抓取恢复得很慢——它对被长期封禁的站点会留有戒心抓取频率是逐步爬回来的。时间点已编入索引GSC/products/ 日均抓取日志备注2026-01-10117273换 CDN 与改 robots 前一周2026-03-124120进场排查当天2026-04-0262021修复后第三周2026-05-14114868基本回到事故前水平复盘为什么一个季度没人发现总结下来有三条经验说给同样没人管 SEO 的团队收录监控要放报警。GSC API 每天拉一次已索引数量环比掉 10% 就发消息到群成本一小时恒达这次损失的三个多月本可以缩到一周以内。改 CDN、改 robots、改认证策略这类动作上线当天就该跑一遍日志对账确认 Googlebot 还能正常进站。CDN 的 WAF 误拦 Googlebot 也是高发事故和这次的 robots 封禁是同一种病。换 CDN 后响应头要全部核对X-Robots-Tag 里残留 noindex、Vary 头异常都会让索引悄悄掉这些在页面上是看不出来的。也有没彻底解决的问题?sid的重复页面在修复后一个月才从 GSC 的重复网页分类里清干净Google 收回这些 URL 的速度远慢于我的预期最后靠站点地图 内链清理双管齐下才压下去。最后靠站点地图 内链清理双管齐下才压下去。百度收录差异的初步观察同一家工厂在百度收录同样从 800 多掉到 300 出头但症结和 Google 完全是另一套。Google 这边是 robots.txt 封禁百度那边我虽然没做完整排查但结合日志和抓包有几个高度可疑的方向和 Google 的排查路径差异很大HTTPS 证书链不完整。换 CDN 时只配了主域名的证书www和几个子域名的证书链没补全。Google 对证书链校验相对宽松抓取时能容忍部分中间证书缺失百度爬虫对证书链的校验更严格握手失败就直接放弃抓取日志里表现为百度 UA 的请求集中在首页产品页几乎为零。这个用openssl s_client -connect www.hengda-example.com:443 -showcerts就能验证证书链是否完整。JS 渲染依赖。产品详情页的型号参数是前端 JS 异步加载的Google 的渲染队列会等 JS 执行完再索引百度对 JS 渲染的等待和重试策略更保守拿到的 HTML 里没有型号文本判定为低质空页收录自然上不去。这个用curl拿到的静态 HTML 和浏览器渲染后的 DOM 一对比就能看出来。百度爬虫 UA 被 CDN 误拦。CDN 的 WAF 规则里只放行了 Googlebot 的 UA百度的Baiduspider被当成异常流量拦了一部分。这个在 CDN 的拦截日志里能看到Baiduspider的 403 记录和 Google 那次 robots 封禁是同一类上线动作没做全量对账的毛病。和 Google 排查路径的差异点在于Google 那边靠「GSC 覆盖率报告 访问日志对账」就能定位百度没有等价的覆盖率报告只能靠「百度站长平台的抓取异常 服务器日志 证书链检查」三条线交叉。而且百度对 HTTPS 证书和 JS 渲染的敏感度明显高于 Google同样的站点在两边收录表现可能差一个量级。百度站长平台对应的排查工具是「抓取异常」和「链接分析」前者能看到百度爬虫抓取失败的 URL 和原因证书错误、连接超时、UA 被拦都会列出来后者能看哪些页面被百度收录、哪些被丢弃。另外「索引量」报表可以按天看收录曲线和 Google 的「网页索引编制」报告对账思路一致只是数据粒度更粗、更新更慢。补一句和 GEOGenerative Engine Optimization生成式引擎优化的关系这次修复让站点恢复干净、结构清晰这既是传统 SEO 的底子也是内容将来被 AI 搜索引擎引用的前提——索引都进不去的页面谈不上被任何引擎引用。参考与延伸Google Search Console 网页索引编制报告官方文档https://developers.google.com/search/docs/monitoring-debugging/inspect-indexrobots.txt 规范与测试工具https://developers.google.com/search/docs/crawling-indexing/robots/introGoogle 抓取预算说明大型站点必读https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlersMDN 的 X-Robots-Tag 与 robots meta 说明https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Robots-TagGSC覆盖率 · 访问日志对账 · 索引诊断 · robots.txt · 抓取预算 · SEO · 网站优化