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

收录好的域名：怎样形成可复用检查清单

把“收录好的域名”拆成可核对的状态项，而不是只看一个总数，就能形成可复用检查清单。核心做法是：先定义哪些页面算“应该被收录”，再按抓取、索引、展示三层逐项检查，最后把每次结论写成可复查的记录。这样换一个域名或换一批页面，清单仍然能用。

准备：先确定检查范围和判断标准

没有范围，清单就会变成漫无目的的翻页。准备阶段只做三件事：列出目标页面、确定参照页面、写下判断标准。

• 目标页面：从站点地图、导航链接、栏目页中各取一部分，覆盖首页、列表页、详情页、分页。
• 参照页面：选几个已经确认能被搜到的页面，作为“正常状态”的对照，不靠感觉判断。
• 判断标准：用site:查询、页面标题搜索、日志中的抓取记录交叉确认，而不是只看一个数字。

这一步的产出是一张表：页面地址、页面类型、期望状态、实际状态、证据来源。表建好之后，后面每一步都往里面填，不另起炉灶。

实施：按抓取、索引、展示三层逐项检查

检查顺序不能乱。抓取是前提，索引是结果，展示是表现，跳过前一层直接看排名会得出错误结论。

抓取层

先确认目标页面没有被robots.txt挡住，也没有被noindex标记。这里要分清两件事：robots.txt限制的是抓取，不等于可靠的索引移除；页面即使被禁止抓取，仍可能因为外部链接而被索引。所以看到“已屏蔽抓取”时，不要直接判定“已从索引移除”，要另行核对索引状态。

索引层

索引层要回答的是：页面有没有进入候选库，以及进入的是哪个地址。重点核对规范地址、参数版本、大小写变体、带斜杠与不带斜杠的版本是否指向同一页。站点地图能帮助发现页面，但不保证收录，所以站点地图里有、索引里没有，属于正常现象，需要继续查原因而不是直接判定故障。

展示层

展示层看标题、摘要、结构化数据是否符合预期。这一层的问题通常不影响是否被索引，但会影响点击表现，因此要单独记录，不要和索引问题混在一张清单里。

验证：用可重复的证据确认结论

验证的关键是让第二个人按同样步骤能得到同样结论。建议对每个可疑页面记录三项证据：查询语句、查询时间、观察到的结果。以下是一个假设例子，用于说明记录格式，不代表任何真实项目：

页面：/example-page；查询：site:example.com/example-page；结果：未返回该地址；同时段日志：有抓取记录，返回200；初步判断：已抓取但未索引，需查内容质量与规范标签。

验证时要注意，不同搜索引擎的收录范围和支持的查询语法并不相同，同一页面在不同引擎中的状态可能不一致，因此结论要标明是在哪个引擎、哪个时间点得到的。HTTPS 只说明传输层加密，不保证站点没有安全漏洞，也不构成收录或排名的保证，所以不要把 HTTPS 当作收录好的证明。

维护：让清单能长期复用

清单要能复用，必须做到两点：固定字段、固定复查节奏。固定字段指每次检查都填同样的列，不临时增删；固定节奏指按页面类型分批复查，而不是等出问题才翻记录。

维护阶段最值得保留的是“判断依据”一栏。它记录的是当时为什么得出这个结论，而不是结论本身。几个月后回看，能凭这一栏判断问题是持续存在还是已经变化。对于已经确认的原因和可能原因要分开写：例如“日志显示返回404”是已定位的原因，“可能是服务器配置变动”只是待验证的推测，两者不能混在同一格。

下一步：从现有页面中挑出十到二十个覆盖不同模板的地址，按上面的四层填一遍表。填完之后，把出现次数最多的那一类问题排在处理顺序的最前面，其余按影响页面数量从多到少排列。