你的 sitemap.xml 返回 200，里面列了 800 个 URL，Search Console → Sitemaps 状态是 Success，还写着 “Discovered pages: 800”——但 Page indexing 报告里却几乎找不到这些 URL。
最快的答案： Sitemaps 报告里的 “Discovered pages” 只代表 Google 从 XML 里解析出了这么多 URL，它既不是收录数，也不是”待处理队列”。想看 Google 到底拿这些 URL 做了什么，打开 Page indexing（左侧导航 Indexing 下面），用报告顶部的下拉框把 All known pages 切换成 All submitted pages，或者直接选 Specific sitemap URL 指定你的 sitemap。这个视图会精确告诉你 sitemap 里多少 URL 是 Indexed、多少是 Not indexed，并按原因分类。十有八九 URL 都在，只是被归到了 “Crawled - currently not indexed”、“Page with redirect” 之类的原因下面，而不是真的丢了。
如果 Sitemaps 报告本身显示 0 discovered pages（不是数量偏少，是字面上的零），那是另一个更简单的 bug：文件格式有问题、提交到了错的 property，或者 URL 和 Google 选定的 canonical 对不上。下面两种情况都会讲到。
症状
sitemap.xml在浏览器里返回200且列出了 URL- Sitemaps 报告状态是 Success，但 “Discovered pages” 为
0，或远低于真实 URL 数 - Page indexing 报告里 sitemap 的 URL 全是 Not indexed，或者根本找不到
- 某个 URL 在 URL Inspection 里显示不属于任何 sitemap
先判断你属于哪一类
| Sitemaps 报告显示 | 最可能的原因 | 跳到 |
|---|---|---|
| 状态 Couldn’t fetch | robots.txt 拦了文件、URL 写错，或有未解决的 manual action | 原因 8 |
Success，Discovered pages = 0 | XML 格式错、带 BOM、<loc> 用了相对路径、http/https 不符 | 原因 1、5、7 |
| Success，发现数远低于真实数 | sitemap 过大，被截断在 50,000 URL | 原因 6 |
| Success，发现数正确，但 Pages 报告空 | URL 与 canonical 不符、返回 404/重定向，或 property 错 | 原因 2、3、4 |
| 一切都对，只是刚提交 | 处理延迟——等 2-3 天 | ”哪些情况不是你的错” |
第一步：先确认这真的是个问题
动手改任何东西之前，先搞清楚 URL 到底去哪了。光这一步就能解决大多数”消失”的报告，因为 URL 通常根本没消失。
- Search Console → Indexing → Page indexing。
- 点报告顶部的来源下拉框（默认 All known pages），选 All submitted pages，或 Specific sitemap URL → 你的 sitemap。
- 看 Why pages aren’t indexed 那张表。如果你的 URL 出现在 “Crawled - currently not indexed”、“Discovered - currently not indexed”、“Page with redirect”、“Alternate page with proper canonical tag”、“Duplicate without user-selected canonical” 这类原因下面，那说明 sitemap 是正常工作的——Google 读到了 URL 并做了收录判断。这是收录问题，不是 sitemap 问题。
想查单个 URL 的来源：把它粘进 URL Inspection 工具，展开 Page indexing，看 Discovery。那里会列出 Google 关联到这个 URL 的 Referring sitemaps。如果你的 sitemap 在列表里，说明 Google 接受了它；如果显示没找到 sitemap，说明你 sitemap 里的 URL 形式和 Google 选定收录的那个对不上——去看原因 2。
常见原因
1. Sitemap 用 http 但站点是 https（或反过来）
<url><loc>http://yourdomain.com/page/</loc></url>Google 会完全按 sitemap 里写的字面去抓取 URL（官方 build-a-sitemap 规范明确写了这点）。如果你站点跑 https、sitemap 里写 http，Google 跟着重定向去收录 https 那个，而 http 这条就被算成一次 redirect、而不是一次干净的匹配。
如何判断：
curl -s https://yourdomain.com/sitemap.xml | grep "<loc>" | head -5
# 所有 URL 都必须已经是 https://2. 尾斜杠、大小写或 www 与 canonical 不一致
<url><loc>https://yourdomain.com/article</loc></url>但你的 canonical 标签是 https://yourdomain.com/article/（带斜杠）。Google 把这俩当成两个不同的 URL，并收录 rel="canonical" 指向的那个，而不是 sitemap 里的字符串。这是”已发现”的 URL 始终不显示为干净已提交页面的头号原因。
如何判断。 抽 5 个 sitemap URL，逐个和它自己的 canonical 比对：
for url in $(curl -s https://yourdomain.com/sitemap.xml | grep -oE 'https://[^<]+' | head -5); do
canonical=$(curl -sL "$url" | grep -oE '<link rel="canonical" href="[^"]+"')
echo "sitemap: $url"
echo "canonical: $canonical"
echo "---"
done必须完全一致——协议、www. vs 裸域、大小写、尾斜杠都算。
3. Sitemap 所在的 property 和你正在看的不是同一个
你的 Search Console 验证的是 https://yourdomain.com/，但 sitemap 在 https://www.yourdomain.com/sitemap.xml。对一个 URL prefix property 来说，这是两个不同的站点，所以这份 sitemap 的 URL 永远不会汇总进你正在看的报告。
如何判断。 Search Console → Settings → Ownership verification，或左上角的 property 切换器。看 property 是 Domain 类型（覆盖所有子域、协议、路径）还是 URL prefix 类型（只覆盖那个精确 prefix）。
4. Sitemap 里的 URL 返回 404 或重定向
sitemap 写了一个 URL，但抓取后是 404 或 301。404 直接丢弃；301 被并到它的重定向目标里，于是列出来的那个 URL 永远不是被收录的那个。
如何判断：
for url in $(curl -s https://yourdomain.com/sitemap.xml | grep -oE 'https://[^<]+' | head -20); do
status=$(curl -sI -o /dev/null -w "%{http_code}" "$url")
echo "$status $url"
done应该全部 200。任何 301 / 404 都要修。
5. XML 不规范，被 Google 默默截断
sitemap 协议很严格，Google 对一些错误的容忍方式是：只读到第一个出错前的有效部分。
<?xml version="1.0" encoding="UTF-8"?>必须是文件第一行——前面不能有字节序标记（BOM）、空格或空行。- 必须有
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">这个 namespace。 - 标签值必须做实体转义（URL 里出现裸
&会直接让文件出错）。 - 文件必须是 UTF-8 编码。
如何判断。 用浏览器打开文件（有解析错误会立刻报出来），再用校验工具跑一遍，比如 XML Sitemaps Validator。查 BOM：
curl -s https://yourdomain.com/sitemap.xml | head -c 3 | xxd
# 开头若是 "ef bb bf" 就是 UTF-8 BOM，必须去掉6. Sitemap 文件太大
单个 sitemap 上限是 50,000 个 URL 或未压缩 50 MB（截至 2026 年 6 月，Google 文档确认的现行限制）。超限后的行为才是坑：
- 超过 50,000 URL：Google 忽略前 50,000 之后的全部。
- 超过 50 MB：Google 可能直接拒收整个文件。
这两种都不会触发 Search Console 报错——状态照样是 Success，只是 discovered 数比你真实 URL 总数少。这个差值就是线索。
修法： 拆成 sitemap index 加多个子 sitemap（见 Step 5）。
7. sitemap-index 用了相对路径
<sitemapindex>
<sitemap><loc>./sitemap-1.xml</loc></sitemap> <!-- 相对路径，会被拒收 -->
</sitemapindex><loc> 必须是完整的绝对 URL。Google 完全按写的字面抓取，相对路径解析不到任何东西，子 sitemap 永远读不到。
8. 状态是 “Couldn’t fetch”
如果 Sitemaps 报告显示的是 Couldn’t fetch 而不是 Success，说明 Google 根本没读到文件。常见原因：
robots.txt拦住了 sitemap 路径（Google 抓 sitemap 时也遵守robots.txt）。- 提交的 URL 写错，或返回非
200状态。 - 站点有未解决的 manual action——有未处理的人工处罚时 sitemap 不会被处理（Search Console → Security & Manual Actions → Manual actions）。
如何判断。 用无痕窗口打开 sitemap URL，再查 https://yourdomain.com/robots.txt 里有没有 Disallow 规则正好命中它。“Couldn’t fetch” 也可能是旧状态；如果你已经修好访问，点开那行 sitemap 重新提交即可。
最短修复路径
Step 1：用浏览器和校验工具打开 sitemap.xml
浏览器： https://yourdomain.com/sitemap.xml （应看到结构化 XML，无错误提示）
校验： https://www.xml-sitemaps.com/validate-xml-sitemap.htmlXML 坏了就先修——文件解析不了，后面所有步骤都没意义。
Step 2：抽 5 个 URL 验 canonical 一致性
跑原因 2 的 canonical 对比脚本。修掉任何协议、www. vs 裸域、大小写或尾斜杠上的不一致。治本的办法是统一源头：让 sitemap 生成器和 canonical 标签渲染器调用同一个 urlFor() helper，从根上避免两者漂移。
Step 3：确认 sitemap 在正确的 property 上
Search Console → Settings，看 property 类型：
- Domain property（
yourdomain.com）：覆盖所有子域、协议、路径。 - URL prefix property（
https://yourdomain.com/）：只覆盖那个精确 prefix。
如果 sitemap 在 www.yourdomain.com 但 property 是 https://yourdomain.com/（无 www），要么换成 Domain property，要么给 www 主机单独加一个 URL prefix property。
Step 4：确认每个 URL 都返回 200
跑原因 4 的 curl 状态脚本。对每个有问题的 URL：
301：直接把最终目标 URL 写进 sitemap。404：从 sitemap 里删掉。
Step 5：拆大 sitemap
<!-- sitemap-index.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap><loc>https://yourdomain.com/sitemap-articles.xml</loc></sitemap>
<sitemap><loc>https://yourdomain.com/sitemap-pages.xml</loc></sitemap>
</sitemapindex>每个子 sitemap 都保持远低于 50,000 URL 和 50 MB。
Step 6：重新提交，再用过滤器验证
Search Console → Sitemaps → 删掉旧的那条 → 重新输入 URL → Submit。然后去 Page indexing，把下拉框设成 Specific sitemap URL，看接下来几天 Indexed 数往上走。
如何确认已修好
- Sitemaps 报告显示 Success，且 “Discovered pages” 等于（或接近）你真实的 URL 数。
- 在 Page indexing 过滤到 All submitted pages 时，大部分 URL 是 Indexed，剩下少数也归在你能看懂的原因下面。
- 对一个抽样 URL 跑 URL Inspection，在 Page indexing → Discovery → Referring sitemaps 里看到你的 sitemap，且 Google 选定的 canonical 和你 sitemap 里的
<loc>一致。
哪些情况不是你的错
刚提交的 sitemap 几乎立刻会被抓取，但处理里面的 URL 要时间——通常几天，大站或权重低的站更久。如果你是过去 48-72 小时内提交的、文件也能校验通过，先给它点时间，再深挖。
容易误判的情况
- 以为 “Success” = 每个 URL 都进了收录队列。 不是——它只代表文件解析成功。
- 以为 “Discovered pages” = 收录数。 这是两个完全不同的数：前者是从 sitemap 解析出的 URL 数，后者是真正进了索引的数。要比这两个数，用 Page indexing 的过滤器，不是 Sitemaps 报告。
- 以为 sitemap 一提交就生效。 抓取很快，但抓取并收录里面的 URL 要几天。
- 以为 discovered 数偏低 = Google 拒收了 sitemap。 有时只是报告还没刷新；过两天再看。
预防建议
- sitemap 与 canonical 标签用同一数据源生成（共享一个
urlFor()helper），让 URL 形式无法漂移。 - 在 CI 里校验 sitemap：XML 格式正确、无 BOM、URL 数不超上限、每个
<loc>都返回200。 - URL 形式（协议、
www、尾斜杠）与 canonical 完全一致。 - 单 sitemap 超过约 5,000 URL 就尽早拆成 sitemap index。
- 每次部署后
curl一次 sitemap，确认200且 URL 数符合预期。
FAQ
Q：我的 Sitemaps 报告是 Success，但 Discovered pages 是 0，怎么回事？
A：Google 解析出的有效 URL 是零。常见元凶：XML 声明前有 BOM 或空格、缺 urlset namespace、<loc> 用了相对路径、或有未转义的 &。用浏览器打开文件看解析错误，再校验一遍。
Q：怎么看 sitemap 里哪些 URL 真的被收录了？ A：打开 Page indexing，点顶部下拉框，选 All submitted pages 或 Specific sitemap URL。Sitemaps 报告里的 discovered 数永远不会告诉你这个。
Q：单个 sitemap 能放多少 URL？ A：最多 50,000 个 URL 或未压缩 50 MB（2026 年 6 月）。超出后 Google 只读前 50,000 个；更多就用 sitemap index。
Q：lastmod 必须填吗？Google 会信吗？
A：选填，但推荐填。Google 只在 lastmod 可验证为准确时才采信。如果每次构建都把每条的 lastmod 设成当天日期，Google 会察觉并在全站范围内忽略这个字段——所以要给每个 URL 输出真实的最后修改时间。
Q：要为每种语言单独提交 sitemap 吗？ A：都行。分语言（或分版块）的 sitemap 能让你用 Specific sitemap URL 过滤器更方便地单独监控收录。