很多站点在排查抓取问题时，会先看 Sitemap、再看日志，最后才发现一个尴尬的情况：某些 URL 明明写在 Sitemap 里，服务器也能正常返回 200，但翻遍全站的内链，没有任何一个可点击的入口指向它。这类页面通常被称为孤岛页面，它们不是打不开，而是没人带着蜘蛛走过去。
为什么内链往往比 Sitemap 更早带来抓取
Sitemap 更像一份清单，它告诉蜘蛛这些地址存在，但不保证蜘蛛会按顺序、按时间把每一行都走一遍。内链不一样，它是蜘蛛在渲染页面时顺着 href 一路走出来的路径，属于站点结构的一部分。一个 URL 被多个相关页面链接，意味着它处在一条真实的浏览路径上，被发现的概率和频次通常都会更稳定一些。
换句话说，Sitemap 解决的是交代清单，内链解决的是铺路。两者不冲突，但清单不能替代路。
孤岛页面通常是怎么产生的
- 历史活动页、专题页下线后没有做 301，也没有从栏目里移除链接，最后链接被删、页面还在。
- 批量生成的标签页、筛选页，只在某一次改版中出现过入口，改版后入口消失。
- 后台导出的数据页、接口生成的详情页，只能靠直接访问 URL 到达。
- 分页翻到很后面的列表页，前面的页面已经不再链接过去。
- 只在 JavaScript 渲染后才插入的链接，静态 HTML 里看不到。
这些页面的共同点是：能返回内容，但在站内找不到一条稳定、可点击的到达路径。
怎么把孤岛页面找出来
- 日志与 URL 清单比对。把 Sitemap、数据库里的 URL 和一段时间内的抓取日志做差集，长期没有被抓、也没有被访问的地址，多半就是孤岛。
- 做一次站内链接统计。用爬虫工具从首页出发抓一遍，看哪些 URL 出现在 Sitemap 里却没有出现在任何一次抓取的链接列表中。
- 区分无内链和内链很深。有的页面只是层级偏深，仍然能被走到；真正的孤岛是完全没有任何入链。
- 确认状态码和渲染方式。排除掉 404、301 和必须执行脚本才出现的链接，避免把技术问题误判成结构问题。
把孤岛页面接回主路径的常见做法
- 补一条语义相关的内链。从内容相关的文章、同级页面里加自然链接，比在页脚堆链接更有效。
- 做聚合入口。用列表页、专题页、标签页把同类 URL 收拢，再让聚合页从栏目或导航可达。
- 用好面包屑和上下级导航。让每个详情页都有明确的上一层出口，蜘蛛顺着层级就能走回来。
- Sitemap 作为补充。给确实不适合出现在导航里的页面保留 Sitemap 位置，同时接受它被发现得慢一些。
- 控制孤岛的数量。如果批量页面注定没有入口，就要考虑它们是否真的需要对外可访问。
内链改造不追求一次到位，先让重要页面从零入链变成至少一条稳定入链，比一次性堆几十个链接更稳妥。
改造之后看什么
改完之后不要只看收录数量。可以先观察抓取日志里这些 URL 的出现频次、抓取时返回的状态码，以及抓取后是否有新的链接被带出来。如果一段时间内仍然只有零星抓取，就要回头检查入链的位置是否足够靠前、是否被渲染出来、页面本身是否值得抓。
服务器稳定性同样会影响结果：入口页响应慢或者间歇性返回 5xx，蜘蛛走到一半就断了，后面的孤岛自然更没机会被发现。所以内链梳理最好和稳定性检查放在一起做。
孤岛页面不是靠提交就能一劳永逸解决的，它更像是站点结构里漏掉的几段路。把路补上，Sitemap 和主动提交才有意义。