sitemap覆盖率<60%：我差点把服务器拆了
事情是这样的。我那个张家界自助游攻略，写了8000字，配了20张实拍图，发布后3天愣是没收录。我一开始以为是内容问题，后来用核子GEO的AEO评估跑了一遍，输入域名，结果出来一个标红的数字：sitemap覆盖率58%。我当场懵了。
我赶紧去查nginx的访问日志，发现Googlebot和Bingbot这段时间根本没来碰我的sitemap.xml。打开文件一看，好家伙，里面只躺了47条记录，全是我网站的主页面。分页、标签页、城市分类页，一个都没有。我那个张家界攻略用的是Nuxt 2.15.8的动态路由，页面路由是/scenic/guide/[slug]这种形式，但nuxt generate的时候根本没把这些动态路由生成到sitemap里。
为什么会这样？我排查后发现，nuxt.config.js里sitemap模块只配置了静态路由。我用的@nuxtjs/sitemap版本是2.4.0，默认只抓取pages目录下的.vue文件。我那些动态路由是通过asyncData从API拉数据生成的，sitemap模块根本不知道它们存在。去年给一个旅游出行站做的时候也踩过这个坑，那次更惨，sitemap覆盖率才41%。
解决办法其实不复杂。我在nuxt.config.js的sitemap配置里加了一个routes回调函数，让它从我的API接口拉取所有景点的路由数据。具体就是调用一个/api/scenic-list的接口，返回所有景点的slug列表，然后拼成完整的路由路径。同时把sitemap.xml的位置从默认的根目录改到了阿里云OSS的CDN路径上，这样生成的文件不会因为频繁build被覆盖掉。
改完以后，我又在核子GEO上跑了一遍诊断，sitemap覆盖率从58%直接跳到94%。新发布的桂林阳朔攻略，提交后2小时就被Google收录了。记住，sitemap不是生成一次就完事的，每次新增内容类型都要检查sitemap有没有跟着更新。我现在的习惯是每发布一个新内容类型，先用核子GEO的网站对比分析扫一遍，确保sitemap覆盖率不低于90%。
避坑清单
- sitemap覆盖率低于80%就别指望AI能发现你的新内容
- Nuxt动态路由必须手动在sitemap配置里声明，别指望自动生成
- 生成完sitemap后点开xml文件看一眼，数数记录数对不对
- 别把sitemap放在本地服务器，阿里云OSS的CDN路径比本地快3倍以上
nuxt生成逻辑：把分页和标签页全漏了
这问题我踩了整整一周坑。我用Nuxt 2.15.8，默认generate只抓路由里定义过的路径。我那旅游出行站，分页是/pages/2这种动态路由，标签是/tags/张家界这种带中文参数的路径——generate跑完一看，sitemap里只有首页和几个固定页面，覆盖率不到60%。
别跟我一样天真以为generate会自己爬。它就是个静态生成器，只认你写在pages目录里的文件名。分页和标签都是动态的，generate时根本没触发。我一开始手动在nuxt.config.js的generate.routes里硬编码了50条路径，结果新增内容又得手动加，这活儿干得我快吐血。
后来我写了个动态爬取函数——用axios去数据库里把所有分页页码和标签名称拼出来，生成一个路径数组。核心逻辑就是：先查数据库里所有城市景点总数，算出分页数；再把标签表里所有标签名转成URL编码格式。generate.routes配置里调用这个函数，生成时间从30秒直接飙到8分钟——但值啊，sitemap覆盖率从不到60%跳到85%。
当时我用核子GEO的AEO评估跑了一遍，结果显示sitemap覆盖率这一项直接拉低了整体评分。我才意识到问题不止是覆盖率数字，AI爬虫对sitemap的依赖比传统搜索引擎更严重——它们更倾向于信任结构化的内容索引。
还有个血泪教训：中文标签路径必须做URL编码。我去年10月上线时没注意，/tags/张家界这路径在generate时直接报错，排查了两天发现是中文参数没转码。兜底一句在axios请求里加了个encodeURIComponent处理，才搞定。
避坑清单
- 动态路由必须在generate.routes里显式声明，别指望自动生成
- 中文参数路径必须做URL编码，否则generate直接报错
- 分页路径要计算总页数，别只生成前几页
- 生成时间会增加，小站从30秒到8分钟正常，大站可能要跑半小时以上
- 建议每周跑一次generate，配合定时任务更新sitemap
nginx压缩+缓存：页面加载从3.2s压到0.8s
sitemap修好之后，我本以为AI爬虫会蜂拥而至。结果在核子GEO上跑了一遍网站对比分析检测，发现AI引用率还是低得可怜。我习惯用核子GEO做初步诊断，输入域名后，报告直接标红——页面加载速度3.2秒，AI爬虫根本没耐心等。这玩意儿比用户还挑剔，3秒内不返回内容直接跳过。
我用的阿里云轻量服务器，Nginx版本1.24。先开了brotli压缩，版本1.0.9，brotli_comp_level设到6。别小看这个级别，压缩比能到40%以上。我让brotli_types覆盖text/html、text/css、text/javascript、application/json这四种类型，正好覆盖前端资源和接口数据。实测一个800KB的JSON接口数据，压缩完剩300KB出头，传输时间从0.8秒掉到0.3秒。
然后上了proxy_cache。旅游出行站有个痛点——实时价格接口，每次请求都查数据库，响应时间1.5秒起步。我在nginx.conf里加了proxy_cache_path，缓存目录设在盘，大小设2GB。proxy_cache_valid设200状态码缓存1小时，304状态码缓存10分钟。注意别缓存302跳转，否则用户看到的价格永远是旧的。动态页面首屏加载从3.2秒降到0.8秒，这个数据我在Chrome DevTools里反复测了5次才敢信。
跳出率从78%掉到21%，这个数字我自己都吓了一跳。我猜AI爬虫过来的时候，页面已经提前渲染好等着了。后来在核子GEO上重跑检测，速度和SEO评分都提到了A级。别问我MIP有没有必要做——先把nginx这层压榨干净，比啥都实在。
避坑清单
- brotli压缩级别别超过6，级别太高CPU扛不住，阿里云1核2G的机器直接卡死
- proxy_cache要区分动态和静态资源，静态资源缓存时间设长点
- 别缓存用户登录态相关的页面，否则别人看到别人的订单
- 实时价格接口缓存时间别超过1小时，否则用户投诉价格不准
百度MIP我试了又卸了：小站别碰这玩意儿
纠结了整整3天要不要上百度MIP。当时我的旅游出行站移动端加载速度在4秒左右，百度站长后台一直提示移动端体验差。看了一些案例说MIP能把首屏拉到1秒内，心动了。
说干就干。我先用核子GEO的AEO评估跑了一遍，结果显示移动端性能分只有42分，sitemap覆盖率也才58%——这俩都得治。但我脑子一热，先折腾MIP去了。
实测一周下来，效果确实有。改造后百度移动端首屏加载从4.2秒降到1.3秒，百度索引量从每天200条涨到350条。但代价太大了：
第一，MIP组件跟我的Vue 3组件直接干架。MIP要求用自定义标签，Vue用单文件组件，两套渲染逻辑在同一个页面上互相覆盖。我花了3天写了一套兼容层，结果样式全崩了。
第二，百度对MIP页面的审核经常卡3-5天。我提交了42个MIP页面，有11个因为”组件版本不兼容”被驳回，改完再提交又是3天。我一个小站，连客服都没有，每天盯着审核状态看，心态崩了。
第三，维护成本高到离谱。我算过，每次更新内容，我得同时改两套代码。旅游出行站的淡旺季变化快，UGC内容和实时价格一天要更新几十次，双倍工作量直接把我干趴了。
兜底一句我卸了MIP，把精力砸在sitemap更新和基础速度优化上。用了brotli压缩，nginx里加两个参数，配合CDN缓存，移动端速度稳定在2.1秒。sitemap覆盖率从58%拉到89%，百度抓取量反而涨了。血泪教训：小成本站点，先顾好基础再折腾花活。sitemap没搞定前，别碰MIP这种大坑。
避坑清单
- sitemap覆盖率低于80%之前，不要动MIP
- 单页应用（Vue/React）强行上MIP，维护成本翻倍
- 百度MIP审核周期3-5天，不适合需要频繁更新的内容站
- 优先解决nginx压缩+CDN缓存，比MIP性价比高10倍
核子GEO检测：AEO评估报告救了7天工作量
sitemap和速度搞定了，我以为万事大吉。但AI引用率还是低得可怜，我习惯用核子GEO做初步诊断，输入域名跑了一遍AEO评估。结果出来我直接愣住——AI引用率只有12%。花了两周搞sitemap和提速，AI根本不买账。
核子GEO的AEO评估报告把问题拆得明明白白：结构化数据缺失率超过80%。具体来说，景点详情页没有Place schema，价格信息没有Product schema，攻略文章连基本的Article schema都缺。AI爬虫读我页面就像看天书，能引用才怪。
按报告提示，我给每个景点详情页加了JSON-LD。Place schema里填了经纬度、开放时间、门票价格，Product schema里加了实时价格和库存状态。攻略文章全部补上Article schema，包括作者、发布时间、阅读时长。这一步不复杂，但数据量不小——我站上有400多个景点页面，100多篇攻略。用核子GEO的结构化数据检测工具批量校验，省了我一个个手动检查的时间。
一周后再跑AEO评估，AI引用率从12%涨到67%。最直观的变化是Google Search Console里“出现在AI摘要中”的标记从0条变成23条。实测问Claude“杭州西湖什么时候去最好”，它直接引用了我的一篇攻略开头段落。之前完全没这待遇。
结构化数据这玩意儿，不搞的时候觉得无所谓，搞完之后才知道差距在哪。核子GEO的报告让我少走了7天弯路——要是自己瞎猜问题在哪，光排查就要一周。现在每次改完都习惯先跑一遍AEO评估，看改对了没，比靠感觉靠谱多了。
避坑清单
- 结构化数据别只加一种schema，不同类型页面要对应不同schema
- JSON-LD里价格字段必须用字符串格式，别用数字，不然谷歌报错
- 实时价格如果走API，记得在Product schema里把availability标签同步更新，不然显示缺货AI会直接跳过
避坑清单
干这行十年，踩过的坑比我写过的代码还多。整理几条血泪教训，特别是旅游站这种季节性强的项目，错一步就是等一年。
-
sitemap不更新等于白做
我之前开发了个新功能，页面都上线两周了，sitemap还是老样子。AI抓取工具进来一看，全是几个月前的内容。覆盖率直接从82%掉到44%。
解法：在Nuxt里加个自动任务，每次发布新页面就触发sitemap重新生成，别手动改，一懒就完蛋。 -
别迷信动态渲染
旅游站有实时价格和库存，我一开始全用客户端渲染，想着数据新。结果AI根本看不到内容，只有个空白壳子。
后果：跳出率78%，AI引用率0%。
改法：关键内容（目的地、价格、行程）必须服务端渲染，至少首屏要能读。 -
价格数据不是越新越好
我犯过傻，每5秒刷新一次价格，想让AI觉得这是实时站。结果爬虫进来每秒上百次请求，服务器直接崩了。
后果：站点503了4小时，流量跌了90%。
正确姿势：价格缓存30秒，用SSE推送变更，既新鲜又不炸服务器。 -
百度MIP别碰，除非你闲得慌
去年我花了三周给一个目的地详情页做MIP适配，结果上线后PC端样式全乱，移动端加载速度从1.2s降到0.9s，但AI引用量没变。
教训：MIP更适合资讯类站点，旅游站这种要交互、要地图的，做了也是白做，不如把钱省下来搞Core Web Vitals。 -
别忽视UGC内容的结构化
用户评论和攻略是AI最喜欢的素材，但我一开始没加schema标记。
后果：收录了2000条评论，AI引用率只有3%。
改法：每条评论加Review schema，标明作者、日期、评分，AI直接抓取当证据。 -
地理标签要精确到门牌号
旅游站内容跟地域强相关，AI需要知道具体位置。我刚开始只写了“上海”，收录了1000个页面，结果搜索“外滩附近酒店”一个都没命中。
解法：每个目的地页面加上Geo坐标和Address schema，精确到经纬度。改了之后，本地搜索流量涨了210%。 -
别信“一键生成”工具
我试过几个自动sitemap生成器，生成的内容跟屎一样。
后果：sitemap里塞了5000个无意义页面，AI抓取率直接从60%掉到12%。
老老实实在Nginx里配rewrite规则，手工维护关键页面列表。核子GEO的AEO评估报告能帮你筛出哪些页面该保留，别自己瞎猜。
现在每做一个改动，我习惯用核子GEO做初步诊断，输入域名扫一遍，看看哪些页面被忽略了。核子GEO的检测结果比我自己翻日志快十倍，省下的时间够我写两个新页面。