电商sitemap怎么做？百万SKU的分片、进出场与lastmod诚实度实战

摘要：博客站的sitemap是一张薄薄的目录，电商站的sitemap是一座随时在塌方和重建的城市地图。几十万SKU、每天上架下架、一个商品裂成几十个变体URL、库存价格分钟级抖动——这些都不是博客会遇到的问题。这篇把电商sitemap当成一项工程来拆：先记死50000 URL／50MB／sitemap index三条硬红线，再讲清楚按内容类型分库、产品页的进出场、变体到底进不进、lastmod的诚实度、图片sitemap这条被忽略的购物通道，最后给一份能直接照着跑的体检清单。priority和changefreq这两个老古董，Google和Bing都明说忽略了，别再浪费时间填。

做内容站的人聊sitemap，三句话能聊完：装个插件、自动生成、提交到搜索后台，收工。做电商的人聊sitemap，能从产品架构吵到抓取预算，从库存系统吵到CDN缓存，最后发现没一个人能说清自己站里那几个sitemap文件到底装了什么、漏了什么。

差别不在sitemap这个格式本身，而在它要描述的东西。内容站的URL是相对稳定的——文章发出去就躺那儿了。电商站的URL是活的：今天上架2000个新品，明天清仓下架800个，后天某个爆款裂出40个颜色尺码变体，每个变体一个URL。你的sitemap如果还停留在装插件自动生成的水平，它要么在拼命告诉Google一堆早就404的死链，要么把真正该被收录的新品晾在外面没人管。

电商站的sitemap是另一个物种

先把规模感建立起来。一个中等独立站，光产品页就轻松过万；做铺货或多SKU品类（服装、3C配件、汽配）的，几十万URL是常态；平台级的，百万起步。这个量级下，sitemap不再是一个文件，而是一套需要分片、分库、调度更新的子系统。

更麻烦的是动态性。电商页面的状态在不停切换：有货→缺货→补货→永久下架。每一次切换都牵动sitemap该不该收录这条URL、该用什么lastmod、要不要配合301还是410。内容站一年改不了几次的东西，电商站一天要处理成千上万次。

还有变体爆炸。一件T恤5个颜色4个尺码，理论上20个组合，如果每个组合一个独立URL，单品就是20条。这种结构如果不加治理直接全塞进sitemap，等于主动把抓取预算往火坑里推。变体到底该合还是该拆，保哥在产品变体SEO那篇里讲透了，这里只谈它在sitemap层面的取舍。

所以电商sitemap的核心命题，从来不是“怎么生成一个sitemap”，而是“在一个URL不断生灭的系统里，怎么让搜索引擎拿到一份准确、新鲜、不浪费的地图”。

2026年了，sitemap到底还管不管用

每隔一阵就有人喊sitemap没用了、Google早就靠链接自己爬了。这话对一半。对小站确实如此——几百个页面，内链做好，Google闭着眼睛都能爬完，sitemap锦上添花而已。但对电商大站，sitemap是刚需，不是可选项。

原因很简单：大站一定有Google靠内链爬不到、或者爬得很慢的角落——深层分类下的长尾商品、刚上架还没被任何页面链接的新品、季节性下架又重新上架的SKU。这些页面如果不在sitemap里明确告诉搜索引擎“这条存在、这条刚更新”，它们可能几周都进不了索引。对电商来说，一个商品晚收录一周，就是一周的自然流量和销售凭空蒸发。

sitemap这个格式本身是一套开放协议。从 维基百科的Sitemaps词条能看到，它从2005年起就被Google、Bing、Yahoo等主流引擎共同支持，是搜索引擎抓取的通用语言——不是某一家的私货。而AI搜索时代，这套老协议反而更重要了。Bing在2025年7月那篇 AI搜索时代如何让内容保持可发现的官方博客里说得很直白：即便搜索在往AI驱动演进，sitemap依然是确保URL覆盖完整性的基础信号，和IndexNow这类实时推送互补。换句话说，AI概览也好、AI购物也好，模型要先能“看见”你的商品页，才谈得上把它们拉进答案里。

三条硬红线先刻进脑子

不管你用什么平台、什么生成方式，下面三个数字是协议级的死规矩，违反了搜索引擎直接不认或截断处理：

这两个50000不是我编的。sitemaps.org的协议规范写得明明白白：每个sitemap文件不得超过50000条URL、不得大于50MB（精确到字节是52428800），而sitemap index文件同样最多列50000个子sitemap。Google在构建并提交sitemap的官方文档里重申了完全一样的上限：所有格式都限制单个sitemap不超过50MB（未压缩）或50000条URL。

有意思的是上限之上还有上限。Google关于大型sitemap的官方指引提到，一个站点在Search Console里最多能提交500个sitemap index文件。算一下：500个index × 50000个子sitemap × 50000条URL，理论容量是天文数字，Bing那边干脆给了个具体说法——单个index支撑25亿URL，多index叠加可达2.5万亿。所以容量从来不是电商站的瓶颈，组织方式才是。

单文件装不下：sitemap index的正确分片姿势

一旦你的URL总数过了50000，就必须上sitemap index。这东西本质是一个“sitemap的sitemap”——它不直接列URL，而是列一堆子sitemap的地址，搜索引擎先读index，再逐个去读子文件。

分片有个容易踩的坑：目录层级。Google的sitemap index官方文档明确要求，被引用的子sitemap必须和index文件在同一目录或更深的目录，且必须托管在同一站点上。也就是说，如果你的index放在 /sitemap_index.xml，那它能引用的子文件得在根目录或子目录里，不能指到别的域名去（除非你专门配了跨站提交）。这个规矩很多人自建sitemap时栽过跟头：把图片sitemap扔到CDN域名上，结果index引用不生效。

分片的颗粒度怎么定？两条经验：

• 别贴着50000装满。留出余量，单个子sitemap控制在20000～40000条，方便增量更新时不至于一条新品就触顶重切。
• 按业务逻辑切，不要按生成顺序机械切。下面这一节专门讲——按内容类型分库，远比按“前5万条一个文件”有用。

按内容类型分库：产品、集合、博客、静态页各管各的

这是电商sitemap最关键、也最被低估的一招。与其把所有URL不分青红皂白塞进一串编号文件（sitemap-1、sitemap-2……），不如按内容类型拆成独立的子sitemap：

• sitemap-products.xml（或分片成products-1、products-2……）——所有商品详情页
• sitemap-collections.xml——集合页／分类页
• sitemap-pages.xml——关于我们、政策页等静态页
• sitemap-blog.xml——内容营销文章
• sitemap-images.xml——图片sitemap（后面单讲）

为什么值得这么折腾？因为Search Console的sitemap报告是按你提交的每个sitemap文件分别统计“已提交vs已收录”的。如果全混在一起，你只能看到一个笼统的收录率；分库之后，你能立刻看出“产品页收录率92%、集合页收录率只有40%”这种结构性问题，诊断一下子就精准了。先分桶，才能看清抓取资源到底花在了哪一类页面上。

主流平台其实早就这么干了。Shopify帮助中心查找并提交sitemap的页面写得很清楚，店铺会自动生成一个sitemap.xml主索引，下面挂着产品、集合、博客、网页各自独立的子sitemap，当某个子sitemap超过5000条URL时，会自动再裂出新的子文件来守住50000的上限。WordPress这边的Yoast、Rank Math同样是按内容类型（文章、页面、各种自定义类型）分组成一个index，并随你的增删改实时更新。

产品页的进出场：上架、下架、缺货怎么处理

这是电商sitemap区别于一切内容站的命门。商品有生命周期，sitemap必须跟着这个生命周期同步进出，否则就是在给搜索引擎喂假地图。

分四种状态说：

核心原则就一句：sitemap里只放你希望被收录的、返回200的活页面。一旦一个商品转成301或410，它必须在下一次sitemap更新时被剔除。如果你的sitemap还在列一堆301／410的URL，等于反复告诉Google“这条还在、快来爬”，浪费抓取预算不说，还显得整个站的地图不可信。

缺货是最容易拍脑袋的环节。很多人一缺货就把页面noindex或者直接404，这是大错。临时缺货的爆款，它积累的排名和外链是资产，补货后想再爬回来成本极高。正确做法是页面留着、保持200、保持在sitemap里，只在页面上诚实标注缺货并导流到替代品。永久下架才走301／410的决策树——这块的完整决策逻辑，保哥在Magento缺货下架SEO收尾那篇里按状态机画过流程图，可以配合着看。

变体URL到底进不进sitemap

回到变体爆炸的问题。一件商品几十个变体URL，进sitemap的原则取决于你的canonical策略：

• 变体共用一个canonical（指向主商品页）：只把那个canonical主URL放进sitemap，变体URL全部不进。这是绝大多数服装、配件类目的正解。
• 变体各自独立可索引（有独立搜索需求，比如不同容量的硬盘、不同型号的配件）：每个变体作为独立canonical进sitemap，但前提是它们内容差异足够大、不会互相蚕食。

判断标准很简单：去搜一下用户是不是会针对这个变体单独搜索。“iPhone手机壳”是商品级搜索，颜色不用各自开页；“512GB移动硬盘”是变体级搜索，容量值得独立。sitemap是canonical决策的下游——你不该在sitemap里塞一堆被canonical指走的非规范URL，Google官方一贯建议sitemap里放的应该是你认可的规范URL。变体和分面页的边界（变体是单商品多SKU、分面是分类页筛选）别搞混，分面那一类URL的治理完全是另一套打法，见分面导航SEO治理那篇——简单说，分面筛选产生的URL基本不该进sitemap。

lastmod的诚实度——电商站最爱作弊的地方

lastmod是sitemap里唯一真正影响抓取调度的标签，也是电商站最容易作弊、且作弊代价最高的地方。

先说它的本意。Google的官方说明讲得很清楚：lastmod应该反映页面最后一次“重大更新”的时间，而不是版权年份这种鸡毛蒜皮的改动；而且Google只在这个值“持续且可验证地准确”时才会采信它。Bing那边说法几乎一样，强调lastmod要反映页面内容的真实修改时间，而不是sitemap文件本身的生成时间，并建议用ISO 8601时间戳来帮搜索引擎优先抓取真正更新过的页面。格式这块，sitemap协议要求用W3C Datetime格式，年月日或带时分秒都行。

电商站的作弊有两种典型姿势，都是自毁长城：

• 每次重新生成sitemap就把所有lastmod刷成今天。很多自建脚本图省事这么干。后果是Google发现你“全站每天都在大更新”，但爬过来发现内容根本没动，几次之后直接判定你的lastmod不可信，整个站的lastmod信号全部作废——以后你真更新了它也不信。
• lastmod永远停在某个老日期不动。另一个极端，模板写死了从不更新。这样Google永远不知道你哪个商品改了价、换了描述、补了货，新鲜内容得不到优先抓取。

正确姿势是：lastmod跟着页面内容的实质变化走。商品改了标题、描述、主图、规格，更新lastmod；纯粹的库存数字抖动、价格小幅波动，可以不算重大更新（这个有争议，保守做法是价格变动也更新，毕竟价格是电商页的核心内容之一）。关键是“诚实”二字——你的lastmod要能被Google反复验证，它才会长期把它当回事。这和站内文章更新时间要带真实分秒、不能造假是同一个道理。

priority和changefreq：可以删掉的两个老古董

如果你的sitemap里还在认真填 <priority> 和 <changefreq>，可以停了。这两个标签是sitemap协议早期的设计，搜索引擎早就不看了。

Google在官方文档里明确写道：忽略priority和changefreq的值，这两个标签不会影响抓取或索引。Bing那篇博客里也是同样的话——changefreq和priority被Bing忽略，不影响内容如何被抓取或排名。连sitemap协议本身都把changefreq描述成“仅供参考的提示，不是命令”，priority也只是站内相对优先级、不影响跨站比较。

所以这两个字段的真实价值约等于零。留着不会扣分，但填它们花的时间，不如去把lastmod搞准。把工程精力放在真正有信号价值的地方，这是电商技术SEO的基本判断力。

图片sitemap：被忽略的购物流量通道

电商站有一类被严重低估的sitemap：图片sitemap。商品图是电商的核心资产，而Google图片、Google购物、AI购物答案都极度依赖图片信号。一张图能不能被Google发现、能不能进图片搜索结果，图片sitemap是一条直通车。

XML sitemap是可扩展的，Google官方文档里就提到sitemap支持图片、视频、新闻等扩展数据。图片sitemap的做法是在每个URL条目下用 <image:image> 标签列出该页面的关键图片地址。对电商，这意味着你可以把每个商品页的主图、细节图、场景图都明确告诉Google，而不是指望它自己从HTML里扒。

几个电商专属的注意点：

• 主图优先。一个商品几十张图，sitemap里突出主图和最具代表性的几张，不必把缩略图、UI图标都塞进去。
• 图片URL必须是可抓取的（别被robots.txt挡了，别要求登录）。
• 图片sitemap同样吃50000／50MB的上限，大站要分片。
• 图片改了（换了新主图）要更新对应页面的lastmod，让Google重新来取图。

这条通道做好了，等于在自然搜索和购物结果里多开了一个曝光面。很多电商把全部精力放在文字SEO上，图片sitemap一片空白，相当于守着金矿不挖。

视频sitemap：有就用，没有别硬凑

如果你的商品页有真实的产品视频（开箱、演示、3D展示），视频sitemap同样值得做。它用 <video:video> 扩展告诉Google视频的标题、缩略图、时长、播放地址，能帮你进视频搜索和富媒体结果。

但别为了做而做。如果你的“视频”只是个自动播放的banner动图，或者全站就三五个视频，那这条投入产出比很低，把图片sitemap做扎实更划算。视频sitemap是锦上添花，不是必选项。

sitemap和抓取预算的联动

大站绕不开抓取预算这个词。Google分配给你站的抓取资源是有限的，几十万URL的电商站，如果让爬虫把预算浪费在301链、参数URL、分面组合、早就死掉的旧品上，真正该被频繁抓取的新品和爆款就轮不上。

sitemap在这里扮演的是“调度建议书”的角色。一份干净、准确、lastmod诚实的sitemap，相当于告诉Google：“这些是我所有该收录的活页面，这些是最近真的更新过的，优先来这里。”反过来，一份塞满死链、lastmod全是今天的脏sitemap，会让Google对你的全站调度信号产生怀疑，抓取效率不升反降。

所以sitemap治理和抓取预算优化是一体两面。把分面URL挡在sitemap外、把死品及时剔除、把lastmod喂准，本质都是在帮Google把有限的抓取预算花在刀刃上。这套组合拳的全貌，抓取预算优化2026那篇里有12项实操，sitemap是其中绕不开的一环。

GSC sitemap报告：submitted vs indexed的诊断打法

提交完sitemap不是结束，是诊断的开始。Search Console的sitemap报告里，每个sitemap文件都有“已发现URL数”，再配合“网页索引编制”报告，你能算出每一类内容的收录率。这是电商技术SEO最值钱的一块仪表盘。

典型的诊断场景：

• 产品sitemap提交了5万、只收录了3万。那2万去哪了？大概率是重复内容、薄内容、被canonical指走、或者抓取预算不够。这时候分库的价值就出来了——你能精确定位是哪一批产品出了问题。
• 集合页收录率异常低。可能是集合页内容太薄（只有商品列表没有描述）、或者大量空集合页被收进了sitemap。
• 新品迟迟不收录。检查sitemap更新是否及时、lastmod是否正确、新品有没有内链支撑。

把submitted和indexed的缺口当成一个持续监控的指标，按内容类型分别看，比盯着全站一个笼统数字有用一百倍。这也是为什么前面反复强调要分库——不分库，这张仪表盘就是糊的。

动态生成还是静态缓存：百万级sitemap的工程实现

到了百万URL量级，sitemap怎么生成本身就是个工程问题。两种路线：

动态实时生成——每次爬虫来请求sitemap，服务器现查数据库现拼XML。好处是永远最新，坏处是大站每次生成都要扫几十万行数据，爬虫一频繁请求就能把数据库拖垮。这条路只适合中小站。

静态预生成 + 增量更新——定时任务（比如每小时或每次商品状态变化时）把sitemap生成成静态XML文件存好，爬虫来直接读文件。大站标配。关键是增量：别每次全量重生成几十万条，而是只更新发生变化的那个子sitemap分片。这就是前面强调“单个子sitemap别贴着50000装满”的原因——留余量才好做增量。

两个工程细节：

• 用gzip压缩。50MB是未压缩上限，但传输时可以gzip，大幅省带宽。Google支持读取 .xml.gz格式的sitemap。
• sitemap文件本身要能稳定访问。别放在会被CDN缓存到过期、或者偶尔500的路径上。爬虫几次拉不到sitemap，会降低对它的信任。

定时生成这类运维活，挂个cron就能自动化，不用人盯。具体怎么把sitemap生成、缓存清理、推送都交给定时任务，是另一个话题了，这里不展开。

平台现实：Shopify、WooCommerce、Magento的默认行为

大部分人不是从零写sitemap，而是在平台默认行为上做改造。三大平台的现状：

• Shopify：自动生成，按资源类型分子sitemap，超5000条自动再分片。优点是省心，缺点是几乎不给你控制权——你没法手动把某批URL排除出sitemap，也改不了分片逻辑。想精细控制只能靠app或在robots／canonical层面间接干预。
• WooCommerce（WordPress）：靠插件，Yoast或Rank Math都自动生成index + 分类型子sitemap，并自动排除noindex页面。Yoast的说明里讲到它会随内容增删改实时更新sitemap index和各子文件。可控性比Shopify高，能按内容类型开关。
• Magento：原生sitemap功能可配置度最高——能设分片大小、能控制图片是否包含、能调lastmod逻辑，适合大型复杂目录。代价是要自己懂得配，配错了一样出问题。

不管哪个平台，第一步都一样：去看一眼你站现在实际生成的sitemap到底长什么样。打开 yoursite.com/sitemap.xml，看它分了几个库、每个库多少条、lastmod是不是真的在动。八成你会发现一些意外——比如某批测试商品也在里面，或者下架了半年的品还赖着不走。

sitemap不是产品feed，别搞混

这是电商人最容易混淆的一对概念。XML sitemap和Google Merchant Center的产品feed是两个完全不同的东西，服务两套系统：

简单说：sitemap管的是“页面被不被收录”，feed管的是“商品在购物和AI选品里露不露脸”。两者都要做，互不替代。很多人以为提交了sitemap，Google购物就有数据了，这是误会——购物系统读的是feed，不读你的XML sitemap。产品feed该谁管、怎么管、在AI购物时代为什么是核心资产，是另一个独立的大话题，和sitemap配合着看才完整。

sitemap之外：IndexNow这条实时通道

sitemap是被动的——你挂在那儿，等爬虫来读。对上架速度敏感的电商，光等不够，得有主动推送。IndexNow就是这条实时通道：商品一上架或更新，你的服务器立刻ping一下IndexNow API，把这条URL推给Bing（以及接入了IndexNow的其他引擎），通常24小时内就会被抓取。

前面提到的Bing那篇官方博客把sitemap和IndexNow定位成互补关系：sitemap保证覆盖的完整性，IndexNow保证更新的实时性。对电商，这个组合特别合适——大盘靠sitemap兜底，新品和促销变价靠IndexNow抢时效。需要提醒的是，IndexNow主要服务Bing和Yandex一系，Google至今没正式接入，所以Google那边还是得靠sitemap + 内链 + 抓取预算这套老办法。

一份电商sitemap体检清单

把上面所有东西收成一张能直接照着跑的清单。拿你自己的站对照打钩：

• ☐ 打开 /sitemap.xml，确认是index结构，且按内容类型分了库（产品／集合／页面／博客／图片）
• ☐ 每个子sitemap的URL数都在50000以内，且留了余量（建议 ≤ 40000）
• ☐ sitemap里没有任何301／404／410的URL，全是返回200的活页面
• ☐ 缺货商品（会补货的）保留在sitemap里，没有被误删或noindex
• ☐ 永久下架商品已从sitemap移出，并配了301或410
• ☐ 变体URL的进出与canonical策略一致，没塞一堆非规范URL
• ☐ lastmod跟着内容实质变化走，不是每天全刷成今天，也不是写死不动
• ☐ priority和changefreq不再花精力维护（删不删随意，别投入）
• ☐ 有独立的图片sitemap，覆盖商品主图
• ☐ 大站用静态预生成 + 增量更新，且gzip压缩
• ☐ sitemap文件访问稳定（不被CDN缓存到过期、不偶发500）
• ☐ Search Console里按sitemap分别监控submitted vs indexed收录率
• ☐ 区分清楚sitemap和产品feed，两套都在维护
• ☐ 上架／更新接了IndexNow实时推送（至少覆盖Bing）

这张清单里能打满钩的电商站，凤毛麟角。多数站卡在第三条（sitemap里全是死链）和第七条（lastmod造假）上。把这两条先修好，收录率往往就能肉眼可见地往上走。sitemap不是炫技的地方，它是地基——地基歪了，上面盖再多内容营销和外链都是事倍功半。

常见问题解答

小电商站（几百个商品）也需要这么折腾sitemap吗？

不需要全套。几百个商品，单个sitemap文件就装得下，平台默认生成的基本够用。你要做的只有三件事：确认sitemap里没有死链、确认新品能及时进去、提交到Search Console。分库、分片、增量生成这些是为几万、几十万URL准备的，小站上这套属于过度工程。但lastmod诚实和死链清理这两条，无论站多小都该做。

下架的商品到底该从sitemap删掉，还是留着配301？

页面层面配301或410，但sitemap层面必须删掉。这是两回事：301／410是给那些已经收录了这条URL的爬虫和用户看的，告诉他们“这页搬走了／没了”；sitemap是你主动推荐去抓的清单，里面只该放活的200页面。一条URL一旦转成301／410，就立刻从sitemap移出，但301／410本身要在服务器层面长期保留。

商品价格或库存每天变，lastmod要不要跟着每天更新？

有争议，保守做法是更新。价格是电商页面的核心内容，价格变了算得上实质变化。但要警惕一种情况：如果你的库存数字每分钟都在抖、你也每分钟刷lastmod，那Google会觉得这页变化太频繁反而不可信。折中方案是把lastmod的更新粒度定在“每天最多更新一次”，反映当天有没有发生过实质变化，而不是分钟级跟着库存跳。

图片sitemap真的有用，还是又一个鸡肋功能？

对电商真有用，对内容站才鸡肋。电商的图片是商品本身，Google图片和购物结果带来的流量不容忽视，图片sitemap是让这些图被发现的明确信号。内容站的配图大多是装饰性的，做不做无所谓。判断标准就一条：你的图片本身是不是用户搜索和决策的对象——电商是，所以值得做。

提交了sitemap，为什么很多URL还是不被收录？

sitemap是“邀请”不是“命令”。它告诉Google这些页面存在、建议来抓，但收不收录是Google根据页面质量、重复度、抓取预算综合决定的。提交了不收录，八成是页面本身的问题：内容太薄、和别的页面重复、被canonical指走、或者整站抓取预算不够分给这些长尾页。这时候要去查“网页索引编制”报告里给出的具体原因，而不是反复重新提交sitemap——重新提交对收录率毫无帮助。

Shopify不让我控制sitemap，怎么排除不想被收录的页面？

Shopify的sitemap确实改不了，但你可以从别的层面间接控制。想让某类页面不被收录，用 noindex 元标签或在主题里加robots控制——被noindex的页面虽然还在sitemap里，但Google会尊重noindex不收录它。想更彻底的，用第三方sitemap管理app接管生成逻辑。但说实话，多数情况下你想排除的页面（比如购物车、账户页）Shopify默认就没放进sitemap，真要操心的反而是别让该收录的页面被误noindex了。

权威参考资料