站内总有一些页面不是编辑一条条写的，而是系统按规则自动生成的：标签页、日期归档页、作者页、搜索结果页、筛选组合页。它们数量大、互相链接多，往往比内容页更早被抓取。问题在于，这些页面并不都值得进入搜索索引。判断标准不是“能不能被抓”，而是“有没有独立价值”。
先分清三种列表页
同样叫列表页，用途差别很大。可以先把它们分成三类，再决定收录策略。
- 内容聚合页：围绕一个明确主题，把相关内容集中展示，用户会主动搜索这个主题。例如“某类产品的选购指南”或“某位作者的专栏”。这类页面有独立检索需求，可以考虑保留在索引里。
- 站内导航页：主要为了方便站内跳转，例如按年份归档、按字母排序的作者索引。用户很少通过搜索引擎专门找它，它的价值更多在站内。可以保留给用户，但不必强求被索引。
- 无差别组合页：搜索结果页、多条件筛选页、空标签页、重复参数页。它们通常由站内搜索或筛选产生，内容随查询变化，重复度高，也容易无限生成。这类页面一般应该收口。
收口方式不同，结果也不同
决定不让某个列表页进索引后，还要选对方法。不同方法对抓取和索引的影响不一样。
noindex 适合“给用户看，但不进索引”
如果页面本身有用，只是不希望出现在搜索结果里，用 noindex 比较合适。搜索引擎仍能抓取页面，也能看到 noindex 指令，从而把它排除在索引之外。注意不要同时用 robots.txt 屏蔽抓取，否则抓取不到，noindex 也可能看不到。
robots.txt 屏蔽要更谨慎
robots.txt 阻止的是抓取，不是索引。已经被索引的 URL，即使后来被 robots.txt 屏蔽，也可能因为缺少更新信息而继续留在索引里。通常只在确实不需要抓取、且不介意索引残留时使用。
canonical 解决的是重复变体
如果多个 URL 展示的是同一批内容，只是排序参数或分页参数不同，可以用 canonical 指向主版本。canonical 不是“删除”指令，它是给搜索引擎的合并建议。内容本身不同的列表页，不要硬指到同一个 URL。
排查顺序：从实际收录情况开始
不要凭感觉批量处理。按下面顺序看一遍，通常能分清哪些该留、哪些该收。
- 查索引：用 site 查询或搜索控制台的覆盖率报告，看实际被收录的列表页有哪些。先处理数量大、明显无价值的类型。
- 看流量与转化：如果某类标签页或归档页有稳定搜索流量，说明它可能满足了一部分检索需求，不要一刀切屏蔽。
- 看抓取占用：从服务器日志里观察，列表页是否占用了大量抓取次数，而内容页更新却迟迟不被抓取。如果是，优先收口无差别组合页。
- 定策略：保留有价值的聚合页，合并重复变体，对导航页和组合页使用 noindex 或 canonical。一次改一类，观察几周再继续。
保留的列表页也要有基本质量
决定保留在索引里的列表页，不能只是一个标题加链接的清单。至少应该做到：
- 标题和描述能说明这个列表的主题，而不是只显示“标签：某某”。
- 每个条目有摘要、缩略图或时间等辅助信息，让用户能判断是否点击。
- 分页有清晰的上一页、下一页关系，避免第 2 页之后被当成独立内容大量收录。
- 空结果页、只有一两条内容的标签页，不要生成可索引的 URL。
收口的目标不是让收录量看起来变少，而是让真正有内容、能满足搜索需求的页面更容易被发现和更新。不要为了减少列表页收录，把整站抓取都堵住。
自动生成列表页本身不是问题。问题在于是否给了它们与价值匹配的索引身份。先把类型分清，再选收口方式，最后用数据和日志验证，通常比一次性批量 noindex 更稳妥。