很多站点运营者會把“提交站点地图”当成 URL 發現的全部手段：只要 URL 出現在 sitemap.xml 里，就認為搜尋引擎一定會知道它、並且會去抓。實际執行一段時間後常常發現，地图里列了几千條 URL，日誌里被爬的却總是那几百條。
原因通常不在站点地图，而在連結结构。一個頁面如果没有任何站内連結指向它，只能通過站点地图或外部連結被發現，這類頁面一般被称為孤岛頁面。它們不一定不被收錄，但被發現和被重訪的概率明顯更低。
站点地图解决“知道有這個地址”，不解决“值得抓”
站点地图的作用是声明地址和更新信号，它本质上是一份被動清單。搜尋引擎讀到清單之後，仍然要判断這個 URL 在站点中處于什么位置：有多少頁面連結它、連結出現在什么頁面、連結锚文本是什么。
内鏈承担的是另一種信息：它說明這個頁面對站点结构有多重要。一個被首頁或栏目頁連結的頁面，通常比只在站点地图里出現過一次的頁面更容易被優先抓取。站点地图和站点结构不是互相替代的關系，但如果只有前者，頁面的發現效率會明顯打折。
孤岛頁面常见于哪几種情况
- 改版或迁移後，舊列表頁被刪除，正文頁的入口連結一並消失，但頁面本身還返回 200。
- 後台生成的頁面（标簽组合、篩選结果、活動落地頁）只存在于資料库和站点地图里。
- 内容被移動到新路径並設定了跳轉，但没有任何頁面連結到新地址。
- 分頁列表只放出第一頁的連結，後續頁面的内容没有其他入口。
- 由程序批量生成的頁面，模板里有導航，但導航指向的是另一套路径規則。
自查顺序：先確認是不是孤岛，再確認有没有被爬
排查不要一上来就改模板，先按下面的顺序確認問题卡在哪一步。
- 在日誌里篩選目标 URL，看它是否被訪問過。如果長期零訪問，說明發現环节就没走通。
- 检查站内是否有連結指向该 URL，包括導航、面包屑、正文内鏈、相關推荐和列表頁，統計入鏈數量與来源层級。
- 確認這些連結是可抓取的普通連結。用 JS 事件跳轉、需要交互才渲染的連結，發現效果會弱很多。
- 確認该 URL 没有被 robots.txt 拦截，也没有在頁面里被 noindex，這两者會造成“能發現但不能索引”的错觉。
- 如果曾经被抓取過但很久没再訪問，看内容是否有實质更新、頁面是否長期返回错誤狀態或超时。
抓取和收錄是两件事。孤岛頁面通常先卡在“發現與抓取”這一步，而不是“内容质量”這一步。先解决入口，再讨论质量。
修复时優先做這几件事
- 给栏目頁或聚合頁补充指向詳情頁的稳定入口，避免只依赖分頁加载或搜尋框。
- 面包屑保持可点击、可抓取，不要用纯文本或图片代替連結。
- 相關内容模块尽量輸出真實的主题關联，而不是随机推荐，随机連結的传递作用有限。
- 站点地图仍然保留，但把它当作补充手段，而不是唯一入口。
- 如果頁面确實没有保留價值，用 404 或 410 明确處理，不要让它長期以孤岛狀態存在。
一個容易被忽略的细节：入鏈的位置也在起作用
同样是孤岛變有鏈，從首頁加一個連結，和從深层頁面加十個連結，效果往往不一样。首頁和栏目頁被抓取更频繁，連結被重新發現的速度也更快。反過来，如果連結全部来自本身就很少被抓取的頁面，發現速度提升有限。
另外，内鏈數量不是越多越好。短時間内给一個頁面塞進大量重复連結，並不會让抓取變快，反而可能让頁面结构顯得混乱。更實际的做法是让每個重要頁面都從一到两個稳定的上游頁面可達，並且這條路径在站点结构里長期存在，而不是靠一次性的活動頁带流量。
最後提醒一句：孤岛頁面是结构問题，修复後通常需要几周時間才能在抓取日誌上看到變化。與其反复追問某一篇内容為什么還没收錄，不如先確認它在站内到底有没有被“指路”。