很多刚接触网站运维或者SEO诊断的朋友，第一次打开Xenu这个软件时都会愣一下——界面长得像上个世纪的产物，按钮密密麻麻，跑起来还弹一堆窗口，完全不知道从哪下手。但就是这么个其貌不扬的小工具，在死链检测这件事上，至今仍然是很多老手的首选。它能把一个站点里所有的链接扒出来，一条条告诉你哪个返回404、哪个跳转异常、哪个响应慢得离谱。这篇内容我就围绕Xenu的基本使用方法展开，把界面、配置、跑批、读报告这几个环节讲透，顺带把那些说明书上不会写的坑一并交代清楚。不管你是刚接手一个老站要排查死链，还是日常做站点健康巡检，看完都能直接上手跑起来。

1. 先搞清楚Xenu到底在干什么

1.1 它不是一个"爬虫框架"，而是一台链接扫描仪

很多人对Xenu的误解在于，以为它是个功能全面的站点分析工具。实际上它的定位非常窄：从一个起始URL出发，按照页面里的超链接一层层往下走，把遇到的每一个链接记录下来，然后对每个链接发起一次请求，看返回的状态码是什么。就这么一件事，它做了二十多年。

理解这一点很关键，因为它决定了你该怎么用它。Xenu不解析JavaScript渲染出来的内容，不执行页面里的脚本，也不会去分析CSS里引用的资源（默认情况下）。它看到的就是HTML源码里那些<a href>、<img src>、<frame src>之类的静态链接。所以如果你的站点是纯前端渲染的，Xenu跑出来的结果会非常少，这不是它坏了，是它本来就只能看到服务端返回的那份HTML。

我一般把Xenu的扫描结果理解成"服务端视角的链接地图"。这个视角恰好是搜索引擎爬虫早期抓取时看到的视角，所以用它来排查死链、检查重定向链条，参考价值非常高。你不需要把它当成万能工具，只要在"链接可达性检查"这个场景里用它，就不会失望。

1.2 为什么老手还在用它

现在市面上做死链检测的工具不少，有在线的、有集成在各类站长平台里的，但Xenu依然有一批忠实用户，原因大概有这么几个。

第一是本地运行、不依赖外部服务。你的站点URL列表不会上传到任何第三方服务器，对于一些不方便公开的内网站点或者测试环境，这一点很重要。第二是扫描深度和范围可控，你可以精确指定只扫某个子目录、只跟多少层、排除哪些路径，这种颗粒度在很多在线工具里是给不了的。第三是报告足够原始，它导出的就是一张张链接清单，状态码、类型、来源页面都列得清清楚楚，你想怎么二次处理都行，不会被工具"加工"过。

还有一点比较实际：它跑起来对机器要求极低，一个几百页的站点几分钟就能扫完，不会像某些重型工具那样开一堆进程把内存吃满。对于日常巡检这种高频、轻量的需求，Xenu的性价比确实高。

1.3 使用前你需要准备什么

在打开软件之前，有几件事先想清楚，能省掉后面很多返工。

• 一个明确的起始地址：通常是你站点的首页，或者你想重点排查的某个栏目页。地址要带完整的协议头，别只写域名。
• 扫描范围的边界：你是想扫全站，还是只扫某个目录？这个在配置里要设，否则它可能顺着外链跑到别人站点上去，白白浪费时间。
• 对站点结构的粗略了解：如果站点有分页、有大量动态参数（比如带?id=的URL），你要提前想好这些参数要不要参与去重，不然同一个内容会被当成几百个不同链接反复请求。
• 一个能接受的时间窗口：扫描期间会持续发请求，虽然Xenu默认并发不算激进，但对小站点还是有压力的，尽量避开访问高峰。

提示：第一次用建议先拿一个页面数量不多的测试站点练手，把整个流程走一遍，熟悉了再对正式站点跑全量。

2. 界面与核心配置项逐个拆解

2.1 主界面那几个区域分别管什么

打开Xenu之后，主窗口大致分三块。上方是菜单和工具栏，中间是扫描结果的主列表，下方是状态栏显示进度。工具栏上最常用的几个按钮是新建扫描、停止、导出报告、以及一个"仅显示错误"的过滤开关。

中间那个列表是核心，每跑完一次扫描，这里会按行列出所有发现的链接。列的含义包括：地址、类型（是页面、图片还是其他资源）、状态（比如正常、404、超时）、以及这个链接是从哪个页面被发现的。刚上手的时候容易忽略"来源页面"这一列，但它其实特别有用——当你发现一个死链时，能立刻知道是哪个页面里埋着它，直接去改那个页面就行。

状态栏在扫描过程中会滚动显示当前正在检查的URL和整体进度。如果扫描卡住不动了，多半是某个链接响应极慢，这时候可以看状态栏停在哪个地址上，基本就能定位问题。

2.2 新建扫描时那几个关键选项

点新建扫描，会弹出一个配置窗口，里面选项不少，但真正影响结果的就那么几个，我按重要性排一下。

起始URL：填你要扫的地址，带http://或https://。这里有个细节，如果你填的是https://，而站点里有大量http://的旧链接，Xenu会分别对待，可能产生一些额外的重定向记录，属于正常现象。

扫描深度：也就是从起始页往下跟几层。默认值一般够用，但如果你只想检查首页的直接链接，把它设成1就行，速度快很多。全站排查的话设大一点，或者干脆用"不限制"，让它自己走完。

是否检查外部链接：这个选项要慎重。勾上之后，Xenu会去请求你页面里指向其他站点的链接，这会大幅拉长扫描时间，而且外部站点的响应你控制不了，容易拖慢整体进度。日常巡检我一般不勾，只在专门做外链健康检查时才开。

是否检查图片和其他资源：默认会检查<img>这类资源。如果你只关心页面之间的跳转关系，可以关掉，能省不少请求。

URL去重规则：这一项藏在高级设置里，但很关键。站点如果有带参数的URL，比如列表页的?page=2、?page=3，你可以设置忽略某些参数，避免把同一类页面当成无数个独立链接。具体怎么配，下一节细说。

2.3 那些容易被忽略但很要命的高级设置

配置窗口里有个"更多选项"或者"高级"的入口，点进去才是真正决定扫描质量的地方。

超时时间：默认值偏短，遇到响应慢的服务器会大量报超时，误判成死链。我一般会把它调大一些，给服务器留出反应时间。具体调多少看你的站点情况，如果服务器本身就不快，宁可调大也别让误报淹没真实问题。

并发连接数：这个值决定了同时发多少个请求。调太高会给服务器压力，也可能触发对方的限流；调太低扫描慢得让人抓狂。默认值通常是个折中，小站点可以适当降一点，大站点保持默认或者略升。

User-Agent：有些站点会根据UA返回不同内容，或者直接屏蔽某些UA。如果你发现扫描结果异常少，可以检查一下这里，换一个常见的浏览器UA试试。

是否跟随重定向：这个选项影响你看到的是"最终状态"还是"中间状态"。跟随重定向的话，一个301跳转的链接最终会显示目标页的状态；不跟随的话，你能看到跳转本身。排查重定向链条时，不跟随反而更有信息量。

排除规则：可以填一些URL模式，让Xenu跳过它们。比如后台路径、登出链接、带删除操作的URL，这些绝对不能让扫描器去碰，否则可能误触发操作。这一项一定要在正式扫描前配好。

注意：排除规则里的模式匹配要写准确，写得太宽可能把正常页面也排除了，写得太窄又起不到保护作用。建议先在测试环境验证一遍规则是否生效。

3. 从零跑通一次完整扫描

3.1 第一次扫描建议这样配

假设你要排查一个中小型内容站点的死链，我通常的配置是这样的：起始URL填首页，扫描深度设为不限制，外部链接不检查，图片资源检查打开（因为图片404也是常见问题），超时时间调到比默认稍大，并发保持默认，排除规则里加上后台路径和登出链接。

这样配的理由是：内容站点的页面层级一般不深，不限制深度能一次扫全；不查外链能大幅缩短时间；图片检查打开是因为内容站图片多，图片失效对用户体验影响直接。后台和登出路径必须排除，避免扫描器误操作。

配好之后点确定，扫描就开始跑了。界面上会看到链接一条条往列表里加，状态栏在滚动。这时候别急着动它，让它跑完。中途如果发现某个地址反复出现或者卡住，可以点停止，看看是什么情况再决定要不要调整配置重跑。

3.2 扫描过程中怎么判断是否正常

扫描跑起来之后，有几个信号可以帮你判断它是不是在正常工作。

一是列表在持续增长。如果跑了几分钟列表还是寥寥几行，要么是站点页面确实少，要么是起始页就没抓到多少链接，这时候要检查起始URL是否正确、页面是否需要登录才能看到内容。

二是状态栏的当前URL在变化。如果它长时间停在同一个地址上，说明那个链接响应极慢或者卡死了，可以记下这个地址，扫描结束后单独排查。

三是错误数量在合理范围内。完全没有错误不太现实，但如果错误数量异常多，比如一半以上都是404，那可能是配置有问题，比如起始URL填错了目录，或者站点对扫描器的UA做了限制。

我遇到过一种情况：扫描刚开始没多久就报了大量超时，检查后发现是并发设得太高，把服务器压得响应不过来。把并发降下来重跑，错误立刻少了一大半。所以看到异常多的错误时，先别急着下结论说站点死链多，先怀疑配置。

3.3 扫描结束后的第一件事

扫描跑完，列表里会有成百上千行。第一件事不是从头看，而是用过滤功能把错误筛出来。工具栏上那个"仅显示错误"的开关就是干这个的，打开之后列表只剩异常链接，一下子清爽很多。

筛出来之后，按状态码分类看。404是页面不存在，通常是真的死链；超时可能是服务器慢或者链接本身有问题；还有一类是重定向，虽然不算错误，但如果重定向链条太长（比如A跳B、B跳C、C跳D），也值得优化，因为每次跳转都损耗一点加载时间。

分类看完，再结合"来源页面"这一列，把每个错误定位到具体页面。这一步是后续修复的依据，所以看得细一点，别漏掉那些藏在深层页面里的死链。

4. 读懂报告：状态码背后的真实含义

4.1 常见状态码在Xenu里的表现

Xenu报告里出现的状态码，和HTTP协议里的定义是一致的，但结合扫描场景，有些码的含义需要额外注意。我整理了一张表，把常见的几种列出来。

这里要特别说下403。扫描时看到403，不一定是死链，很可能是站点对非浏览器请求做了限制，或者那个页面本来就需要登录。遇到403先手动在浏览器里打开看看，能正常访问就说明是扫描器被拦了，不用当成问题处理。

4.2 重定向链条为什么值得单独看

重定向本身不是错误，但链条过长会拖慢页面加载，也会稀释页面的权重传递。Xenu在报告里会把重定向的源地址和目标地址都列出来，你可以顺着看一条链接到底跳了几次。

理想情况下，一条链接最多跳一次就到最终页面。如果发现跳了三次以上，就该考虑把中间环节合并，直接让源地址指向最终地址。这种优化对用户体验和站点结构都有好处，而且改起来通常不复杂，就是调整一下跳转配置。

还有一种情况是循环重定向，A跳B、B又跳回A，这种会导致页面永远打不开。Xenu扫描时如果遇到循环，通常会报错或者卡住，看到这类记录要优先处理，因为它对用户是硬伤。

4.3 把报告导出后怎么二次加工

Xenu支持把结果导出成多种格式，最常用的是HTML报告和纯文本/CSV。HTML报告适合直接看，排版清晰，错误会用颜色标出来；CSV适合拿去做进一步处理，比如导入表格软件做统计，或者写脚本批量分析。

我一般的做法是：先导出CSV，用表格软件打开，按状态码排序，把404的挑出来单独一个表，再按来源页面分组，这样就能看出哪些页面集中埋了死链。集中出问题的页面往往是模板或者公共组件的问题，改一处就能解决一大片，效率比逐个改高得多。

导出的时候注意一下编码，如果站点有中文路径，确保导出和打开时编码一致，不然会出现乱码，影响后续处理。

5. 实操中那些说明书不会写的坑

5.1 扫描结果比预期少很多是怎么回事

这是新手最常问的问题。原因通常有这么几个，按可能性从高到低排：站点是前端渲染的，服务端返回的HTML里本来就没多少链接；起始URL填错了，抓到的页面本身链接就少；扫描深度设得太小，只抓了首页一层；站点对扫描器的UA做了限制，返回了精简版页面。

排查方法很简单：手动在浏览器里打开起始页，查看源代码，数一数里面有多少个<a href>，再和Xenu抓到的数量对比。如果源代码里链接很多但Xenu抓到的少，基本就是渲染方式或者UA的问题。

5.2 大量超时但手动访问正常

这种情况多半是并发或者超时设置的问题。扫描器短时间内发大量请求，服务器来不及响应，就会报超时。手动访问时是一个请求，服务器轻松应对，所以看起来正常。

解决办法是把并发降下来，超时时间调大，再跑一次对比结果。如果超时明显减少，就说明是配置问题，不是站点真有那么多坏链接。这个坑我踩过不止一次，一开始还以为是站点服务器不行，后来发现是自己把并发开太高了。

5.3 带参数的URL把结果撑爆了

内容站点常见列表页带分页参数，如果站点还有筛选、排序之类的参数，同一个页面可能对应几十种URL组合。Xenu默认会把这些都当成不同链接去请求，结果就是扫描时间暴涨，报告里全是看起来差不多的地址。

处理办法是在高级设置里配置URL去重规则，把不影响内容的参数忽略掉。具体忽略哪些参数，要结合站点实际情况判断，拿不准的话可以先小范围扫一下，看看哪些参数导致了大量重复，再针对性配置。

5.4 扫描把后台操作触发了

这个坑比较危险。如果站点里有"删除""登出""清空"这类通过GET请求触发的操作，而扫描器又恰好抓到了这些链接，它就会真的去请求，等于替你执行了一遍操作。虽然大多数正规站点这类操作都走POST，但老站点或者内部系统里走GET的情况并不少见。

所以正式扫描前，排除规则一定要配，把后台路径、操作类URL都排除掉。宁可多排除一些，也别让扫描器碰到不该碰的地址。这一条我在给任何站点做扫描前都会先确认。

5.5 报告里的"来源页面"为空

偶尔会看到某些链接的来源页面是空的，这通常是因为那个链接是从重定向或者某种特殊跳转里被发现的，Xenu没能记录到明确的来源。这类链接数量一般不多，处理时可以单独拎出来手动确认，不用太纠结。

6. 把Xenu用进日常巡检的几个习惯

6.1 固定一套配置，减少变量

每次扫描如果配置都不一样，结果就没法横向对比。我的习惯是给每个站点固定一套扫描配置，存下来，每次巡检都用同一套。这样跑出来的结果，错误数量的增减才有参考意义。如果某次错误突然变多，就能判断是站点真的出了问题，而不是配置变了导致的。

配置固定下来之后，还可以把每次的扫描结果按日期存档，时间长了就能看出趋势。比如某个栏目的死链是不是在持续增加，某类错误是不是反复出现，这些信息对站点维护很有价值。

6.2 扫描频率和时机的选择

全量扫描不需要太频繁，站点内容更新不密集的话，一个月一次足够。如果站点更新频繁，或者刚做过大的结构调整，可以临时加一次。时机上尽量避开访问高峰，选在流量低的时段跑，减少对正常用户的影响。

对于重点页面或者核心栏目，可以单独做小范围的高频扫描，比如每周扫一次首页和主要入口页的直接链接，这样能更快发现新出现的死链，而不用等全量扫描。

6.3 扫描结果要落到具体的人

扫描出问题只是第一步，关键是有人去改。我见过不少团队，扫描报告出来往群里一发就没人管了，下次扫描还是同样的问题。比较有效的做法是把报告按来源页面拆分，分给对应页面的负责人，改完之后再跑一次验证。Xenu的报告里来源页面列得很清楚，拆分起来不费劲。

验证的时候不用全量重扫，针对修改过的页面做一次小范围扫描就行，确认那些死链已经消失。这样闭环起来，死链才不会越积越多。

6.4 别只盯着404

很多人用Xenu就只看404，其实其他状态码同样值得关注。403可能意味着有页面被错误地限制了访问，500说明目标页面有程序问题，大量重定向说明站点结构需要梳理。把这些都纳入巡检范围，站点健康度才看得全面。

另外，图片和其他资源的404也别忘了看。页面本身能打开，但里面的图片挂了，用户体验一样受影响，而且这类问题在只看页面链接的时候容易被漏掉。

7. 几个能提升效率的小技巧

7.1 用过滤和排序快速定位问题

扫描结果列表支持按列排序，点一下状态列就能把相同状态的链接聚在一起。配合"仅显示错误"的过滤，几秒钟就能把问题清单整理出来。来源页面列也可以排序，这样同一页面的问题会挨在一起，方便批量处理。

如果报告特别大，导出CSV之后在表格软件里做透视或者筛选，比在Xenu界面里翻要快得多。尤其是需要统计"每个页面有多少死链"这种问题时，表格软件的优势很明显。

7.2 分批扫描大站点

站点页面数量很大的时候，一次性全量扫描可能跑很久，中途出问题还得重来。比较稳妥的做法是按栏目或者目录分批扫，每次扫一个子范围，跑完存档，最后再汇总。这样单次扫描时间可控，出问题也只影响一小批。

分批扫描还有个好处是，你可以针对不同栏目设置不同的排除规则和深度，灵活性更高。比如产品目录可能层级深，就多跟几层；新闻栏目更新快，就单独高频扫。

7.3 保存扫描配置供复用

Xenu支持把扫描配置保存下来，下次直接加载，不用重新填一遍。对于需要定期巡检的站点，这个功能很实用。把每个站点的配置分别存好，命名清楚，用的时候一选就行，既省时间又避免手误改错参数。

配置保存之后，如果站点结构有调整，记得同步更新配置里的排除规则和去重规则，不然可能扫到不该扫的地方，或者漏掉新增的栏目。

7.4 结合浏览器手动抽查

工具报告是批量结果，但有些情况需要人工确认。比如某个链接报404，手动打开看看是不是真的打不开；某个页面报403，手动访问确认是不是权限问题。工具负责发现，人负责判断，两者结合才不会误伤。

我一般会从报告里随机抽几条不同类型的记录手动验证一下，确认工具的判断和实际情况一致。这个习惯能帮你及时发现配置问题，避免基于错误报告做决策。

8. 关于Xenu适用边界的几点体会

Xenu在链接可达性检查这个场景里确实好用，但它的能力边界也很清楚。它看不到JavaScript动态生成的链接，不分析页面内容的语义，也不评估链接的质量，它只回答"这个地址能不能请求通"这一个问题。所以别指望用它做全面的站点诊断，它只是工具箱里的一件。

我在实际使用中的体会是，把它当成日常巡检的第一道筛子最合适。它跑得快、结果直接，能快速把明显的死链和异常挑出来。至于更深层的问题，比如页面结构、内容质量、加载性能，那是其他工具和人工分析的事。各司其职，效率才高。

还有一点，工具再顺手，配置和判断还是靠人。同一份报告，懂站点结构的人能看出模板层面的问题，不懂的人只能一条条改。所以用工具之前，先花点时间了解自己的站点，比研究工具的高级功能更有价值。