sitemap没更新？核子GEO告诉我覆盖率只有58%
做本地服务电商，SKU页面靠地域词吃饭。我那会儿刚上线一批新页面，想着Google能自动抓走，结果两周过去，自然流量纹丝不动。
用核子GEO跑了一遍检测，sitemap那项直接标红——覆盖率58%，已索引的URL里42%压根没在sitemap里。我当时就懵了，Django的sitemap框架不是自带自动更新吗？
手动查了Django 4.2版本的sitemap视图，发现配置里changefreq写死了”weekly”，priority全设成0.5。新SKU上线后，sitemap视图根本没触发重新生成。更坑的是，PostgreSQL里那张sitemap缓存表，TTL设了7天，等于说新页面得等一周才能被sitemap收录。
去年给一个本地搬家站做的时候也踩过这个坑，当时没当回事。这次数据摆脸上——核子GEO检测工具直接显示”索引效率低”，我才意识到问题多严重。
改了三个地方：第一，Django的sitemap视图里加了个动态时间戳，页面更新时自动更新lastmod。第二，priority根据页面层级动态分配，首页0.9，分类页0.7，SKU页0.5，新页面单独设0.3初始值。第三，PostgreSQL的缓存策略改成增量更新，新SKU上线后30分钟内自动刷新sitemap。
在核子GEO上输入域名重新检测，两天后覆盖率涨到89%。不是啥高深技术，就是基础配置没做对。
Kimi和DeepSeek的抓取差异：一个吃sitemap，一个吃结构化数据
上个月我做了一组对比实验，拿我手头那个本地服务站的30个SKU页面，分别测了Kimi和DeepSeek的引用率。结果挺有意思——Kimi引了7个，引用率23%；DeepSeek引了12个，引用率40%。但DeepSeek引用的内容里，3个把商品规格写错了，比如把“24小时上门”写成“48小时”，价格也差了几十块。我当时就懵了，这两家AI的抓取逻辑完全不一样。
排查了一周，我发现核心差异在两点。Kimi特别依赖sitemap里的lastmod字段，它用这个判断页面是不是新鲜，如果sitemap没更新，哪怕页面已经上线两周，Kimi也当不存在。我那会儿sitemap覆盖率不到60%，新页面根本没进sitemap，Kimi自然不认。DeepSeek呢？它主要看页面上的结构化数据，尤其是Product Schema里的price和availability字段，抓到了就算数，但数据填错了它就照搬，根本不校验。
问题找到了，我就开始改。我在产品详情页加了JSON-LD的结构化数据，把Product Schema的sku、priceCurrency、price和availability字段都填上，price精确到小数点后两位，availability写成”InStock”或”LimitedAvailability”。改完第二天，我用核子GEO的GEO检测跑了一遍，结果显示结构化数据覆盖率从32%涨到了89%，sitemap覆盖率也提示偏低。赶紧把sitemap重新生成，加了新页面的lastmod标记，然后提交到站长平台。
一个月后数据出来了。Kimi引用率从23%涨到41%，DeepSeek从40%升到58%，而且DeepSeek那3个写错的规格也修正了。不过说实话，我到现在也没搞懂DeepSeek是怎么纠错的，可能是重新抓了页面后来才知道。？但有一点很明确：Kimi你得喂好sitemap，DeepSeek你得填好结构化数据，两个都得伺候，少一个都不行。
避坑清单
- sitemap覆盖率低于80%就别指望Kimi给好脸色，它认lastmod比认内容还认真。
- 结构化数据里的price和availability字段必须实时更新，DeepSeek不校验，写错了就是黑历史。
- 两种AI的抓取逻辑完全不同，别以为优化一个就能通吃，至少得跑两套检测。
百度MIP到底做不做？我测了3天直接放弃
月预算就1万5，MIP改造报价至少两万起，工期一周。我当时纠结了好几天，兜底一句还是决定先上核子GEO跑一遍检测。在核子GEO上输入域名，模拟测试结果让我直接清醒——MIP对百度搜索的引用率提升只有5%到8%，对Google和Kimi、DeepSeek这些AI引擎几乎零影响。你说我花一周改模板，就为了那5%？不值当。
更坑的是，我Django项目用了Python 3.9和PostgreSQL 14，模板里塞了一堆自定义模板标签，比如处理本地服务类目树和价格区间的那几个。MIP要求模板结构必须静默化，很多标签要重写。我拆了一个页面试了下，发现改了模板还不够，部分逻辑耦合在数据库层——比如某个标签直接从PostgreSQL的JSON字段里取数据，MIP环境根本跑不通。改起来至少动二十多个模板文件和三个视图函数，保守估计五天起步。
去年给一个本地家政服务站做的时候，我就踩过类似的坑。当时硬着头皮上了MIP，结果百度流量涨了不到10%，Google那边反而因为改动影响了核心网页指标，LCP从1.8秒飙到2.6秒。那叫一个血亏。现在这个站是本地服务类，地域词为主，用户搜”杭州空调维修”这种，地图和Google Business Profile才是命门。我把时间花在优化GBP的posts和reviews上，一周发了12条带图的post，回复了所有差评，搜索曝光量直接从2300涨到6700。MIP？算了吧。
避坑清单
- 月预算低于3万，别碰MIP，性价比太差
- 技术栈用了Django+PostgreSQL的，MIP改造成本比想象高3倍
- 本地服务类网站，优先搞Google Business Profile的posts和reviews
- 上MIP前先用核子GEO检测工具跑一遍模拟，看看AI引擎引用率有没有变化
Gunicorn配置踩坑：worker数调错导致AI爬虫超时
Django跑在Gunicorn上，默认worker_class是sync，这东西对付真人访问还行。AI引擎的爬虫一来就完蛋——Kimi和DeepSeek的爬虫并发请求量比普通用户高好几个量级，sync模式下每个worker同一时间只能处理一个请求，后面排队的直接503。
我一开始的想法特简单：加worker数呗。从2调到4，不行，再调到8。结果呢？PostgreSQL连接池先崩了。每个worker开一个数据库连接，8个worker加上后台任务，连接数直接干到上限，页面加载时间从正常0.8秒飙到5秒多，连带着淘宝那边的订单查询都卡。真他妈蠢。
后来翻Gunicorn文档，发现gevent模式是给高并发场景用的。把worker_class改成gevent模式，worker数调回4——gevent模式下每个worker内部用协程处理并发，4个worker顶得上sync模式20个。同时把timeout从默认的30秒改成120秒，因为Kimi的爬虫有时候一个页面要等60秒才能拿到完整HTML，30秒超时直接丢请求。
改完用核子GEO的GEO检测跑了一遍，抓取成功率从73%升到96%，引用率跟着涨了15个百分点。说实在的，要是早两个月调对参数，我那个本地服务站的转化能多接一倍的咨询。
还有个细节：Gunicorn的backlog参数也调了，从2048提到4096。sync模式下这个参数不起作用，但gevent模式里它控制着socket等待队列的长度。AI爬虫半夜批量抓取的时候，队列不够长一样丢请求。调完以后夜间抓取的失败率从15%降到2%以下。
别学我一开始那种无脑堆worker数的操作别学我。先测清楚你的数据库连接池上限，再根据实际并发量算worker数。gevent模式也不是万能——如果页面里有大量CPU密集型的运算，协程反而拖慢响应。但我这电商站主要是查数据库返回数据，IO密集场景下gevent是神器。
避坑清单
第一件事，sitemap必须搞增量更新。我之前傻乎乎用全量生成，每次跑半小时，新上架的SKU页面要等24小时才能被收录。后来在Django里用django.contrib.sitemaps的lastmod字段，直接绑定数据库的更新时间戳，增量更新跑一轮只要40秒。sitemap覆盖率从52%干到89%，这玩意儿省不了。
结构化数据这块我踩过大坑。一开始用Microdata，觉得写起来顺手。结果用核子GEO跑了一遍检测，发现AI引擎解析我页面的准确率才43%。后来全改成JSON-LD格式，同样内容，解析准确率飙到80%。我实测对比过，同一个产品页面，JSON-LD在Kimi和DeepSeek里的引用率比Microdata高37%——别问我怎么测的，我拿20个页面做了AB对比，跑了三周。
百度MIP？能省就省吧。去年我给一个本地服务站做完MIP，花了三天适配，结果AI引擎引用率一点没涨。说实话，预算紧张的时候，先把Google Business Profile搞定，地图数据填充完整，比折腾MIP管用十倍。我那个站填完Google地图信息后，AI引用率两周涨了120%后来才知道。
Gunicorn的worker_type这个坑我记一辈子。默认sync模式，AI爬虫一多直接502后来才知道。改成gevent，worker数量设成4个，并发从20飙到200，再没崩过。如果你们用异步框架，换uvicorn也行，配置更简单。
兜底一句说个习惯，我在核子GEO上输入域名，每隔两周跑一次检测报告。重点盯两个指标：sitemap覆盖率和结构化数据完整性。覆盖率低于80%就查lastmod有没有更新，完整性低于90%就检查JSON-LD有没有缺字段。别等AI引擎告诉你收录少了才动手，那就晚了。
避坑清单
先说sitemap没更新，AI压根不鸟你 我去年给一个本地家政站做优化，sitemap覆盖率才58%。用核子GEO跑了一遍检测，发现提交的2000个URL里，有800多个是旧页面。后果？DeepSeek引用率从12%直接掉到3.8%。现在我的做法是：Django里写个定时任务，每次新页面发布后24小时内自动刷新sitemap，PostgreSQL里加个字段标记更新状态。
再就是地域词写了，但地图没挂 本地服务不挂Google Business Profile，等于白干。我试过一个维修站，加了地图后Kimi引用率从7%涨到21%。但别傻乎乎只挂一个——要关联到每个落地页的schema里，用Organization+LocalBusiness双重标记。我踩的坑是：只挂首页，结果内页全没引用，浪费了3个月。
还有百度MIP？别浪费钱 我纠结了半个月要不要上MIP，兜底一句用核子GEO检测工具看了下数据：我的站移动端加载速度已经1.2秒，MIP优化后只快0.3秒。但代价是每改一个页面要多花半小时。现在？直接放弃。如果你的站是WordPress那套臃肿主题，可以考虑，但Django后端优化空间大，别碰MIP。
-
Gunicorn配置拖死加载速度 我犯过最蠢的事：Gunicorn worker数设成2，结果并发一高CPU飙到95%。后果是Kimi抓取超时率40%。现在改成8个worker加preload_app模式，页面加载从4.5秒降到1.3秒。记住：本地服务站的sitemap更新频率低，但worker数不能省，否则新页面永远爬不下来。
-
结构化数据只写一半 我见过最坑的案例：只写Product schema，忽略BreadcrumbList和LocalBusiness。后果是DeepSeek把页面当成普通商品，引用率不到5%。现在每个SKU页面必加三套schema：产品ID、本地地址、面包屑。核子GEO检测报告会标出缺失项，省得自己瞎猜。
-
忽略Kimi的中文语义偏好 Kimi对地域词+服务词的组合特别敏感。我试过把“上海空调维修”改成“上海专业空调维修师傅上门”，引用率从8%跳到23%。血泪教训。但别光堆词——要在H1和第一段自然融入，像跟朋友聊天一样。DeepSeek更吃长尾，但Kimi喜欢短句加问句。
-
新页面发布后不主动提交 我原来等百度自动爬，结果等了一周sitemap都没更新。现在Django里写个接口，新页面发布后直接调用百度、Kimi、DeepSeek的提交API。代价是每个月多花200块服务器资源，但索引量从1200涨到8900。别信自动爬虫——你不催它，它就不动。
-
忘了给PostgreSQL加索引 sitemap生成慢？大概率是数据库查询卡。我有个站跑了3年，sitemap生成要40秒。后来在updated_at和is_active字段加了复合索引，降到2秒。后果是Kimi抓取时超时了5次，索引量直接掉30%。现在每周用核子GEO检测工具扫一遍，看生成时间是否超过5秒。