本文是一份面向实际网站运维和 SEO 基础建设的 sitemap 指南。重点不是只给出 XML 模板，而是讲清楚它的作用、限制、文件拆分方式、更新策略，以及如何和 robots.txt、canonical、站点迁移配合。
适用场景
- 帮助搜索引擎发现站点页面
- 为大站点拆分多个 sitemap 文件
- 给图片、视频、新闻等内容提供额外元数据
- 配合 robots.txt 提供站点地图入口
- 用于站点发布、迁移和定期更新
Sitemap 是什么
Sitemap 是一个 XML 文件，里面列出站点中的 URL，并可附带一些辅助信息，例如：
- lastmod：最后修改时间
- changefreq：更新频率提示
- priority：相对优先级提示
它的作用是告诉搜索引擎：
- 站点上有哪些重要页面
- 哪些内容最近发生了变化
- 搜索引擎更值得先抓取哪些内容
但它只是“提示”，不是命令。
核心结论
如果你只记住一条：
- Sitemap 不是保证收录的工具，而是帮助搜索引擎更高效发现页面的工具
因此：
- 不能把它当作强制索引入口
- 不能把低质量页面全部塞进去指望排名提升
- 不能让不同版本域名混写到同一份 sitemap 里
基本规范
Sitemap 协议的核心要求包括：
- 文件必须是 UTF-8 编码
- XML 根节点必须是 <urlset>
- 每个 URL 用 <url> 包裹
- 每个 <url> 必须至少包含 <loc>
- 所有 URL 应属于同一个主机名
最小可用模板
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.example.com/</loc>
<lastmod>2026-05-21</lastmod>
</url>
<url>
<loc>https://www.example.com/about</loc>
<lastmod>2026-05-20</lastmod>
</url>
</urlset>这个模板已经足以满足很多普通站点的起步需求。
常用标签说明
loc
必须项，表示页面 URL。
要求：
- 必须是绝对地址
- 必须带协议，例如 https://
- 应与站点主域名保持一致
lastmod
表示页面最后修改时间。
建议：
- 使用真实更新时间
- 使用 W3C Datetime 格式
- 不要把生成 sitemap 的时间当成最后修改时间
changefreq
页面可能变化的频率提示。
可取值包括：
- always
- hourly
- daily
- weekly
- monthly
- yearly
- never
注意：
- 它只是建议，不是命令
- 很多搜索引擎会弱化它的实际权重
priority
表示站内页面的相对优先级，范围通常是 0.0 到 1.0。
注意：
- 它只在站内比较时有意义
- 不会让你的网站比别的网站更容易排名
- 如果所有页面都写成高优先级，就失去区分意义
Sitemap 文件位置
Sitemap 可以放在站点任意目录，但最常见的是直接通过以下地址暴露：
/sitemap.xml建议：
- 主站优先提供 /sitemap.xml
- 如果有多个拆分文件，用 sitemap index 统一入口
- 在 robots.txt 中声明 sitemap 地址
文件大小与数量限制
根据协议和 Google 的最佳实践：
- 单个 sitemap 文件最多 50,000 个 URL
- 单个 sitemap 文件未压缩大小最多 50MB
如果超出限制，应：
- 拆分为多个 sitemap 文件
- 用 sitemap index 文件统一管理
Sitemap Index
当站点页面很多时，推荐使用 sitemap index。
示例：
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://www.example.com/sitemaps/sitemap-1.xml</loc>
<lastmod>2026-05-21</lastmod>
</sitemap>
<sitemap>
<loc>https://www.example.com/sitemaps/sitemap-2.xml</loc>
<lastmod>2026-05-21</lastmod>
</sitemap>
</sitemapindex>适用场景：
- 内容量很大
- 你要按栏目拆分
- 你要区分文章、商品、图片、视频
- 你需要增量更新
站点分类建议
如果你的站点比较大，建议按类型拆分：
- sitemap-pages.xml
- sitemap-articles.xml
- sitemap-products.xml
- sitemap-images.xml
- sitemap-videos.xml
这样做的好处：
- 便于定位问题
- 便于单独监控某类内容
- 便于分批更新
生成规则
一个好用的 sitemap 应该只包含“值得被搜索引擎看到”的 URL。
建议收录：
- 首页
- 栏目页
- 文章详情页
- 产品详情页
- 公开静态落地页
通常不收录：
- 登录页
- 后台页
- 搜索结果页
- 带临时参数的 URL
- 测试环境页面
与 canonical 的关系
Sitemap 中的 URL 应该与页面规范化地址一致。
也就是说：
- 页面 <link rel="canonical"> 指向哪里
- sitemap 里就应该写哪一个版本
- 不要 www 和非 www 混着写
与 robots.txt 的关系
建议在 robots.txt 中声明 sitemap：
Sitemap: https://www.example.com/sitemap.xml这样爬虫更容易发现它。
同时要注意：
- robots.txt 屏蔽的页面一般不应出现在 sitemap 里
- sitemap 只列出你愿意被抓取和索引的公开页面
与站点迁移的关系
迁移域名或更换主域名时，sitemap 也要同步调整。
建议迁移动作包括：
- 统一 canonical
- 统一 sitemap 中的 URL
- 更新 robots.txt 中的 sitemap 地址
- 保证旧域名 301 到新域名
如果只改了站点跳转，却没改 sitemap，搜索引擎会收到冲突信号。
更新策略
1. 实时更新
适合小站或 CMS 驱动站点，每次内容发布后立即生成 sitemap。
2. 定时更新
适合中大型站点，按小时或按天重新生成。
3. 增量更新
适合大站点，按内容变更部分更新对应分片 sitemap。
4. 只更新 lastmod
适合内容变化明显但 URL 结构稳定的站点。
Sitemap 对 SEO 的实际价值
Sitemap 的主要价值是：
- 帮助发现新页面
- 帮助发现深层页面
- 帮助内容更新更快被感知
- 帮助大站点更清晰地组织抓取入口
它不是：
- 排名加速器
- 作弊工具
- 低质量页面的遮羞布
常见错误
1. 混入不同主机名
协议要求 sitemap 中的 URL 应属于同一个主机名。不要把 example.com 和 www.example.com 混写在同一份文件里。
2. 放入不可访问 URL
如果 URL 本身会 404、需要登录、或者会跳转到别处，就不应该放进 sitemap。
3. 只生成不更新
内容变了，sitemap 也要同步变。旧的 lastmod 会误导搜索引擎。
4. lastmod 乱填
不要把生成时间当作最后修改时间。搜索引擎会更信任真实的更新时间。
5. 过度依赖 changefreq 和 priority
这两个字段只是提示，别把它们当核心优化手段。
检查清单
上线前建议检查：
- XML 结构是否合法
- 文件编码是否是 UTF-8
- URL 是否绝对且统一主域名
- sitemap 是否和 canonical 对齐
- 是否超出 50MB / 50,000 URL 限制
- 是否需要 sitemap index
- 是否在 robots.txt 中声明了 sitemap
HTTP 输出建议
如果你的站点由程序输出 sitemap，建议：
- 返回 200 OK
- 使用 application/xml 或 text/xml
- 保持内容编码为 UTF-8
- 对动态生成的 sitemap 做缓存
缓存建议
对于大站点：
- 生成后落盘
- 通过定时任务更新
- 由 Nginx 或 CDN 提供缓存
这样比每次请求都实时生成更稳定。
最小可用流程
一个比较稳妥的默认流程是：
1. 选定主域名
2. 生成 sitemap.xml 或 sitemap index
3. 确保所有 URL 都是绝对地址
4. 在 robots.txt 中声明 Sitemap
5. 提交给搜索引擎站长平台
6. 站点更新时同步更新 lastmod推荐实践
- 小站用单个 sitemap.xml
- 大站用 sitemap index + 多分片
- sitemap 只放公开、规范化后的正式 URL
- lastmod 只在内容真正变化时更新
- robots、canonical、sitemap 三者保持一致
结论
Sitemap 的本质是给搜索引擎的站点结构地图。
最重要的不是“有没有生成”，而是：
- URL 是否规范
- 是否只包含公开页面
- 是否和 canonical、robots、跳转一致
- 是否能稳定更新
- 是否符合大小和数量限制