sitemap提交的地址，页面自己认不认账？

摘要：从116个海外品牌独立站的sitemap里各随机抽6条地址，一共694条，逐条实抓之后跟提交层、交付层、索引层三处的声明对照。结果是561条（80.8%）三处一致，133条（19.2%）至少有一处对不上：31条提交之后跳到了别的地址，28条页面上明写着不要收录，18条直接返回403，16条的canonical指向别处。更值得注意的是那63条非200的地址——换成普通浏览器身份重抓一次，其中18条立刻变成200，说明将近三成的失败不是页面坏了，是它不接待这个身份。

前两篇分别量了一份文件内部两条规则打架、一份响应里两个字段打架。这一篇往上走一层：同一个地址被四个地方各声明了一次身份，而这四处分属不同的文件、不同的团队、不同的更新节奏。

八月十七日那条关于llms.txt第二版的消息给了这件事一个新注脚——它又加了两种链接关系，可以写在HTML里，也可以写在响应头里。这意味着一个页面的身份声明从四处变成了五处，而它们之间从第一天起就没有任何一致性检查。

所以保哥把这批站的sitemap全拉了下来，随机抽样实抓，看看这几处说的到底是不是同一件事。

你提交的那个地址，交付层还认它吗？

先说最基础的一层。sitemap的语义是我希望你收录这些地址，那么最起码这些地址得能打开。

单站也做过同类抽查，585条网址里48条是坏的而生成程序一次都没报错。

这份文件的写法讲究不少，2400个站踩出来的sitemap坑基本都在那份清单里。

这里先交代一个边界：本文只看sitemap里声明的地址，不做全站爬取。两者的差别不小——全站爬取能发现那些没被提交但存在的页面，而本文关心的恰恰是反过来的方向：提交了的这些，到底是什么状态。

样本是怎么建起来的

起点是157份能正常读取的robots.txt，其中143个站按robots协议里的声明方式写了sitemap地址，一共676条声明。每站取前两条去抓，第一层拿回157份，其中116份是协议里定义的索引文件、36份是地址清单，剩下几份无法识别。

反方向的检查也有一套，孤岛页面检测的抽样口径怎么定讲的是没被提交的那些。

批量拿地址有现成办法，六种格式的sitemap解析与URL提取能省掉手工翻页。

同一批robots.txt里还量过规则本身，两条规则撞车时赢的不是先写的那条是按路径长度判的。

索引文件里又声明了8573个子文件，每站挑最多三个抓第二层。两层合起来共拿到263203条地址，覆盖109个站。抽样时每站至多抽6条、排除掉图片和文档类地址，最终694条覆盖116个站。

抽样时特意排除了图片、样式表、文档这类非页面地址，因为它们的状态判断标准不一样。剩下的全是HTML页面，涵盖商品页、分类页、内容页和各种功能页，跟真实的收录目标基本重合。

打不开的有63条，占9.1%

694条里631条最终返回200，63条不是。分布是403十八条、404九条、302八条、406六条、400六条、429六条、完全连不上四条、410三条、500两条、301一条。

批量确认地址还在不在有现成办法，死链怎么批量查出来再分类提交可以直接套用。

这些状态码各自的含义有张速查表，301、302、404和410该在什么场合用能省掉不少争论。

把这张表跟上一批的一组数字放在一起会更有感觉：那次抽了585条某个站的sitemap地址，48条是坏的，比例8.2%，跟这次跨站抽样的9.1%相当接近。单站和跨站两个口径得出同一量级的数字，说明这不是某几个站的毛病。

410这个状态码值得单独看

falconeri.com有三条返回410，意思是这个地址已经永久删除。这其实是个好信号——它说明这个站认真处理了下架页面，用410而不是404告诉对方别再来了。

下架之后那一页该怎么办，集合页没有产品时的三种场景处置给了判断依据。

改版之后最容易出这类问题，一次揪出全站404与重定向链是改完必跑的一步。

问题在于同一批地址还留在sitemap里。一边说这个页面永久没了，一边把它提交给搜索引擎，两个声明的时间差可能是几周，也可能是几个月。生成sitemap的程序显然没有读过页面的状态码。

还有一个判断上的细节：410和404在这批数据里我没有合并统计，因为它们表达的意图不同。前者是站方主动声明永久删除，属于处理得当只是没同步；后者可能是主动删除，也可能是路由改了没人知道。两者混在一起会掩盖掉前一类的正面信号。

500那两条更麻烦

intimissimi.com有两条商品页返回500，服务器内部错误。这类地址在sitemap里的危害比404大得多：404是明确的否定答案，搜索引擎知道该怎么处理；500是我暂时坏了，对方会重试，重试的次数还不少。

抓取额度被浪费的账要算清楚，抓取预算优化的十二项实操按优先级排过序。

服务器出问题时常常悄无声息，抓取速率被调低的那几天日志里一条错误都没有就是这种情形。

把持续报500的地址留在sitemap里，等于主动引导对方反复来撞同一堵墙。这也是为什么sitemap的生成不该只依赖数据库里的商品状态，还该带一层实际响应校验。

400那六条也值得提一句。请求被判为不合法，通常是地址里带了服务器不认的字符或者参数组合。这类地址能出现在sitemap里，说明生成程序拼地址时没做转义，而拼出来的东西自己从来没试过。

406这个状态最容易被误解

hoka.com抽到的六条地址全部返回406，意思是服务器没法提供你能接受的内容格式。这是内容协商失败，通常跟请求头里的接受类型有关。六条全中说明这不是个别地址的问题，是整个站对这类请求的统一反应。

请求本身也可能被判不合法，老用户打不开的页面而工具全都返回200就是这么来的。

内容协商这一层坑不少，出厂只压HTML一种类型、其余字节全额计入预算是常见默认值。

下一节会讲到，406这一组在换了身份之后依然是406，属于真问题而不是身份歧视。

换个身份再问一次，答案会变吗？

这是本篇最重要的一个方法论环节。所有非200的结论，都必须先回答一个问题：是这个地址坏了，还是它不接待我？

身份决定待遇这件事我量过一次，robots说允许、仍有十个站把GPTBot挡在门外是同一层错位。

弄清对面是谁是所有判断的前提，120种爬虫标识的分类与真假验证可以直接照做。

还有一个容易忽略的因素是请求来源的地理位置。这台服务器在中国境内，很多面向欧美市场的站点对这个区域的请求本来就更严格。同一批地址换一台美国的机器去抓，403的数量很可能不一样。所以严格说，本文的结论是从这个位置、用这个身份看到的样子。

本文的抓取全部只发普通的GET请求、不带任何参数、也不重复访问同一地址，请求节奏也压得很低。这样做的目的是让每一条记录都反映这个地址本身的状态，而不是我们制造出来的负载。做跨站普查时这一点必须自律，否则拿到的数据既不准确，对被抓的站也不厚道。

为什么必须做这个对照

第一轮抓取用的是搜索引擎爬虫的身份标识，但请求来自一台普通的云服务器，地址段跟真正的搜索引擎完全不同。很多站的边缘防护会检查这一点：声称自己是爬虫、地址却对不上，直接拦。

请求方式不对会漏掉字段，用HEAD查说没配缓存头、换成GET那五个全在是踩过的坑。

要看清谁在真抓你的站，五千个站样本里的爬虫伪造与预算实测是更硬的参照。

边缘防护到底拦了谁并不好判断，防火墙拦不拦得住AI爬虫实测答案挺意外。

这种情况下拿到的403，反映的是防护规则，不是页面状态。上一批我在别的实验里吃过这个亏，182条被挡住的路径完全无法判定存在性，占了样本的一半。

把63条全部用普通浏览器身份重抓一次

第二轮换成常见的桌面浏览器标识，加上正常的接受类型和语言偏好，其它条件不变。结果是18条变成了200，45条维持原样。

名单上那些名字有没有真来过也能量，266个令牌里只有23.3%真的来过是另一组实测。

按身份做拦截要防误伤，拦AI爬虫怎么不把Googlebot一起拦掉有具体的匹配写法。

这里也得说清对照的局限：换身份只能区分出按标识判的那部分防护，按地址段判的仍然拦得死死的。那12条两轮都是403的，很可能就属于后者，我没法进一步区分它们到底是页面坏了还是这台机器被整体拉黑。

身份造成的失败占了28.6%

18除以63等于28.6%。将近三成的非200结论，如果不做这个对照，就会被写成这个站的sitemap里有坏地址——而事实是那些地址对普通用户完全正常。

中间层改写内容的情况不止一种，自动翻译把yes改成forks而数据看不出异常是同一种沉默污染。

补对照组这件事经常能救命，量出七成页面有差异、补上对照组后只剩两个点是同一类返工。

用别人的工具前先校准，第三方数据准不准的六步校准法能挡掉大部分噪声。

这个比例值得所有做类似普查的人记住。任何一次跨站抓取，只要目标站有边缘防护，结论就必须分成两层：这个地址的状态，和这台机器的待遇。

反过来看，那12个换身份也进不去的403更值得站主注意。它们意味着任何一个第三方工具都测不了这些页面，包括排名监控、性能监测、结构化数据校验。防护是必要的，但把所有自动化请求一刀切掉，代价是自己也失去了观测能力。

429那六条尤其说明问题

限速返回429，第二轮换个身份立刻正常。这说明限速规则是按身份标识而不是按请求频率判的——我们两轮的请求间隔完全一样，唯一的变量是那个标识。

有时候拦你的是自家主机，托管环境可能正悄悄拦AI爬虫而监控没报警是同一种失控。

限速规则的反噬可能很大，限速拒掉的第四个请求正好是robots.txt会让抓取停十几个小时。

这类规则的副作用很直接：真正的搜索引擎爬虫如果撞上同一套规则，也会被限速，而它不会换个身份再来一次。上一批量过一个更极端的例子，限速把robots.txt本身给拒了，导致整站抓取停了十几个小时。

做完这一步还有个副产品：那12个站的防护规则被间接量出来了。它们对声称是爬虫的请求一律拒绝，不管这个请求本身有多规矩。这套策略挡住的不只是我这台机器，还有所有第三方审计工具——包括站主自己买的那几款。

剩下45条才是真问题

刨掉身份因素，694条里真正打不开的是45条，占6.5%。这个数字比9.1%小了将近三分之一，但仍然不算低——每十五条提交的地址里就有一条是坏的。

工具选型别只看功能列表，五大类SEO工具的完整推荐与取舍说清了各自的能力边界。

完整的诊断框架能避免漏项，从抓取、内容到AI可见度的审计框架可以当检查表。

被防护挡住的后果不止拿不到数据，人机验证屏被当成正文索引是更严重的一种。

后面所有的分析都以这个修正后的口径为准。凡是提到交付层有问题，指的都是这45条。

页面自己说不要收录的有多少？

交付层能打开只是第一关。打开之后，页面上还可能明写着一行别收我。

加了标注之后还得等，页面要多久才从搜索结果里消失有六个场景的实测。

这两个手段该用哪个常被搞反，robots.txt和meta robots各管哪一段里分工写得很清楚。

这里的判定只认明确写着不要索引的那一类，取值里只有不要跟随链接、不要缓存快照之类的都不算。判据卡紧一点，数字会小一些，但每一条都站得住。上一批就吃过判据太松的亏，量出来的问题里一大半是假的。

28条，占能打开那批的4.4%

631条能正常打开的地址里，28条的页面上带着不要索引的声明。响应头里的同类声明是零条——没有任何一个站用响应头这条路来做索引控制。

分页方案选错会连累一大片，五种分页方案的对比与配置可以先看结论再动手。

该收和不该收得先分开，大量无用页面拖垮流量的诊断与处置有一张决策矩阵。

页面被什么挡在索引外可以一次查清，可索引性体检把几层原因分开列比逐个猜快得多。

这28条分布在若干个站上，其中相当一部分是同一个站的多条。翻开看，最常见的是几类页面：账户相关页、站内搜索结果页、以及一些明显是活动结束后留下的落地页。

还有一种更明确的做法是干脆把这批地址单独放一份sitemap，标注清楚它是回收清单，等确认从索引里消失之后整份删掉。这样意图是清楚的，任何一个接手的人都能看懂，而不是混在正式清单里让人猜。

把这28条按站看，分布也很有信息量：其中一大半集中在少数几个站，说明它们是整批处理的产物，比如某次活动结束后统一给一批页面加了标注。零星出现在各站的那几条，反而更可能是真的遗漏。

这算不算矛盾，得看意图

严格说，提交给搜索引擎又标注不要索引，是两个方向相反的信号。但实务中它有个正当解释：先让对方抓到这一页，读到不要索引这条指令，然后把它从索引里去掉。想让一个已收录的页面消失，这是标准做法。

生成器说格式正确的时候，它其实只查了三件事剩下的还得自己看。

两种手段能不能一起用是高频疑问，noindex和canonical同时用的九种场景逐个给了答案。

判断的关键在于时间。如果这批地址是最近才加上标注的，那它们留在sitemap里合理；如果标注已经挂了半年，sitemap还在天天提交，那就是生成程序压根没读页面。

还有个更快的判断：拿这批地址在搜索引擎里查一下还在不在索引里。如果早就不在了，那标注已经生效，sitemap里的记录纯属残留；如果还在，那说明这轮回收还没走完，留着是对的。这个查法几分钟就能出结果。

怎么区分这两种情况

看sitemap里那条记录的最后修改时间。如果它跟着页面一起更新过，说明生成程序至少读到了页面的变化；如果那个时间是很久以前，或者干脆是每天自动刷新的当天日期，那就没有参考价值。

时间格式这一层坑不少，各处各要什么格式有一份速查。

百万级商品的地址怎么组织，分片、进出场与lastmod诚实度是一整套工程实践。

那个时间字段的格式也有讲究，从sitemap的lastmod到结构化数据的日期都得转对。

上一批我量过一个相关的现象：一份sitemap里抽了585条地址，48条是坏的，而生成它的程序一次都没报错。程序不报错的原因很简单——它只是把数据库里状态为已发布的记录导出来了，从来没访问过这些地址。

判断某类页面该不该进提交清单，有个简单的问法：这一页有没有一个具体的搜索需求在对应它？商品页有，分类页有，帮助文档有；站内搜索结果、筛选组合、分页第二十页往后，通常没有。答不上来的那些先别提交，留着看自然表现。

站内搜索结果页出现在sitemap里，是另一个问题

28条里有几条指向站内搜索结果。这类地址本来就不该进sitemap——它们数量无限、内容重复、对用户没有独立价值。页面上标注不要索引是对的，错的是它们被提交了。

筛选组合产生的地址更难缠，分面导航的海量URL怎么治理单独拆过一遍。

站内搜索地址到底该不该禁，四种方案的对比与适用场景讲清了各自的副作用。

这种组合暴露的是生成规则太宽：把所有能生成URL的页面类型一股脑扔进去，再靠页面上的标注去兜底。兜底当然有用，但每一条都要花掉一次抓取。

顺带说，这两条路的优先级在规范里是有规定的：两处都写时按更严格的那条执行。也就是说页面上写允许收录、响应头写不要收录，结果是不收录。这跟前一篇量过的响应头矛盾是同一类规则，只是这次跨了两个位置。

响应头那条路一个人都没走

索引指令除了写在页面里，还可以写在响应头里。后者的好处是能给非HTML的资源用，比如PDF、图片、接口返回。这批样本里响应头这条路是零使用。

同一份响应里两个字段打架也有实测，142个站里108个至少有一处自相矛盾是上一篇的结论。

没有标签可写的地址怎么办，接口和feed拿什么说自己不想被收录量的就是这一层。

这跟我上一批的一个发现对得上：接口和数据源这类没有标签可写的地址，实际上没有任何一个站给它们配了索引控制。能力存在，但没人用。

canonical指向别处意味着什么？

第三层是规范网址声明。631条能打开的地址里，523条的canonical指向自己，73条压根没写，35条指向了别的地址。

它是提示不是命令这一点很关键，八种误用与Google自选规范页的逻辑解释了为什么常常不生效。

这个标签的基本用法先理清，九个决策场景加完整设置指南能覆盖大部分情形。

刨掉的那一部分其实也有可改进的地方：既然最终地址跟提交地址不同，那sitemap里就该直接写最终地址，省掉一次跳转。对单条地址来说这点开销可以忽略，对几十万条的站来说，省下的是实打实的抓取额度。

把跳转因素刨掉之后是16条

35这个数字要修正。其中有一部分是页面发生了跳转，最终地址跟提交地址不同，而canonical指向的正是最终地址——那属于正常行为。刨掉这一类，真正意义上的指向第三方地址是16条。

首页那一层也量过，132个首页有23%自己跟自己矛盾是同一类对照实验。

最终由谁说了算有明确逻辑，Google选择规范网址的九条决策逻辑可以照着排查。

16条听着不多，但性质很硬：你提交了A，A自己说正主是B。搜索引擎大概率会去收录B，而A在你的sitemap里白占一条。

还有个细节：这批地址里有几条的canonical写的是相对路径。规范允许这么写，浏览器和抓取器都会按当前地址解析，但只要页面被别的地址访问到，解析结果就跟着变。稳妥的写法一律用完整地址，这样无论从哪里被读到，指向都是确定的。

73条没有canonical的更值得看

没写canonical不算错，规范也不要求必须写。搜索引擎会自己挑一个它认为最合适的版本，通常就是被抓到的那个地址。

同一商品的几十个地址该合还是该拆，产品变体的URL与索引策略需要先想清楚。

重复内容的成因得先分类，八类成因地图加诊断清单比一刀切有效。

但对于电商站来说，不写canonical风险不小：同一个商品在不同分类路径下、带不同筛选参数时，会产生一堆内容相同的地址。没有canonical，选哪个全看对方判断，而对方的判断依据里包括内链数量、外链、地址长度这些你未必控制得住的因素。

那73条没写canonical的地址里，有相当一部分是内容型页面，地址结构简单、没有参数变体，不写确实没什么风险。真正需要担心的是商品页——同一件商品在不同路径下能生成好几个地址，不表态等于把选择权交出去了。

自指才是sitemap地址该有的状态

一个地址被放进sitemap，等于你在说这是我希望被收录的版本。那么它的canonical理所当然应该指向自己。523条做到了这一点，占83%。

分页地址的规范化尤其要小心，集合页分页的索引判断与canonical设置有具体做法。

这份文件的作用常被高估，提交网站地图到底能不能提升排名得先把预期放对。

剩下的17%要么没表态，要么指向别人。这两种情况都会让提交这个动作打折扣：前者是让对方替你决定，后者是自己否定了自己的提交。

还有一个数字可以并排看：那批首页里有23%自相矛盾，这批内页是17%要么没表态要么指向别人。两个数字的口径不同不能直接比，但方向一致——声明这件事的出错率，在任何层面上都不是个位数。

上一批量过首页的同类问题

那次的对象是132个站的首页，结论是23%的首页canonical自相矛盾。这次抽的是内页，比例低一些，原因大概是内页的canonical通常由模板统一生成，而首页经常有人手工改过。

两套模板各写一份也很常见，插件和主题各冒出一套canonical怎么归一是同类清理。

写在哪里也决定生不生效，工具说在head、浏览器说在body该信哪边是一次真实排查。

两批数据合起来能看出一个规律：越是被人手工碰过的页面，声明出错的概率越高。模板生成的东西虽然笨，至少是一致的。

提交之后跳到别的地址，算不算问题？

31条地址在抓取时发生了跳转，最终落在别的地址上，占能打开那批的4.9%。这一类的判断要分情况。

跳转链本身也要单独查，两个方向的301跳转怎么配有完整实战。

跟随跳转各家实现不同，工具报的死链和Googlebot抓的从来不是同一批就是这么来的。

还有一种介于三者之间的情况：跳转目标带上了追踪参数或者会话标识。这类地址每次访问都不一样，收录价值为零，而且会在报告里制造大量重复。它们通常来自某个营销工具的自动改写，站方甚至不知道自己的地址被加了尾巴。

三种跳转，性质完全不同

第一种是地址规范化，比如去掉末尾斜杠、补上语言前缀，跳转目标跟原地址基本是同一个页面。这种属于轻微不整洁，改一下sitemap生成规则就行。

临时性的跳转要有收尾计划，A/B测试怎么做才不影响SEO里有官方表态和清理动作。

被自动加上的参数也要处理，URL里那个srsltid参数的四种处置办法是现成对照。

跳转目标带参数是另一种麻烦，给内链加UTM参数为什么伤SEO是流量分析与抓取的取舍。

配置通过不代表没事，Googlebot每八次抓取就有一次撞在301上是同一类隐形代价。

第二种是内容合并，原地址的内容被并进了另一个页面，跳转目标是个不同的页面。这种应该把sitemap里的记录直接换成目标地址。

第三种是按访问者所在地区跳转，同一个地址在不同地方拿到不同的目标。这一种最麻烦。

这类跳转还有个更隐蔽的后果：它让所有的第三方审计工具都测不准。工具服务器在哪个国家，就看到哪个版本；同一份报告在不同工具那里结论不同，而站主根本不知道差别来自地理位置。

nomadgoods那六条全跳到了中国区

抽到的六条地址，全部从根路径跳到了带中国区前缀的路径。原因很清楚：抓取请求发自中国境内的服务器，站点按来源地区自动跳转。

地区声明与真实资源常常对不上，236条地区声明背后只有6个真页面是一个极端例子。

按IP自动跳语言版本的代价很大，半数页面会因此进不了索引是实测出来的结果。

这意味着提交给搜索引擎的那个地址，任何一个来自特定地区的访问者都拿不到。搜索引擎的抓取器如果从某个地区发起请求，看到的也是跳转后的地址，而不是你提交的那个。

按地区自动跳转的代价，上一批算过

那次的结论是按访问来源自动跳转语言版本，会让国际站的半数页面进不了索引。原理是搜索引擎的抓取通常来自固定的几个地区，一跳转，别的地区版本就永远没机会被抓到。

写了标注也未必被当成独立页面，Google只把它们当规范页的别名是另一层现实。

正确的多版本标注怎么写，return tags对称与x-default实操避坑有完整清单。

正确做法是给用户提示而不是强制跳转，同时用语言声明标注各版本的关系。这件事的技术难度不高，难的是说服业务方——强制跳转的转化率数据通常更好看。

flyingtiger那几条是另一种情况

它有几条地址带着井号后面的片段，比如门店定位页加上具体某家店的标识。抓取时片段部分不会发给服务器，所以最终落在了不带片段的同一个页面上。

前端路由与抓取的关系要弄清，八类抓取与索引影响实战解释了片段为什么不算地址。

地址本身的写法有讲究，影响抓取与排名的九个URL细节是一份实操清单。

这类地址进sitemap是没有意义的——对服务器来说它们全是同一个地址。想让每家门店都被单独收录，得给每家店一个真正的独立地址，而不是靠前端片段区分。

还有第三个问题值得问：这次跳转是永久还是临时？永久跳转意味着原地址不该再出现在任何提交里；临时跳转说明原地址还会回来，留在sitemap里可以接受，但要给它一个复查时间。样本里两种都有，而sitemap里的记录看不出区别。

判断跳转要不要处理，看两个问题

第一，跳转目标是不是也在sitemap里？如果在，那原地址就是多余的，删掉即可。第二，跳转是不是对所有访问者一致？不一致的话，问题的根不在sitemap，在跳转规则本身。

跳转规则通常写在同一个文件里，重写、缓存、规范化与HSTS六层治理可以一起看。

换架构之后这套东西得重搭，sitemap、重定向这些不会自动跟过来是常见上线失分点。

被自己的robots.txt挡住的有几条？

这一节的结论是个负面结果，但我认为它比正面结果更有价值。

同一批样本上量过分组，给单个爬虫开组会丢掉通配组全部规则中招比例高得离谱。

这份文件写废了后果不小，整站从谷歌搜索结果里消失的那类事故多半从一行规则开始。

694条里只有2条

拿每个站自己的robots.txt规则去判自己sitemap里的地址，判定为禁止抓取的只有2条。比例是0.3%，而如果扩大到26万条全量地址、每站抽300条来跑，命中率是0.05%。

筛选类地址该不该禁要分情况，三类判别法与处理策略给了处置办法。

哪些页面真该挡有判断依据，电商该屏蔽的七类页面与Shopify实操逐类给了理由。

这个数字远低于我的预期。自己提交的地址被自己挡住是各种审计清单里的经典高危项，实测下来在这批成熟站点上几乎不存在。

顺便说，测试目录被提交这件事本身也值得记一笔。那批地址的路径里明明白白写着沙箱两个字，说明它们是内部预览用的，却和正式页面一起被导出了。生成规则按状态筛而不按路径筛，就会漏进这类东西。

那两条也不全算失误

全量抽样里被挡住的14条，其中philips.com有8条落在一个明显是测试用的目录下——那个目录本来就该被挡，错的是它们被提交了。theordinary.com那两条指向站内搜索结果页，被挡住反而是对的。

拿这个文件解决它管不了的事很常见，用robots.txt拦UTM参数的危害就是一个典型。

测试环境的东西泄漏出去代价不小，测试站被索引后的八步清除与四层防御是完整方案。

真正称得上失误的没几条。这跟我做这个实验之前的假设完全相反。

还有第三个原因：现在主流的建站平台会自动生成sitemap，而它们生成时用的就是平台自己的路由规则，跟平台默认的robots.txt天生对齐。真正容易出问题的是那些自己写生成脚本、又单独维护robots.txt的站，而这类站在样本里是少数。

为什么这一项在实际中很少发生

想了想，原因大概有两个。一是sitemap和robots.txt通常由不同的系统生成，前者是内容管理系统导出的、后者是运维配置的，两者覆盖的地址空间本来就不太重叠——运维挡的是后台、接口、参数地址，内容系统导出的是正式页面。

虚拟文件和物理文件谁优先常被搞混，这两层的优先级与AI爬虫拦放讲得比较清楚。

平台替你做的事情不少，托管、自建还是纯代码怎么选把各自代价摊开了。

二是这类问题一旦发生，后果非常显眼：整批页面掉出索引，报告里会直接标红。所以它属于那种发生了就会被立刻发现并修掉的问题，长期存活率很低。

顺带说，这一项之所以长期留在清单里，多半是因为它太好理解了——自己挡自己，任谁都觉得荒唐。而真正高发的那几类，比如提交后跳转、页面标注不要收录，解释起来要多说三句话，就没那么容易被写进检查表。清单的构成往往取决于哪一条最好讲，而不是哪一条最常发生。

负面结果为什么值得写出来

因为审计清单不会自己更新。一项检查被写进清单之后，很少有人回头验证它现在还是不是主要矛盾。结果是每次审计都花时间在一个0.3%命中率的项目上，而真正有19.2%命中率的三层不一致却没人查。

清单之外的问题更值得警惕，被忽略的那几类技术SEO失灵原因说的正是这种局面。

检查项该按什么顺序排，五百个站实测排出来的技术SEO优先级可以当排期底稿。

把负面结果发出来，至少能让下一个做审计的人重新排一下顺序。

三层信号加起来，一致率是多少？

把前面几层合在一起算总账。判定标准是：能正常打开、没有跳转、页面没标不要索引、canonical没指向别处、没被robots挡住，五条全过才算一致。

抓取报告怎么读也有讲究，五类问题URL的占比与排查顺序能帮你分清是谁的问题。

官方报告里的状态词各有含义，八种未编入索引状态的决策路径对照着看才不会误判。

561条一致，133条至少有一处对不上

694条里561条五条全过，占80.8%；133条至少有一处不过，占19.2%。也就是每五条提交的地址里，有一条的几个声明说的不是同一件事。

口径不清的指标最容易误导，从指标体系到异常诊断的完整做法可以拿来搭框架。

指标定义清楚才谈得上对比，三个平台三百个站的收录速度实测是一份口径统一的样本。

不过有一类组合值得单独盯：跳转加上canonical指向别处。这两项一起出现时，通常说明这个地址已经彻底被弃用了，只是没人把它从提交清单里拿掉。那6条属于最该优先处理的一批。

绝大多数是单项失分

133条里同时踩中两项的很少，最常见的组合是canonical指向别处加上发生跳转，只有6条。这说明这些问题基本是各自独立的，不存在某一类问题会连带引发另一类。

相互牵连的问题要另一种拆法，五个维度的信号区隔实战处理的是彼此干扰的情形。

好处是修起来可以分头进行，坏处是没有一个万能的修法能一次解决大半。

把身份因素刨掉，一致率会更高一点

前面说过403那18条里有6条是身份造成的，429那6条也是。把这12条从失分里刨掉，一致率会从80.8%上升到约82.6%。

验证一条结论有没有效有个笨办法，给那条建议配一个注定无效的对照组比讲道理管用。

换个口径结论可能完全不同，三类站点的聚合自然流量实测就是一次口径切换。

我在正文里保留了未修正的数字，因为对搜索引擎来说，它的抓取器同样可能撞上这些防护规则。修正后的数字更接近技术真相，未修正的更接近实际后果。两个都有用，但必须标清楚是哪一个。

另一个角度是修复难度。文件内部的冲突改一行就行，责任人也明确；三层不一致要动的可能是内容管理系统的导出逻辑、前端模板、以及防护规则，分属三个团队。比例低不代表容易修，往往正相反。

跟前两篇的数字放在一起看

一份文件内部两条规则打架，36.2%的路径中招；一份响应里两个字段打架，76.1%的站中招；跨文件的三层身份不一致，19.2%的地址中招。

这类欠账攒起来相当可观，技术债怎么排查和分批偿还给了可执行的顺序。

同一条线上还有一篇，有多少条指令压根没有接收方在读量的是更早的一层。

越往上走，比例反而越低。原因不难理解：层数越多、跨越的团队越多，出问题的地方也越显眼，越容易被业务侧发现。真正长期没人管的，恰恰是那些藏在单个文件内部、谁看了都觉得没问题的地方。

出问题的站是零星几条，还是整站都这样？

把133条失分按站分组，能看出一个很关键的区别：有些站是偶尔漏一条，有些站是抽到的六条全中。

跨团队协作有具体抓手，后端工程师配合SEO的七个动作点是从真实账本里总结的。

要推动全站规则改动没那么容易，甲方拒绝建议八成源于身份冲突给了重写汇报的办法。

需要说明的是六条抽样的统计力有限。一个站六条全过，不能证明它整份sitemap都干净，只能说问题密度不高；反过来六条中一条，也可能只是运气不好。跨站比较用命中站数是稳的，单站结论必须扩大抽样才能下。

116个站里40个至少有一条

抽样全部干净的站76个，占65.5%；至少一条有问题的40个，占34.5%。三分之一的站在六条随机抽样里就能撞出问题，说明这不是罕见现象。

同一批域名上量过验证类字段，142个站里只有52个回得出304口径卡得很死。

同一批站还量过首页可读性，132个独立站首页有28个是空壳是另一组抽样。

这13个站里，问题类型也各不相同：有的是六条全跳转，有的是六条全返回同一个状态码，还有的是六条都带着同样的声明。类型一致本身就是最强的信号——随机抽样能抽出同一种表现，只能说明它是全站规则的产物。

这里也要留个尾巴：六条全中的站里，有几个的问题类型是403和406，而那正是身份因素最重的两类。把身份修正考虑进去之后，真正六条全是内容侧问题的站会少几个。系统性这个判断本身也需要先过一遍身份这道闸。

13个站是六条全中

更值得看的是那13个站：nomadgoods、peakdesign、hoka、article、gymshark、loccitane、otto、sezane、shein、ugreen、wayfair、weber、yeti，抽到的六条无一幸免。

统一规则会统一出错，默认配置变更却没人通知的漂移比例并不低。

全站规则出问题往往在结构层，架构搭错了爬虫根本找不到商品页是更上游的问题。

六条随机抽样全中，几乎不可能是巧合。它意味着问题出在某个统一规则上——要么是全站按地区跳转，要么是整站对这类请求返回同一个状态码，要么是模板统一带了不该带的声明。

还有个折中的处理：先把系统性的那批从sitemap里整体摘出来，单独放一份文件，等规则改完再合回去。这样至少不会一边提交一边浪费抓取额度，代价是要多维护一份清单，而且必须记得回收。

系统性和零星的修法完全不同

零星几条通常是内容侧的遗留：某个页面下架了没同步、某次活动结束后留了个尾巴。修法是把sitemap的生成逻辑接上页面状态，一次搞定。

规则叠加之后排查更难，应用栈精简与冲突排查给了可执行顺序。

这类失分往往第一年就埋下了，建站第一年最容易失分的十二项配置是同批经验的汇总。

系统性的那批要动的是全站规则：跳转策略、防护规则、模板里的声明。这类改动影响面大、需要走完整发布流程，而且往往牵扯业务决策——比如按地区跳转到底要不要保留。

分组之后还能顺手做一件事：把同一个站的失分类型也统计出来。类型集中说明是单一规则，类型分散说明是维护松散。前者找一个人改一处就行，后者要立流程，两种情况给出的建议完全不同。

先看是不是系统性，能省掉大量无用功

所以做这类审计的第一步不该是逐条修，而是先按站分组看分布。同一个站命中三条以上，基本可以判定是规则问题，去查规则比去修那三条地址有效得多。

能交给机器的就别靠人记，哪些SEO工作能交给工具、哪些不能划了一条边界。

分组统计这件事日志里也要做，读懂Googlebot抓取与预算浪费给了分析路径。

这个判断只需要一次分组统计，几秒钟的事，但它决定了后面的工作量是三小时还是三天。

还可以换个角度看这批干净的站：它们并不都是技术最强的那几个。里面既有大集团也有小品牌，共同点是站点结构简单、页面类型少。复杂度本身就是这类问题的主要来源，能砍掉的复杂度都是收益。

反过来，76个干净的站说明什么

值得强调的是三分之二的站六条全过。这说明把这几层做一致并不难，也不需要什么特殊技术，只要生成sitemap的时候读一眼页面状态就行。

开发期就该埋好这些点，自建站开发阶段的十大优化要点能省掉上线后的返工。

上线检查表该包含什么，前十二周从技术地基到内容蓝图是一份排好序的清单。

做到的和没做到的差别，往往只是有没有人把这件事列进上线检查表。

sitemap这一层本身，有多少是拿不到的？

前面聊的都是sitemap里的地址。往回退一步：这份文件本身有多少能被正常读到？

不同系统的生成方式差别不小，免插件做sitemap的改造与分页是另一个平台的做法。

自己生成这份文件要注意什么，动态优先级、分页与缓存策略有完整实战。

这676条声明里还有个小现象：不少站声明了好几份sitemap，其中一部分是历史遗留的旧文件，内容早已不更新。robots.txt里的这几行同样属于写完就没人再看的东西，跟前一篇量过的那些无接收端字段是同一种沉积。

143个站声明了，676条声明

157份能读到的robots.txt里，143个站在里面写了sitemap行，一共676条，去重后每站平均四五条。14个站一条都没写——这不算错，sitemap可以只在搜索引擎后台提交，但少了一条被发现的路径。

除了提交文件还有主动推送，三种推送方式的实战对比可以并行用。

这份文件里还有别的例外规则，通配组的星号对广告爬虫不生效是最容易漏的一条。

另一个可以对照的数字是：这20个站在上一批的响应头实验里，同样是失败率最高的一群。跨实验的重合度这么高，基本能确认它们的防护策略是统一的、长期的，不是某次配置调整的临时结果。

20个站第一层就拿不到

按声明去抓，186条里157条成功，24条返回403、2条404、3条完全连不上。折算到站，有20个站的sitemap一份都没抓到。

还有一种思路是干脆收费，要不要向AI爬虫按次抓取收钱已经有平台在做了。

防护该做在哪一层，robots、UA识别、WAF三层的选型框架比只改一处靠得住。

这20个站里有相当一部分是知名大牌，包括好几个西班牙快时尚品牌。它们的共同特点是防护严格——同一批站在别的实验里也是最难抓的那批。

这里必须重复一遍身份的问题

这些403同样存在身份因素。用搜索引擎身份从一台普通服务器发请求，被拦是很正常的结果。真正的搜索引擎抓取器地址在对方的白名单里，大概率能正常拿到。

原始记录留下来才好复查，日志怎么收集成可检索的结构是越早做越好的事。

把日志按对象拆开看会很清楚，八类爬虫标识的二十二周访问账本是一份可对照的样本。

所以这20个站不能被判定为sitemap有问题，只能说这批数据在它们身上是缺失的。本文所有比例的分母都相应缩小到实际拿到数据的那批站，而不是157。

子文件的组织方式也值得一提。做得好的站按内容类型分片，商品一份、分类一份、内容一份，每份的更新频率不同；做得糙的按数量硬切，每五万条一个文件，改一个商品可能牵动好几份文件的最后修改时间。后者会让对方无法判断该重抓哪一份。

索引文件里的8573个子文件

116份索引文件里一共声明了8573个子sitemap，最多的一个站声明了2171个。这个数量级说明大站的地址管理已经完全程序化，人不可能逐个看。

定时表达式记不住就用生成器，把巡检、推送和清缓存都自动化是很划算的投入。

生成与校验都可以交给定时任务，备份、sitemap、缓存、证书一条龙脚本可以直接改。

程序化本身没问题，问题是程序只做了导出这一件事。要让它同时校验状态，成本其实不高——每条地址发一个轻量请求就够，而且可以增量做。

还有一个跨主机的小发现

抽样里有一个站的sitemap指向的全部是另一个主域名下的地址，301条。这种写法本身是允许的，前提是那个域名的所有权能被验证。但从维护角度看，它意味着两个站的地址管理耦合在了一起，改一边要记得改另一边。

跨域的归属声明要写清楚，一稿多发怎么不被副本反超给了做法。

多域名怎么组织是更上层的决策，建一个大站还是多个品牌小站会影响后续所有工作量。

新加的那层声明，有人写了吗？

八月中旬llms.txt出了第二版规范，新增两种链接关系：一种指向页面的Markdown版本，一种指向覆盖这个页面的说明文件。两种都能写在HTML里，也能写在响应头里。

要进AI的候选池得先过技术这关，五步技术优化的实战顺序把门槛列清楚了。

想知道AI爬虫真正在乎什么，从代码逆向出它的抓取偏好比看官方说明更实在。

顺带一提，检索这两种声明并不难：在页面头部区域搜链接关系的取值就行，几行代码的事。真正麻烦的是判断它指向的那个地址是不是有效——这一点等有站真的写了之后才有得测。

631个页面里，零个

我在抓回来的631个页面里逐个搜了这两种声明。指向Markdown版本的零个，指向说明文件的零个。一个都没有。

这层声明的读者已经换了，AI爬虫抓取量超过Googlebot好几倍改变了很多判断。

一项标记该不该做可以看采纳数据，官方第一次公开的全网使用统计比凭感觉堆类型强。

这个结果并不意外——规范八月十日才发布，抓取是八月下旬做的，中间只隔了十天出头。零采用率反映的是时间，不是态度。

要让这个基线有用，得把口径写死：抓哪一批站、每站抽几条、认哪几种写法算数、什么时候抓的。少写一条，半年后的对比就没法做。这也是我在正文里反复交代口径的原因之一。

但它给了一个很好的基线

正因为现在是零，它成了一个干净的起点。半年后再跑同一套脚本，就能算出这半年里有多少站接上了这层声明，以及接上的是哪一类站。

监控工具各家口径差别很大，二十款监控工具的评测与选型得先看它们怎么算。

长期观测要先把闭环搭起来，四步把引用率监控做成闭环可以套到别的指标上。

做这种长期观测最难的是找到起点。绝大多数技术采纳曲线，等到有人想起要量的时候已经过了早期阶段，只能从中段开始估。

这类新声明层的价值判断有个通用问法：它的读者是谁、那个读者有没有承诺读它、以及读了之后会不会改变什么。前一篇量robots.txt字段有效性时用的就是这套问法，答案是绝大多数字段过不了第二问。新层现在的处境跟当年那些字段刚出现时很像。

Google那边的表态很直接

官方说法是搜索本身不使用这些文件，维护它既不会帮你也不会害你。这句话把这层声明的性质定得很清楚：它是给别的读者准备的，不是给搜索引擎的。

不同引擎的偏好并不一样，四大AI搜索引擎的分引擎策略是更靠前的一步。

判断某项标记有没有人读是同一个问题，结构化数据对AI搜索到底有没有用里有官方说法和实测。

值不值得做，取决于你的内容有多少被AI助手引用、以及那些引用带不带来实际收益。这件事每个站的答案不一样，没法一概而论。

不过普及不等于写对。上一批我量过这层声明的另一面：某个站声明了236条地区版本，背后真实存在的页面只有6个。写了不等于对应的资源存在，这跟本篇讲的三层不一致是同一类问题，只是发生在别的字段上。

语言版本声明倒是普及得很好

顺带量了一下多语言声明：631个页面里315个带了，占接近一半。这层声明已经是国际站的标配了，跟前面那层零采用形成鲜明对比。

生成器给的代码要复核，粘上去就是一份单向标注是常见问题。

多语言标注可以自动生成，用脚本从爬虫结果生成多语言sitemap省掉手工维护。

差别在哪？语言声明直接影响哪个版本会展示给哪个国家的用户，收益立刻可见；新那层的收益既不确定也不可测。技术采纳的速度，最终还是由收益的可见度决定的。

确定唯一真相来源这件事说起来简单，落地时的难点是谁来当那个源。内容管理系统最有资格，因为页面状态本来就在它手里；但实践中robots.txt归运维、跳转规则归前端、防护规则归安全，没有一个系统能看到全貌。所以更现实的做法是定期做一致性比对，而不是指望某一处天然正确。

第五层加进来之后，一致性检查更难了

现在一个页面的身份可能被五个地方声明：sitemap、robots.txt、页面上的索引指令、canonical、以及新的说明文件。它们分属五套系统，更新节奏各不相同。

多份声明怎么合成一个实体，@graph与知识图谱怎么搭是另一套合并规则。

信号打架时怎么定夺，六类消歧信号的管控实战给了处理顺序。

不一致不是偶发故障，是这套架构的常态。真正该做的不是追求五处永远一致，而是明确哪一处是唯一真相来源，其它几处都从它生成。

自查该按什么顺序做？

把这套检查落到自己站上，六步就够，顺序不能乱。

判断一个站的技术欠账有多深，三类站点的高ROI修复清单可以当快速评估表。

常规全站审计有覆盖边界，桌面爬虫能查出的十二类问题清单可以对照看缺哪块。

这一步还该顺手核对一件事：robots.txt里声明的地址，跟你在搜索引擎后台提交的那份是不是同一个。两处不一致的情况比想象中常见，尤其是站点做过改版或者换过生成工具之后。

第一步：确认sitemap本身拿得到

用命令行拉一次robots.txt里声明的每一条sitemap地址，看状态码。这一步经常就能发现问题：声明的地址写错了、文件挂在一个已经废弃的域名下、或者被防护挡住。

官方后台里能挖的东西比想象中多，用过滤器精准拆分品牌流量是个被低估的功能。

快速看一眼收录情况有个老办法，site命令怎么用、什么时候会误判得先知道它的边界。

拿不到就没有后面的事。这也是为什么它必须排第一。

抽样时最好按页面类型分层：商品页、分类页、内容页、功能页各抽一部分，而不是完全随机。完全随机的话，地址数量最多的那类会占据绝大部分样本，而问题往往集中在数量少的那几类上。

第二步：抽样，别全量

大站的sitemap动辄几十万条，全量校验成本太高而且没必要。每个子文件随机抽几条，覆盖各种页面类型即可。抽样时把随机种子写死，这样每次跑的是同一批地址，结果可比。

抽样跑实测是这类结论的常规做法，46个电商站里4个的商品链接根本没被读到也是这么量出来的。

抽样与对照的思路在别处也通用，别让本来就会买的人冒领功劳那套测法值得借鉴。

本文用的口径是每站至多6条，是为了跨站对比；自查的话每站抽一两百条更合适。

请求本身也有讲究：跟随跳转但限制次数，超过五六跳就当异常记下来；设一个合理的超时，太长会让整批跑不完；响应体只留前面一部分，头部区域的信息足够判断这几层，全文下载纯属浪费。这三条能让一次几百条的抽样在几分钟内跑完。

第三步：一次请求拿齐三层信息

对每条抽样地址发一次请求，跟随跳转，同时记下：最终状态码、跳转次数、最终地址、响应头里的索引声明、页面里的索引声明、canonical。一次请求全部拿到，别分几轮。

页面骨架层面也有一次性体检，揪出标题层级、图片alt与语义标签短板适合改版后跑。

看清一个地址的真实响应有顺手工具，用接口测试工具查状态码与响应头比在线评分靠谱。

记得保存原始响应，方便事后复查。存下来的东西比结论有价值——结论会因为判据变化而改，原始数据不会。

对照的身份也别只换一个。条件允许的话跑三组：搜索引擎标识、普通浏览器标识、以及完全不带标识。三组结果放在一起，能把防护规则的判断依据大致还原出来——是看标识、看频率，还是看请求头的完整程度。

第四步：做身份对照

把所有非200的地址挑出来，换一个普通浏览器身份重抓一次。变成200的那些从失分里刨掉，单独归为一类：这个地址正常，只是不接待爬虫身份。

同一家的抓取器也不都守同一套规矩，有一整类抓取器压根不看robots.txt这次改名把它推到台前。

新出现的抓取器要单独认一遍，Google-Agent是什么、怎么识别和应对是最近才需要处理的问题。

这一步在本文里刨掉了28.6%的失败。跳过它，结论会系统性地夸大问题。

这一步还能顺手校准优先级：命中数最多的那几个站往往就是流量最大的那几个，因为它们页面多、结构复杂。按命中数排序基本等同于按影响面排序，不用另外算权重。

第五步：按站分组，先判系统性还是零星

把失分按站分组。同一个站命中三条以上就去查规则，别急着修地址。本文样本里13个站是六条全中，那13个站真正需要处理的是一条规则，不是七十八条地址。

排期这件事在大促期间尤其要紧，大促与日常SEO的八维度差异给了完整时间轴。

分组之后该派给谁也要想清楚，内容、技术、外链三类分工与团队配比是同一个协作问题。

接回去的方式不必复杂。最省事的做法是维护一份排除清单，生成时过一遍；稍微讲究一点的是在导出前对每条地址发一次轻量请求，非200的直接不写。后者对几十万条的大站成本偏高，可以只对最近改动过的那部分做。

第六步：把结论接回生成程序

最后一步也是最容易被跳过的：把校验逻辑接进sitemap的生成流程，让下次导出时自动排除掉那些状态不对的地址。

自动化流程会走形，那批页面早已进了索引说的就是没人复查的后果。

这类小脚本自己写最快，用Vibe Coding做SEO小工具的八步避坑讲的就是自养工具。

不做这一步，这次修完的东西下个月又会回来，因为生成程序还是老样子。审计的价值不在于修了多少条，在于有没有把判据固化进流程。

这批数据里，哪几处口径差点搞错？

照例交代方法论上的坑，给想复现的人省时间。

样本量大不代表结论可用，三千条数据揭开的认知差说明该信什么不该信什么。

同一个名字各家算法不同到处都是，关键词难度为什么各家工具差那么大是最典型的一例。

第一处：没做身份对照，结论会夸大三成

这是本批最大的一处。第一轮抓完直接算，非200的有63条；做完对照才知道其中18条是身份问题。如果不做，会得出交付层失败率9.1%的结论，而实际是6.5%。

两个数字对不上先怀疑口径，工具排名为何与实际不一致给了六步排查法。

没有记录就没有结论，AI爬虫到底有没有抓你的站那套挖法可以直接套用。

更糟的是它会误伤具体的站：那六个403变200的站会被写进有问题的名单，而它们的页面对普通用户完全正常。

这个坑的成因很典型：判据是在看到数据之前定的，而数据里存在一种当初没想到的正常情况。所以任何一版统计跑完，都得随机翻二三十条明细人工看一遍——不是为了验证结论，是为了发现自己漏掉了哪种情况。

第二处：canonical指向别处要先刨掉跳转

原始统计是35条指向别处。翻明细才发现其中一批是因为页面跳转了，canonical指向的是跳转后的最终地址——那是完全正确的行为。刨掉之后是16条。

标签类地址的处理也要单独定，标签页URL优化与301重定向实战是一个具体例子。

不同页面类型该给什么声明有差别，五类页面的配置差异可以直接照搬。

判据是拿canonical跟提交地址和最终地址两个都比一遍，只有两个都不等才算问题。第一版脚本只比了提交地址，虚高了一倍多。

第三处：抽样上限决定了谁的比例被算进去

每站至多抽6条，是为了不让地址有几十万条的巨型站压过只有几百条的小站。如果按地址总数比例抽，最后的数字基本就是那三五个巨型站的数字。

把指标拆层看更清楚，社媒指标拆成四层漏斗是一种可搬用的拆法。

指标怎么选决定了你看到什么，砍掉虚荣指标只盯真信号是同一种取舍。

这个选择有代价：小站的六条抽样统计意义有限，一条失分就是16.7%。所以站级结论我只用了命中数，没用比例。

第四处：sitemap的两层结构不能只抓一层

116个站的sitemap是索引文件，里面套着子文件。第一版脚本只抓了第一层，结果拿到的全是索引文件本身，一条真实地址都没有。

解析结构化文本别靠肉眼，把JSON-LD调试这件事讲透省下不少比对。

解析器的边界要自己试出来，一个尾逗号就能让整页标记失效是同一类静默失败。

补了第二层之后才有了26万条地址。做这类抓取时，先看拿回来的是索引还是清单，这个判断必须写进脚本，不能靠肉眼。

第五处：一个不报错的PHP坑

输出统计时，双引号字符串里变量名后面紧跟中文标点，标点会被当成变量名的一部分。这批犯了两次，两次都是关键数字凭空消失。修法是所有插值一律用花括号包起来。

有些字节级问题症状很明显，一个看不见的字节头就能让页面白屏是另一种极端。

脚本层面的小疏忽代价可能很大，上传目录还能跑PHP的五种加固写法是另一类低级但致命的问题。

还有一层原因是这类实验的结论有保质期。所有数字都是2026年8月下旬那几天的快照，站点每天都在改。半年后重跑同一套脚本，比例大概率会变，而变化本身才是更有价值的数据——前提是这次的口径写得足够清楚，让那时候的人跑得出可比的结果。

为什么把这些写出来

因为9.1%和6.5%这两个数字放进文章里都很有说服力，读者无从判断哪个对。把判据、剔除规则、修正过程摊开，是唯一能让人放心引用的做法。数字本身不值钱，能被复现的数字才值钱。

把过程写出来比只给结论有用，从AI搜索到结构化数据的实施策略也是一步步摊开的。

数据分析入门先建立习惯，三类工具与排名追踪的日常做法比学工具更重要。

常见问题解答

sitemap里的地址返回404，影响大吗？

影响的是抓取效率而不是排名。搜索引擎会浪费一次抓取额度去撞一个不存在的地址，量大的时候会明显拖慢新页面的发现速度。本文样本里404占1.3%，比例不高；更值得注意的是500，那会引发重试，浪费的额度是404的好几倍。

页面写了不要索引，还留在sitemap里对吗？

短期是对的，长期不对。想让一个已收录页面消失，必须让对方抓到并读到那行指令，所以保留一段时间是标准做法。但如果这个标注已经挂了几个月、sitemap还在天天提交，就说明生成程序没有读页面状态。判断办法是看那条记录的最后修改时间有没有跟着变。

canonical指向别的地址，这条还该不该提交？

不该。提交等于说这是我希望被收录的版本，而canonical说正主是另一个，两个声明互相拆台。正确做法是把sitemap里的记录换成canonical指向的那个地址。本文样本里刨掉跳转因素后有16条属于这种情况。

抓自己的站需要做身份对照吗？

需要，尤其是站前面挂了边缘防护的时候。防护规则经常按身份标识判，用爬虫标识从公司网络发请求，很可能被自家防护拦下。本文的对照实验里，63条失败中有18条换个身份就正常了，占28.6%。

被自己robots.txt挡住的地址真的很少见吗？

实测确实少见。694条抽样里只有2条，扩大到全量每站抽300条也只有0.05%。原因是sitemap和robots.txt通常由不同系统生成，覆盖的地址空间本来就不太重叠，而且这类问题一旦发生后果非常显眼，很快会被修掉。审计清单里把它列为高危项，跟实际风险已经不太匹配。

llms.txt第二版那两种声明现在有人用吗？

本文抓的631个页面里一个都没有。规范八月十日发布，抓取在八月下旬做，中间只有十天出头，零采用反映的是时间不是态度。Google那边明确说搜索本身不使用这些文件，维护它既不会帮你也不会害你，所以是否要做取决于你的内容有多少被AI助手引用。

这套检查多久做一次合适？

抽样版每月一次，全量版每季度一次。更重要的是把校验逻辑接进sitemap的生成流程，让不合格的地址在导出时就被排除掉。不做这一步的话，这次修完的问题下个月还会原样回来，因为生成程序没变。

权威参考资料