orphan pages 怎么找出来

orphan pages 指站内没有任何一个页面链向它的那些页面。Google 照样能通过 sitemap 或外部链接找到它们，所以「成了孤岛」不等于「不可见」。它们丢掉的是上下文：没有一句锚文本描述它，在你的站点结构里没有位置，已经在站内的读者也走不过去。找出它们只需要做一次减法。

读这篇之前

你得先有一套在跑的内链结构，以及一个「这个站本来该长什么样」的判断。两件事都写在 网站结构与内链怎么做。这一篇是那套结构建起来之后要跑的体检，因为孤岛的定义完全由「结构没碰到哪些页面」决定。

什么才算 orphan pages

只有一条判据，另外有两件事常被错误地加进来。

第四行最费时间。一个没被收录的页面和一个孤岛页面，在报表里长得一模一样，实际上毫无关系。一个页面可以既是孤岛又被收录，也可以内链充足却没被收录，两者的诊断从完全不同的地方开始。

为什么放进 sitemap 解决不了孤岛

Google 列了它找到网址的三条路：「Some pages are known because Google has already visited them. Other pages are discovered when Google extracts a link from a known page to a new page: for example, a hub page, such as a category page, links to a new blog post. Still other pages are discovered when you submit a list of pages (a sitemap) for Google to crawl」（How Google Search works，2026-09-03 访问）。

sitemap 管的是「被发现」，也只管这一件。它携带的只有一个网址，别的什么都没有 —— 没有锚文本，没有上下文句子，也不说明这个页面属于站里哪一块。而 Google 举的那个例子里的链接，这三样都带着。同一个页面走两条路被发现，附带的信息量差得很远。

sitemap 告诉爬虫这个页面存在，链接才告诉它这个页面是干什么的。

读者那一侧更直白。在你站内浏览的人，根本到不了一个孤岛页面。它只对从搜索结果直接落地的人存在，对别人不存在。

五步把 orphan pages 找出来

方法是一次集合差：你打算发布的全部，减去你自己的链接能走到的全部。难的地方在于两份清单要建得诚实。

1. 建清单 A：你打算拥有的每一个网址。sitemap 是最快的来源；CMS 导出更完整，因为它包含了 sitemap 生成器漏掉的那些页面。
2. 建清单 B：从首页出发、顺着内链能走到的每一个网址。用你手上现成的爬虫就行，如果导航是脚本生成的，记得让它执行 JavaScript。
3. 用 A 减去 B。剩下的是候选清单，不是判决。
4. 把每个候选分诊成链接、合并或删除三类中的一类。下面那张表就是全部的判断。
5. 复验留下来的那些。补完链接后，用网址检查工具确认它真的被收录了，读法在 网址检查工具怎么读。

# 清单 A：sitemap 声称有的全部网址
curl -s https://example.com/sitemap.xml \
  | grep -oE '<loc>[^<]+' | sed 's/<loc>//' | sort -u > all-urls.txt

# 清单 B：从你的爬虫导出，一行一个网址
sort -u crawled-urls.txt > reached.txt

# A 减 B：孤岛候选
comm -23 all-urls.txt reached.txt

两份文件如果在结尾斜杠或协议头上写法不一致，这次减法会把你整个站报成孤岛。跑之前先把两边归一化，拿到数字之后先做一次常识检查再相信它。

手上同时有 sitemap 和 CMS 导出的，这次减法值得做两遍。两份候选清单对不上的地方，本身就是发现：一个在 CMS 里有、在 sitemap 里没有的网址，说明你的构建流程已经悄悄不再发布它了 —— 那是另一个 bug，也是另一个人的活。

还有一处容易漏：清单 B 要从首页开始走，而不是从「所有已知网址」开始走。把 sitemap 喂给爬虫当种子，它会把每个网址都访问一遍、然后报告全站可达 —— 那测的是「这些地址能不能打开」，不是「站内有没有路通过去」，正好把这次体检要回答的那个问题绕开了。

分诊表

每个候选都落在四行中的一行。表摆在面前时，一个页面大约三十秒就能定下来。

最后一行值得放慢。删任何东西之前，先查这个页面有没有别的站链过来。站内的孤岛，完全可能是你外链最多的那个页面，删掉就是把它攒下来的唯一信号扔了。

这套测量骗你的三种方式

三种都会产出一份看起来很有说服力、实际是错的候选清单。

1. 你的爬虫渲染不出导航。链接由脚本生成而抓取时没执行它，清单 B 就是短的，于是半个站看起来都成了孤岛。这种失效的形态量在 什么样的链接爬虫才跟得上。
2. 清单 A 只来自 sitemap。sitemap 生成器漏掉的页面根本没进入比对，而最可能成为孤岛的，恰恰就是这批从输入里就缺席的页面。
3. 分页和筛选把两边都灌大了。分面网址能造出几千个候选，而那些本来就不是谁打算发布的页面。分诊之前先按模式排除掉，别一个一个去判。

成了孤岛不代表什么

它不是惩罚。Google 的文档里没有把孤岛页面描述成负面信号，我们也没有任何相反的测量。它也不代表这个页面没法排名，因为通过 sitemap 被发现是文档写明的路径。还有，一个孤岛页面到底损失了多少流量，我们说不出来 —— 那需要在同一个页面上做一次「只加内链、其余不动」的前后对照，这个测试我们没跑过。

能明说的是另一件：一个站内没人链的页面，是一个团队里没人认为值得指向的页面。多数时候这才是更有用的发现。要在决定它的去留之前先看清一次抓取到底返回了什么，可以 看看 QueryWin 是怎么读一个页面的。

常见问题

orphan pages 对 SEO 有害吗

不直接有害，也没有任何文档说它有害。代价是间接的：没有锚文本描述这个页面、没有站内权重流到它、站内的人也没有路径走过去。这三样都是真实的损失，加起来不小，但它们都不是惩罚。

没有爬虫怎么找孤岛页面

拿 sitemap 和最近一个月的服务器访问日志对照，留下那些没有任何带站内来源的访问的网址。这个办法更粗，也会漏掉一些因为别的原因没人访问的页面，但它不需要日志之外的任何工具。

页脚有链接还算孤岛吗

按这里的判据不算 —— 它被链到了。至于一个出现在每个页面上的页脚链接，能不能有效地描述目标页面，那是另一个问题，这次体检不回答。

要不要把孤岛页面放进 sitemap

只有在你同时给它补上链接的前提下才放。一个只在 sitemap 里的页面，是「能被发现但没有上下文」，而这正是你本来要修的那个状态。放进 sitemap 就收工，解决的是报表不是问题。

这套体检该多久跑一次

每次迁移之后跑一次，每次改导航之后跑一次，其余时候一个季度一次。孤岛是成批出现的 —— 一次模板改动或一次换 CMS 会一口气造出几十个，不是一个一个冒出来的。