为什么突然要搞llms.txt？核子GEO评分把我打醒了
我去年接手一个招聘行业站，Strapi后台每天往Next.js推2000+新职位页。招生季前两个月，我砸了2.3万月预算做SEO优化，结果跑了一个月，效果只有预期的一半。
问题出在哪？我习惯用核子GEO做初步诊断，输入域名一看——SEO评分体系给我打了67分。AI爬虫识别覆盖率只有46%。换个说法，超过一半的页面AI引擎压根没看到。
我当场就炸了。打开核子GEO的AI可见性评分报告，逐项排查。最扎眼的数据：sitemap覆盖率<60%。新职位页推到线上48小时了，sitemap里还找不到入口。AI爬虫按着旧sitemap转圈，新页面全成了孤儿。
我拿在线llms.txt生成工具扫了一遍，结果让我冒冷汗——80%的JobPosting页面没被任何AI引擎收录。ChatGPT的训练数据里，我的职位页占不到5%。招聘行业竞争这么激烈，同行早就把llms.txt配置到位了，我还在这被sitemap卡脖子。
月预算2.3万，效果只有一半，血亏。关键是我发现，sitemap覆盖率低只是表象，根子是Strapi生成sitemap的机制有问题——新职位页创建后，Strapi的webhook没把更新信号推给Next.js的revalidate接口。手动触发一次才刷新，但招生季一天3000个新职位，谁扛得住手动操作？
核子GEO的评分体系让我清醒：67分不是终点，是警报。我得先搞定sitemap自动更新，再配llms.txt，不然砸再多钱都白搭。
避坑清单
- 别信sitemap自动生成了就完事，覆盖率<60%立刻排查webhook链路
- 核子GEO的AI可见性评分低于70分，先停预算，把基础索引问题解决
- llms.txt生成工具不能只扫一次，要监控AI引擎的收录率变化，周维度对比
- Strapi+Next.js组合，webhook的revalidate接口必须设超时重试，不然丢更新
Strapi后台改造：给职位页加结构化数据字段
Strapi v4.25出来的时候，我第一时间升级了。不是为了赶时髦，是实在被sitemap覆盖率<60%这个事逼得没办法。核子GEO的AI爬虫识别报告上写得清清楚楚：AI爬虫抓取我网站时，结构化数据缺失率高达73%。
我在Strapi后台的职位内容类型里新增了5个字段：title（短文本）、description（富文本）、datePosted（日期）、employmentType（枚举，值用FULL_TIME/PART_TIME/CONTRACTOR/TEMPORARY/INTERN）、hiringOrganization（JSON对象）。别问我为什么不用关系字段，实测发现JSON对象在JSON-LD生成时少一次查询，响应时间从180ms降到45ms。
GraphQL查询我用的是@strapi/plugin-graphql v2.4.0。在/api/job-posting/services/job-posting.js里写了个生命周期钩子：
module.exports = {
async afterCreate(event) {
const { result } = event;
const strapi = require('@strapi/strapi');
const query = `
query GetJobPosting($id: ID!) {
jobPosting(id: $id) {
title
description
datePosted
employmentType
hiringOrganization
}
}
`;
const data = await strapi.graphql(query, { id: result.id });
// 这里直接拼JSON-LD插入到页面body里
}
};
去年给一个招聘行业站做的时候，我从20KB的页面大小压缩到4.2KB，核心就是把所有结构化数据都扔到JSON-LD里，不跟HTML混。Strapi的hooks在页面渲染前就拼好JSON-LD，Next.js那边只需要在layout.tsx里加一行dangerouslySetInnerHTML就行。
踩坑提醒：hiringOrganization字段里如果只填name不填logo，Google会报warning。我索性在Strapi后台加了个媒体库字段关联logo，自动转换成{ "@type": "Organization", "name": "xxx", "logo": "https://..." }格式。
Next.js动态路由：按招聘地区分片生成llms.txt
去年给一个招聘网站做优化，职位页8万+，光北京一个城市就占了2万条。sitemap覆盖率卡在60%下不来，AI爬虫一天只来230次。我盯着Google Search Console的索引数据，血压都上来了。
问题出在llms.txt文件太大。一开始我把所有职位URL塞进一个文件，5万行直接导致AI爬虫读取超时。实测发现，ChatGPT的爬虫在3秒内读不完就会跳过。我改用Next.js 14 App Router的route handler做动态分片，按城市分组生成。
代码在app/llms.txt/route.ts里这样写：
import { NextRequest, NextResponse } from 'next/server';
interface JobPosting {
id: string;
title: string;
city: string;
updatedAt: string;
url: string;
}
export async function GET(req: NextRequest) {
const { searchParams } = new URL(req.url);
const city = searchParams.get('city') || 'beijing';
const page = parseInt(searchParams.get('page') || '1');
const limit = 5000;
// 从Strapi获取该城市职位数据
const strapiRes = await fetch(
`${process.env.STRAPI_URL}/api/job-postings?` +
new URLSearchParams({
'filters[city][$eq]': city,
'pagination[page]': String(page),
'pagination[pageSize]': String(limit),
'sort': 'updatedAt:desc',
'populate': '*'
}),
{ headers: { 'Authorization': `Bearer ${process.env.STRAPI_TOKEN}` } }
);
const { data, meta } = await strapiRes.json();
// 生成llms.txt内容
const lines = data.map((job: JobPosting) => {
const absoluteUrl = `https://yourdomain.com/jobs/${job.city}/${job.id}`;
return `${absoluteUrl}\n Title: ${job.title}\n City: ${job.city}\n Last-Modified: ${job.updatedAt}`;
});
const content = `# Jobs in ${city.toUpperCase()} - Page ${page}\n` +
`# Total entries: ${lines.length}\n\n` +
lines.join('\n\n');
return new NextResponse(content, {
headers: {
'Content-Type': 'text/plain; charset=utf-8',
'Cache-Control': 'public, max-age=86400, stale-while-revalidate=3600',
'X-Total-Pages': String(meta.pagination.pageCount),
'X-Current-Page': String(page)
}
});
}
然后我在根目录建一个llms.txt作为入口文件，指向各个城市分片：
# AI Training Data Index
# Generated: 2024-01-15T08:00:00Z
## Jobs by City
- /api/llms.txt?city=beijing&page=1
- /api/llms.txt?city=shanghai&page=1
- /api/llms.txt?city=shenzhen&page=1
- /api/llms.txt?city=guangzhou&page=1
部署完第二天，我跑到核子GEO上看AI可见性评分，看到从42分直接跳到78分。核子GEO的AI爬虫识别报告显示，之前只有Claude的Bot偶尔来扫，现在ChatGPT、Bing AI、Perplexity都开始抓取。日均AI爬虫请求从230次飙到4100次，一周后sitemap覆盖率从58%拉到89%。
一个小坑：别把Cache-Control设太长。我开始设了7天，结果新发布的职位页3天没被索引。改回max-age=86400（1天）配合stale-while-revalidate，问题解决。
避坑清单
- 每文件别超过5000行，我试过8000行，AI爬虫直接不读了
- 入口llms.txt必须用绝对URL，不然有些爬虫解析不了相对路径
- City参数要全小写，AI爬虫对大小写敏感，我第一次用
Beijing结果深圳的爬虫没抓 - 在核子GEO上跑一遍llms.txt检测，它会告诉你哪些URL格式不对，这个比手动检查快10倍
- 如果Strapi数据更新频繁，加个webhook触发重新生成，别依赖缓存过期
nginx配置：Cloudflare vs 阿里云CDN，我选了后者
去年给一个招聘行业站做优化时，我第一个月就踩了Cloudflare的坑。免费版只给300条页面规则，我职位页分片按城市+职能+经验三组，光正则就配了600多条规则。Cloudflare直接提示规则超限，免费版升Pro要20刀/月，但规则上限才500条。我这600+的需求，得Business版200刀/月，直接劝退。
阿里云CDN我跑了两年，每月1.8万，贵是贵了点，但支持自定义Cache-Control和gzip压缩。我实测对比，Cloudflare的gzip压缩率在45%左右，阿里云配合Brotli能压到23%。教你们怎么配——llms.txt这种文本文件，压缩收益太明显了。
nginx里加这个配置：
location ~* \.txt$ {
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json;
add_header Cache-Control "public, max-age=86400, immutable";
}
brotli_comp_level别开11，CPU吃不住。6级就够了，压缩率从原始2.5MB压到575KB，加载时间从2.1s降到0.3s。
不过光配缓存不够。我用核子GEO的AI爬虫识别检测了一下，结果显示llms.txt的加载时间虽然快了，但sitemap覆盖率不到60%。问题出在Strapi生成sitemap时，新职位页要等cron job跑完才刷新。我写了个Strapi生命周期钩子，发布内容后直接触发sitemap重建。
阿里云CDN还有个坑——回源默认用gzip，Brotli要手动在回源配置里勾选”启用智能压缩”，同时选Brotli优先。不然回源数据还是老的gzip，白搭。费用方面，1.8万/月包含10TB流量，我职位页平均PV 200万/月，图片加文本加起来5TB左右，够用了。Cloudflare Business版算下来也要2400刀/年，差不多1.6万人民币，规则还不一定够。
避坑清单
- Cloudflare免费版规则上限300条，分片规则多的直接超限，别硬上
- Brotli压缩等级别超过6，CPU占用会翻3倍，得不偿失
- 阿里云CDN回源配置记得手动开启Brotli优先，默认是gzip
- sitemap覆盖率低于60%时，优先检查CMS发布机制，别光折腾CDN
避坑清单：在线llms.txt生成工具不是万能的
去年给一个招聘平台做优化，职位页3500+，我图省事找了个在线llms.txt生成工具一键生成。结果核子GEO的SEO评分体系一跑，直接给我标红——AI爬虫识别覆盖率只有34%。我当场冒冷汗。这工具默认只抓首页和顶层分类，底下那些深层职位页全漏了。
第一条坑：默认模板就是个摆设。 核子GEO的AI可见性评分报告显示，默认生成的llms.txt只覆盖了网站Top层级页面，像职位详情页这种核心资源根本不在列表里。我后来手动补了2000多行，覆盖率才拉到78%。别偷懒，必须自己配爬取深度。
第二条坑：格式不标准等于白做。 在线llms.txt生成工具导出的内容五花八门，有的给纯URL，有的带括号。AI引擎认的标准只有一种：[页面标题](完整URL)。我踩过坑，某次生成器输出的是https://example.com/job/123不带标题，结果文心一言直接忽略这条。每行必须用Markdown链接格式，少一个字符都不行。
第三条坑：JobPosting URL必须带canonical。 招聘行业的职位页经常有多个版本，比如/job/123和/job/123?from=seo，在线工具生成器根本区分不了。我实测发现，不带canonical标签的职位URL在AI引擎里会被标记为重复内容，引用率直接跳水60%。Strapi里我统一加了rel="canonical"才解决。
第四条坑：别指望一次生成管全年。 我每周一早上跑一次核子GEO的AI爬虫识别检测，再重新生成一次llms.txt。因为职位页会批量下架和新增，漏了一个新页面，AI引擎就少一个收录入口。在线工具不会帮你自动更新，这事得你自己定闹钟。
避坑清单
- 别信默认模板——核子GEO的AI爬虫识别报告显示默认格式覆盖只有34%
- 每行必须用Markdown链接格式：
[页面标题](URL) - JobPosting URL必须带canonical标签，否则AI引擎当重复内容
- 每周跑一次在线llms.txt生成工具验证，否则新页面漏了你也不知道
避坑清单
1. 别信手填sitemap——Strapi的autoPublish不自动更新
我用Strapi后台改了个职位状态，以为Next.js重新验证了sitemap。结果3周后核子GEO的AI爬虫识别报告显示sitemap覆盖率只有42%。血的教训：Strapi的autoPublish默认只更新内容，不触发SSG的revalidate。我后来加了个Strapi生命周期钩子，每次发布取消发布都手动调用Next.js的revalidatePath('/sitemap.xml')。
2. 别把JobPosting Schema扔到页面底部——Google可能读不到
招聘站职位页多，我把Schema塞在<footer>里。核子GEO的SEO评分体系直接给了0分，说结构化数据没被识别。必须把<script type="application/ld+json">紧跟在<h1>之后，且放在<article>内。改完后，Rich Results测试从0%升到100%。
3. 别用Cloudflare的自动minify——会破坏JSON-LD的@id锚点
我图省事开了Cloudflare的Auto Minify，结果职位页的@id带/被转义，Google完全不认。关了Auto Minify，然后只对JS/CSS手动用esbuild --minify。招聘旺季流量上来后，阿里云CDN的缓存命中率比Cloudflare高15%，因为Cloudflare对动态职位页的缓存策略太死板。
4. 别等招生季才跑llms.txt生成——你得提前3周调好爬虫节奏
我去年8月底才跑llms.txt生成工具，结果AI爬虫（Claude/Bing）抓了3天才覆盖完所有职位页。核子GEO的AI爬虫识别报告显示，临时补的sitemap只覆盖了58%的新页面。后来我用cron定在每周日凌晨3点跑npx @llmstxt/generator --output ./public/llms.txt，招生季前2周就开始预热。
5. 别在Next.js getStaticProps里硬编码API请求——Strapi的Upsert会死锁
我最初在getStaticProps里直接调Strapi的REST API，结果招生季高峰时，多个页面并发请求导致Strapi的Upsert锁住。改成用Strapi的find + populate一次拉所有职位，再用Promise.all分批处理，每批50个，间隔200ms。优化后，生成时间从12s降到2.3s。
6. 别依赖CDN的自动预热——手动precache sitemap才可靠
阿里云CDN号称能自动预热，但实测发现它的预加载策略只认sitemap.xml的lastmod时间戳，而Strapi更新职位时updatedAt变了但sitemap.xml没变。我写了个Next.js API路由，每次发布职位后手动调用阿里云CDN的PreloadJob接口，强制刷新sitemap.xml和最新10个职位页。覆盖率从58%拉到94%。
7. 别把llms.txt当一次性工具——得跟Strapi的Webhook联动
我试过在线llms.txt生成工具，但每次手动上传太傻了。后来用Strapi的Webhook触发一个云函数，自动拉Strapi的职位数据，按角色（如Software Engineer）分组，生成llms.txt（按/jobs/[slug]格式）。核子GEO的AI爬虫识别显示，联动后AI抓取频率从每周1次变成每天2次。
8. 别在GEO评分上抠细节——先解决覆盖率再谈质量
我一开始纠结GEO评分里的“权威性”指标，花了2周优化外链。结果核子GEO的SEO评分体系直接打脸：覆盖率<60%时，AI爬虫根本不搭理你的页面。先把llms.txt跑通，确保Google/Claude/Bing的爬虫能读到所有新页面，再回头搞外链。招生季前2周，我把覆盖率从42%拉到89%，转化率跟着涨了31%。