网站不收录-怎样形成可复用检查清单

📍 WDQWDWQD987AAAAA:216.73.216.61
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /09be963ddfc1.html
📄

网站不收录-怎样形成可复用检查清单

把“网站不收录”拆成一条从抓取、解析到索引的排查链，并为每一环写下一个可观察信号、一个动作和一个通过条件，就能形成可复用检查清单。核心原则是：先确认页面是否被抓取，再确认内容是否被解析，最后判断是否满足索引条件；每一步都要有证据，不能靠感觉。适用前提是你能访问服务器日志、robots.txt 和页面 HTML 源码，并且每次只改一个变量。验收信号是：同一份清单换一个 URL 或换一个栏目仍能执行，且能明确得出“问题在抓取层、解析层还是索引层”的结论。

先分清抓取、解析与索引三层

“网站不收录”是现象，不是原因。同一个现象至少有三类解释：搜索引擎没有抓取该 URL；抓取了但解析出的内容不符合预期；内容被解析但未进入索引。三者对应的处理动作完全不同，因此清单的第一项不是改代码，而是定位层级。

如果日志里完全没有访问记录，优先查 robots.txt、内链和站点地图；如果日志有访问但状态码异常，优先查服务器与重定向；如果抓取正常仍不收录，再转向内容与规范化检查。

把每个检查项写成“信号—动作—通过条件”

可复用的关键是格式统一。每个条目只写三件事：观察什么信号、执行什么动作、达到什么条件算通过。下面给出一份可直接套用的骨架，示例中的域名和路径均为假设，用于说明写法。

  1. 抓取信号：在日志中筛选 GET /example-page。动作：确认返回码与抓取时间。通过条件：出现 200，且时间在最近一次内容更新之后。
  2. robots 信号：读取 https://example.com/robots.txt。动作：检查是否误屏蔽该目录。通过条件：目标路径未被 Disallow 覆盖。注意，robots.txt 的抓取限制不等于可靠的索引移除，被屏蔽只影响抓取，不保证页面从索引中消失。
  3. 可发现性信号：查看该 URL 是否有站内链接指向。动作：从栏目页或相关文章补一条上下文链接。通过条件：至少有一个可抓取的站内入口。站点地图不保证收录，它只是辅助发现，不能替代内链。
  4. 解析信号：用“查看源代码”对比正文。动作：确认标题、正文、主要链接是否出现在 HTML 中。通过条件：核心内容无需执行脚本即可读到。
  5. 规范化信号：检查页面 <link rel="canonical">。动作：确认它指向自身而非其他 URL。通过条件：canonical 与页面实际地址一致，且同一内容只有一个主 URL。
  6. 索引指令信号：检查 <meta name="robots"> 与响应头。动作：确认没有误加 noindex。通过条件：页面未被自身指令排除。

HTTPS 不保证安全无漏洞，也不保证排名，它只是排查中的一项基础条件，不应作为收录的充分理由。

按“影响面÷处理成本”排序，先做高杠杆项

时间和人手有限时，不要按清单顺序逐条执行，而要先算两个值：这一项影响多少 URL，以及修一次需要多少时间。优先处理影响面大、成本低的项。

判断结果的方式是：修复后观察日志中该 URL 的抓取频次与返回码是否变化。如果抓取恢复正常但索引仍未变化，说明问题已从抓取层转移到索引层，清单应进入下一组检查项。

让清单可复用的三个维护动作

清单写一次容易，长期可用需要维护。第一，给每条检查项标注“适用条件”，例如仅适用于分页、仅适用于多语言站点，避免把特例当通例。第二，记录“已定位的原因”和“可能原因”的区别：日志显示 404 是已定位，页面未被收录只是现象，两者不能混写。第三，每次排查结束后补一条新条目，只写这次真正验证过的信号，不写推测。

验收信号可以设为：把清单交给另一位同事，在不额外解释的情况下，他能对一个新的未收录 URL 独立完成三层判断，并说出下一步该改哪里。如果做不到，说明条目里还混着结论而非可观察信号。

下一步：挑一个当前未被收录的 URL，按上面的骨架填写三层信号，先只执行全局项和模板项，记录修改前后的日志返回码与抓取时间，再决定是否进入单页内容检查。

图1 图2
nginx