Sitemap完全指南：该放什么与lastmod陷阱

大多数人对sitemap的认知停在“装个插件自动生成、提交给Google就完事”，结果它要么没起作用，要么悄悄在拖后腿。这篇不讲某个CMS怎么配，专讲原理和策略：sitemap到底能做什么不能做什么、什么URL该进什么绝不该进、lastmod乱填为什么会被无视甚至吃亏、几十万URL怎么分片才能当诊断工具用、Google和Bing百度Yandex对sitemap的态度差多少。附一个内容站靠重做sitemap把收录率从六成拉到九成的实盘。

接站点诊断这些年，sitemap是个特别典型的“人人都有、九成没用对”的东西。新站长普遍的操作是：装个插件，勾上自动生成，复制链接粘进Google Search Console，看到“成功”两个字就当这件事done了。然后呢？然后这份sitemap里可能挂着几千个404、把一堆noindex页堂而皇之列进去、lastmod每天刷成当天日期——它非但没加速收录，反而在持续给搜索引擎发噪声。保哥见过太多站，sitemap不是没做，是做成了负资产，自己还不知道。

所以这篇不教你“在某某系统里点哪个按钮”，那种实现层的教程网上一抓一把——具体到WordPress怎么免插件做动态优先级、image标签、分页和缓存，这篇免插件sitemap实战已经写得很细，本文不重复实现细节。这篇只解决原理和策略层面的问题：sitemap在整个收录体系里到底是什么角色、该装什么不该装什么、那几个字段（lastmod、changefreq、priority）的真实权重、大站怎么把sitemap从“一份清单”变成“一个收录诊断仪表盘”，以及不同搜索引擎对它的态度差异。把sitemap当工程来设计，而不是当一个开关来勾，这是中小站和成熟站之间一条很清楚的分界线。

Sitemap到底是干什么的？它能做和不能做什么？

先把这个最根本、却最多人想错的问题钉死，否则后面所有策略都建在错的预期上。

sitemap是“发现加速器”，不是“收录保证书”

sitemap的唯一核心作用是帮搜索引擎更快、更全地"发现"你的URL，它不保证收录，更不影响排名。这句话要刻进脑子。提交sitemap≠会被收录，sitemap里有的URL，照样可能因为内容太薄、重复、质量不够而被“已发现未编入索引”。我遇到过太多人，sitemap提交了一个月，页面没收录，跑来问“是不是sitemap没生效”——sitemap生效了，它只负责把URL递到门口，进不进门是内容质量和站点权重那一关的事。这套“发现”和“收录”是两段独立关卡的逻辑，和搜索引擎抓取索引排名三段流水线里“抓到≠收录≠排名”是完全一致的，sitemap只作用在最前面那一小段。

没有sitemap就不会被收录吗？

不是。一个内链结构健康、页面之间互相链接得当的中小站，爬虫顺着链接就能发现绝大多数页面，没有sitemap照样收录。sitemap真正不可替代的价值场景是这几类：页面多到内链覆盖不全的大站；新站外链少、爬虫被动发现慢；存在内链到不了的“孤儿页”；以及内容更新频繁、希望新页被更快发现的资讯站。所以“要不要认真做sitemap”的答案不是一刀切的“都要”，而是看你属不属于这几类——属于，它是刚需；不属于，它锦上添花，别在它身上花过多精力而忽略内链。把sitemap当成万能药是另一种常见误区。

什么页面该进sitemap，什么绝对不该进？

这是sitemap从“无害”变“有害”的分水岭。一份合格的sitemap不是“全站URL大全”，是“我希望被收录、且确实够格被收录的规范URL清单”。

只放“规范、可索引、想被收录”的URL

进sitemap的URL要同时满足几个硬条件：返回200（不是301也不是404）；是自引用canonical（即它自己就是规范版，不是被canonical指向别处的副本）；没有被noindex；没有被robots.txt的Disallow拦住；并且是你真心希望出现在搜索结果里的页面。把这几条做成一个准入清单，生成sitemap时逐条过滤，比生成完再回头清理省事得多。

把noindex、被canonical指向别处、参数页放进sitemap的代价

很多人觉得“多放点没关系，引擎自己会判断”。错。sitemap里混进noindex页、被canonical指走的副本页、筛选排序参数页，等于你一边用sitemap喊"这些重要快来抓"，一边用noindex/canonical喊"别收这个"——给引擎发互相矛盾的信号。后果有两层：一是浪费抓取预算在你自己都不想收的页上，大站尤其肉疼；二是Google会下调对你整份sitemap的信任度，认为这份清单不靠谱，进而连带影响它对里面好URL的处理优先级。一份“脏”sitemap的危害不是中性的零，是负的。

大站把sitemap当"收录诊断工具"用

这是大站才玩得起、也最该玩的高阶用法，多数人完全没意识到。把不同业务类型的URL拆进不同的sitemap文件（比如商品页一份、分类页一份、文章页一份），提交后在GSC的sitemap报告里能分别看到每一份的“已提交与实际收录”的比例。这等于给你一个按业务维度切开的收录覆盖率仪表盘——哪类页收录差一目了然，根本不用瞎猜。商品sitemap收录率90%、文章sitemap只有55%，问题立刻定位到文章这一类，再去查是不是内容薄或模板雷同。sitemap在大站手里的最高价值不是“帮发现”，是“帮你看清哪里没被收录”。

举个具体的读法，让你知道这个仪表盘怎么用。某站把URL拆成“核心产品”“资讯文章”“用户生成内容（UGC）”三片，GSC里读出来的收录率分别是约92%、约70%、约38%。这三个数立刻给出三个完全不同的结论：核心产品片健康，不用管；资讯片七成说明有三成内容卡在“已发现未编入索引”，去抽查多半是薄文或主题重复；UGC片只有不到四成，但这未必是坏事——UGC本来就有大量低质，关键要判断“这38%里有没有该收的优质UGC也没进去”，如果优质UGC也收不进，说明可能是模板或内链问题，如果没进的基本都是垃圾贴，那这个低收录率反而是正常的。同一份sitemap报告，三片三种读法、三种动作——这才是把sitemap当工程用，而不是当一个勾选框。

图片、视频、hreflang要不要单独做sitemap？

这是进阶但很值钱的一问，多数指南略过不讲。结论分场景。图片/视频sitemap（在URL条目里加图片或视频扩展字段）对“内容本身就是图片或视频、且这些媒体是流量来源”的站才有意义——图库站、视频站、商品图是核心的电商站，给图片sitemap能帮Google更好地发现并在图片/视频搜索里收录；普通博客配图根本不需要，加了纯增重。判断标准很简单：你有没有真的在做图片搜索或视频搜索的流量？没有就别碰，这不是“做了更好”的项，是“不相关就别加”的项。

hreflang sitemap则是另一回事，它解决的是多语言/多地区站的“同一内容不同语言版本怎么对应”问题。如果你站点有中英多语言或分国家站点，把hreflang关系写进sitemap是比在每个页面头部塞一堆hreflang标签更易维护、更不易出错的做法（页面级hreflang一旦某个语言版本URL变了，全站标签都要改，sitemap集中管理改一处即可）。但前提是你确实有多语言对应关系要声明——单语言站完全用不上，别为了“功能完整”硬上。一个反复出现的认知偏差是把sitemap的高级特性当成“越多越好”，其实每一种sitemap变体都只服务一类特定需求，不相关的全是负重。

lastmod到底该怎么填？为什么乱填会被无视甚至吃亏？

lastmod是整个sitemap里最被滥用、也最被误解的一个字段。它本意是告诉引擎“这个页最后实质修改时间”，引擎据此判断要不要重抓。问题是绝大多数站把它用废了。

lastmod的真实作用与被整体无视的条件

Google公开说过：因为太多网站的lastmod不可信，它对很多站点的lastmod是整体打折甚至忽略的，只有当它发现你的lastmod长期诚实可信，才会真的拿它当重抓信号。所以lastmod的价值是建立在"信用"上的——你要么诚实地填（页面有实质内容变更才更新它），让它逐渐积累信用变成有效信号；要么干脆别乱填，别让它变成噪声。填一个会被无视的lastmod没意义，填一个不诚实的lastmod有害。

全站lastmod每天刷成当前时间，是一场灾难

这是我见过最高频、危害最大的sitemap错误，很多自动生成方案默认就这么干。每天把全站每个URL的lastmod都刷成“今天”，等于天天对引擎喊“我全站每一页昨天都改了”。Google大概率直接判定你这份lastmod不可信、全盘忽略，你白做。而Bing对lastmod比Google认真得多——给Bing喂不实的高频lastmod，更容易被判为操纵抓取、降低对你sitemap的信任，这点Google相对宽容、Bing不会。这是个跨引擎差异的冷知识：同一个坏习惯，在Google那里是“无效”，在Bing那里可能是“扣分”。要么让lastmod真实反映内容变更，要么在你控制不了生成逻辑时索性不输出这个字段，都比天天刷新强。

changefreq和priority这两个字段还要不要写？

结论很干脆：Google基本忽略changefreq和priority，写了无害，但别指望它们影响抓取或排名，更别花时间精雕。它们是sitemap协议的历史遗留，早年有点用，现在Google官方明确说不依赖它们做抓取调度。把精力从"给每个URL算priority"挪到"保证sitemap里的URL都规范、lastmod诚实"上，回报率高一个数量级。纠结priority填0.8还是0.6，是典型的把力气花在没用的地方。

几十万URL的sitemap怎么分片才高效？

规模一上来，sitemap就不是一个文件的事了，分片策略直接决定它好不好用。

单文件上限与sitemapindex

硬规则先记住：单个sitemap文件最多5万个URL，且未压缩不超过50MB，超了就必须拆成多个文件，再用一个sitemapindex（sitemap索引文件）把它们汇总，提交那个index即可。这是协议层的限制，不是建议，超限的文件引擎会直接拒绝或只读一部分。

按"业务/更新频率/索引价值"分片，不要随机切

关键不在“拆”，在“按什么维度拆”。最差的做法是按URL顺序随机切成等份——这样切完每一片都是大杂烩，GSC里看每片的收录率没有任何诊断意义。正确做法是按业务类型、更新频率或索引价值分片：商品/文章/分类各自成片，高频更新的和常青的分开，核心页和长尾页分开。这样切完，每一片在GSC里的收录率就变成了一个有意义的指标，你能直接读出“哪一类页面收录有问题”，分片本身就成了诊断结构。同样是拆成20份，随机拆是体力活，按维度拆是诊断仪表盘，成本一样，价值差十倍。

sitemap多久重新生成一次？新页多久进得去？

这是运营每天都会碰、却很少有人答到点子上的问题。先纠正一个预期：sitemap里出现了新URL，不等于这个URL马上会被抓、更不等于马上被收录——sitemap只是把它列进了“待发现清单”，引擎什么时候来读这份清单、读完什么时候来抓那个URL，取决于站点权重和抓取需求，从几小时到几周都可能。所以指望“发布后立刻塞进sitemap就能秒收”本身就是错的预期。

更新频率的正确做法和站点类型挂钩：高频更新的资讯/电商站，sitemap应该跟着内容发布节奏走——新内容发布后尽快（理想是触发式，发布即重新生成对应分片），让引擎下次来读时就能看到；低频的企业站、文档站，按天或按周定时生成完全够用。没必要为了“实时”把生成频率拉到每分钟，引擎也不是每分钟来读你的sitemap。真正要追求“发布即被发现”的场景，靠的不是把sitemap刷得勤，是主动推送（Google的Indexing API有适用范围限制，Bing用IndexNow，百度用推送API）——sitemap负责“全量兜底”，主动推送负责“新页提速”，两者分工，别让sitemap去干它干不快的活。新页迟迟不进，先别怀疑sitemap刷新够不够勤，多半是页面本身没过收录那一关，或者内链根本没给它入口。

sitemap放哪、robots要不要声明、要不要GSC提交

三件配套动作：sitemap（或sitemapindex）放在站点可访问的稳定路径；在robots.txt里用Sitemap指令声明它的完整地址，这样所有支持的引擎（不只是Google）都能自动发现；同时在GSC、Bing站长工具里手动提交一次，拿到那两个平台的收录诊断报告。三者不是三选一，是叠加——robots声明负责广覆盖，站长工具提交负责拿诊断数据。漏掉robots声明，等于只告诉了Google，Bing和其他引擎还得靠自己撞见。

Google、Bing、百度、Yandex对sitemap的对待一样吗？

很不一样，拿一套sitemap策略通吃所有引擎是国内做多引擎站最常见的想当然。

Google：发现辅助，不依赖changefreq和priority

Google把sitemap当发现辅助，认真对待lastmod（前提是你诚实），明确忽略changefreq和priority，对脏sitemap会降信任。它的渲染和内链发现能力强，所以对内链健康的中小站，sitemap是补充而非命脉。

Bing：对lastmod更认真，IndexNow是更优解

Bing对sitemap和lastmod比Google更当真，也因此对不实lastmod更敏感。但对Bing来说，比sitemap更高效的是IndexNow——内容一发布或更新就主动推送URL，几乎实时，比等它来读sitemap快得多。做Bing流量的站，重心应该放在IndexNow主动推送上，sitemap作兜底。

百度：sitemap偏弱，主动推送才是主力

百度对sitemap的响应一向偏慢偏弱，国内站只靠sitemap等百度来抓，新页收录会慢到让你怀疑人生。百度生态里真正有效的是主动推送（API实时推送），sitemap只能算补充。这套“百度必须主动推、不能被动等”的逻辑，百度主动推送实战那篇拆得很细，做国内流量的话那个的优先级高于打磨sitemap。

Yandex：相对更看重sitemap规范性

做俄语市场或Yandex流量的话，Yandex对sitemap的规范性（格式严谨、URL干净、lastmod合理）相对更看重，它通过Yandex Webmaster提交。多引擎站的正确姿势是：一份干净规范的sitemap作为所有引擎的公约数，再针对Bing叠IndexNow、针对百度叠主动推送，而不是指望一份sitemap解决所有引擎的发现问题。

把四家的差异压成一张对照表，做多引擎站时贴在手边：

sitemap常见的几个坑，哪个最隐蔽？

把高频踩坑按隐蔽程度排一下，越靠后越容易被忽略、危害越久。

sitemap里挂着大量已404或301或noindex的URL

最常见。站点改版、删内容、调结构后，自动生成逻辑没跟上，sitemap里堆着一批死URL或已不想收录的URL。引擎反复来抓这些，浪费预算，也拉低对整份sitemap的信任。定期用爬虫拉一遍sitemap里所有URL的状态码，非200和被noindex的清掉，是个该排进运维周期的常规动作，不是一次性的。

sitemap和canonical或robots互相打架

比上一个隐蔽。URL在sitemap里（喊"收我"），同时被canonical指向另一个URL或被robots Disallow（喊"别收"）——信号自相矛盾。这种不会报错，页面也"看起来正常"，但引擎在反复纠结中浪费抓取、降低信任，你从表面完全看不出来，只能靠交叉核对sitemap清单与canonical/robots规则才能揪出。

动态生成的sitemap超时或返回非200

最隐蔽、危害最彻底。大站sitemap常是脚本动态生成的，URL一多，生成时数据库查询慢，引擎来拉的时候超时、返回500或干脆拉不动。关键后果是：引擎拉不动你的sitemap，会直接放弃整份，不是少读几个URL，是这份sitemap白做。而你在GSC里可能只看到一个不起眼的“无法读取”，很容易被忽略好几个月。动态生成的sitemap必须做缓存（生成好的静态化、定时刷新），别让引擎每次来都触发实时全量查询。这个坑不报错、不掉排名、悄无声息，等你发现新页一直收录慢去查，才发现命脉早断了。

实盘：一个内容站靠重做sitemap把收录率从六成拉到九成

把上面的原理落到一个真实项目。客户是国内一个垂直行业内容站（约8万篇文章，2020年，自建系统，sitemap是建站时写的一个动态脚本，团队没有专职技术SEO），症状是：持续产出内容，但自然流量增长远低于内容增长，大量新文长期搜不到。

诊断：一份sitemap把所有问题盖住了

问题用GSC加爬虫一交叉就清楚了。他们全站8万URL塞在一份巨大的动态sitemap里：第一，这份sitemap经常拉取超时（URL太多、实时查库），GSC里间歇性“无法读取”，等于很多时候整份失效；第二，里面混着大量已删文章的404和一批专题noindex页；第三，lastmod每次生成都是当前时间，全站统一刷新。GSC里能收录率大致估出来只有六成上下，而且因为全站一份，根本看不出是哪类内容没被收录。

动作：拆片、清洗、lastmod诚实化、静态化

动作全部围绕原理，没碰内容本身：一、按内容业务把sitemap拆成多份（按频道/内容类型分片）并用sitemapindex汇总，让GSC能按片读出每类收录率；二、生成前加准入过滤，只放200、自引用canonical、非noindex的URL，死URL和noindex页一律不进；三、lastmod改成读取文章真实最后修改时间，没改过的文章就保持旧时间，不再全站刷新；四、把动态生成改成定时任务生成静态文件、引擎来拉直接给静态文件，彻底解决超时。robots里补上Sitemap声明，GSC和Bing都重新提交。

结果与适用边界

分片后第一次看GSC就定位到“资讯类那一片收录率特别低”，顺藤摸瓜发现那批是早期模板生成的薄文——这是重做sitemap额外送的诊断红利。整体上，sitemap稳定可读、死URL清掉、lastmod开始积累信用之后，大约一个多季度，整站收录率从估算的六成上下提升到九成上下，新文被发现的速度明显加快。但必须说清边界：sitemap工程能解决的是"该被发现的页没被高效发现、该看清的收录问题看不清"，它解决不了"页面本身不够格被收录"。那批薄文最后还是靠重写内容才收进去的，sitemap只负责让它们被发现、并让你看清它们没被收录——发现之后能不能留下，是内容质量那一关的事，sitemap不背这个锅，也别指望它背。

这个项目还有个值得单独说的收尾经验：他们一开始急着想知道“多久能见效”，盯着收录率天天刷。我的建议是按双周看，别按天——sitemap这类基础设施类改动，引擎重新建立信任、把死URL从认知里清掉、让诚实lastmod积累出权重，都是以周为单位的过程，第一周往往看不出动静，甚至因为引擎重新评估出现短暂波动，这和改title后的波动期是同一类机制。基础设施改动要给它“按周生效”的耐心，用日数据去判断一个周级别的过程，只会让你在第三天做出错误的回滚。这条对所有“改完不会立刻见效”的技术SEO动作都成立，不只sitemap。

常见问题解答

提交了sitemap为什么页面还是没被收录？

因为sitemap只负责帮引擎发现URL，不保证收录。页面被发现后还要过质量、重复、权重那几关，内容太薄或重复照样“已发现未编入索引”。sitemap生效了，进不进索引是内容和站点权重的事，不是再提交一次能解决的。

小网站有必要做sitemap吗？

内链健康的小站，爬虫顺链接就能发现绝大多数页面，sitemap是锦上添花不是刚需。真正离不开它的是页面多到内链覆盖不全的大站、外链少的新站、有孤儿页或更新频繁的站。属于这几类才值得在它身上认真投入。

sitemap里能不能放noindex或被canonical指走的页面？

绝对不要。那等于一边喊“收我”一边喊“别收”，给引擎矛盾信号，既浪费抓取预算又降低引擎对整份sitemap的信任。只放返回200、自引用canonical、非noindex、确实想被收录的规范URL。

lastmod要不要每天更新？

不要全站刷新成当前时间。Google会因此判你的lastmod不可信而整体忽略，Bing对不实lastmod更敏感甚至降信任。lastmod要诚实反映内容实质变更，没改的页就保持旧时间，控制不了生成逻辑时宁可不输出这个字段。

changefreq和priority还有用吗？

Google基本忽略这两个字段，写了无害但不影响抓取和排名，别花时间精雕。把精力放在保证sitemap里URL都规范、lastmod诚实上，回报率高得多。纠结priority填多少是典型的力气用错地方。

几十万URL的sitemap该怎么拆？

单文件上限5万URL或50MB，超了用sitemapindex汇总。关键是按业务类型、更新频率或索引价值分片，不要随机等分。按维度分片后，GSC里每片的收录率就成了按类别的诊断仪表盘，能直接读出哪类页收录有问题。

各搜索引擎对sitemap的态度一样吗？

不一样。Google当发现辅助、忽略changefreq/priority；Bing对lastmod更认真、但IndexNow主动推送更优；百度sitemap弱、必须靠主动推送；Yandex相对看重规范性。正确做法是一份干净sitemap做公约数，再按引擎叠加推送策略。

动态生成的sitemap有什么风险？

URL一多容易生成超时或返回非200，引擎拉不动会直接放弃整份sitemap，不是少读几个URL，而是全份白做，且GSC里只显示不起眼的“无法读取”，极易被忽略数月。必须改成定时静态化生成，别让引擎每次来都触发实时全量查询。