判断问题属于哪一层,不能只看“有没有收录”这个结果。正确做法是先确认搜索引擎爬虫是否来过、拿到的是不是你期望的内容,再判断是抓取层、解析层还是收录层出了问题。多人协作时,把这三层分开记录,能避免前端、后端、内容和运维互相返工。
很多团队看到页面不出现在搜索结果里,第一反应是改标题、加关键词、重写正文。但如果搜索引擎爬虫根本没有抓取,或者抓取到的是一段空壳 HTML,内容改得再多也不会进入后续流程。收录是结果,抓取和解析才是前置条件。
这里要区分“可能原因”和“已经定位的原因”。日志里出现爬虫访问记录,只能说明抓取层可能没问题;页面返回 200 也不代表正文已经被正确解析,因为内容可能由客户端脚本渲染,而爬虫拿到的是初始 HTML。
抓取层关注的是搜索引擎爬虫是否请求了 URL,以及服务器返回了什么。检查项可以从服务器访问日志入手,筛选常见爬虫的 User-Agent,看目标 URL 的状态码、响应时间和返回字节数。
robots.txt 的抓取限制不等于可靠的索引移除。它只约束爬虫抓取行为,已经被收录的 URL 仍可能出现在结果里。要移除索引,应使用对应的 noindex 指令,并确认该页面没有被 robots.txt 阻止抓取,否则爬虫读不到 noindex。
解析层关注搜索引擎爬虫拿到的 HTML 里,核心内容、标题、链接和结构化信息是否完整。一个可执行的检查是:用抓取工具以爬虫身份请求 URL,查看原始响应,而不是看浏览器渲染后的页面。
如果原始 HTML 中正文为空,而浏览器里能看到内容,问题大概率在客户端渲染。此时要判断搜索引擎是否能执行 JavaScript 并等待渲染完成。不同搜索引擎对脚本渲染的支持程度不同,必须分别核查,不能用一个引擎的表现推断另一个。
另一个常见问题是关键内容被放在图片、Canvas 或需要交互后才加载的模块里。爬虫可能无法触发点击、滚动或登录,因此拿不到这部分信息。适用条件是:内容对用户可见,但对未登录、未交互的爬虫不可见。判断结果是解析层缺内容,而不是收录层拒绝。
当抓取和解析都正常,页面仍可能不被收录。这时要检查页面是否输出了 noindex,是否被 canonical 指向了其他 URL,是否与站内其他页面高度重复,以及是否属于低价值聚合页。
还要区分“已抓取未收录”和“已收录但排名低”。前者是索引问题,后者是排序和相关性竞争问题,处理方式不同。多人协作时,建议在交付单里写明:本次修改针对哪一层、验证方式是什么、由谁在什么时间复查。
假设某产品页在浏览器中正常显示,但原始 HTML 只有 <div id="app"></div>,日志显示爬虫返回 200。这个例子说明问题可能在解析层,而不是抓取层;下一步应验证渲染方案,而不是先改文案。
下一步:选一个当前有疑问的 URL,按上面五步跑一遍,把每步的实际结果填进交付单,再决定由谁修改哪一层。