llms.txt校验器亮绿灯时，5条链接可能全是死的

摘要：llms.txt校验器把一份清单的结构拆成六项逐条给结论——H1标题、摘要引用块、H2分区、链接条目格式、Optional分区、llms-full.txt是否存在，然后抽样验证条目里的地址还能不能打开。我们做了一份自建探针文件，把它的判定顺序整个跑穿了。

最需要先知道的一条：顶部那个绿色的“结构合规”跟链接死活无关。探针文件结构完全合规、5条链接全部打不开，顶部照样是绿的——结论在链接验证请求发出去之前就已经渲染完毕，死链结果回来时只更新下方列表，不回头改结论。

另外三条是解析口径的问题：相对路径一律按域名根拼接，放在子目录里的清单会被解析到根本不存在的地址；llms-full.txt那一栏查的永远是域名根；地址里带圆括号会被截断，被切掉的右括号还会窜进说明栏。这篇把每一条的复现方式、影响范围和绕开的办法讲清楚。

做SEO的人对文件校验器这类东西是有肌肉记忆的：跑一遍，看见绿色就放心走。这个习惯在robots.txt和sitemap.xml上大体没问题，因为那两份文件有正式规范托底，什么算合法、什么算违规，规范里写得明明白白。llms.txt不一样，它是一份社区提案，正式规范这一层根本不存在。

于是校验这件事就变得微妙起来：工具报的“不合规”，究竟是提案明确禁止的，还是某个实现自己加的偏好？这个区别对使用者很重要，因为它直接决定了你该不该照着改。保哥笔记的llms.txt校验器是站里负责检查这份文件的那一款，这篇教程会先讲清楚它每一项在查什么，再把它的判定口径逐条拆开——顺便把提案原文真正规定了哪些事、没规定哪些事，一次说明白。

那个绿色的“结构合规”到底在保证什么？

先说结论：它保证的是文件的骨架搭对了，不保证骨架上挂的东西还在。

探针文件是怎么设计的

为了把这件事测干净，我们在服务器上放了一份完全按提案写的探针文件：一个H1、一个以大于号开头的引用块、两个H2分区、每条链接都是绝对地址、每条都带说明、还专门加了一个名为Optional的分区，返回的Content-Type也是text/plain。按工具自己列的六项检查，这份文件应该项项满分。

关键在链接。那5条链接指向的地址是我们故意挑的：4条确定返回404，1条是构造出来的特殊地址，GET能通而HEAD返回405。换句话说，这份清单的结构无可挑剔，但它指向的内容一个都取不到——正是一份改版之后没人维护的llms.txt会有的样子。

结果是绿的，而且没有任何提示

跑出来顶部是绿色的“✅ 结构合规”，说明文字写着“文件存在且符合提案定义的结构”。下面的分区列表里，5条链接确实老老实实标着红色的404和405，但顶部的结论一动不动。整个页面上，没有一个字提示你这份清单已经指不到任何东西了。

这不是判定标准松，是判定和验证根本不在同一个时间点上发生。它的前端拿到文件内容之后，立刻算出结论并渲染到页面上；链接可达性是另一个请求，发出去要等好几秒才回来，回来之后只负责填下面那张表。结论那一块的代码从头到尾只跑一次，链接结果回来时它已经不参与了。

这个顺序为什么值得你专门记住

因为llms.txt出问题的方式，九成是这一种。文件刚写好的时候大家都会认真检查，格式肯定是对的；出问题都在半年之后——站点改版、栏目重排、slug批量调整，正文页的地址换了一批，而那份躺在根目录的清单没人记得改。这时候文件的骨架依然完美，内容已经全烂了。

所以用这款工具有一条实操纪律：顶部的结论只看有没有红色的“结构不合规”，绿色和黄色一律当成“结构这关过了”，然后直接往下滚，去看每条链接前面那个状态码。真正告诉你这份文件还有没有用的，是下面那一列数字，不是上面那句话。

提案原文只规定了一件事，其余都是建议？

这一节可能是整篇最有用的部分，因为它决定了工具报出来的黄灯你该不该理。

回到提案原文

llms.txt由Jeremy Howard在2024年9月提出，提案原文短得可以一口气读完。它规定的结构是：一个H1写项目名，这是唯一必填的；一个可选的引用块写简短说明；若干可选的普通段落；若干H2分区，每个分区下面是格式为方括号名称加圆括号地址的链接列表，地址后面可以跟一个冒号和一段备注；以及一个可选的、名为Optional的分区，放次要资源。

注意“可选”这两个字出现的密度。除了H1，剩下全是可选的。提案原文里还有一句话经常被忽略：它明确说自己不对“如何处理这个文件”给出任何特定建议。也就是说，读取方怎么解析、按什么顺序取、遇到相对路径怎么办，提案通通没管。

三条黄灯，全扣在提案没写的事上

工具在文件结构没毛病时会给出黄色的“可以用，但有几处建议改”，触发它的一共有五种情况，其中三种是这样的：

把这张表读一遍你会发现一件有点好笑的事：一份严格按提案写的、一个字都不多的最小合规文件，在这款工具里几乎注定拿不到绿灯。因为最小文件不会有Optional分区，多半也不会给每条都写说明。它没错，只是不合工具的偏好。

一份最小合规文件长什么样

把提案的必填项和可选项分清楚之后，最小合规文件其实短得让人不太敢信：

# 某某公司产品文档

## 文档

- [快速开始](https://example.com/docs/start)
- [接口说明](https://example.com/docs/api)

就这些。一个H1，一个H2分区，两条链接，没有引用块、没有说明、没有Optional分区。按提案，这份文件挑不出毛病。把它扔进校验器，结果是黄灯，理由三条：缺摘要引用块、2条链接没写说明、没有Optional分区。

这个结果本身没错，它给的确实都是有价值的建议。要小心的是别把黄灯读成“我写错了”，它的准确含义是“还有几处可以更好”。这两句话对你接下来的动作影响完全不同：前者会让人急着改，后者才会让人先想清楚要不要改。

那这些建议还要不要听

要听，但要换个理由听。别把它们当成“不改就违规”，当成“不改可能吃亏”更准确。

说明那一条尤其值得照做。一份只有链接没有说明的清单，对读取方来说信息量约等于一份sitemap，模型得把每个地址都取回来才知道里面是什么；写了说明，它可以先看说明再决定取哪几个。这个差别在上下文紧张的时候是实打实的。至于Content-Type，text/markdown这个媒体类型确实有正式定义，就在RFC 7763里，但那份文档规定的是这个类型本身怎么用，从没说过llms.txt必须用它。只要你的服务器没把文件返回成text/html导致读取方按网页去解析，这条一般不用管。

顺便把三份文件的分工理一遍，因为总有人把它们混着理解。robots.txt管的是“允不允许抓”，是权限声明；sitemap.xml管的是“这个站有哪些地址”，追求的是全；llms.txt管的是“这个站里最值得读的是哪几篇”，追求的是精选。前两份有正式规范、有明确的消费方；第三份两样都还没有。把llms.txt写成一份缩水版sitemap，是最常见的一种理解偏差——它要是能被一段脚本从数据库里全量导出来，多半就已经写偏了。

相对路径为什么会被解析到网站根目录去？

这是这款工具最容易让人得出错误结论的一处，而且它有一组特别干净的对照实验。

先看现象

我们把探针清单放在一个子目录里，地址形如站点下的某个工具目录加llms.txt。清单里有一条相对路径的条目，写的是同目录下的一个文件名。按RFC 3986关于基准地址的规定，相对引用要以“包含它的那份文档自身的地址”为基准来解析，所以这条相对路径应该指向同一个子目录下的那个文件——那个文件真实存在，直接访问返回200。

工具解析出来的却是域名根目录下的同名文件。那个地址不存在，返回404，于是这条链接被标成红色死链。同一份清单里的绝对地址条目全部正常。对照组干净得没有任何解释空间：真实存在的文件被判成死链，原因只是基准取错了。

为什么会这样

它拼接地址时用的基准，是从你输入的站点地址里拆出来的协议加主机名，路径部分整个丢掉了。所以不管这份清单躺在哪个目录，相对路径都会被拼到域名根上去。如果清单本身就放在根目录——绝大多数站都是这样——这个做法碰巧是对的，因为此时文档地址的目录部分正好就是根。一旦清单不在根目录，它就会全线偏掉。

谁会踩到这个坑

三类站：把清单放在语言子目录下做多语言的、用子目录部署多个独立项目文档的、以及在测试环境里先把文件放到某个临时路径试跑的。前两类是真实场景，第三类是很多人第一次用这个工具的方式——先随便找个能放文件的路径试试看，结果试出一堆假死链。

绕开的办法只有一个，而且顺带解决了上一节那条黄灯：清单里一律写绝对地址。这样既不依赖任何一方对基准的处理，也躲开了这个解析差异。这也是为什么上一节里我说，相对路径那条建议该听，只是理由不是提案要求，而是各家实现对相对路径的处理压根不一致。

llms-full.txt那一栏为什么永远显示存在？

六项检查里的最后一项是llms-full.txt检测，它会告诉你这个文件在不在、多大。这一项有个固定行为需要你知道：它查的永远是域名根目录下的llms-full.txt，跟你正在校验的那份清单在哪儿没有关系。

我们用放在不同子目录里的三份探针清单分别跑了一遍，那三个子目录下都没有llms-full.txt，但三次的结果一模一样，都报“存在 · 12.9 KB”——12.9 KB正是本站根目录下那个文件的真实大小。它是完整下载了这个文件之后拿到的字节数，不是估算，也不是HEAD拿的响应头。

这个行为在清单放在根目录时完全正确，跟上一节是同一个成因。它的实际影响是：如果你在子目录里试跑，这一项给的是隔壁的答案；更要紧的是，如果你正在校验的是别人的站，这一项报“存在”只能说明那个站的根目录有这个文件，不能说明它和你看的这份清单是配套的。做竞品调研的时候容易被这一栏误导。

顺带说一句llms.txt和llms-full.txt的分工，因为工具在这一栏的提示语里也建议两个都提供。前者是索引，给地址和说明，读取方按需去取；后者是全文，把主要内容拼在一个文件里一次读完。索引式的文件小、维护简单，代价是读取方要发多次请求；全文式一次到位，代价是文件可能大到吃不下，而且更难跟正文保持同步。

哪些合法写法会被它的解析器悄悄吃掉？

这一节讲四种情况，共同点是：文件里写了，页面上没有，也没有任何报错。安静地消失是所有解析问题里最难查的一种。

地址里带圆括号会被截断

维基百科那种消歧义地址是最典型的例子，地址本身末尾带一对圆括号。工具提取地址时是从左括号找到第一个右括号为止，所以地址在消歧义那对括号的左括号处就被截断了，右括号连同后面的内容被当成了说明。

结果是双重的：这条链接指向一个被砍掉尾巴的地址，验证时返回0或者404标成红色死链；同时这一条的说明栏里，会莫名其妙地出现一个孤零零的右括号开头的残句。看到说明栏开头有个不知道从哪儿来的括号，基本就是这个原因。

顺带一提，这不是它自己发明的写法。CommonMark规范对这种情况有明确处理：地址里的圆括号只要成对出现就是合法的，或者用尖括号把地址包起来。工具的正则两种都没照顾到。

第二个H1会人间蒸发

文件里如果出现第二个一级标题，它既不会被显示，也不会被报错，就是没了。解析器在认出第一个H1之后会把开关关掉，后面所有以井号加空格开头的行都不再被当成标题；而收集普通段落的那个分支又明确排除了以井号开头的行。两头都不收，这行内容直接掉进缝里。

提案确实只允许一个H1，所以出现第二个是文件本身有问题。但这里的问题是工具没告诉你——一份合并了两个项目的清单，或者从两份文件复制粘贴拼起来的清单，最容易出现这种情况，而校验器看不出来。

尖括号包起来的地址会被当成相对路径

Markdown里有一种写法是把地址用尖括号包起来，这在CommonMark里是自动链接的标准语法。工具判断地址是不是绝对地址的方式，是看这个字符串开不开头就是协议名——尖括号包着的地址第一个字符是尖括号，判断直接失败，于是被当成相对路径，接着被拼到域名根后面去。

拼出来的东西是一个域名后面跟着一整个尖括号包着的地址，这玩意儿当然打不开。所以这一条会同时吃到两个误报：既被标注“（相对路径）”，又被标成死链。

全角冒号会窜进说明里

提案定义的条目格式，地址后面跟一个半角冒号再写备注。工具的正则认的也是半角冒号。中文作者写这份文件时，十有八九会顺手打成全角冒号——中文输入法下这几乎是默认结果。

全角冒号不被识别为分隔符，于是它连同后面的备注一起被整个收进说明字段。页面上这条的说明就以一个全角冒号开头。这不影响链接本身，也不影响任何判定，纯粹是显示上的小别扭，但它是中文站跑这个工具时最常见的一处观感问题。

空分区不会被报出来

还有一种情况是反过来的：工具在说明里承诺会标出的问题，实际上没标。它的使用说明里写着会指出“分区为空”，但实测建一个只有标题没有任何条目的H2分区，页面上那个分区确实显示着0条，黄色的建议列表里却一个字都没提。

这个疏漏的影响不大，因为分区列表里那个刺眼的0本来就够显眼。但它值得作为一个提醒：工具说明里写的检查项，和代码里真正实现的检查项，不一定一一对应。碰到关键判断，最好用一份自己造的、故意写错的文件去验一次，而不是直接相信功能说明。

超过500 KB的部分会被直接切掉

抓取时它只保留前50万字节，超出的部分静默丢弃。对llms.txt来说这个上限基本碰不到——本站125条目的清单也才21 KB，要写到500 KB得有几千条，那时候文件早就失去精选的意义了。

真正会碰到的是另一种用法：把llms-full.txt的完整地址粘进去校验。全文式文件几百KB是常态，上兆的也不少见。一旦超过上限，后面的内容整个不参与解析，而页面上没有任何“内容被截断”的提示，你看到的分区数和条目数就都是残缺的。

所以对llms-full.txt，这款工具只适合确认它存在、能取到、开头部分格式正常，不适合用来清点条目。文件状态那一行显示的KB数是真实下载字节数，可以拿它和你自己文件的实际大小对一下——两个数字对不上，就说明解析用的内容被切过。

打得开的地址为什么被判成死链？

链接验证这一步用的是HEAD请求：只要响应头，不要正文，快而且省流量。这个选择本身没毛病，绝大多数场景下它就是正确做法。

问题出在少数服务器上。HTTP语义规范要求HEAD的处理方式必须和GET一致，只是不返回正文；但现实里，有些应用框架的路由只声明了GET方法，收到HEAD就回405方法不允许。我们专门构造了一个这样的探针地址：GET返回200，HEAD返回405。工具的判定结果是红色的405。

会这么干的服务端不算罕见：某些框架的默认路由配置、部分CDN和WAF的规则、以及一些明确声明只支持GET的接口。所以看到405要多想一步——405说的是“这个地址不接受HEAD”，不是“这个地址不存在”。真正代表内容没了的是404和410，那两个才需要立刻去改清单。

另外还有两种状态码值得分开看。3开头的橙色表示跳转，工具跟随了最多3次跳转之后拿到的才是最终状态，所以显示橙色说明这条能打开但地址不是最终地址——清单里应该直接写最终地址，让读取方少跑一趟。显示“超时”的那些则要单独重试，6秒的超时对慢站来说确实有点紧。

还有一处轻微的信息缺失值得提：你如果用http开头的地址去校验一个已经全站跳转到https的站，工具会跟随跳转拿到内容并给出绿灯，但界面上显示的地址仍然是你输入的http版本，全程没有任何“这里发生了跳转”的提示。后端其实拿到了最终地址，只是没往前端传。

一次完整的校验该怎么跑，结果怎么读？

把上面这些放在一边，说说正常怎么用。整个流程比看起来简单，六步走完不到一分钟。

输入与触发

输入框填域名就行，不用带路径，它会自动去取根目录下的llms.txt。如果你想校验的是子目录里的文件或者llms-full.txt本身，把完整地址粘进去也认——它会检查你给的路径是不是以llms.txt或llms-full.txt结尾，是就直接抓那个地址。旁边那个“用本站试一下”的按钮会填入本站域名并立刻跑起来，第一次用建议先点它看看输出长什么样。

六项检查怎么读

其中“链接条目”那一项报0需要格外注意，因为它经常不是真的没写链接，而是格式差了一点点导致一条都没匹配上。

一条都没匹配上时先查这三种写法

条目的识别规则比看起来严格，下面这几种写法在Markdown编辑器里预览完全正常，在这里一条都认不出来：

+ [名称](https://example.com/a)     ← 列表符号只认减号和星号
1. [名称](https://example.com/b)   ← 有序列表不认
- [名称] (https://example.com/c)   ← 方括号与圆括号之间多了空格
  - [名称](https://example.com/d)  ← 行首有缩进
- [名称](https://example.com/e)    ← 这一条才是对的

前四种写法里，第一种和第二种是习惯问题，用惯了加号或有序列表的人很容易带过来；第三种在从富文本编辑器里复制粘贴时特别常见；第四种则多半来自嵌套列表——有人喜欢把链接放在分区标题下的二级缩进里，看着整齐，实际上一条都不会被认出来。

判断方法很直接：如果分区那一项是绿的、条目那一项是0，问题一定在写法而不在内容。因为分区能被认出来就说明文件读到了，那么读不到条目就只剩格式一种可能。这时候把出问题的那几行贴到一个纯文本编辑器里，把行首的不可见字符和多余空格看一遍，基本就能找到。

链接列表怎么读

结构检查渲染完之后，工具会去验证链接可达性，这一步要等十几秒。它验证的是前24条，分两批发出，每批12条并发跑。超过24条的部分在列表里显示为“未验”的橙色标记——这不是问题，只是没测。

24这个上限对小站够用，对大清单就不够看了。本站自己的清单有125条，也就是说只有不到两成被验证过。所以对大清单，这款工具给出的死链结论是抽样结论：抽样里有死链，说明文件肯定该修了；抽样里全绿，不能推出剩下的也全绿。这一点工具自己在说明里也写明了，不算隐瞒。

拿本站自己的清单跑一遍，能看出什么？

光说不练没意思，我们把本站的llms.txt扔进去跑了一遍，正好是一个既典型又有瑕疵的样本。

结构层面全绿：一个H1、有摘要引用块、5个H2分区、125条链接条目、有Optional分区、Content-Type是text/plain、根目录下的llms-full.txt存在且是13 KB。125条全部是绝对地址，所以相对路径那条黄灯不会触发。按工具的六项标准，这份文件是满分。

但翻到下面的分区列表，问题就露出来了。125条里有42条的说明是以全角冒号开头的——上一节讲的那个解析口径，在真实文件里就是这么表现的。更值得说的是那42条说明的内容：它们不是人工写的一句话概括，而是从正文开头截下来的一段，读起来是半截话，甚至有的把页面上的杂项内容也截了进去。

这就引出了一个校验器完全看不见的问题：说明字段“有”和“有用”是两回事。工具只统计有多少条没写说明，写了的它一律算过。而一份清单真正的价值恰恰在这些说明里——读取方靠它决定要不要取这个地址。截取正文开头当说明，字段是填上了，判断价值接近于零。

这一条也是保哥自己站上待办清单里的一项。工具能查的是结构，不能查的是内容质量，这个边界得自己心里有数。

5个分区是怎么分的

分区设计这件事，校验器只数个数不评好坏，但它其实是清单里最需要动脑子的部分。本站这5个分区分别是站点页面、核心专题、工具、按主题的文章索引，再加一个Optional。这个分法背后的逻辑是按“读取方可能的意图”分，而不是按站内的栏目结构分。

差别在哪儿？栏目结构是给人看的导航，通常按内容生产的组织方式来分；而读取方来取这份清单，多半是想快速搞清楚这个站在哪些问题上有可信内容。所以分区名要写得像意图标签而不是栏目名——写“技术SEO实战”比写“教程”有用，写“工具与在线检测”比写“资源”有用。

Optional分区里适合放的是那种“有人明确要才有用”的东西：归档页、条款与版权页、联系方式、变更记录。这些内容不该占用读取方宝贵的上下文，但真被问到时又必须能找到。这个分区的设计意图容易被忽略，它不是垃圾桶，是明确标注的次要区。

这款工具做对了哪些别人常做错的事？

挑完毛病得说句公道话，它在几个容易被做错的地方处理得比同类工具讲究。

它防住了服务端请求伪造。这类“输入一个地址，服务器帮你去抓”的工具，最经典的安全问题就是被人拿来探测内网。它在抓取前会把域名解析成IP，落在私有地址段或保留地址段的一律拒绝，同时也挡掉了localhost和几个内部域名后缀。这一步没什么展示价值，但少了它，这个工具会变成一把递给别人的内网扫描器。

它对首次抓取失败做了重试。抓取超时或连接失败时，它会等0.4秒再试一次，第二次的超时给得更宽松。目标站偶发慢响应在真实网络里太常见了，不重试的话使用者只会得到一个莫名其妙的失败。

链接验证是真并发。24条链接分两批并发跑，不是排队一条条来。这件事说起来理所当然，但站里之前测过的另一款工具，界面上写着分批并发，实测是老老实实串行，6个目标花的时间正好是1个目标的6倍。这次这款是货真价实的并发。

它对自己的边界是诚实的。工具页面的说明里明明白白写了五条做不到：校验的是社区提案不是正式标准、只抽样验证前24条、不判断内容质量、不检测更新时效、不代表模型会怎么用这个文件。这几条没有一条是自夸，尤其最后一条——直说了没有任何一家主流AI厂商公开确认会读取llms.txt。做工具的人肯把这话写在自己的产品页上，不太容易。

顺着这条再补一句现状：想知道哪些爬虫是真在抓你的站，最靠谱的做法还是去查各家公开的爬虫标识文档，然后回自己的访问日志里对照那个文件的抓取记录。日志里能看到的llms.txt抓取，多数来自第三方工具和研究型爬虫，这一点和工具页说的一致。

生成器和校验器怎么配成一条流水线？

站里这两款工具是配套的：生成器负责产出，校验器负责确认产出的东西没随时间烂掉。分开用都能用，配起来才顺手。

第一次做的顺序

先用llms.txt生成器把文件搭出来，逐字段填法和分区怎么设计那篇里讲得很细。生成完部署到根目录，然后立刻用校验器跑一遍——这一遍主要是确认服务器把文件正常吐出来了，Content-Type对不对、有没有被某条重写规则拦掉。新部署的文件最常见的问题不是内容错，是根本没被正确解析出来。

之后的维护节奏

把校验纳入发布流程比定期回跑更有效。具体说就是两个触发点：站点结构调整之后跑一遍，内容有较大批量更新之后跑一遍。这两件事是清单烂掉的主要原因，其余时间它其实相当稳定。

拿保哥手上一个B2B工业阀门外贸站举例。那个站去年把产品线的目录结构重排过一次，从按品类分改成按标准分，正文页地址批量换了。清单文件当时没人想起来，直到几个月后有人顺手跑了一遍校验，才发现列在首位的十几条产品页地址全部指向已经不存在的路径。文件本身的结构一直是绿的，中间那几个月它就是一份指不到任何东西的目录。

这个站后来的做法很简单：把跑校验这一步写进了改版检查清单，和跑sitemap、检查重定向放在一起。这三件事的共同点是——它们都不会主动报错，你不去查就永远不知道坏了。

不同站型该往清单里放什么

清单该收多少条、收什么，跟站型关系很大。三种常见情况可以照着套：

三类站有个共同的取舍原则：宁可少列几条写清楚，也别把整站目录搬过去。这份文件的全部价值就在“有人替读取方筛过一遍”，筛的动作一旦省掉，它和sitemap就没区别了，而sitemap那份人家早就有了。

条数上去之后还有个现实约束值得记住：校验器只验前24条。所以列的时候顺手把最重要的放前面，既符合读取方的阅读顺序，也让抽样验证正好覆盖到你最在意的那些地址。这不是投机，是把有限的检查力气花在刀刃上。

更要紧的一件事

最后得把这个工具放回它该在的位置。llms.txt目前仍然是一份社区提案，没有厂商公开承诺读取它，关于它到底有没有用，站里有一篇拿10个站做了90天实测的记录可以参考；Chrome的Lighthouse倒是悄悄加了一项检查它的审计，这件看起来矛盾的事在另一篇里拆过。

把这些放在一起看，结论是稳的：写这份文件的成本极低，值得顺手做；但它对AI可见度的贡献，远远排在内容本身的质量、结构和可抓取性之后。花两个小时把清单写好写对，是划算的；指望靠它把引用率拉起来，是不划算的。校验器的作用是让那两个小时不白花，仅此而已。

真要在AI可见度上使劲，力气该花在正文本身能不能被切成一块块自足的内容上——检索方召回的从来不是整篇文章，而是其中某一段。站里的RAG分块预览器教程讲的就是那一层，可以接着看。这两件事的先后顺序值得记住：清单是让人找得到你，分块是让人引用得动你，后者的权重高得多。

常见问题解答

结构显示合规，是不是就说明这份清单没问题了？

不是。绿色的结论只覆盖文件骨架，跟链接死活完全无关。我们测过一份结构完美但5条链接全打不开的文件，顶部照样是绿的。原因是结论在链接验证请求发出去之前就渲染完了，死链结果回来只更新下面的列表。用的时候把绿灯当成“结构这关过了”，然后直接往下看每条链接前面的状态码。

清单放在子目录里，为什么相对路径全被判成死链？

因为它拼接相对路径时用的基准是协议加域名，路径部分被丢掉了，所以不管清单在哪个目录，相对路径都会被拼到域名根上。清单在根目录时这个做法碰巧正确，放在子目录就会全线偏掉。解决办法是清单里一律写绝对地址，既躲开这个差异，也躲开各家实现对基准处理不一致的问题。

链接返回405，是不是这个页面没了？

不是。405的意思是这个地址不接受HEAD请求，不是内容不存在。工具验证可达性用的是HEAD，而有些框架的路由只声明了GET，收到HEAD就回405。真正说明内容没了的是404和410。遇到405可以自己用浏览器打开确认一下，多半是好的。

工具说没有Optional分区，我必须加一个吗？

不必须。Optional在提案里本来就是可选的，这条黄灯扣的是工具自己的偏好而非提案要求。判断标准是你有没有真正的次要资源需要单独标出来——有就加，比如变更日志、历史归档、条款页；没有就别为了消掉一个黄灯硬凑。同理还有Content-Type那条建议。

为什么只验证前24条链接，剩下的怎么办？

为了控制耗时，分两批各12条并发跑，超过的显示为未验。清单条目少时够用，条目多时就是抽样。读结论要注意方向性：抽样里出现死链，说明文件肯定该修了；抽样里全绿，推不出剩下的也全绿。条目上百的清单，建议自己另外拉一遍全量检查。

说明栏开头那个奇怪的括号或者冒号是怎么回事？

两种情况。开头是右括号，说明这条的地址里带圆括号，被从第一个右括号处截断了，切掉的部分窜进了说明；开头是全角冒号，说明你用中文输入法打了全角冒号，而它认的是半角，于是冒号连同备注一起被当成了说明内容。前者会导致这条被误判成死链，后者只影响显示。

校验器能替我判断这份清单写得好不好吗？

不能，它只查结构不查内容。最典型的例子是说明字段：工具只统计有多少条没写，写了的一律算过。所以把正文开头截一段填进去，字段是满的，判断价值接近于零。清单的价值恰恰在这些说明里，读取方靠它决定要不要取这个地址，这部分只能人工写。

多久该回来跑一次校验？

比起定期回跑，更有效的是绑在两个触发点上：站点结构调整之后跑一遍，内容批量更新之后跑一遍。清单烂掉的主要原因就是这两件事，其余时间它相当稳定。建议把这一步写进改版检查清单，和跑sitemap、检查重定向放在一起——它们的共同点是都不会主动报错。

权威参考资料