在开始排查收录问题之前,需要先准备四类信息:目标页面清单、服务器的抓取日志、页面的技术状态记录,以及站内链接结构。缺少这些信息,后续的检查只能靠猜测,无法定位真正原因。
不要一上来就全站排查。先明确哪些页面出现了收录问题,把范围缩小到可操作的程度。
这一步的产出是一份带页面类型的 URL 清单,后续所有检查都围绕它进行。
抓取日志是判断搜索引擎是否来过、来了多少次、拿到什么状态码的直接证据。没有日志,就无法区分“没来抓”和“抓了没收录”这两种完全不同的情况。
robots.txt 和服务器是否对搜索引擎做了限制;如果状态码大量是 5xx,说明服务器响应不稳定;如果是 200 但页面仍不收录,问题更可能在内容质量或重复度上。需要注意,robots.txt 的抓取限制只影响抓取,不等于可靠的索引移除手段。页面即使被 robots 屏蔽,仍可能因为外部链接被索引。
对清单中的每个 URL,逐项记录以下技术信息,形成一张对照表。
<title> 和 meta description 是否与页面内容匹配。<meta name="robots"> 中的 noindex 指令。判断逻辑:noindex 和 canonical 指向他处是常见的“页面正常但被主动排除”的原因;如果正文只在 JS 执行后出现,而搜索引擎拿到的初始 HTML 是空壳,收录就会延迟或失败。HTTPS 只解决传输加密,不保证页面没有安全漏洞,也不直接决定收录结果。
搜索引擎需要通过链接发现页面。孤立的页面即使质量不错,也可能长期不被抓取。
nofollow;打开站点地图文件确认 URL 是否在列。nofollow,爬虫可能不会沿着它继续发现页面。把上述四类信息合并到一张表中,每行一个 URL,列包括:页面类型、日志抓取次数、状态码、robots 指令、canonical 指向、是否有站内链接、是否在站点地图中。填写完成后,问题模式通常会自己浮现出来——比如所有未收录页面都带 noindex,或者都缺少站内链接。
下一步是根据对照表锁定最可能的一类原因,先修改一个页面做验证,确认抓取和收录状态变化后,再批量处理其余页面。不同搜索引擎对 JavaScript 渲染、站点地图和指令的支持情况需要分别核查,不要用同一个结论套用到所有搜索引擎。