XML Sitemap 里该放哪些 URL？用可索引清单排除错误页面

直接答案：XML Sitemap 应只列出你希望在 Google 搜索中出现的正式、可公开访问、返回 200、允许索引且以自己为规范版本的完整 URL。noindex、重定向、404、测试域名、重复参数页和仅供登录用户访问的页面都不应混入；lastmod 只在正文、结构化数据或关键链接发生实质更新时修改。

Sitemap 是“希望被索引的清单”，不是全站 URL 导出

Sitemap 的价值是向搜索引擎说明哪些页面和文件对站点重要，以及它们何时发生了更新。它不是数据库表、路由列表或爬虫日志的完整镜像。

Google 不保证抓取或收录清单中的每一项

Google 的 Sitemap 概览明确说明，Sitemap 能帮助搜索引擎发现 URL，但不保证其中所有项目都会被抓取和索引。页面仍要满足可访问、可索引、内容清楚和规范信号一致等条件。

因此，Sitemap 的判断问题不是“这个 URL 存不存在”，而是：

我们是否希望搜索用户从结果页进入这个正式 URL？

如果答案是否定或不确定，就不应自动加入。

小站也需要清单质量，不需要堆数量

Google 将约 500 页以下且内部链接完整的网站视为可能不依赖 Sitemap 的小站场景，但企业官网仍可通过 Sitemap 管理新页面和更新时间。重点是准确，不是把数量做大。

NeoGress 连接：NeoGress 官网公开工作流把站点生成、正式发布、Sitemap 和 Search Console 检查串在一起。发布系统应从“公开且可索引”的内容源生成 Sitemap，而不是从所有项目、草稿或预览记录直接导出。

一个 URL 进入 Sitemap 前要通过哪些条件？

建议把资格门槛写成可执行规则，而不是依赖运营人员逐条记忆。

检查项	应满足	失败时动作
环境	正式域名与正式协议	排除测试、预览、localhost 和旧域名
公开性	匿名访客可访问	登录页、后台和私有资源排除
HTTP 状态	最终返回 200	3xx 放目标页；4xx/5xx 排除
索引规则	无 noindex	noindex URL 排除
robots.txt	允许必要抓取	修正规则或重新判断页面目标
canonical	指向自身规范 URL	只保留真正规范版本
内容状态	已发布且正文完整	草稿、空页、占位页排除
站内关系	有自然内部链接	修复孤儿页，不用 Sitemap 掩盖结构问题
URL 形式	完整绝对 URL	统一 HTTPS、主机名、大小写和结尾斜杠
更新时间	lastmod 可核验	只在实质更新时变化

正式、公开和可索引必须同时成立

页面即使返回 200，也可能是登录壳、软 404、空状态或 noindex。生成器不能只按状态码纳入，还要读取内容发布状态、索引规则和规范 URL。

canonical 必须与 Sitemap 一致

Google 的 canonical 指南建议，不要用不同规范化方式为同一页面指定不同 URL。例如 Sitemap 列出带参数版本，而页面 rel="canonical" 指向无参数版本，会造成维护意图冲突。Sitemap 应只保留无参数的规范地址。

正文 如果团队还没有统一“抓取”和“索引”规则，先阅读本系列第 1 篇《robots.txt 能阻止 Google 收录吗？什么时候应该用 noindex？》，再把上述条件写进 Sitemap 生成逻辑。

哪些 URL 应该明确排除？

noindex 页面

noindex 表达“不希望进入搜索结果”，Sitemap 表达“希望搜索引擎关注这个规范 URL”。两者同时存在会让清单自相矛盾。确定 noindex 的感谢页、内部搜索页或公开工具页，应从 Sitemap 移除。

301、302、307、308 重定向 URL

Sitemap 应列最终规范目标，不应让爬虫先访问旧地址再跳转。永久迁移后，把旧 URL 从 Sitemap 删除并保留正确重定向；临时跳转页面也通常不应作为规范入口。

404、410、5xx 与软 404

不存在、已删除或系统错误页面不属于可索引清单。软 404 尤其容易漏掉：它返回 200，却只显示“未找到”、空列表或通用占位内容。生成前需要结合页面内容判断。

测试域名和预览链接

测试站应在访问权限层隔离，并从所有公开发现入口清除。具体做法见本系列第 2 篇《测试站被 Google 收录怎么办？预览环境上线前这样隔离》。

重复与参数版本

跟踪参数、排序参数、打印版、大小写变体和同内容多路径，通常只保留一个规范 URL。若不同参数确实产生独立、有价值且希望搜索展示的页面，再单独评估。

私有、登录后和一次性页面

后台、订单、客户项目、预览 token、购物流程状态、一次性下载和带个人信息的 URL 必须从源头排除。Sitemap 不是访问控制，但把私有 URL 列进去会扩大暴露风险。

lastmod 应该什么时候更新？

<lastmod> 用来描述页面最后一次实质修改时间，不是 Sitemap 文件生成时间，也不应每天批量刷新。

哪些变化属于实质更新

Google 的构建 Sitemap 文档列举了正文、结构化数据和页面链接的实质更新。企业官网可按以下方式判断：

• 产品规格、服务范围、价格或可用状态发生变化；
• 核心正文新增了可验证信息；
• FAQ、步骤或重要表格被重写；
• canonical、hreflang 或结构化数据发生有效修正；
• 关键内部链接关系改变，影响页面发现与主题解释；
• 页面从草稿变为正式发布。

只改页脚年份、修一个不影响含义的标点、重新构建同一 HTML，通常不应刷新 lastmod。

Google 会忽略不可信的 lastmod

Google 表示，只有当 lastmod 持续且可验证地准确时才会使用它。如果系统每天把全站 lastmod 改成今天，长期会削弱这个字段的可用性。时间应来自内容的真实更新时间，而不是部署时间。

priority 和 changefreq 不必花时间调参

Google 当前忽略 XML Sitemap 中的 <priority> 和 <changefreq>。保留符合协议的字段不会直接报错，但不要把它们当成抓取频率或排名命令。把精力放在 URL 资格、lastmod 准确性和站内链接上更有价值。

怎样生成一个最小且正确的 XML Sitemap？

一个基本条目只需要完整 URL，lastmod 为可选项。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/services/industrial-design</loc>
    <lastmod>2026-08-03</lastmod>
  </url>
</urlset>

使用完整绝对 URL

Google 官方要求使用完整 URL，包括协议和主机名。不要写相对路径，也不要混用 HTTP/HTTPS、www/非 www 或测试域名。

正确转义 XML

URL 中的 & 等字符必须按 XML 规则转义。Sitemap 文件应使用 UTF-8。即使浏览器能勉强显示格式错误的 XML，也不代表搜索引擎会完整解析。

超过限制时拆分

单个 Sitemap 的上限是未压缩 50MB 或 50,000 个 URL，以先达到者为准。超过后应拆分并使用 Sitemap index。企业站可以按内容类型拆分，如页面、产品、文章和图片，以便在 Search Console 中分别观察。

只放一个主机范围内的 URL

遵守 Sitemap 协议的主机范围与文件位置规则。多子域、多语言或多品牌站点应设计清楚各自的 Sitemap 与验证范围，不要把互不相关主机随意混在一个文件中。

如何对 Sitemap 做一次可复现的质量检查？

一次检查要同时验证 XML、URL 集合、页面响应和页面声明。

第 1 步：检查文件可访问与格式

• Sitemap URL 返回 200；
• Content-Type 合理；
• XML 可解析、UTF-8 无乱码；
• 没有 HTML 错误页伪装成 XML；
• URL 数量和文件大小未超过限制。

第 2 步：检查主机名和协议

提取所有 <loc>，统计主机名、HTTP/HTTPS、www/非 www、尾斜杠和大小写变体。发现测试域名、旧域名或混合协议时先停止提交。

第 3 步：抽查最终响应

对首页、栏目页、最新文章、最旧文章和随机样本跟随重定向：

curl -I -L https://www.example.com/page

记录初始状态、最终状态、最终 URL、X-Robots-Tag 和缓存结果。任何重定向 URL 应从清单换成最终目标。

第 4 步：核对 HTML 声明

检查 robots meta、canonical、语言标记和结构化数据 URL。Sitemap URL应可索引并通常自指 canonical；不要让 JavaScript 在渲染后把 canonical 改到另一个地址。

第 5 步：与内容源做差集

至少计算两组差异：

1. 已发布且可索引，但不在 Sitemap 中；
2. Sitemap 中存在，但内容源不是已发布可索引状态。

这比只数 URL 总量更能发现生成逻辑错误。

第 6 步：在 Search Console 分组观察

提交后观察 Sitemap 读取状态、发现 URL 数和页面索引报告。状态用于诊断，不代表每个 URL 都会收录。不要每天重复提交完全不变的 Sitemap；Google 抓取排错文档也建议避免这种做法。

Sitemap 与站内链接应该怎样配合？

Sitemap 可以帮助发现，但不能替代导航和正文内链。一个只存在于 Sitemap 的孤儿页，往往也暴露出信息架构问题。

重要页面应从可抓取链接到达

产品、服务、解决方案、专题和文章应从首页、栏目页或相关正文获得自然入口。链接锚文本要说明目标内容，而不是统一使用“点击这里”。

下线页面要同时清理多个入口

页面删除或迁移时，同时处理：

• Sitemap；
• 导航、面包屑和正文内链；
• canonical 与 hreflang；
• 结构化数据 URL；
• RSS/Atom；
• 重定向或 404/410 响应。

只删 Sitemap 不会让页面自动消失，只保留重定向也不代表清单已干净。

现有问题页继续解决“提交后不收录”

如果 Sitemap 已经正确，但页面仍未进入索引，继续阅读《提交 sitemap 后为什么还是不收录》。那篇聚焦内容价值、孤儿页、站点主题与索引判断；本文只负责 URL 清单质量。

这套方法有哪些限制？

Sitemap 是提示，不是抓取或收录指令。清单完全正确，也不能替代内容质量、内部链接、服务器稳定性和搜索引擎的索引判断。lastmod 准确只能帮助表达更新，不代表页面会立即重抓或提升排名。

不同搜索引擎对扩展字段和提交方式可能有差异；本文的时效性结论以 2026-08-03 的 Google 官方文档为准。

常见问题

Sitemap 中可以放 noindex 页面吗？

技术上 XML 仍能解析，但意图冲突。既然页面声明不进入搜索结果，就应从“希望展示的规范 URL 清单”中移除。

Sitemap 中可以放 301 URL 吗？

不建议。应放重定向后的最终规范 URL。旧地址继续保留正确重定向，但从 Sitemap 清理。

lastmod 每天自动改成当天有用吗？

没有。lastmod 应反映页面最后一次实质更新。每天刷新同一日期会让字段失真，Google 可能忽略不可信值。

priority 设置成 1.0 会更快收录吗？

不会。Google 当前忽略 Sitemap 的 priority 和 changefreq。它们不能强制抓取、索引或排名。

Sitemap URL 越多越好吗？

不是。数量不是目标。只列正式、公开、200、可索引且规范的 URL，远比导出所有路由更有价值。

提交 Sitemap 后还需要内链吗？

需要。Sitemap 帮助发现，站内链接帮助用户和爬虫理解页面在站点中的关系。重要页面不应成为只存在于 Sitemap 的孤儿页。

结论：把 Sitemap 当成发布合同，而不是抓取垃圾桶

可靠流程是：从已发布内容源筛选正式 URL，验证 200、可索引和 canonical，自主排除测试、noindex、重定向、错误与重复版本，按真实更新维护 lastmod，再通过 Search Console 观察结果。

如果你正在搭建或重构企业官网，可从 NeoGress 首页规划公开页面，再用 Google 收录指南把 robots、canonical、Sitemap、站内链接和发布验证合并成一套上线门禁。