收录问题的麻烦之处在于，它很少一次暴露完整：今天发现一批页面没进索引，明天觉得另一批 URL 参数太乱，后天改版又把旧链接翻出来。如果每次都临时排查，同样的判断会重复做好几遍，结论也留不下来。把 URL 当成一份可以长期维护的清单来管，比出了事再去查要省力得多。
台账要回答的不是“收录了多少”，而是“该不该收”
收录数量本身参考价值有限。索引里多几十个参数页，未必是坏事；少几个核心栏目页，才是问题。台账的作用是先把“你希望被收录的 URL”写清楚，再拿实际索引状态去对，这样差异才有意义。写清单的过程本身也会暴露问题：有些 URL 当初为什么上线、页面上是否有入口指向它、会不会和其他页面内容重复，往往写的时候才发现没人说得清。
一条 URL 记录哪些字段
- URL 本身：统一大小写、结尾斜杠、参数顺序，写成规范形式。
- 页面类型：栏目页、文章页、列表页、参数页、附件页等，类型决定后续的处理方式。
- 主要入口：这条 URL 从哪个页面可以点到，入口决定它能否被发现。
- 目标状态：希望被收录、允许被抓取但不强求收录、不希望进入索引，三选一。
- 当前状态：已发现未抓取、已抓取未索引、已索引，按最近一次核对填写。
- 核对时间与备注：改过 canonical、加过 noindex、做过跳转，都记一笔，方便回溯。
按价值分层，比全部一视同仁更现实
站点规模上去以后，逐条盯着 URL 不现实。按层管理，判断会快很多。
第一层：核心页
首页、主要栏目、重点内容页。这一层要求最严：URL 唯一、内链可达、内容完整、状态码正常。发现问题时优先处理，也值得定期人工抽查。
第二层：长尾与聚合页
标签页、筛选页、站内搜索结果页、分页。这一层的关键不是“能不能被收录”，而是“是否值得被收录”。有独立检索价值、内容不重复的，可以放行；只是同一批内容换个排序的，用 canonical 或参数规则收敛，别让它占着抓取次数。
第三层：可丢弃页
测试页、过期活动页、临时参数组合。这一层不需要精细管理，明确处理方式即可——该 301 的跳转，该 410 的直接下架，别长期挂着返回 200，让爬虫反复来抓。
例行核对可以固定成几步
- 抽样：每层各抽若干条 URL，核心层抽得多一些。
- 看可达性：状态码、跳转链、robots 规则、页面是否要求登录或依赖脚本渲染。
- 看规范性：是否存在带参数、大小写或斜杠不同但内容相同的兄弟 URL，canonical 指向是否一致。
- 看索引状态：把后台的索引报告和搜索语法交叉核对，注意两者口径不同，不必强求数字一致。
- 记录变化：把这次和上次的结论对比，只看新出现的问题。
几个常见的坑
- 把爬虫日志里的访问次数当成收录信号。爬虫来过，不代表页面进了索引，两件事要分开看。
- 台账只记 URL 不记目标状态，最后变成一堆地址清单，没人知道该拿它做什么。
- 屏蔽规则改了却不更新台账，半年后重新排查时，判断依据还是旧的。
- 只维护新页面不管下线页面，索引里残留的旧地址越积越多。
台账不能保证页面被收录，它的价值在于让判断有依据、让排查有起点。真正影响结果的，仍是页面本身是否值得被展示，以及 URL 与链接结构是否清楚。
如果站点页面不多，一张表格就够了；页面规模大时，至少把核心层单独维护一份。开始时不必追求完整，能覆盖住你确实希望被搜到的那些 URL，就已经比临时救火强很多。