做站点运营的人偶尔会遇到一种情况：查自己网站的收录时，索引里冒出来一批自己没做过的地址。带一长串参数的、已经删掉的、拼写不对的、大小写不一致的，甚至还有压根没上过线的路径。看到这些先别急着批量删，处理动作选错了，反而会让问题拖得更久。
先确认：它们是真的在索引里吗
用 site: 查询只能当粗略参考，它给出的数量本身就不精确。要判断一个具体 URL 的状态，用 URL 检查类工具更靠谱：看它是「已编入索引」，还是「已发现但未抓取」，或者「已抓取但未编入索引」。这三种状态对应的处理方式并不一样。
另一个常见误判是把「出现在站内」当成「出现在索引」。如果某个地址只出现在 sitemap、内链、订阅源或前端路由里，索引里其实没有它，那清理站内引用就够了，不必动用移除类操作。
把来源分类，别一上来就动手
同一个不存在的 URL，来源不同，处理顺序也不同。可以先按下面几类过一遍：
- 外部引用：别的站点链接了你的旧地址，或转载时保留了老链接。
- 参数拼接：筛选、排序、跟踪参数被自动加到 URL 后面，生成大量变体。
- 写法变体：大小写、http 与 https、带 www 与不带、带尾斜杠与不带。
- 历史遗留：改版前存在、现在已经下线的地址。
- 前端生成：脚本或路由按规则拼出来的路径，服务端并没有对应页面。
- 站内文件残留：sitemap、订阅源或后台列表里还留着旧条目。
- 规范页指错：某个页面的 canonical 指向了一个并不存在的地址。
不同来源，处理动作不一样
页面确实不存在
如果是外部链接或旧地址产生的，且站内没有内容等价的新页面，让服务器正常返回 404 或 410 就好。为了让首页「兜住」所有 404 而做全站 301 到首页，效果通常不好，也容易让搜索引擎判断你有一批重复的软 404。
URL 变体
这类问题的重点在源头：站内输出的链接统一成一种写法，导航、列表、面包屑都别混用。服务器层面可以做归一化跳转，把变体收敛到唯一地址。参数页则先问一句「这个参数有没有真实用户需求」，有就保留并处理好规范页，没有就别让它被大量链接到。
历史遗留与规范页指错
有对应新页面的，用 301 把关系说清楚；没有对应页面的，就让它自然消失。canonical 指向不存在的地址属于配置错误，先改回正确目标，再观察索引是否跟着更新，顺序不要颠倒。
别用屏蔽代替判断
把一批不存在的地址全部写进 robots.txt，往往只是让它们留在索引里，而不是把它们移除掉。
robots.txt 控制的是抓取，不是移除。一个已经被索引的 URL 被禁止抓取后，搜索结果里仍可能显示它，只是缺少描述。真正想让一个地址从索引里退出，要么让它返回 404/410，要么在页面仍可访问时用 noindex。判断清楚它该不该存在，比堆规则更重要。
一套可以照着走的核对顺序
- 取样：从索引里挑若干条不存在的 URL，不要只看一条就下结论。
- 确认状态：逐条查它是已索引、已发现未抓取，还是已抓取未索引。
- 定位来源：外部链接、站内引用、参数规则、文件残留，找到就记下来。
- 判断归属：站内有没有等价的内容页面？有就走 301，没有就让它 404/410。
- 修源头：清理 sitemap、统一链接写法、修正 canonical、去掉无意义参数输出。
- 复查：过一段时间再看同一批 URL，确认是否按预期退出，而不是频繁改规则。
长期该做的两件小事
一是保持站内只输出一种规范的 URL 写法，二是定期清理 sitemap 和订阅源里的旧条目。这两件事做到了，索引里冒出来的「陌生地址」会少很多，剩下的多来自站外，处理起来也简单。
收录核对本身不是一锤子的事。把「抓取」「索引」「展示」分开看，先分来源再定动作，比看到异常就批量屏蔽要稳得多。