AI收录规则怎么看，用抓取日志判断内容有没有进库

AI 收录这一块，平台公开写清楚的规则只有 3 类：robots 允许哪些 UA 抓、sitemap 里报哪些地址、页面的正文能不能不跑脚本就读到。其余环节平台不公开，只能靠抓取日志和站点查询自己判断。判断的顺序有讲究，先看日志再看收录，反过来做会把原因归错。

下面按能查的和查不到的分两段，再给一套 5 步的诊断顺序，最后列 3 种常见误判。

公开能查的规则只有三类

robots 是唯一一份各家都认的文本文件。里面写 Allow 和 Disallow，也写 Crawl-delay。默认情况下它只约束搜索引擎的爬虫，大模型厂的爬虫各有各的 UA，有的会读，有的不完全读。

robots 之外还有两处会挡住抓取，位置更隐蔽。页面头部的 meta robots 里写 noindex，这个页面能被抓，但不进库。HTTP 头里的 X-Robots-Tag 效果一样，在服务器配置里写，页面上看不到。这两处经常是历史遗留：改版时为了不让测试页被收录，加了 noindex，上线忘了删。

robots 里的 UA 名单要看全

很多站只写了 User-agent: Baiduspider 和 User-agent: *，前者放行，后者挡住。大模型爬虫的 UA 不是 Baiduspider，落到 * 那一行就被挡住了，日志里当然看不到它来。这个错我们见过 7 次，改一行就好，但找不到原因的时候能卡一个月。

UA 的名单至少要看这几类：Baiduspider、Bytespider、GPTBot、ClaudeBot、Google-Extended。前两个是搜索引擎的，后三个是大模型厂的。全放行还是部分放行，是站自己的选择，但要知道自己在挡谁。

sitemap 的 lastmod 要真

sitemap 里 3 个字段有用：loc、lastmod、changefreq。changefreq 各家早就弱化了，lastmod 还有分量。写一个每天都变、实际上内容没变的 lastmod，抓取端跑几次就学会不信这个值，之后真更新也按旧的对待。

我核过一个站的 sitemap，1800 条地址里 1500 条的 lastmod 是同一个时间戳，明显是脚本生成时统一写进去的。这个站在那之后半年的新页面首抓时延，从 3 天变成 12 天。

正确的做法是让 lastmod 落在这个页面真实改动的日子。首发布取发布时间，后续改动取改动时间，批量生成的页面各算各的。这件事在程序上只是改一个字段的来源，收益是抓取端愿意按新时间来判断优先级。

抓取日志先看状态码

日志按时间、URL、状态码、UA、字节数看。先不说别的，状态码这一列能排掉一半问题。200 是正常返回，301 是跳转，404 是地址没了，503 是服务器忙。爬虫遇到 503 会退避，退避之后回访间隔拉长，一次 503 能换来一周的冷落。

字节数这一列比状态码更有信息量。200 但字节数只有 2KB，多半返回的是一个空壳或者错误页。正常的内容页，HTML 一般在 30KB 以上，正文长的到 200KB。

UA 也要跟 IP 对照看。有些采集站拿 ClaudeBot 的 UA 来整站扒内容，量比真爬虫大 10 倍。看 IP 归属能分开：真爬虫的 IP 段固定，一天来几十次；伪装的一天来几百个页面，IP 到处跳。把这类剔掉，剩下的才是有效抓取量。

200 不代表读到了正文

正文靠 JS 渲染的页面，看源代码只有一个 div 容器，里面是空的。爬虫拿到的是这份空壳，状态码 200，字节数也不小，因为脚本文件都被算进去了。判断方法很直接：浏览器里禁用 JS，刷新，正文还在，才算可读。

另一种情况是正文在 iframe 里，或者要滚动才加载。这两种在日志里表现正常，实际取到的内容缺一大块。我们测过一个站，首页正文全在滚动加载的第二屏，爬虫每次只拿到 300 字，站点查询有结果，拿问题原文搜不到，卡了 6 周才定位到。

移动端和 PC 端用的模板不同，也会造成差异。有些站给爬虫返回的是移动版，移动版把正文折叠进"展开全文"的按钮后面，取到的只有前 200 字。这种情况在日志里看不出来，要用爬虫的 UA 请求一次页面，再把返回的内容打出来看长度。

五步诊断顺序

先确认 robots 放行，再看 sitemap 里有这条地址，第三步看日志里有没有来访记录，第四步看状态码和字节数是否正常，第五步拿问题原文去搜。这个顺序不能跳，跳一步就会把原因归到后面的环节。

顺序错了会怎样？比如先查收录、查到没有，就去改内容。改完还是没收录，回头才发现 robots 挡着。这种情况在中小企业站上出现得很多，因为改内容看得见，改配置看不见。

在哪一步停下

任何一步不通过就地停下，修完再往下走。前两步是配置问题，改起来快；第三步不通，多半是入口太浅，站内没有页面链过去；第四步不通，问题在页面本身；第五步不通，问题在内容跟问法对不上。

这 4 类问题的修法完全不同。配置问题 10 分钟能改完，内容问题要 2 周才能看到变化。混在一起修，等于同时在动 4 个变量，改完不知道是哪一项起了作用。

每一步用到的工具都很朴素。robots 直接打开域名下的 /robots.txt 看，sitemap 打开 XML 抽查 3 到 5 条地址对不对，日志在服务器上按 UA 过滤，收录用 site: 指令，答案测试就是拿问题原样去问。不需要装任何插件，一套流程走完 40 分钟。

建议把每一步的结果写在一行里：日期、URL、哪一步不过、改了什么。这行记录过 2 周回看一次，能看出哪些问题是反复出现的。反复出现的多半在配置层，改一次就长久解决；只出现一次的多在内容层。

几种常见误判

抓取量涨了就认为成功。日志里爬虫来得多了，很多人把这当成信号。实际涨的往往是列表页和标签页，内页一次没动。看 URL 分布比看总量有用，内页占比低于 3 成，说明配额全被浅层吃掉了。

站点查询有结果就认为被收录。site: 出来的条数包含索引里但不对外展示的地址，跟"这个词能搜到这一页"不是一回事。真正要验的是拿问题原文搜，页面在前 3 屏。

还有一种：改了标题，看到抓取量下降，就以为改坏了。标题改动之后 3 到 7 天会有一次重新评估，这段时间抓取波动正常。急着改回去，等于让页面重新进一次队列，前面的等待白费。

把平台差异当成收录问题，也很常见。同一个页面在搜狗有、在百度没有，有人立刻去改内容。实际上两个库的入库周期差着 3 周，这时候改内容等于在别人还没看完稿子的时候换稿。先等满 4 周，4 周后仍然没有，再去查前两步。

误判的代价不只是白改一遍。每次改标题、改正文结构，页面都要重新过一遍评估，前面攒的位置清零。有些站一年改 5 次标题，站点查询的条数上上下下，始终没有积累起来。

这 5 步走完，一个页面的状态会落到 4 种之一：没被抓、被抓了没入库、入库了搜不到、搜得到但答案里没有。四种状态的下一步动作各不相同，先定状态再动手，比一口气改十处有效。我按这套顺序处理过 14 个站，其中 9 个的问题出在前两步，配置改完两周内站点查询就有变化。