一、孤立页面是怎么产生的
做站时间一长，几乎每个站长都会遇到同一个问题：明明发了文章、提交了 sitemap，页面也返回 200，但几个月过去搜索引擎一条收录都没有。这时候大家习惯去查「抓取异常」「索引覆盖率」，其实很多情况下问题根本不在搜索引擎那边，而在自己的站内结构——这个页面没有任何内部链接指向它，也就是孤岛页面（orphan page）。
孤岛页面的产生路径非常固定，几乎都来自三类操作：改版时删掉了旧栏目页但留下了文章；用插件批量导入或定时任务自动生成内容，只写进了数据库没进列表模板；给某些文章设了「不在首页显示」但又忘了加归档入口。还有一个隐蔽的来源：分页过深。文章被挤到列表第 30 页之后，实际上已经等同于没有内链。
二、先用工具确认，不要凭感觉
最直接的办法是拿到「站内所有被链接的 URL 集合」和「站内所有已发布的 URL 集合」，做一次差集。
第一步，从 sitemap 取全集。Typecho、WordPress 都能生成 sitemap，也可以用一条 SQL 或后台导出：
# 假设 sitemap_index.xml 里有多条子 sitemap
curl -s https://www.example.com/sitemap_index.xml | grep -oE 'https://[^<]+\.xml' \
| while read u; do curl -s "$u" | grep -oE 'https://[^<]+\.html'; done \
| sort -u > /tmp/all_pages.txt
wc -l /tmp/all_pages.txt第二步，抓首页和列表页，提取出所有内链，形成被链接集合：
for p in "" page/2 page/3 page/4 page/5; do
curl -s "https://www.example.com/${p:+$p/}" \
| grep -oE 'href="https://www.example.com/[0-9]+\.html"'
done | sed 's/href="//;s/"//' | sort -u > /tmp/linked_pages.txt
wc -l /tmp/linked_pages.txt第三步做差集，得到候选孤岛：
comm -23 /tmp/all_pages.txt /tmp/linked_pages.txt > /tmp/orphans.txt
wc -l /tmp/orphans.txt
head -30 /tmp/orphans.txt这里有个必须注意的前提：只抓列表页是不够的。正文里的内链才是站内链接的主体。所以正确的做法是对全站页面逐个抓取并提取 href，量大的站点可以限定在最近 200 篇。抓取时要控制并发（比如每次 5 个、间隔 200ms），别把自己的站打成 DDoS。用 xargs -P 5 配合 curl 就够，不需要上爬虫框架。
三、为什么不靠 sitemap 就够了
很多人的误解是「我 sitemap 里有，搜索引擎一定会抓」。实际上 sitemap 只是建议，不是命令。搜索引擎会参考它，但对于权重不高、外链为零、站内也无链接指向的页面，抓取优先级会排得非常后。更重要的是，sitemap 提供的只是「存在性」，而站内链接提供的是「重要性信号」——一个被首页、栏目页、相关文章多处链接的页面，和一个只出现在 sitemap 里的页面，在爬虫眼里完全是两回事。
用 site: 查收录是最粗糙的手段，它给出的数字有严重偏差，也不告诉你具体哪些页面没收录。想看到具体清单，得用站长平台的「网址检查」逐个查，或者看「已发现但尚未编入索引」这一项——如果这个数字很大，基本就是爬取预算被浪费在了低价值 URL 上，孤岛页面正是其中一部分。
四、最常见的三类孤岛，以及各自的修法
4.1 分页过深导致的老文章
站点发了 300 篇，首页只显示 10 篇，第 11 页之后基本没人点，爬虫也很少往下翻。修法不是无限加首页条数（那会拖慢首屏），而是建立时间归档和分类归档两个入口，并且确保每个归档页都能从导航或页脚一步到达。归档页本身是二级入口，它把老文章重新接回链接图。
4.2 标签页、搜索页、参数页造成的链接稀释
标签云动辄几十个标签，每个标签页只对应一两篇文章，这些页面既薄又重复。正确做法是合并同义标签、给标签页加 noindex,follow（保留链接权重传递，但不让其进入索引），并把主要入口收敛到分类。这一步通常能把全站可索引 URL 数量砍掉三到五成，爬取预算集中到内容页上。
4.3 自动生成但没进列表的内容
定时任务写入数据后，如果列表模板走的是缓存或按某个字段过滤，新内容可能不进列表。这个问题最隐蔽，因为数据库里有、前台访问也正常，只是「没人连它」。修法是给自动发布流程加一步验证：发布后立刻请求列表页，用 grep 确认新链接出现；同时把「相关推荐」改成基于同分类动态查询，保证新文章至少有一处入链。
五、修内链的优先级：先接主干，再做主题簇
发现孤岛之后不要一股脑往首页塞链接。首页链接是最贵的资源，放多了会稀释所有页面的权重。合理的顺序是：
- 接到对应的分类归档页。这是零成本、零风险的修法，只要归档页可访问即可。
- 在同类文章的正文里加语境化的内链。这是收益最高的做法：同主题的两篇文章互链，对读者是延伸阅读，对搜索引擎是主题相关性的强信号。
- 做主题簇（Pillar-Cluster）。选一个核心主题写一篇长文作为支柱页，把所有细分文章从支柱页链出去，细分文章再链回支柱页。这套结构做完之后，一个主题下二十篇文章会形成一个紧密的链接网络，整体排名通常比单篇各自为战好得多。
- 最后才考虑首页或导航。只放真正重要的枢纽页。
六、锚文本怎么写才不像作弊
内链锚文本的常见错误是千篇一律用完全匹配关键词，几百条一模一样的「SEO 优化教程」会让链接看起来极其机械。更自然的分布是这样的：
- 精确匹配占少数：
Nginx 反向代理配置 - 部分匹配占多数：
这篇讲 Nginx 反代的文章 - 自然语句为主：
之前在这篇里踩过同样的坑、具体参数可以看这里 - 偶尔用 URL 或「原文」这类中性词
关键不在于关键词密度，而在于链接是否出现在读者真的想点的地方。一段讲完 502 排查的段落里链到 FPM 进程池那篇，链接自然会被点；在文末堆十个「相关阅读」而正文里一个都没有，效果就弱得多。这也是我后来把「文末相关推荐」改成「正文内嵌 + 文末补充」的原因，点击率差别很明显。
七、把这件事变成例行工作
孤岛不是一次性问题，只要还在发文章就会持续产生。所以在服务器上放一个小脚本，每周跑一次，把新增的孤岛页面列出来：
#!/bin/bash
# /usr/local/bin/orphan-check.sh 每周一早上跑
SITE="https://www.example.com"
TMP=$(mktemp -d)
curl -s "$SITE/sitemap_index.xml" | grep -oE 'https://[^<]+\.xml' \
| while read u; do curl -s "$u" | grep -oE "$SITE/[0-9]+\.html"; done \
| sort -u > "$TMP/all"
curl -s "$SITE/" | grep -oE "href=\"$SITE/[0-9]+\.html\"" \
| sed 's/href="//;s/"//' | sort -u > "$TMP/linked"
comm -23 "$TMP/all" "$TMP/linked" > "$TMP/orphans"
COUNT=$(wc -l < "$TMP/orphans")
[ "$COUNT" -gt 0 ] && echo "发现 $COUNT 个疑似孤岛页面" && cat "$TMP/orphans"
rm -rf "$TMP"注意这里只抓首页，所以结果里会包含大量「其实被归档页链接了」的误报。实际使用时应该把归档页、分类页都加入抓取列表，误报率会降到很低。脚本的价值不在于精确，而在于每周给你一个待办清单——看到清单变长，就知道最近的发布流程有环节漏了。
八、一个具体的修复案例
有个站从 120 篇涨到 400 篇的过程中，收录数卡在 180 不动了。查下来是三个原因叠加：标签页生成了 90 多个低质索引页；文章列表的分页只到第 10 页，之前的老文章全部掉出链接图；自动发布的 60 多篇内容没有进「相关推荐」。修的时候按优先级来：先给标签页加 noindex，再补时间归档入口，最后改相关推荐的查询逻辑。两周后「已发现未编入索引」从 200 多降到 40 以内，收录数开始稳步上升。
这个过程里没有改一行正文、没有加一条外链，纯粹是把已有的链接结构补完整。这也说明一件事：收录问题的排查顺序应该是「先站内结构，再抓取诊断，最后才怀疑搜索引擎」。大部分所谓「收录慢」，其实是自己没给爬虫一条路。
九、小结
孤岛页面的本质是链接图断开了。诊断靠全集与链接集的差集，修复靠归档入口、主题簇和正文内嵌，维护靠每周一次的小脚本。把这三件事做扎实，比追着搜索引擎算法更新跑要有效得多。