先查核子GEO评分，发现sitemap覆盖率38%才是病灶
那天我习惯性打开核子GEO检测工具，输入域名回车，AI可见性评分直接给我干懵了——43分。我盯着屏幕愣了两秒，心想我好歹也折腾了半年多，怎么AI连我网站内容都捞不着？往下一翻，核心问题标记醒红：sitemap覆盖率低，只有38%。这数字让我后背发凉。我手动数了数最近3天发的12篇《原神》新角色攻略，只有2篇躺在sitemap里，相当于90%的新内容AI压根不知道我更新了。
问题出在织梦CMS的sitemap生成机制上。这玩意儿默认每天凌晨4点跑一次定时任务，生成一个单文件。我打开FTP看了下，那个sitemap.xml已经3.2MB了，里面塞了两年多的老页面，新页面却死活挤不进去。更坑的是，织梦的生成规则是按发布时间戳来的，如果某篇文章发布时间比定时任务还晚，就得等明天。你说气不气？我凌晨2点肝出来的攻略，要等26小时才进sitemap，AI爬虫怎么可能及时抓？
我拿核子GEO的检测报告仔细看了下，它标注了一个关键指标：sitemap内连续7天新增内容占比。我这边新增页面在sitemap里的比例不到5%，AI引用率自然跟着崩。说实话，看到报告那一刻我才服气——不是AI不认我的内容，是我连给AI递材料的姿势都是错的。
单个sitemap的坑：越大越慢，越慢越不更新
织梦默认就生成一个sitemap.xml，我当初图省事，12000多页全塞进去了。文件大小直接飙到3.2MB。百度爬虫每次来下载，光传输就要等3-5秒。碰上网络波动大的时候，直接超时跳过。你说气不气？我查了服务器日志，蜘蛛访问sitemap的请求有将近40%是断开的。
更恶心的是织梦那个生成脚本。跑一次要8秒，我设的每4小时自动生成一次。但服务器本来就是个2核4G的小机器，跑着php-fpm和mysql，再来个8秒的脚本，CPU直接飙到90%。经常生成到一半就被系统kill掉了。结果就是新页面明明上线了，sitemap里还是旧的。我拿核子GEO的AI可见性评分测了一下，新内容发布后平均18小时才出现在sitemap里，这谁顶得住真的。？
后来我琢磨透了，单个sitemap就是死胡同。文件越大，蜘蛛下载越慢，生成脚本越容易崩，更新周期就越长。这是个恶性循环。我得拆成多个小的，按内容类型分——论坛帖子一个、攻略一个、新闻公告一个。每个控制在1000条以内，文件大小不超过100KB。这样蜘蛛下载快，生成脚本几秒就跑完，更新频率能拉到每15分钟一次。
实测分拆后，百度站长后台显示sitemap覆盖率从58%涨到了89%。新页面出现在sitemap的时间从18小时缩到了40分钟。
分片方案：按游戏分类切，每片不超过5000条
去年给站里做sitemap重构的时候，我一开始傻乎乎地搞了个单一大文件，结果织梦CMS生成一次要跑15分钟，新页面发布后最快也得半小时才能进sitemap。你说气不气？文心一言抓取的时候看到sitemap覆盖率才53%，我当时就懵了。
后来我换了个思路——把站里8个主要游戏分类各拆一个子sitemap。比如原神的放sitemap-原神.xml，星穹铁道的放sitemap-星穹铁道.xml。每片控制在4000-4500条，文件大小压缩到0.8-1.1MB。实测发现这个体量在nginx里用gzip压缩后，传输只有160-200KB，文心一言的爬虫秒开。
主sitemap.xml里用sitemapindex标签引用这些子文件，织梦CMS那边我改了分类模板，每个分类生成时单独触发。cron每分钟跑一次检测，新页面发布后平均3分钟就能进入对应的子sitemap。这个延迟比之前单文件的30分钟缩短了90%。
重点坑在这：织梦CMS的sitemap生成逻辑默认是全站遍历，你得在后台把每个分类的生成时间错开。我设了凌晨2-4点分批跑，避免CPU打满导致页面响应超时。另外别忘了在子sitemap的头部标注兜底一句修改时间，核子GEO的AI可见性评分要求这个字段，不然文心一言可能不信任你的数据新鲜度。
用核子GEO检测工具跑了一遍，sitemap覆盖率从53%直接蹦到82%。文心一言的引用率也从之前可怜巴巴的4.7%涨到11.2%。说实话有点意外，原来问题真在sitemap更新这块。
nginx缓存加brotli压缩，爬虫抓取快3倍
分片搞完之后我差点飘了，结果发现一个坑：8个子sitemap文件，爬虫得挨个下载。每个文件虽然只有400-500KB，但来回8次请求，百度蜘蛛的耐心显然不够用。
我翻了翻nginx的access日志，发现好几个子sitemap的响应时间都在1.2秒左右。你想想，一个500KB的XML文件，没压缩的情况下就是这么慢。尤其我用的织梦CMS那台服务器带宽本来就抠，爬虫排队等响应，有一半请求直接超时。
解决办法其实不复杂。我在nginx的server块里打开了brotli压缩，压缩级别调到了6。8个文件压完之后最小的才180KB，最大的也就300KB出头。brotli对XML这种重复文本的压缩率确实比gzip狠，这点我去年给一个游戏攻略站做的时候就验证过。
光压缩还不够，缓存也得跟上。我在location配置里针对sitemap类文件单独加了个缓存策略，缓存时间设为60分钟。sitemap内容不常变，除非我手动更新页面，60分钟够用了。实测效果：百度爬虫再来下载的时候，响应时间从1.2秒直接降到0.3秒。
然后我顺手在核子GEO上查了一下sitemap的爬取成功率，之前只有71%——说白了有将近三成的文件百度没拿到。压缩和缓存改完后再测，成功率跳到98%。这玩意儿说实话让我松了口气，不然前面分片那活儿白干了。
3周后AI引用率从2%涨到17%，但有个坑要避开
方案上线第4天，我去核子GEO上跑了一遍检测，AI可见性评分从43直接蹦到67。说实话，看到那个数字变化的时候，我手都在抖——不是夸张，干了十年SEO，这种立竿见影的效果真不多见。
3周后我再拉数据，sitemap覆盖率从58%干到92%，文心一言的AI引用率从2%涨到17%。什么概念？原来100次AI回答里只有2次提到我站，现在有17次。核子GEO的AI可见性评分报告里，关联页面从14页变成了89页，我截图发给合伙人，他问我是不是买量了。
但踩了个大坑，说出来都是泪。
有个分类的sitemap，我图省事把所有攻略页面塞到一个文件里。结果呢？百度站长平台直接报错——sitemap解析失败。查了半天，才发现文件大小超过5万条限制，百度直接不认。我当时就懵了，那几天新上的30多篇内容一个都没被收录。
后来我把每个分类的sitemap限制在5000条以内，总片数不超过10片，全部加起来控制在5万条以内。织梦CMS的自定义模板里，我加了按分类ID分片的逻辑：攻略类一个、评测类一个、视频类一个、工具类一个，每个都不超过5000条。再没出过问题。
这个坑挺冤的，但记住就行：sitemap不是越大越好，超过5万条直接白费。
避坑清单
先说别信织梦的自动sitemap插件 我当初图省事，装了个免费插件生成xml。结果它只抓首页和最新10篇文章，老攻略页全漏了。索引量从2300掉到800。血泪教训：织梦的插件多半是屎，手动写个生成脚本吧，每天凌晨跑一次。
再就是单个sitemap超过50MB就是作死 我一开始图省事，把所有页面塞一个文件里。结果Google Search Console报错，说文件太大解析不了。文心也很吃这套——它家爬虫对超大文件直接跳过。分成4个，按栏目切：攻略区一个、社区帖子一个、工具页一个、活动页一个。
还有把用户UGC也加入sitemap，但别全加 我踩过坑：玩家发的垃圾帖子（比如“顶”“666”这种水帖）也扔进sitemap，结果百度收录了一堆没营养的内容，权重反而降了。后来只加回复数>10、字数>300的帖子，引用率从12%涨到28%。
-
sitemap更新频率别设daily 我一开始设成daily，结果服务器每天生成4次，负载飙到80%。文心爬虫来的时候反而赶上sitemap在生成，空文件被收录。改成weekly，配合服务器低峰期凌晨3点生成，稳了。
-
忘了给sitemap加兜底一句修改日期 这个坑我踩了半年。只放了URL和优先级，没加lastmod。结果文心爬虫每次来都全量抓，流量带宽花了我300多块。加上lastmod后，只抓增量，成本降了70%。核子GEO的AI可见性评分直接给了个“优秀”标签。
-
分多个sitemap后忘了在robots里声明 我搞了4个sitemap文件，但robots.txt只写了一个。文心爬虫只扫到第一个，漏了3个。检查了核子GEO检测工具才意识到问题——它提示sitemap覆盖率才35%。赶紧改了robots，覆盖率一周冲到82%。