这个博客的搜索流量已经平了两三年，我也不指望它再动了。所以我转而去看访客都是从哪来的，AI 助手在不在其中。在，勉强算在。截至 2026 年 9 月 16 日的十二个月里，访问统计记到这里有 5,372 个会话。其中 27 个来自 AI 助手：12 个来自 chatgpt.com，9 个来自 gemini.google.com，6 个来自 Perplexity，来自 claude.ai 的是零。半个百分点。不过从 ChatGPT 来的访客是好的那种。他们平均停留五分钟，直接访问是 27 秒，Google 来的是三分钟，因为他们已经读过答案，想看的是细节。

所以我花了些时间琢磨，一个小博客怎么才能被选中当这些回答的来源。这篇写的是我在这个站上做了什么，以及日志对此怎么说。有数字的地方我给数字，靠猜的地方我说明是猜。初稿里有三句话，一查之下发现是错的，我把改正留在了文里。

两种 bot，只有一种会引用你

#

第一件要弄清楚的事：“AI bot” 其实是两种不同的活，用的是不同的 user agent，拦住一种对另一种毫无影响。

训练爬虫成批地抓页面，用来训练下一个模型。OpenAI 的叫 GPTBot，Anthropic 的叫 ClaudeBot，Google 的由 Google-Extended 这个 token 控制，Apple 的是 Applebot-Extended，Common Crawl 的 CCBot 则喂着大多数开放数据集。它们拿走的东西最后变成权重，不会有任何链接指回你。拦掉这些是有道理的，我不觉得这想法傻。

检索 bot 是另一种。有人问 ChatGPT、Claude 或 Perplexity 一个问题时，助手会跑一次搜索，当场抓几个页面，读一遍，然后写出带引用的回答。这些抓取来自 OAI-SearchBot 和 ChatGPT-User、Claude-SearchBot 和 Claude-User、PerplexityBot 和 Perplexity-User。Google 的 AI Overviews 用的就是普通的 Googlebot，所以根本没有单独的开关。会把访客送回来的是这些 bot。如果目标是被引用，你要优化的就是它们，而且值得知道的是，拦不拦 GPTBot，ChatGPT 的搜索结果都不会因此变好或变坏。

这个站的 robots.txt 是 Hugo 的默认，也就是全部放行：

User-agent: *
Allow: /
Sitemap: https://jared.lynskey.co.nz/sitemap.xml

我想过把它拆开，放检索 bot 进来，把训练爬虫挡在外面，最后觉得对一个存在意义就是被人读的博客来说不值得。真要那么做的话，写出来就是下面这样。把它放出来是因为和Cloudflare 给 Googlebot 发了一个空页面里的教训一样：列表里写的得是 bot 的名字，不是厂商。没有哪一行能写成"OpenAI"。

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: CCBot
Disallow: /

User-agent: *
Allow: /

站在 Cloudflare 后面的话，有一件事要查一下。从 2025 年年中起，那里新建的 zone 默认拦 AI 爬虫，bot 设置里还有一个一键开关，能对已有的 zone 做同样的事。它两种都拦。这个博客上周刚搬到 Cloudflare Pages，所以这件事在我的清单上。如果你因为"AI bot"听起来像该挡的东西就把它打开了，那你也把引用一起关掉了。Cloudflare 后来开始在它托管的 robots.txt 里写一行 Content-Signal，带 search、ai-input 和 ai-train 三个独立的标志。没人有义务遵守它，但这套词是对的：和上面一样的划分，只是表达成一种偏好，而不是一堵墙。

真正来敲门的是谁

#

搬到 Cloudflare 有个副作用：我头一次能按 user agent 看到每一个请求。下面是 2026 年 9 月 13 日到 16 日这四天进来的东西，假冒的已经剔掉了，那部分后面再说。

有两点很显眼。训练爬虫把整个站读了两遍，用的时间只够检索 bot 读几十个页面。而检索 bot 抓的不是随机页面：ChatGPT-User 和 Claude-User 都奔着更新服务器那篇去了，那是站上最具体的一篇，日语的冷启动那篇被抓的也正是日语版。

再说假冒的。自称 GPTBot 的 20 个请求里，有 18 个来自 OpenAI 公布的地址段之外，要的是 /.env、/.git/HEAD 和 /firebase-adminsdk.json。36 个 “ChatGPT-User” 请求里有 15 个是同一路货色。“PerplexityBot” 的流量大多想要 /id_ed25519。user agent 就是一个谁都能发的字符串，漏洞扫描器已经发现 AI bot 的名字会被放行。OpenAI、Anthropic 和 Perplexity 都公布了自己的 IP 段。如果你打算对某个 bot 特殊对待，不管是放还是拦，查地址，别查名字。上面的 20、59 和 8，是从正确地址来的那些请求。

页面不用浏览器也得能读

#

检索 bot 在回答的那一刻抓取，有超时，而且大多数不跑 JavaScript。一个在 bundle 加载完之前只是一个空 div 的页面，就是它们读不到的页面。Hugo 输出的是完整的 HTML，所以这个博客白得了这一点，这也是我从没动过心思把它搬到什么更聪明的东西上的主要原因。我做的市场应用是反面例子，一个 React Native 的 Web 应用，为了让爬虫拿到一份真正的文档，先做了一条动态渲染分支，然后又被一个缓存 bug 悄悄抵消了。上面那篇 Cloudflare 的文章讲的就是这事。

速度也是同样的道理，而这里日志纠正了我。我原本以为，静态站放在 Cloudflare 后面，就是从最近的边缘节点出去的。不是。这个博客放在 Cloudflare Pages 上，HTML 是不经缓存发出去的，从首尔发请求，响应从洛杉矶回来，大约要半秒。对一个超时有好几秒的 bot 来说这仍然够用，但它不是我原本会张口就说的几十毫秒，而且我知道这一点只是因为我测了。一个正从六个页面里拼答案的助手，会把那个要花三秒的丢掉，而且不会告诉你它丢了。

写得让一段话能单独被摘出来

#

这些系统用页面的方式和读者不一样。它们把页面切成块，给每块按问题打分，引用得分高的那些。一篇用八百字铺垫到结论的文章，每一块的分都低。一篇每一节第一句就亮出观点、后面再论证的文章，会在匹配的那一节得分。

这件事对我在这里写东西的影响，比任何技术上的事都大。front matter 里的 description 现在是对文章内容的概括，不是勾你点进来的钩子，因为 description 往往是助手唯一展示的部分。小节标题说的是这一节的结论。数字连同单位写进句子，而不是放在图表里。日期写全，因为"上周"对一年后读这页的模型来说什么都不是。还有，一篇文章只讲一件事。

另一半是要有值得引用的东西，而这里的数据是掺杂的。日志里，回答时的 bot 抓的都是具体的那些页面：冷启动、更新服务器、iOS 调试。Naver 的爬虫叫 Yeti，Daum 的叫 Daumoa，我用的托管平台上机器重启是一个 30 秒的 504 窗口，Cloudflare 在线做的 Brotli 在我的 bundle 上测出来比 gzip 还差。这些事实没几个地方写过，所以需要其中某一条的问题就会落到这里。可是从助手那边点进来的人，大多落在 2023 年和 2024 年那些讲管理的文章上，每篇一两个会话。具体的文章被机器读，泛泛的文章拿到点击。这我给不出一个利落的解释，宁可照实报出来，也不想编一个。杠杆要是有的话，仍然是把你这周弄明白的、当初搜也搜不到的那件具体的事写下来，因为机器明摆着读的就是这些。

说清楚是谁写的，而且每次都说一样的

#

一个助手在决定要不要引用一个页面时，做的事和一个认真的读者差不多：这是谁写的，什么时候写的，和我找到的其他东西对得上吗？这个站上这部分的机制大多是主题的功劳。每篇文章都带 Article 结构化数据，有作者、发布日期和修改日期，作者是一个 Person，链接到同一组公开主页。这在模板里只是几行，却是"一个页面"和"一个有来历的、署了名的人写的页面"之间的区别。

不是主题功劳的那部分是一致性。关于页、llms.txt、各个公开主页和每篇文章顶上的那一行，描述的都是同一个人，同一段工作经历。有东西变了，就全都要改，不然忘掉的那个就成了错的那个。听起来挺较真，但一个页面说我是工程经理、另一个说我是自由职业，正是那种会让模型含糊其辞、或者干脆换个人引用的矛盾。

修改日期也得老实。内容变了它才变，否则我不碰它。为了显得新鲜而去改它，是那种管用一次、然后整个域名都被打折扣的事。

llms.txt 是什么，以及没人读它这件事

#

llms.txt 是 2024 年 9 月提出的一个方案：在站点根目录放一个 Markdown 文件，给语言模型一段站点概述和一份精选的链接列表。我今年 2 月加了一份。开头一段讲我是谁，然后按管理、基础设施、移动和社区分节，每篇文章一行：标题、URL，加一句话说这篇文章的结论。读起来像一份写给赶时间的人的目录。

要说明的是，没人读它。在我手上这四天的日志里，请求过 /llms.txt 的只有我自己。Common Crawl 在 2026 年 8 月那一轮抓取里收了这个站的 76 个页面，从来没收过这个文件。没有哪家主要的助手说过它会读它。所以这里有什么被引用都不是因为它，我也不会以此为由推荐给任何人。留着它有两个原因。它只花了一个小时，而且给每篇文章写一句"这篇到底得出了什么结论"，比文件本身更值，因为它让我看到了哪些文章什么结论都没有。它也是站上唯一一个告诉机器这个站是干什么的页面，我宁愿有它而用不上。之后它已经跑偏了，因为我是手写的，会忘，这也是应该改成用 Hugo 的输出格式从 front matter 生成它的理由。这事在清单上。

Feed、sitemap 和五种语言

#

无聊的管道照样算数。sitemap 是爬虫在新文章上线当天找到它的方式。RSS 是它得知一篇文章改过的方式。两个都是 Hugo 的默认，我从没需要操心。ClaudeBot 两天里读了 36 次 sitemap，它就是这样那么快找到 1,380 个页面的。

语言是我没料到会有影响的部分。这里的所有内容都有英语、日语、韩语、简体中文和越南语版本，带 alternate 链接，让爬虫知道它们是同一篇文章。爬虫把它们当成五个站：ClaudeBot 的抓取几乎是在五种语言之间平分的，Common Crawl 8 月收走的 73 个文章页面里，只有四个是英语的。助手用被提问的语言回答，也偏向那种语言的来源，所以一个关于冷启动的韩语问题，可以直接从韩语页面回答，而不是现场把英语页面翻一遍，而 ChatGPT 实际抓走的正是日语那一页。条件是译文读起来得像用那种语言写的。今年早些时候我请母语者帮着检查做的那一遍修订，本来是为了人类读者，但也正是它让越南语页面成了一个来源，而不是一个稀奇玩意儿。

我能测量什么

#

比我以为的多，只要别再靠猜。Cloudflare 的免费套餐给的是按 user agent 和路径分的请求日志，一次查询一天，上面那张 bot 表就是从这来的；referrer 要付费套餐才有。访问统计工具里有 referrer，通过它的报表 API 把数据拉出来，而不是眯着眼看仪表盘，开头那些数字就是这么来的。两边合起来能看出个大致轮廓。四天里，检索 bot 从 OpenAI 和 Anthropic 的地址抓了大约九十个页面。上一个月，有两个人从 ChatGPT 过来。读得多，偶尔引，很少点。据我所知，还是没有办法看到那些用了某个页面却没被点击的回答。最有用的检查依然是手动的那种：拿你文章回答的那个问题去问助手，看它引的是谁的页面。

如果这一切里只能留一样，我留写作那条规则。robots.txt、结构化数据和 llms.txt 是一个下午的活，做完就完了。让每一节先说观点，写具体的事而不是泛泛的事，是一种习惯，而正是这个习惯决定了一个页面到底值不值得引用。第二样是：先测了再说。被机器信任，结果看起来和被人信任很像：说你是谁，说你知道什么，而且每次都用同一种说法。

我做的这个集市应用是用 React Native Web 写的单页应用。在 JavaScript 跑起来之前，每一个商品页都只是一个 script 标签加一个空 div。这对人没问题，对搜索却是致命的：Google 有时能执行那段 JS，Bing 不会，而对一个商品几乎全是韩语的站点最要紧的 Naver 爬虫，肯定不会。

这篇讲的是我怎么让这些页面被看见，以及之后那条以我没预料到的方式把成果抵消掉的缓存规则。

动态渲染，不是伪装

#

办法很老，而且 Google 认可：识别爬虫，给它返回一份服务端渲染的 HTML，内容和 SPA 本该画出来的一样。不是不同的内容，是同样的内容，只是更早。

于是像 /listings/view?id=... 这样的商品 URL 分叉了。浏览器拿到 SPA 外壳。爬虫拿到一份真正的文档：一个标题，商品的关键信息，每张照片一张带 alt 的图，一段正文摘录，以及通往几个相关商品的链接，好让这页不至于成为孤儿。

最后那点比我预想的重要得多。在这些内链存在之前，大约一千个商品页没有任何东西指向它们，Search Console 里能看到抓取一路沉到每天 7 到 11 次请求。找不到你页面的爬虫，不会在乎那些页面有多好。

陷阱：厂商的名字不是它家爬虫的名字

#

爬虫识别是 user-agent 匹配，问题就出在这里。

韩国平台用的爬虫名字和公司名一点都不像。Naver 的爬虫叫 Yeti，Daum 的叫 Daumoa，Kakao 的链接抓取器叫 kakaotalk-scrap。三个都不是厂商名。

与此同时，同样这几家还发布带内嵌浏览器的 App，那些浏览器发送的是真实浏览器 UA，后面缀上 App 的名字。KakaoTalk 的内置浏览器说自己是 KAKAOTALK/10.5.1，Kakao 的抓取器说自己是 kakaotalk-scrap/1.0。

用 kakao 去匹配，两个都会中。我当初正是这么干的，结果每一个打开链接的 KakaoTalk、Naver App、Daum App 用户，拿到的都是爬虫页：没有 JavaScript，没有导航，没有登录。一份挑不出毛病的文档，对人却毫无用处。

修复靠的是判断顺序，这一点值得明确写成规则：

import re

# 内嵌浏览器会在普通浏览器 UA 后面附上应用名。
INAPP_BROWSER_RE = re.compile(r"kakaotalk/|naver\(inapp|daumapps", re.I)

# 认机器人名，不认厂商名：Naver 用 Yeti，Daum 用 Daumoa，
# Kakao 的链接预览抓取器用 kakaotalk-scrap。
CRAWLER_RE = re.compile(r"googlebot|bingbot|yeti/|daumoa|kakaotalk-scrap", re.I)


def is_crawler(user_agent: str) -> bool:
    # 内嵌浏览器永远不是爬虫，所以这个判断放在最前面。
    if not user_agent or INAPP_BROWSER_RE.search(user_agent):
        return False
    return bool(CRAWLER_RE.search(user_agent))

内嵌浏览器先判断，而且它赢。并且每一个爬虫匹配词都必须指向一个机器人，而不是一个厂商。

然后我在前面放了 Cloudflare

#

源站是悉尼的一台共享 CPU 机器，能撑住每秒二三十个请求。Googlebot 要走大约 995 个 URL，而它们全都打到了悉尼，因为每一个 URL 的 cf-cache-status 都是 DYNAMIC：除非有规则明说，Cloudflare 不缓存 HTML。 整个站点大约 16% 的内容被缓存，而真正要紧的那部分一个也不在里面。

那就给爬虫页加一条缓存规则。很简单。除了一点：一个商品 URL 并不只有一个响应体，它有三个。

• 要 HTML 的爬虫拿到服务端渲染页。
• 人拿到 SPA 外壳。
• 发送 Accept: text/markdown 的 agent 拿到 Markdown，从数据库拼出来的，因为把一个空的 HTML 外壳转换一遍只会得到一份空文档。

源站会发 Vary: Accept，而对 user-agent 做 Vary 本来也没什么指望。然后就是我不知道的这件事：

Cloudflare 在 HTML 上忽略 Vary。 三个响应体共用一个缓存键。

哪个先到，哪个就占住这个 URL，对该边缘节点之后的所有访客生效，持续源站 s-maxage 允许的一小时，再加上一天的 stale-while-revalidate。

我在生产环境两个方向都亲眼见到了：

• 一个 Naver App 用户用爬虫页预热了某个商品 URL，随后普通的 iPhone Safari 就在一次 HIT 上拿到了那个页面。一个人盯着一份没有 JavaScript 的文档。
• 一个人用 SPA 外壳预热了某个 URL，Googlebot 拿到了空外壳。整套 SEO 工作要防的正是这个失败，如今它更快了，还是从边缘发出来的。

靠收窄来修复的规则

#

你没法让 Cloudflare 在 HTML 上尊重 Vary。你能做的，是确保三个响应体里只有一个有资格进缓存：

(starts_with(http.request.uri.path, "/listings/")
 and not any(http.request.headers["accept"][*] contains "text/markdown")
 and (lower(http.user_agent) contains "googlebot" or ...)
 and not (lower(http.user_agent) contains "kakaotalk/" or ...))

只匹配爬虫 UA，并排除 Markdown 请求。现在人的请求不匹配任何规则，于是读到 DYNAMIC 并像以前一样回源。只有爬虫请求读写缓存，而能进到缓存里的响应体只有爬虫那一个。

边缘 TTL 用 respect_origin，于是有效期仍归渲染这个页面的代码所有，而不是被钉死在控制台里。

一个容易漏掉的运维细节：收窄规则并不会驱逐已经在缓存里的东西。 得手动清一次缓存，否则那些刚刚已不再生成的污染条目还会继续被发出去。

两份清单，以及它们的错误为何不对称

#

这条规则需要一份爬虫 UA 清单，而 Django 里已经有一份。同一份知识在两个系统里存两份通常是坏味道，但这里有意思的是它们漂移时会发生什么，因为并不对称：

• Cloudflare 里的机器人清单必须始终是 Django 那份的子集。 一个 Cloudflare 认为是机器人而 Django 不认的匹配词，会把 SPA 外壳缓存到爬虫专用键下，然后发给真正的爬虫。
• 内嵌浏览器的排除清单必须是 Django 那份的超集。 排除得太多，代价只是少几次缓存命中。

任何一边朝安全方向错，你只是少缓存一点。第一条朝另一个方向错，你就又在给 Googlebot 发空页面了。顺带一提，这种不对称也正是这些清单用 contains 而不是正则的原因：matches 需要 Business 套餐，而对一份允许在已知安全方向上粗糙的清单，contains 够用了。

一条让构建失败、而不是让页面失败的不变式

#

爬虫页里嵌着有效期七天的预签名图片 URL。页面本身在边缘缓存一小时，外加一天的 stale-while-revalidate。

这两个数字是相关的，一旦缓存寿命超过图片寿命，边缘就会开始发出每张照片都 403 的页面。不会有任何告警，因为 HTML 本身没问题。

所以定义这些数值的代码，在关系被破坏时会拒绝导入：

CRAWLER_IMAGE_TTL = 7 * 24 * 3600  # 预签名图片 URL
EDGE_S_MAXAGE = 3600
EDGE_STALE_WHILE_REVALIDATE = 24 * 3600

# 边缘缓存可能比图片 URL 活得更久时，在 import 时就失败。
if EDGE_S_MAXAGE + EDGE_STALE_WHILE_REVALIDATE >= CRAWLER_IMAGE_TTL:
    raise RuntimeError("edge cache lifetime must stay below the image URL lifetime")

两个分处不同文件的常量之间的约束，在代码评审里看不见，在进程启动时却一目了然。把它放在进程启动的地方。

Cloudflare 做的两件、我不得不撤销的事

#

Vary: Origin 把打包产物挡在了缓存之外。 django-cors-headers 会在它经手的每个响应上打 Vary: Origin，而 Cloudflare 拒绝缓存任何在 Accept-Encoding 之外还有 vary 的响应。这就悄悄把关键路径上最大的那个 1.6 MB JavaScript 包整个排除在边缘之外。修法是把一个中间件放在列表最前面，让它在出站方向最后执行，重写静态资源路径上的 Vary。

边缘压缩比源站压缩更差。 让 Cloudflare 现场做 Brotli 得到 2,041,742 字节，而源站自己的 gzip 是 1,658,115 字节。为了不用动脑，代价是大了 23%。即时压缩优化的是 CPU，不是压缩率；源站预压缩的资源会赢。

不等抓取就告诉搜索引擎

#

两个协议，加在一起覆盖面也令人失望。

IndexNow 接受一次 ping，覆盖 Bing、Yandex 和 Seznam。Google 和 Naver 不参与。每次保存商品时，我在后台带着很短的超时发一次 ping，已售出和已关闭的条目直接跳过。网络失败只记一条警告，绝不让触发它的那次保存失败——这是一个尽力而为的旁路通道唯一可以接受的行为。

Google 的 Indexing API 只接受两种结构化数据类型，其中之一正是我有的 JobPosting。在招的职位发 URL_UPDATED，关闭的发 URL_DELETED。那条删除通知之所以诚实，是因为关闭的条目同时输出了 noindex，代码里也这么写着——好让日后拿掉 noindex 的人知道自己还顺手破坏了什么。

这里有两处让我耗了不少时间。配额是每天 200 个 URL，而批量导入一次商品就会触发几百次，所以导入进来的条目会被跳过，否则一次导入就把当天预算全花光。另外端点是带冒号的 urlNotifications:publish。用斜杠的话，Google 返回一个普通的 HTML 404，看起来和 API 没启用一模一样。

结构化数据教给我的

#

三条规则，每一条都是被 Search Console 数落出来的：

1. 解析不了的就别输出。 薪资是自由文本。我以前把原始字符串当作 baseSalary.value 输出，那是无效的，还让每一条职位都被标记缺少单位。现在解析不了的薪资干脆不出现。
2. 别为了满足结构化数据的要求而编造字段。 招聘广告很少带街道地址。人会很想给 PostalAddress 填个看着像样的东西。招聘广告上编造的地址比不完整的地址更糟，所以只放城市和国家。
3. 有效期不是可选项。 Google 会丢掉没有 validThrough 的 JobPosting，所以要推导一个，并加上下限，免得一条旧条目声称自己昨天就过期了。

还有关于站点地图的第四条：别给所有条目都声称 changefreq: daily。 要求 Googlebot 每天重新抓取一千个条目，会被读成一台过载的主机，而它的回应是降低整站的抓取速率。从这东西实际上多久变一次来推导。

站点地图还有一道质量下限：标题加正文合计四十个字符。Search Console 曾把大约一千条报成"已抓取 – 尚未编入索引"，其中某个二手页面的全部独有内容，是一个单词的标题加一个电话号码。四十这个数字是故意定低的，因为 484 条里有 471 条是韩语，而韩语单位字符承载的信息更多；按英语调的阈值会砍掉这个市场的一半。内容单薄的条目仍然通过索引页保持可抓取，一旦有人编辑就会自动重新进入站点地图。

我会从中带走的

#

• 在一个 URL 上返回不同的响应体，首先是一个缓存键问题。 弄清楚你的 CDN 用什么做键，并且在你于那个确切的内容类型上验证之前，就假定它忽略 Vary。
• 当两个系统必须就一份清单达成一致时，先弄清哪个方向的错误是安全的，然后把它写在两份副本旁边。“它们可以漂移，而且只允许朝这个方向漂”，胜过假装它们不会漂。
• 按机器人名字匹配机器人，永远别按厂商名字。 尤其在英语世界之外，那个厂商同时还做着你用户手里的那个浏览器。
• 把相距遥远的常量之间的不变式，放在会大声失败的地方。 import 时机是免费的，而且没人能跳过。