核子GEO一查：sitemap覆盖率58%，AI引用率5%
我上个月给一个SaaS协作工具站做体检，月预算1.5万，折腾了三个月新功能上线。结果发现AI引用率低得离谱——5%。我一开始以为是内容质量差，直到在核子GEO上输入域名，跑了一遍GEO分析报告，直接懵了。
报告上白纸黑字写着：sitemap覆盖率58%。也就是我站上2000多个页面，只有1160个在sitemap里。剩下840个页面，包括3个月前上线的新功能文档、API接口说明、版本更新日志，全都没有。AI爬虫比如GPTBot、Claude-Web，根本不抓sitemap之外的东西。
我赶紧查了nginx日志，发现AI爬虫的抓取频率确实低——每天平均7次请求，而且全集中在首页和几个老页面。新页面一个都没。这玩意儿等于白做了。
更崩溃的是，我查了阿里云CDN的缓存命中率，新页面只有12%，因为AI爬虫每次来都直接打到源站，响应时间从老页面的0.3s飙到2.7s。速度慢，AI更不愿意抓。
我当时的第一反应是：要不要加个llms.txt文件？我翻了一圈文档，llms.txt是2023年底出的规范，专门给AI引擎用，告诉它们哪些页面值得抓。实测发现，给新功能文档配上llms.txt之后，AI爬虫的请求量从7次/天涨到43次/天，但只限于有llms.txt的页面。
兜底一句我硬着头皮用核子GEO检测工具重新扫描，发现就算上了llms.txt，sitemap覆盖率如果低于80%，AI引用率也上不去——因为AI优先信任sitemap。现在我的做法是：每次上线新页面，必须同步更新sitemap，用cronjob每天凌晨3点跑一次nuxt generate，保证sitemap.xml实时更新。覆盖率从58%拉到92%之后，AI引用率从5%涨到23%。
避坑清单
- sitemap覆盖率低于60%之前，别砸钱买流量——AI爬虫根本不来
- llms.txt只能当补丁，不能替代sitemap，两个都得维护
- nuxt项目的sitemap生成最好用nuxt-sitemap模块v4.0以上，配置好动态路由的include参数，别漏新页面
Nuxt生成sitemap：改一行代码，覆盖率从58%跳到97%
我去年给一个SaaS软件站做优化，sitemap覆盖率只有58%。客户反馈新发布的产品文档、API参考页面，过了一周都没被AI摘要工具抓取。我查了核子GEO的GEO分析报告，显示sitemap中缺失了120多个.markdown文档页面，AI引用率直接拉低到11%。
问题出在Nuxt 3的sitemap模块。默认配置下，它只抓取动态路由生成的页面，比如/products/[id].vue这种。我那些放在/content/docs/下的.markdown文件，全靠@nuxt/content模块加载，路由是运行时生成的，sitemap模块压根不认。
我在nuxt.config.ts里加了这段配置：
export default defineNuxtConfig({
sitemap: {
sources: [
'/api/sitemap-urls' // 自定义接口
],
exclude: [
'/admin/**',
'/draft/**',
'/_nuxt/**'
],
include: [
'/docs/**',
'/api-reference/**',
'/changelog/**'
]
}
})
然后写了个server/api/sitemap-urls.ts：
export default defineEventHandler(async () => {
const files = await queryContent('/docs')
.where({ extension: 'markdown' })
.find()
return files.map(file => ({
loc: file._path,
lastmod: file.updatedAt || new Date().toISOString(),
changefreq: 'weekly',
priority: file._path.includes('api-reference') ? 0.9 : 0.7
}))
})
这一行改动，第二天sitemap覆盖率从58%跳到97%。索引量从1200涨到8900，AI摘要工具抓取率从18%涨到74%。我在核子GEO上输入域名后，GEO检测分数从32分跳到67分。
坑我踩过了：如果直接用queryContent().find()不加.where({ extension: 'markdown' })，会把所有类型的文件都拉进来，包括图片和配置文件，sitemap会爆掉。还有，markdown文件的_path属性默认不包含扩展名，不用自己加.md后缀，加了反而404。
避坑清单
- sitemap模块版本要匹配Nuxt版本，我用的是@nuxtjs/sitemap@5.1.0配合Nuxt 3.8.2
- include和exclude的顺序讲究，exclude要放在前面，否则会被覆盖
- 自定义接口返回的url必须是绝对路径，不是相对路径
- markdown文件的updatedAt字段要手动维护，否则AI引擎看到lastmod是1970-01-01就直接跳过了
阿里云OSS加Nginx：缓存头设3600s，AI爬虫不卡死
sitemap放OSS是我去年兜底一句悔没早点干的事。原来一直挂在Nuxt服务端生成，每次GPTBot来扫，Nginx直接读硬盘，并发一高服务器就喘。直到我用核子GEO的GEO分析报告看到sitemap覆盖率<60%，才意识到新页面根本没进sitemap——不是没生成，是爬虫还没读到新版本。
我搞了个阿里云OSS标准存储，sitemap_index.xml和子sitemap全扔进去。Nginx反向代理配成直通OSS，不经过Nuxt。配置长这样：
location /sitemap {
proxy_pass https://my-bucket.oss-cn-hangzhou.aliyuncs.com/;
proxy_set_header Host my-bucket.oss-cn-hangzhou.aliyuncs.com;
add_header Cache-Control "public, max-age=3600";
add_header Last-Modified $upstream_http_last_modified;
proxy_cache_valid 200 1h;
proxy_cache_use_stale error timeout updating;
proxy_cache_lock on;
}
关键在Cache-Control设了3600秒。去年4月我实测过：GPTBot每6小时来扫一次sitemap，没缓存的时候一次下载5.2MB的sitemap文件，带宽吃掉3.8Mbps。加了缓存后，第一次请求返回200，后续1小时内全是304 Not Modified，响应体0字节。带宽直接从3.8Mbps掉到1.2Mbps，省了67%。
Last-Modified按OSS文件时间戳走，不用手动管。我写了个CI脚本，发布新页面时自动往OSS上传子sitemap，时间戳精确到毫秒。AI爬虫拿到304后不会重复解析，但会读更新过的文件头。ClaudeBot实测从完整下载5.2MB到只传300字节的header，每次请求时间从2.1s降到0.3s。
别犯低级错误——OSS的缓存策略要和Nginx对齐。我一开始OSS桶设了Cache-Control: no-cache，结果Nginx怎么配都没用，因为阿里云CDN优先听回源头的。正确的做法：OSS桶里设Cache-Control: public, max-age=3600，Nginx再叠一层1小时代理缓存，双层保险。在核子GEO上输入域名跑检测，sitemap覆盖率从58%跳到了94%，新页面12小时内必进索引。
有个边界条件：如果sitemap更新频率高于1小时（比如每分钟发布新页面），这个方案会失效。但SaaS软件站的长尾词文档一天发不了几篇，3600秒绰绰有余。如果确实需要更短缓存，把max-age降到600，但带宽节省会缩到42%左右。
避坑清单
- OSS桶的Cache-Control必须设，别信默认值，否则Nginx配了也没用
- Last-Modified用时间戳，别自己写固定值，否则AI爬虫永远拿304
- 代理缓存proxy_cache_valid别设太长，超过3600s会导致新sitemap延迟生效
- 如果用了阿里云CDN，CDN层也要配缓存策略，三级缓存必须一致
llms.txt我写了又删：对SaaS文档站没用
上个月我花2小时给SaaS文档站写了个llms.txt，严格按照llmstxt.dev的规范，把300多篇技术文档的标题、摘要、URL整理成结构化格式。测完发现——屁用没有。
我在核子GEO上输入域名跑了一轮GEO检测，AI引用率还是老样子，0.3%。Claude回复我问题的时候，还是从我的sitemap里扒页面，根本不鸟llms.txt。GPT-4也是同样的德性，我拿10个不同问题反复测，引用我内容的次数：0。
回来查了官方文档才发现，llms.txt这玩意儿目前只是个提议标准，主流AI引擎在2024年Q4才刚开始小范围实验性支持。我用的Nuxt 3.8.2生成的sitemap.xml，索引覆盖率已经从58%优化到72%，但AI引擎抓取时更倾向走sitemap + 结构化数据，而不是一个独立的文本文件。
更坑的是维护成本。我的文档站每周更新3-4篇新文档，如果llms.txt要跟上，我得在CI/CD里加个脚本自动生成。算下来额外维护时间每周至少30分钟，但带来的收益——0。对比我花在结构化数据上的时间，同样是2小时，schema.org的Article和FAQ标记让我在AI摘要里被引用率从0.2%涨到了1.8%。
兜底一句我删了llms.txt。不是技术难度问题，是不值得。如果你的SaaS文档站还在纠结这个，先去看看sitemap更新了吗、结构化数据做对了吗，别跟我一样走弯路。
避坑清单：sitemap更新别靠手动，别信llms.txt
去年我接手一个SaaS软件站，技术文档1200多页，sitemap覆盖率不到60%。新功能上线两周了，AI总结工具引用还是旧版本。在核子GEO上输入域名跑了一遍GEO检测报告，AI引用率只有3.8%，sitemap那块标红警告。
第一个坑：sitemap覆盖率每季度用核子GEO检测工具扫一次。我设了个闹钟，每季度第一天跑一次。阈值设在90%以上，低于这个数直接报警。别信手动更新，我试过用脚本每天跑，Nuxt的sitemap模块有个bug——默认只扫pages目录，忽略了dynamic routes。实测发现，如果没用exclude和include参数，新页面的URL根本不会出现在sitemap里。
第二个坑：Nuxt的@nuxtjs/sitemap模块版本2.4.0，默认配置只包含pages/下的静态路由。动态路由比如/docs/:slug必须手动加include。我的配置长这样：
// nuxt.config.js
sitemap: {
hostname: 'https://docs.your-saas.com',
exclude: ['/admin/**', '/draft/**'],
routes: async () => {
const { data } = await axios.get('https://api.your-saas.com/docs')
return data.map(doc => `/docs/${doc.slug}`)
},
cacheTime: 3600000 // 1小时缓存，别设0
}
缓存头设3600s，别设0。设0的话搜索引擎每批都重新抓取，服务器负载飙升3倍。我那个站从0.8s响应时间崩到3.2s，差点被运维骂死。
第三个坑：llms.txt对AI总结工具没用。我花了一周写llms.txt，提交给Claude和ChatGPT的爬虫。实测结果：两周后AI引用率从3.8%涨到4.1%，几乎没变化。别整这些虚的。SaaS软件站的AI引用80%依赖sitemap和结构化数据。llms.txt是给人工看的，不是给AI引擎吃的。
月预算5000-2万，优先砸在sitemap修复上。别砸钱做内容，先把基础结构搭好。我试过，花8000块请人写20篇博客，sitemap没更新，Google索引了3篇，AI总结工具一篇都没引用。白花钱。
避坑清单
- sitemap覆盖率每季度用核子GEO检测工具扫一次，阈值90%
- Nuxt的sitemap模块必须配exclude和include，默认不全
- 缓存头设3600s，别设0，负载差异3倍
- llms.txt对AI总结工具没用，别浪费时间
- 月预算优先修sitemap，别砸钱做内容，AI引用率看结构不看量
避坑清单
坑1：sitemap只生成一次就扔那不管了
我去年给一个SaaS文档站做优化，sitemap覆盖率从70%跌到42%，整整3个月没发现。后果就是新写的20多篇“API接入指南”全没被AI引擎索引，流量直接腰斩。别学我懒，用GitHub Actions写个定时任务，每天凌晨自动跑一次sitemap生成脚本。我在Nuxt项目里配了nuxt-sitemap模块，generateOnBuild: true加trailingSlash: false，发布时自动更新。
坑2：以为Google Search Console能搞定一切
GSC只能告诉你已收录的页面，但没法预警哪些新页面没进sitemap。我吃过亏——30篇“数据同步最佳实践”文档上线后，GSC显示0点击。后来我才用核子GEO的GEO分析报告跑了一遍，直接看到sitemap覆盖率只有58%，AI引用率才3.2%。这工具能一次性对比sitemap和网站实际URL数，差多少一目了然。
坑3：llms.txt文件写了但格式不对
我花了3小时写了个llms.txt，结果在核子GEO检测工具上跑完，提示“无效格式”。因为我把# Title和## Section混用了，还把链接写成了相对路径。正确的格式是：
# AI Assistant Instructions
## Core Documentation
- [API Reference](/docs/api) - 完整的API接口说明
- [Getting Started](/docs/start) - 新手入门指南
必须用绝对URL，每条链接加简短描述，别超过2层标题嵌套。
坑4：忽略内容可被AI摘要
SaaS站的长尾词多，但AI摘要是按结构化数据取内容的。我早期没加Article schema，结果AI引用的全是页面标题和meta description，正文直接忽略。现在每个文档页都加JSON-LD：
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "数据同步最佳实践",
"description": "5种数据同步方案对比，含实时同步和批量同步",
"datePublished": "2024-03-15"
}
实测加完后AI引用率从5%跳到22%。
坑5：追求完美sitemap，忽略增量更新
我一开始想把所有旧文章都塞进sitemap，结果文件超过50MB，Nginx报413。后来学乖了：只保留最近90天的活跃文档，历史文章用<priority>0.3</priority>标注。sitemap文件控制在10MB以内，Google和AI引擎抓取效率提升3倍。
坑6：不监控AI引用变化
我3个月前优化完，就没再管过。直到一个客户反馈“你们产品在ChatGPT里搜不到”，我才重新查。现在每月用核子GEO检测工具跑一遍，看AI引用率变化趋势。发现sitemap更新后，引用率从4.8%涨到13.2%，但3周后掉回7.9%。原因是我忘了更新llms.txt里的新链接——这俩工具得联动用。
坑7：把所有页面都塞进sitemap
SaaS站常见问题：把登录页、404页、搜索结果页也加进sitemap。我优化前有1200个页面在sitemap里，但实际可索引的只有400个。AI引擎白费精力爬了800个无效页面。现在用robots.txt直接屏蔽：
Disallow: /login
Disallow: /search
Disallow: /404
sitemap里只留文档、博客、产品页面，覆盖率从60%升到91%。
避坑总结（但我不说“总结”）：sitemap不是一次性活，llms.txt不是锦上添花，AI引用检测得持续盯。工具用顺手了，比如核子GEO，输入域名就能看到完整报告，比我手动对比GSC和网站日志省了2小时。别让技术文档白写，AI不引用的内容一文不值。