站内連結是蜘蛛最主要的行路方式：從一個已知頁面出發，顺着 a 标簽一路走下去。但總有那么一些 URL，站内没有任何連結指向它，蜘蛛顺着路径爬到哪儿都碰不到——這類頁面通常被叫做孤岛頁。它們不是打不開，也不是被 robots 挡住，只是没人给蜘蛛带路。
孤岛 URL 一般是怎么产生的
孤岛頁很少是有人故意做的，多數是运营和開發過程中的副产品：
- 改版或栏目調整：舊列表頁被下线，但詳情頁還在，入口連結一起删掉了。
- 篩選、排序、參數頁：由篩選條件動態生成的 URL，只有用戶点選才會出現，站内没有固定連結。
- 活動頁、专题頁：上线时挂在首頁，活動結束後入口撤掉，頁面本身還留着。
- 接口或脚本生成的頁面：由後端資料拼出来的地址，只在特定场景下被調用。
- 分頁深處：列表翻到很後面才有連結，前面几頁又翻不到那里。
這些頁面的共同点是：它們存在于服務器上，返回 200，但站内的連結图上没有它的位置。
蜘蛛發現 URL 的几條补充入口
内鏈之外，蜘蛛還有一些別的路可以走到 URL，虽然不如内鏈稳定，但在孤岛頁的處置上可以作為過渡手段。
Sitemap 兜底
Sitemap 是告诉蜘蛛“我這儿有哪些地址”的清單。把孤岛頁按目錄或類型分组，放進對應的分片文件里，至少在 URL 發現這一层有了交代。要注意的是，Sitemap 只是声明，不等于蜘蛛一定會抓；如果頁面長期孤岛、内容又不更新，抓取優先級通常也不會高。
外鏈與外部提及
如果這個頁面值得被外部引用，一條来自其他站点的正常連結，往往比 Sitemap 更有推動力。但外鏈需要内容本身有價值，為了被發現而四處發連結，属于另一回事。
站内搜尋頁與聚合入口
有些站点的站内搜尋结果是可被訪問的 URL。如果搜尋结果頁能被蜘蛛抓到，里面的结果連結就成了一條發現路径。不過搜尋頁通常需要限制抓取范围，否則參數组合會無限膨胀，反而给抓取路径添乱。
Feed 與结构化資料
RSS、Atom 這類 feed 文件天然带連結，适合更新频繁的内容；结构化資料里的 URL 属性也能起到提示作用。它們更偏向“告知更新”，不适合当作長期入口。
把内鏈补回去才是長久解法
补充入口能解决一时的發現，但頁面拿不到站内連結權重，位置也不會稳。更實际的做法是给它找一條合理的回程路：
- 確認這個頁面還需要存在吗。有些孤岛頁是歷史遗留，直接 301 到相近頁面或下线更干净。
- 從上游頁面加入口。栏目列表、标簽頁、相關推荐，都是自然的入口位置。
- 同級頁面互相連結。同一批内容之間互相引用，能让蜘蛛在几頁之間来回走。
- 面包屑补层級。即使是孤岛頁，也让它有一條回栏目、回首頁的路径，方便蜘蛛繼續跑。
- 检查連結是否可抓。連結用了 JS 跳轉、按钮而非 a 标簽、或者加了 nofollow，都會让這條路走不通。
几個容易踩的坑
- 為了“把所有頁面塞给蜘蛛”，在頁脚堆几百條連結。這類連結權重稀薄，也影响用戶阅讀。
- 只加 Sitemap 不补内鏈，時間一長頁面又會回到孤岛狀態。
- 孤岛頁本身内容薄弱、返回 200 却像空壳，即使被發現，抓取结果也不理想。
- 把内鏈修复当成一次性任務，改版後没有复查，新的孤岛又冒出来。
判断一個頁面是不是孤岛，不用靠猜：在站内連結图里找它的入鏈，找不到就是。發現入口是過渡，内鏈才是常驻路径。
可以按這個顺序排查
- 用爬虫工具跑一遍站内連結，導出只有出鏈、没有入鏈的 URL 列表。
- 對照服務器日誌，看這些地址有没有被抓過、抓的是哪些地址。
- 對照 Sitemap，確認哪些孤岛 URL 不在清單里。
- 按“保留 / 合並 / 下线”三類分別處理。
- 處理完再跑一次連結检查，確認入連結上了。
孤岛 URL 的治理不复杂，难在坚持：站点每次结构性調整，都會产生新的孤岛。把連結检查纳入常規流程，比事後补救省力得多。