孤岛页面检测的抽样口径，决定了你看到的孤岛是真是假

摘要：站内孤岛页面检测的做法是从sitemap拿页面清单，抽一批页面抓出链，两边对账。逻辑没错，但它的数据口径会让你看到一批并不存在的孤岛。我们把后端接口逐条打了桩：本站sitemap索引下六张子图共1830个地址，工具界面报出的总数是1483，真正参与对账的只有600个，工具页、图库页、分类页一个都没进去，全程零提示。

更要命的一处在归一化环节：它会把目录型地址末尾的斜杠剥掉，再拿这个被自己改过的地址去抓页面，于是相对链接的解析基准整层塌陷——同一个栏目页，带斜杠抓到的117条内链全部正确，不带斜杠抓到的117条全部落到了网站根目录。本站124个工具页因此有12个被判成孤岛，而它们全都被对照台页面好好地链着。这篇把每一处口径拆开，并给出这款工具真正靠谱的用法。

孤岛页面这个问题有个很讨厌的特点：它不会报错，只会让页面安安静静地不来流量。你翻后台看不出异常，页面自己打开也正常，只有把整站的链接关系铺开看，才会发现有一批内容根本没人链接。

保哥笔记的站内孤岛页面检测提供了一个轻量的入口：输入sitemap地址，它抽样抓一批页面，把链接关系拼起来，告诉你哪些页面没有入链。这个思路是对的，工具本身也确实能跑出结果。但结果能不能直接拿去做决策，取决于你知不知道它的数据是怎么来的——这篇教程主要讲的就是这件事。

孤岛页面到底指什么？

孤岛页面指的是站内没有任何其他页面链接指向它的页面。它可能好端端地躺在sitemap里，直接访问也能打开，但从链接结构上看，它是一座断桥。

为什么这件事重要，得从搜索引擎发现网址的方式说起。爬虫找页面主要靠两条路：一条是顺着链接爬，另一条是读sitemap。这两条路的权重不一样——链接不只是通道，还携带着“这一页值不值得看”的信号，而sitemap只是一份清单，它告诉引擎地址存在，却说不出这个地址在站里有多重要。

所以孤岛页面的典型症状是：能被收录，但收得慢；收进去了，排名却上不去；站内其他页面涨了它不涨。它不是不能被发现，而是永远排在抓取队列的末尾，也永远拿不到站内的权重传递。

这类页面在跑了两三年的站上多得超乎想象。改版时从导航撤下但没删的页面、批量导入之后忘了做内链的内容、活动结束后遗留的落地页、早期分类调整时被孤立的老文章，都是常见来源。

要说清楚一点：孤岛不等于该删。有些页面本来就该独立存在，法务条款、投放专用落地页、只从广告进来的注册页，没有内链完全正常。判断要不要修，得看这一页原本是不是内容网络的一部分。

一条内链到底传递了什么？

在拆工具之前，得先说清楚我们到底在测量什么。不然算出一堆数字，也不知道该拿它做什么决定。

一条从A页面指向B页面的链接，至少同时在传递四样东西。

第一是可达性。爬虫顺着链接走，走得到才谈得上后面的一切。这是最基础也最容易被sitemap掩盖的一层——很多人以为进了sitemap就等于被发现，实际上sitemap只是提名，链接才是选票。

第二是权重。页面的排名能力会沿着链接往下流，首页和高权重栏目页流出去的那一份，含金量远高于一个没人看的老页面流出去的。这也是为什么“被链接的次数”和“被谁链接”是两件事，而抽样工具只能告诉你前者。

第三是语义。锚文本告诉搜索引擎目标页是关于什么的。同样一条链接，锚文本写成“点击这里”和写成具体的主题词，效果差着量级。孤岛检测工具完全不看锚文本，这是它的能力边界，也是为什么补完链接还得用别的方式复查。

第四是位置信号。正文中间的链接、页脚的链接、侧边栏的链接，在搜索引擎眼里权重不一样。正文里那种“顺着上下文自然提到”的链接最值钱，因为它同时携带了上下文语义。这也正是这款工具剔除高频链接的理由——它想把模板链接从统计里踢出去，只留下正文里的主动推荐。

知道这四层之后再看结果就清楚了：工具给出的“有效入链数”只覆盖第一层和第二层的一部分，第三层和第四层它完全看不到。所以它适合回答“有没有人链过这一页”，不适合回答“这一页的内链做得好不好”。

这款工具是怎么算出孤岛的？

它的流程分三步，每一步都有自己的口径，也都有自己的坑。

第一步，读sitemap。你给一个sitemap地址或者域名，它去抓；如果抓到的是索引型sitemap，它会再往下取一层子图；把所有地址收上来，去重、过滤掉外域，得到一份“应该存在的页面”清单。

第二步，抽样抓页面。从清单里按等距的方式抽出一批地址，默认40个，逐个抓回HTML，用正则把里面的链接提取出来，只保留同域的。

第三步，对账。统计每个地址被多少个抓取页面链接到，出现比例超过阈值的判定为全站导航链接并剔除，剩下的就是有效入链。有效入链为零的，进孤岛清单。

值得先说一句的是，这三步的可靠度并不一样：第三步的算法思路站得住，第一步和第二步却各有几处静默的数据丢失。所以看结果时的正确姿势是先问数据是怎么来的，再看结论说了什么——顺序反过来，很容易被一个漂亮的数字带偏。

这三步里，第三步的思路是最有价值的——把导航剔掉再算入链，这一步很多人自己写脚本时都想不到，而它直接决定了结果有没有意义。问题出在第一步和第二步，那里有几处静默的数据丢失。

它报出的sitemap总数，为什么不是你的真实页面数？

这是本次实测里最需要先讲的一条，因为它决定了后面所有数字的可信度。

本站的sitemap是索引型的，下面挂着六张子图。我们先把真实数据点清楚：

工具界面上那个“sitemap页面”的数字显示的是1483。而真实总数是1830，实际参与孤岛判定的是600。三个数字，没有一个对得上另一个。

丢失发生在三个地方，全部静默：

• 索引型sitemap最多只取六张子图。超过六张的部分直接不抓。本站恰好卡在六张，再多一张就会有整类页面凭空消失。
• 累计地址数超过1200就停止合并后续子图。文章子图一张就有1483条，超过阈值，于是后面五张子图连请求都没发出去。
• 返回给前端的清单最多600条。这是最后一道截断，也是决定性的一道——前端的孤岛判定完全基于这600条，第601条往后的页面，无论有没有入链，永远不会出现在孤岛清单里。

我们验证了这个推论：在返回的600条里，包含/tools/路径的有0条，包含图库路径的有0条，包含分类路径的有0条，全部是文章页。也就是说，如果你输入的是站点根sitemap，那么这个站的工具页、专题页、分类页压根没被检查过，而界面上不会有任何提示。

规避方法很直接：别喂根sitemap，喂子图。一次只测一张子图，条数控制在600以内，这时候清单才是完整的。想测全站就分几次跑，把结果自己合并。

为什么栏目页发出的内链会集体失踪？

这一条更隐蔽，也更值钱，因为它能解释绝大多数“莫名其妙的孤岛”。

工具在处理地址时会做一次归一化：去掉锚点、剥掉几个常见的跟踪参数、去掉末尾的斜杠。前两件事都对，第三件事埋了雷。

去掉末尾斜杠意味着，sitemap里的https://example.com/tools/会变成https://example.com/tools。然后工具拿着这个被自己改过的地址去抓页面。服务器通常会把无斜杠版本301到带斜杠版本，抓取本身能成功，看起来一切正常。

问题出在链接解析上。页面抓回来之后，要把里面的相对链接拼成绝对地址，而拼接用的基准是请求时的那个地址，不是重定向之后的最终地址。请求的是/tools，程序取它的目录，得到的是网站根目录；于是页面里所有形如color-converter.php的相对链接，全被拼成了根目录下的地址。

我们用同一个页面、两种写法各抓了一次，对比结果非常干净：

而工具自己归一化出来的，恰恰是不带尾斜杠的那一种。

RFC 3986对这件事有明确规定：如果内容是通过重定向取回来的，那么用于解析相对引用的基准地址，是最后实际取回内容的那个地址，不是最初请求的地址。工具用的是最初请求的地址，所以整层目录被丢掉了。

这个缺陷的杀伤面取决于你的站长什么样。用目录式固定链接的站——分类页、标签页、专题栏目页大多以斜杠结尾——命中率极高。而这些页面恰恰是站内最重要的链接枢纽：一个分类页可能链着底下几十上百篇文章，它一失效，那几十上百篇的入链就集体归零。

本站跑出来的12个孤岛，是怎么来的？

光讲机制不如看一次真实的运行。我们照着工具的示例按钮跑了完整流程：输入工具子图，样本30个，导航阈值70%。

结果是：清单124个地址，抓取成功30个，识别为导航链接的2个，疑似孤岛12个，入链1到2个的65个。

这12个孤岛值得看一眼名单，里面有颜色转换器、CSS编辑器、JSON格式化、语法检查这些常用工具页。而事实是：本站的工具对照台页面上明明白白列着全部117款工具的链接，这12个页面一个都不少。它们没有一个是真孤岛。

原因就是上一节那条。等距抽样时，第一个样本恰好是工具对照台首页——那是唯一一个链接了全部工具的枢纽页。工具把它的地址剥掉了尾斜杠，抓取虽然成功，但它发出的117条相对链接全被解析到了网站根目录，与清单里的工具页地址完全对不上。于是这些工具页在对账时只能靠彼此底部的推荐模块拿入链，凑不齐的那12个就掉进了孤岛清单。

顺带还有两个细节值得记一笔。

第一次跑的时候有2个页面抓取失败，孤岛数是15；第二次30个全部成功，孤岛数变成12。抓取失败的页面会被静默跳过，界面只告诉你成功抓了多少个，不告诉你失败的是哪几个。如果失败的恰好是那个枢纽页，孤岛数会瞬间暴涨，而你完全不知道发生了什么。

另外，孤岛清单里出现了一个叫做工具目录下link的地址。那其实是sitemap里一个以斜杠结尾的目录页，被归一化剥掉斜杠之后变成了一个并不存在的地址。你把它复制到浏览器里打开，会得到一次跳转——照着这份清单去核对的人，第一反应多半是自己看错了。

抽样与阈值这两个旋钮，实际能调出什么？

界面上只有两个可调项：抽多少个页面，以及多高的出现比例算导航。这两个数字看着简单，实际决定了结果的可信度上限——而它们各自都有一个说明书里没写的边界。

导航链接识别在什么站上会失灵？

剔除导航链接是这款工具设计上最聪明的一步，但它依赖一个前提：模板链接必须真的出现在绝大多数页面里。

判定方式是统计每个链接在多大比例的抓取页面中出现，超过阈值就算导航，默认阈值是70%。本站那次实测，抓了30个页面，最后识别出来的导航链接只有2条。

为什么这么少？因为本站的工具页底部虽然都有推荐模块，但每一页推荐的工具各不相同，没有哪一条链接能出现在七成以上的页面里。真正的全站固定链接只有页脚那几条。

这带来两个后果。往好处说，正文内链没有被误伤。往坏处说，那些“半模板”链接——比如同栏目下的相关文章模块、面包屑里的分类链接、侧边栏的热门文章——它们出现在30%到60%的页面里，既够不上导航阈值，又不是正文里的主动推荐，全都被当成了有效入链。于是一个只被面包屑链着的页面，看起来入链数正常，实际上没有任何一篇内容真正提到过它。

调阈值能缓解，但没法根治。阈值调低会把正文里高频出现的核心页面误判成导航，调高又会让页脚链接漏网。更实际的做法是把这个数字当成相对指标而不是绝对指标：同一次运行里，入链数排在末尾的那批页面确实比排在前面的更需要关注，但“零入链”这三个字不能按字面理解。

样本要抽多大才够用？

工具的样本上限是120个，默认40个。它的说明里建议几百页的站把样本调到100以上。这个建议方向是对的，但没说透一件事：样本大小不是关键，枢纽页在不在样本里才是关键。

做个简单的算术。一个500页的站，抽100个样本，覆盖率20%。如果站内的内链是均匀分布的——每篇文章链两三篇相关内容——那么一个页面被链接过、且链接它的那篇恰好在样本里的概率并不高，大量页面会被误判成孤岛。

但真实站点的内链从来不是均匀分布的。绝大部分内链集中在少数几个枢纽页上：首页、分类页、标签页、专题页、归档页。抓到一个分类页，等于一次性拿到它底下所有文章的入链证据；抓不到，那批文章就集体裸奔。

所以更聪明的做法是：不要指望等距抽样帮你抓到枢纽页，直接把枢纽页所在的那张子图单独喂给它。比如先测分类子图，让所有分类页都被抓到，看看它们链出去的页面覆盖了多少；再单独测文章子图，对照一遍。这样跑两次，比把样本从40调到120有用得多，也快得多。

顺便说一句，本站那次实测里等距抽样的第一个样本恰好是枢纽页，纯属运气好——sitemap把它排在了第一条。换一个sitemap排序方式，结果可能完全不同。

它为什么比你想象的慢得多？

工具的操作说明里写着分批并发抓取。我们测了一下，这个说法不成立。

测法很简单：找一个固定延迟两秒才响应的地址，先让它抓1个，再让它抓6个。如果是并发，6个的耗时应该跟1个差不多；如果是串行，应该是6倍。

实测结果：1个地址耗时3.44秒，6个地址耗时31.89秒。整整6倍多一点，串行无疑。

后端一次最多接收6个地址，循环里一个一个抓；前端把样本切成每批6个，等上一批返回了才发下一批。两层都是串行的，所以总耗时基本等于所有页面响应时间的总和。样本调到120个，就是120次串行请求排队。

本站实测抓30个页面用了38.6秒，还是在自家服务器、网络条件很好的情况下。换成响应慢一点的站，或者把样本拉到100以上，跑一次五六分钟很正常，中途还可能撞上浏览器或者服务器的超时。

这一点直接影响你怎么用它：它适合针对性地测一张小子图，不适合当成全站爬虫来跑。想要全站的链接图，该上专业爬虫软件的时候别硬撑。

哪些链接被算错了，哪些它压根看不见？

对账的准确度取决于两边的地址能不能对上。工具会对地址做一轮归一化，也会用正则从HTML里捞链接——这两步各自都有遗漏，而且误差是双向的：有些真链接被漏掉造出假孤岛，有些假链接被算进来盖住真孤岛。

带参数的地址会被算成两个页面吗？

会，而且规律有点意外。

工具会剥掉几个常见的跟踪参数，但剥的方式只处理紧跟在问号后面的第一个参数。我们做了一组对照，同一个目标页两种参数顺序：

后果是同一个页面被拆成了两个不同的地址，入链被劈成两半，而带参数的那一半永远匹配不到sitemap里的干净地址。如果你的站内链习惯性带来源参数——很多主题的推荐模块会自动加，做站内埋点的更是标配——这一条会大面积影响结果。

同类的还有协议和主机名。工具只保留与sitemap主机名严格一致的链接，所以带www的内链在裸域站上会被整条丢弃；而协议不做归一，同一个页面的http版本和https版本会被当成两个地址。

这几条加起来的结论是：站内链接写法越不统一，这款工具报出的孤岛就越多，而多出来的那部分全是假的。反过来看也有正面意义——如果它报出一堆你确信有内链的孤岛，那本身就是个信号，说明你的站内链接写法该统一了。

还有哪几种链接它压根看不见？

提取链接用的是正则，正则的边界就是它的视野边界。我们用一个探针页把各种写法测了一遍，结果如下。

• 没加引号的属性值看不见。写成裸地址不带引号的链接会被整条漏掉。这种写法在老模板和手写页面里不少见。
• 注释掉的链接照样算数。被HTML注释包起来的链接会被当成有效入链。改版时把旧推荐模块注释掉却没删的站，会因此得到一批虚假的入链数据——真孤岛被这些幽灵链接盖住了。
• JavaScript渲染出来的链接看不见。这一条工具自己说明了。前端框架驱动的导航和列表，抓回来的HTML里根本没有那些链接。
• 带rel标记的链接一视同仁。加了nofollow的链接和正常链接一样计入。判断内链权重传递时这个口径要自己心里有数。
• 隐藏元素里的链接照算。设了display为none的链接也计入，工具不判断可见性。

把这几条串起来看，误差是双向的：有些真链接被漏掉，导致假孤岛；有些假链接被算进来，导致真孤岛被遮住。前者你至少能从结果里察觉异常，后者是彻底的静默失效——后者才更值得警惕。

那这款工具正确的用法是什么？

说了这么多问题，它还值不值得用？值得，但要换个用法。它不是一台判决机器，是一台线索生成器。

几条具体建议：

一次只喂一张子图，条数控制在600以内。这样清单是完整的，截断不会发生。文章多的站按分类或者时间拆成几份跑。

确保枢纽页被抓到。最省事的办法是单独测枢纽页所在的子图。如果枢纽页地址以斜杠结尾，那就要特别小心上面说的解析基准问题——这种情况下它给出的孤岛清单基本不能用，建议改用别的方式验证。

把结果当排序而不是当判决。关注入链数最少的那一批，逐个人工确认，而不是把“零入链”直接当结论。人工确认的方法很简单：在站内搜索一下这个页面的标题关键词，看有没有别的文章提到它。

拿两次运行做对比。补完内链之后用同样的参数再跑一遍，看目标页面的入链数有没有涨。相对变化比绝对数值可信得多，因为两次运行的口径偏差是一样的。

保哥带一个做宠物用品的独立站做内链治理时就是这么用的：先用它圈出三十来个可疑页面，人工核掉一半，剩下十几个才是真的没人链。工具省下的是筛选的力气，不是判断的力气——这个定位摆正了，它就很好用。

连sitemap都没进的页面，怎么找出来？

这款工具有一条自己承认的限制：它依赖sitemap提供清单。sitemap里没有的页面，它根本不知道存在。而讽刺的是，最深的孤岛恰恰是那些连sitemap都没进的页面——既没有内链，也没有被声明，等于彻底从站点的地图上消失了。

这类页面从哪儿来？几个典型来源：

• CMS里状态不对的内容。设成了某种特殊状态、或者分类被删导致归属丢失，插件生成sitemap时把它跳过了。
• 手工上传的静态页。促销活动做的独立页面、下载页、单页表单，走的不是CMS，自然也不在sitemap里。
• 老域名迁过来的遗留页面。做了301的还好，没做的就成了没有任何引用的活地址。
• 被sitemap插件的规则排除掉的。有些插件默认排除某些类型或者某些分类，配置一改就有一批页面被静默剔除。

找它们不能靠链接工具，得换数据源，而且要做对账。

第一份数据源是服务器日志。把一段时间内所有返回200的页面地址去重导出来，跟sitemap的清单做差集。日志里有、sitemap里没有的，就是候选。这个方法最靠谱，因为日志记录的是真实存在且被访问过的地址。

第二份是CMS的内容表。直接从数据库导出所有已发布内容的地址，同样跟sitemap做差集。这一步能查出插件的排除规则有没有误伤。

第三份是搜索引擎自己的数据。Search Console的页面报告里会列出它知道但没收录的地址，那份清单里常常藏着你自己都忘了的页面。

三份数据取并集，再减去sitemap清单，剩下的就是真正意义上的暗页面。它们比抽样工具报出来的那些“孤岛”严重得多，因为那些至少还在sitemap里躺着。

独立站最容易长孤岛的几个地方？

做电商和外贸独立站的，孤岛的分布是有规律的。知道规律就不用全站漫无目的地扫。

下架又上架的商品。商品下架时从分类页移除，重新上架时如果走的是另一条流程，很可能没被放回原来的分类。地址还是老地址，收录记录也还在，但站内已经没有入口了。

批量导入的商品。从供应商表格导进来的商品，分类字段填得潦草的那批往往落在一个几乎没人访问的分类下，或者干脆没分类。这类商品数量一多，就是成片的孤岛。

过期的活动落地页。活动期间首页挂着大banner，活动一结束banner撤掉，页面留着。这类页面通常还带着不错的历史收录，可惜没人链了。要么复用改造，要么合并到常青页面做301，别就这么晾着。

分页深处的商品。分类页有二十页，第十五页往后的商品从首页要点很多次才能到。它们不是没有入链，是链接深度太深，实际效果跟孤岛差不多。这一层抽样工具查不出来，得看链接深度。

多语言副本。主语言版本的内链做得挺完整，副本语言只翻译了内容，内链没跟着建。于是整个副本语言站都是浅层孤岛，靠hreflang标注勉强被发现。这是出海站里非常常见的一种，也是最影响转化的一种——花钱翻译了，流量却起不来。

把这五类列成清单，每季度过一遍，比等到流量掉了再排查主动得多。

补完内链之后，怎么验证它真的生效了？

补链接这个动作本身不难，难的是确认改动有没有兑现。这里有个顺序问题：先验证链接本身，再验证搜索引擎的反应，最后才看流量。这三层的时间尺度完全不同，混在一起看会得出错误结论。

第一层，验证链接确实存在且可被抓取。用同样的参数重跑一次孤岛检测，看目标页面的入链数有没有从零变成正数。因为两次运行的口径偏差是一样的，相对变化是可信的。想看得更细，可以用内链外链分析器检查单页的链接结构，确认锚文本和rel属性都是你想要的样子——毕竟一条加了nofollow的内链，在传递权重这件事上基本等于没加。

第二层，验证搜索引擎注意到了。这一层要等，通常是几天到几周。观察指标是抓取频率的变化，Search Console的抓取统计里能看到；页面从“已发现未收录”变成“已编入索引”也是明确信号。

第三层，才是流量和排名。这一层的滞后更长，而且受太多因素影响，很难把功劳单独归给内链改动。所以别拿两周的流量数据去证明内链有没有用，那个时间尺度上什么都证明不了。

一个实用建议：改动之前先把当前状态存一份。哪些页面入链为零、当时的收录状态是什么、抓取频率大概什么水平。没有基线的话，改完之后你只能靠感觉判断，而感觉在这件事上一向不太靠谱。

确认是真孤岛之后怎么处理？

找到之后别急着一刀切，先分三类。

该有内链却漏了的内容页。这是要处理的主体。找几篇主题相关的已有文章，在正文里自然地提到并链接过去。注意是正文内链，不是塞进页脚或者相关阅读模块——那些位置的链接在权重传递上效果差得多，而且很可能被这款工具自己判成导航链接给剔除掉，你补了等于没补。

本来就该独立的页面。投放落地页、法务条款、感谢页，没有内链是正常的。这类页面如果你不希望它进索引，顺手确认一下它的收录状态是不是符合预期。

该合并或该删的旧内容。一个页面既没有内链、也没有流量、内容还过时了，那它继续存在的理由就不充分。合并进相关文章再做301，比留着一个僵尸页面更好——留着不只是占位置，还在消耗抓取预算。

处理完之后有个动作容易被忘：回头确认这些页面的可索引性。孤岛问题经常和其他技术问题结伴出现，同一次改版既可能切断内链，也可能顺手加了个noindex。这一步可以用可索引性一键体检的排查顺序过一遍，两分钟的事。

想深入理解孤岛页面的成因和危害，站内有一篇专门讲机制的孤岛页面定位与内链修复可以接着看，那篇不谈工具，谈的是链接结构本身怎么烂掉的。

它的入链数和Search Console的内链报告为什么对不上？

经常有人拿这两个数字比对，然后困惑于差距为什么这么大。它们本来就不是同一个东西。

Search Console的内链报告统计的是Google实际抓取过的全部页面上的链接，包括导航、页脚、面包屑，全部算进去。所以那里的数字通常很大，一个普通文章页有几十上百个内链是常态——那是因为整站的导航都链着它。

这款工具统计的是抽样页面里剔除高频链接之后的剩余部分，口径窄得多，数字自然小得多。它想回答的是“有多少篇内容主动提到了这一页”，而不是“总共有多少个链接指向它”。

还有两个差异来源：Google的数据是它历史上抓取过的全量，包括你已经删掉的链接（更新有延迟）；而工具只看当前这一次抓到的几十个页面。此外Google会执行JavaScript，前端渲染出来的链接它看得见，工具看不见。

所以正确的用法是各司其职：要看绝对的链接覆盖，用Search Console；要看正文内链的相对分布，用这款工具。两个数字都往下掉才是真的出了问题，只有一个动通常说明是口径差异而不是站点变化。

什么时候该换成专业爬虫？

判断标准其实很清楚，命中下面任何一条，就别在轻量工具上耗时间了。

• 站点超过一千页。抽样覆盖率太低，结论没有统计意义，而串行抓取的耗时也不能接受。
• 导航或列表由前端框架渲染。抓不到链接，结果会严重失真，还不如不测。
• 需要区分链接位置。正文链接、导航链接、页脚链接的权重完全不同，比例判定只是个粗糙的近似。
• 需要沉淀历史数据。做内链治理要看趋势，一次性的结果没法归档比对。
• 关心的是链接深度而不只是有没有链接。从首页点几次能到，这个指标比入链数更能反映页面的实际处境，而抽样工具算不出来。

反过来，几百页以内的站、想快速看一眼某个栏目的内链健康度、或者补完链接之后想验证一下效果，这款工具是够用的，而且不用装软件、不用配置、三十秒出结果。工具没有高低之分，只有合不合适。

常见问题解答

为什么工具显示的sitemap总数和我的实际页面数对不上？

索引型sitemap最多只取六张子图，累计地址超过1200就停止合并后续子图，最终返回给前端的清单还有600条的上限。三道截断都是静默的。规避方法是一次只喂一张子图，条数控制在600以内。

明明有内链的页面为什么被判成孤岛？

最常见的原因是链接它的枢纽页地址以斜杠结尾。工具会剥掉尾斜杠再去抓，抓取虽然成功，但相对链接的解析基准变成了网站根目录，那一页发出的所有相对链接全部失效。目录式固定链接的站命中率很高。

样本调到最大是不是就准了？

不一定。决定准确度的不是样本大小，而是枢纽页在不在样本里。分类页、标签页、专题页承载了绝大部分内链，抓到一个等于拿到它底下所有页面的入链证据。比起把样本从40调到120，单独测一张枢纽页所在的子图更有效。

为什么跑一次要好几分钟？

抓取是完全串行的。实测一个延迟两秒的地址耗时3.44秒，六个耗时31.89秒，正好六倍。后端循环里逐个抓，前端也是等上一批返回才发下一批，所以总耗时约等于所有页面响应时间的总和。

入链数为零一定要补内链吗？

先确认它是不是真孤岛。工具的口径会造出一批假孤岛，人工核实的办法是在站内搜一下这个页面的标题关键词，看有没有别的文章提到它。确认是真孤岛之后再分三类处理：内容页补正文内链，独立落地页跳过，过时无流量的考虑合并做301。

补内链补在页脚或者相关阅读模块行不行？

效果差很多。这类位置的链接在权重传递上本来就弱，而且出现在大量页面里，很可能被工具自己判定成全站导航链接直接剔除，等于补了个寂寞。要补就补在正文里，用自然的锚文本。

带跟踪参数的内链会影响结果吗？

会。工具剥跟踪参数时只处理紧跟问号的第一个参数，参数顺序换一下就剥不掉了。同一个页面因此被拆成两个地址，入链被劈成两半。带www的内链在裸域站上会被整条丢弃，http与https也不做归一。

它能替代专业爬虫软件吗？

不能，定位不同。站点超过一千页、导航由前端框架渲染、需要区分链接位置或者需要沉淀历史数据，这几种情况都该上专业爬虫。它适合几百页以内的站快速看某个栏目的内链健康度，以及补完链接之后做前后对比。

权威参考资料