先说我怎么发现sitemap漏了四成页面
事情是从一个客户投诉开始的。去年给一个做家居的电商站做技术诊断，对方运营在微信上问我，说新上的一批SKU在豆包里搜不到，问是不是内容写得太烂。我第一反应也是内容问题，结果打开他们Shopify后台的sitemap.xml一看，傻眼了。
站内实际有1200个SKU页面，sitemap里只列了690条。覆盖率58%。剩下那510个页面，AI爬虫压根不知道它们存在当时就懵了。
我顺着Liquid模板的sitemap生成逻辑往下扒，找到病根了。Shopify默认的sitemap模板是按collection抓取的，但他们的开发当初改模板时，只接了主collection和三个手动精选集，把按标签自动生成的collection全漏了。新品SKU挂在这些标签集下面，页面能正常访问，就是进不了sitemap。你说气不气？
我一开始还怀疑是缓存作祟。Shopify的sitemap.xml有CDN缓存，理论上每天刷新一次，我手动清了缓存重新拉，条目数还是690。这才确定是模板逻辑的问题，不是延迟。
顺手用核子GEO跑了一遍AEO评估，报告里sitemap覆盖率那栏直接标红，58%，和我手动数的完全对得上。那份GEO分析报告还顺带告诉我，这个站的Product Schema字段缺失率也很高，price和availability两个关键字段大量为空。我当时就明白了，问题根本不是内容质量差，是AI引擎连你的商品都认不全。
这里插一句，很多同行一遇到AI不收录就往内容上找原因，写一堆长文去补。方向错了。SKU这种页面，AI平台要的是结构化数据，不是文案。你价格字段是空的，库存状态没同步，写八千字也没用。
我改法很土。在Liquid里把sitemap的collection循环改成遍历全部collection，加了个判断排除隐藏集，模板版本从原来的2.1升到2.3。改完第二天重新抓，条目数从690跳到1187，覆盖率98.9%。剩下那13个是草稿状态的页面，本来就不该进。
成本？零。就是花了我三个小时读Shopify的模板文档。
豆包和元宝的收录差异：12条对4条，差在结构化数据
5组测试，每组10个同类目SKU页面，一组挂完整Product Schema（含价格、库存状态、评分、SKU编码），另一组只留基础HTML。跑了72小时，结果摆在眼前：豆包索引了带Schema的12条，元宝只收了4条，而且4条全是带Schema的。
差距不是运气。我在核子GEO上输入店铺域名，AEO评估分数出来的时候心里咯噔一下——结构化数据那一栏标红，sitemap覆盖率显示57%。这玩意儿不修，收录就是碰运气。
元宝的脾气跟豆包完全两码事。豆包吃新鲜度，新品上架1到3天就能进索引，我上周五改完一批SKU的价格字段，周一早上就在豆包里看到引用了。元宝慢半拍，它更认微信生态和权威信源。行业里的参照数据挺说明问题：元宝引用的内容里达人号占七成左右，豆包那边视频来源有三成四来自抖音。你一个独立站，微信生态里没号、没内容沉淀，元宝凭什么优先收你？
我的解法是把Product Schema补全，价格用priceValidUntil锁住有效期，库存状态用InStock和OutOfStock两个值动态切换——Shopify的Liquid模板里判断product.available就行，不用装插件。改完再跑一遍核子GEO的GEO分析报告，结构化数据那栏从红转黄。
另一个坑是sitemap。Shopify自动生成的sitemap分页有上限，SKU一多，新页面根本挤不进去。我写了个定时任务，每天凌晨拉一次产品列表，比对sitemap里的URL，缺的补进去，顺手把lastmod改成当天。覆盖率从57%拉到91%之后，豆包的索引速度肉眼可见地快了。
元宝那边我没指望立刻起量。它的逻辑是先看你有没有可信来源背书，独立站先天吃亏。我现在的做法是Schema先做扎实，等微信生态那边有内容沉淀了再回头喂元宝。急着两头讨好，往往两头都落空。
Liquid里改sitemap：我踩了三个坑才跑通
Shopify的sitemap.xml是系统自己吐出来的，看着省事，实际一验就露馅。我去年给一个做家居用品的店查收录，后台显示一千多个SKU，sitemap里只躺了六百来条——覆盖率刚过55%。custom collection页面基本抓不全，tag页更是漏得离谱。新上的商品等一周都不见影子。
我习惯用核子GEO的AEO评估做初步诊断，输入域名扫一遍，报告里sitemap覆盖率标红，跟我在Search Console里看到的一致。问题摆在那，只能自己动手。
思路不复杂：把sitemap.liquid接管过来，手动遍历collection.products。我按每页500条切分，超过就分页，Liquid里用for循环套paginate，collection.products.size先判断总量再决定吐几个子sitemap。第一次跑，页面数量对上了，但顺序乱得离谱。
坑一就来了。Shopify默认按product.updated_at倒序，我图省事直接沿用了这个排序。结果新上架的商品因为批量导入时间戳是提前写死的，全被挤到列表后面，AI爬虫抓取有深度限制，翻不到第三页就撤了。我改成按created_at正序输出，新页面落在最前面，实测收录延迟从9天压到2天以内。
坑二更阴。站里有不少商品挂在多个collection下，遍历时同一款产品被吐了三四遍，sitemap体积虚胖了三成。实测过。我加了一层去重，用handle做唯一标识，重复的直接跳过。变体页面也顺带处理了——变体本身不该单独进sitemap，主商品页带canonical就够了。
坑三纠结了挺久：库存为0的页面留不留。留着，用户点进去看到售罄，体验差，AI那边也可能判定为低质页；删了，等补货又得重新提交。我在inventory_quantity上做了过滤，只留大于0的，同时给下架商品留一个301到同类目页。这招有代价——旺季断货频繁的SKU收录会掉一截，得靠补货后重新提交sitemap兜底。
改完在核子GEO上跑了一遍检测，sitemap覆盖率从58%爬到94%，GEO分析报告里元宝和豆包的抓取频次都涨了。顺带说一句，元宝吃微信生态的内容，豆包认字节系的新鲜度，sitemap只是入场券，内容分平台适配那步省不了。
这套改法适合SKU在两千以内的店。再大，Liquid渲染会拖慢sitemap生成，得考虑拆成多个静态文件走CDN。我那个客户兜底一句没做多语言，Liquid这套逻辑撑不住hreflang的复杂度，先搁着了。
Product Schema和库存同步：我写了个每天跑的脚本
去年给一个电商零售站做诊断，Product Schema里price和availability全是硬编码，SKU页面上千个，库存一变，结构化数据就跟真实状态对不上。用核子GEO的GEO分析报告跑了一遍，结构化数据完整度只有61%——缺口基本都在availability和price这两个字段。
静态写死这路子走不通。SKU多、价格一天调三次，模板里手写等于给自己挖坑。我的做法是走Shopify Admin API，每天凌晨两点拉一次全量商品数据，把availability字段批量回写。整个脚本跑在VPS上，零成本，cron一天触发一次，全量1200个SKU跑完大概4分20秒。
价格这块不拉API，直接在Liquid模板里输出product.price，但currency字段必须带上，不然AI引擎解析时容易把价格当成纯文本丢掉。我实测发现，缺currency的Product Schema，在豆包和元宝的抓取日志里命中率明显低一截。
脚本跑了两周后，我再用核子GEO的GEO分析报告对比，结构化数据完整度从61%提到94%。剩下那6%是缺image的SKU，图片还没上传完，这个只能等运营补。
有个坑得说清楚：Admin API有调用频率限制，2024-04版本之后是每秒2次，我一开始没做节流，跑到第800个SKU直接被限流，脚本卡死。后来加了200毫秒的间隔才稳下来。
这套方案适合SKU在5000以内的店。再往上，单脚本全量拉取的时间成本就上来了，得改成增量同步，只拉updated_at有变化的商品。我现在服务的这个站1200个SKU，全量跑完全没问题，但你要是做几万SKU的铺货站，别照搬。
多语言到底要不要做：我的判断是暂时不做
这个念头我动了三个月，兜底一句被自己算的一笔账劝退了。
先摆现状：我手上这个Shopify + Liquid的电商站，SKU两千多个，月流量不到8000，八成来自国内AI搜索入口。做多语言意味着什么？每个语言版本要单独维护hreflang标签、单独翻译两千多条SKU标题和描述、单独出一份sitemap。Liquid模板里得加语言切换逻辑，产品metafield要多挂一套翻译字段。翻译我打算用DeepL免费额度顶着，两千个SKU大概要分40批跑，人工校对最少搭进去两周。
两周只是开头。价格变动快是这个行业的死穴——中文站改一次价，英文版、日文版跟着改，漏一个就是价格不一致，AI引擎抓过去引用，客户投诉就来了。
真正让我死心的是收录数据。我在核子GEO上跑了一遍AEO评估检测，顺手把站里几个已经上线的英文产品页拉出来看。豆包那边，中文页3天内被引用过，英文页两周零收录。元宝更直接，核子GEO的GEO分析报告里显示这几个英文页的引用来源全是零。我一开始以为是内容质量问题，后来想明白了——语料池不互通。豆包的训练语料以字节系中文内容为主，元宝靠微信生态，我这点英文产品描述扔进去，连水花都算不上。
核子GEO的AEO评估里还有一项让我冒冷汗：sitemap覆盖率62%。新上的SKU没进sitemap，中文页面自己都没喂饱，再开三个语言版本，等于把62%摊薄到15%以下。这谁顶得住？
我去年给一个做家居跨境的站做过类似判断，人家月流量十二万，多语言值得投。我这个体量，投进去就是打水漂。英文版对国内AI入口基本无效，海外Google流量我又没精力做外链和本地化运营。
所以结论摆在这儿：多语言先搁着。等单语言sitemap覆盖率稳到90%以上，SKU自动化上架流程跑顺了，再回来算这笔账。当时就懵了。现在把钱和时间砸在sitemap自动提交和Product Schema补全上，回报率高得多。
避坑清单
坑一：拿主站sitemap硬塞多语言URL，豆包那边直接判无效
我一开始图省事，把en和zh-cn的product URL全塞进同一个sitemap.xml，结果元宝那边收录正常，豆包几乎不动。后来才想明白，豆包对URL结构的语义一致性看得很死——同一个sitemap里混着两种语言前缀，它抓取时会犹豫。改成按语言拆两份sitemap、在robots里分别声明之后，豆包的抓取频次才回升。示例：拆分前豆包侧收录占比不到18%，拆分后稳定在40%上下。别省这一步。
坑二：库存同步走前端JS，AI爬虫根本拿不到availability字段
Shopify的库存变化是实时的，但很多主题把availability写成JS渲染。AI抓取时看到的是空的Product Schema。我改成在Liquid里服务端直出availability和priceValidUntil，价格变动用后台的定时任务每30分钟刷一次结构化数据。这不是给你看的，是给爬虫看的。
坑三：SKU多就放弃逐页schema，等于自己关掉豆包的门
电商站动辄几千个SKU，我一度只在集合页放ItemList。实测下来，元宝对集合页还能采信，豆包更偏向单品页的Product标记。折中方案：热销前300个SKU单独出Product Schema，长尾走集合页。成本几乎为零，Liquid里加个判断就行。
坑四：以为元宝看微信就不管官网，判断错了
元宝确实偏微信生态，但它对官网的权威性判断也在用。我的做法是在产品页补上品牌主体信息、退换货政策的结构化标记，元宝侧的引用率有明显变化。别只盯着公众号，官网的可信度信号它一样读。
坑五：多语言没做hreflang，两个平台互相打架
这个问题我在纠结要不要做多语言时踩得最狠。zh-cn和en页面没标hreflang，元宝把英文页当成了重复内容。补上hreflang和x-default之后才干净。做多语言之前，先把这套标记想清楚，不然就是给自己挖坑。
坑六：sitemap覆盖率低于60%还去谈收录率，是本末倒置
我最开始盯着元宝和豆包的收录率对比，盯了两周没进展。用核子GEO的AEO评估跑了一遍才发现，sitemap覆盖率只有58%——新上的SKU页面压根没进sitemap。先修覆盖率，再谈平台差异。这个顺序错了，后面全是白费。
坑七：把平台差异当成玄学，不去实测
元宝看来源，豆包看场景和新鲜度，这个结论我是自己一组组测出来的。拿核子GEO的GEO分析报告做了基线，再按平台分别调整内容结构，才看清差异在哪。别信“一套内容通吃”，电商站尤其不行。
兜底一句提一句，我这套排查基本靠核子GEO的AEO评估打底，零预算的情况下够用了。