先记录 Search Console 中提交的完整 Sitemap URL、属性类型、最后读取时间和精确错误。然后从公网、不携带登录 cookie 的环境请求该 URL，保存每一跳 HTTP 状态、最终 URL、Content-Type、字节数和响应体 SHA-256。正常情况应直接返回可解析的 Sitemap XML，不依赖 JavaScript、Cookie、认证或人机挑战。再检查 robots.txt、XML 根元素与命名空间、UTF-8、URL 范围、每份 Sitemap 的 URL/未压缩大小限制，以及 Sitemap index 中每个子文件的可访问性。
直接答案
先记录 Search Console 中提交的完整 Sitemap URL、属性类型、最后读取时间和精确错误。然后从公网、不携带登录 cookie 的环境请求该 URL，保存每一跳 HTTP 状态、最终 URL、Content-Type、字节数和响应体 SHA-256。正常情况应直接返回可解析的 Sitemap XML，不依赖 JavaScript、Cookie、认证或人机挑战。再检查 robots.txt、XML 根元素与命名空间、UTF-8、URL 范围、每份 Sitemap 的 URL/未压缩大小限制，以及 Sitemap index 中每个子文件的可访问性。
一、先区分读取失败与URL索引问题
Sitemap 是向搜索引擎提供 URL 发现信号的文件，不是索引保证。报告能成功读取 Sitemap，里面的 URL 仍可能因 noindex、canonical、重复、质量或抓取问题未索引。反过来，Sitemap 暂时读取失败，已通过链接或旧 Sitemap 发现的 URL 也不会自动从索引删除。
因此要将问题分成两条证据链：Sitemap 资源本身是否可访问和可解析；其中页面 URL 是否可抓取、可索引且规范。本文先修第一条。
二、确认提交的完整URL与属性
从 Search Console 复制完整 URL，不要手工重新输入。检查 scheme、主机名、www/非 www、端口、路径、大小写和文件扩展名。迁移后常见旧 HTTP 或旧主机的 Sitemap 记录仍保留，而实际文件已改到新主机。
URL-prefix 属性与 Domain 属性的范围不同。确保当前用户对 Sitemap 所属站点有正确验证，并且 Sitemap 中的 URL 位于允许的主机和路径范围。跨站 Sitemap 不能只靠 XML 中写入另一个域名就自动获得授权。
三、用无登录的公网请求复现
本地或管理员浏览器可能携带 CDN 绕过 cookie、VPN、内网 DNS 或已登录会话。在独立公网环境以 GET 和 HEAD 检查，但以 GET 响应体作为格式验证依据，因为某些服务对 HEAD 的实现不一致。
保存 DNS 结果、TLS 证书主机匹配、HTTP 状态、重定向链、媒体类型和响应大小。如果返回 HTML 登录页、WAF 挑战或 CDN 错误页，应修正边缘规则，而不是在 XML 解析器上寻找问题。
四、检查HTTP状态与重定向
Sitemap URL 应长期稳定。单次 5xx、上游超时、429、TLS 错误或 DNS 波动都可能让某次读取失败。核对 Google 报告的最后读取时间与 CDN、负载均衡器和源站日志，不要只测试当前一秒。
不要依赖多跳、循环或会丢失路径的重定向链。理想做法是在提交 URL 直接返回当前 Sitemap。如果站点必须迁移，确保每一跳都对公网抓取可用，最终资源不是 HTML 首页。
五、robots.txt与WAF不要阻断Sitemap
Sitemap 本身需要可抓取。检查 robots.txt 是否误将 /sitemap、/.xml 或生成目录禁止，也检查 WAF、Bot 管理、地域限制、IP 允许列表与速率限制。
不要用 User-Agent 字符串伪装 Googlebot 作为唯一验证，因为它不能证明请求真正来自 Google，而且边缘系统可能根据多个信号处理。优先让 Sitemap 成为无认证、低成本、对合法抓取稳定可访问的静态资源。
六、验证XML根元素和命名空间
普通 URL Sitemap 的根元素是 urlset，Sitemap index 的根元素是 sitemapindex，并使用 Sitemap 协议命名空间。每个 URL 项使用 url/loc，每个索引项使用 sitemap/loc。不要把 HTML、RSS、应用自定义 XML 或未完成的模板仅因扩展名为 .xml 就当 Sitemap。
使用 XML 解析器验证原始字节，不要仅看浏览器树形展示。检查未闭合标签、未转义 &、重复 XML 声明、控制字符和在 XML 前输出的 PHP/模板警告。
七、统一使用UTF-8与正确URL转义
Sitemap 文件应使用 UTF-8。XML 实体转义与 URL 百分号编码是两层不同问题：URL 中的非 ASCII 与保留字符先按 URI 规则表示，嵌入 XML 后，& 等 XML 特殊字符还需转义为实体。
不要对完整 URL 重复百分号编码，也不要将 & 当成真实 URL 的字符串参数发送给路由层。用实际解析出的 loc 再做 HTTP 抽样，验证还原后的 URL 正确。
八、检查URL数量与未压缩大小
Sitemap 协议对单个文件的 URL 数和未压缩大小有上限。当站点接近上限时，应分成多个 Sitemap，再用 Sitemap index 引用，不要仅依赖 gzip 压缩后的较小文件大小。
生成后自动计算 URL 数、原始 XML 字节数与 gzip 解压完整性。对大站点按稳定分片键拆分，避免每次构建都让所有 URL 在不同子文件间移动，造成调试和缓存困难。
九、逐个验证Sitemap Index的子文件
Sitemap index 本身返回 200 不代表所有子 Sitemap 都可用。解析每个 loc，检查子文件的状态、最终 URL、格式、大小和 URL 所属范围。常见问题是索引混入旧版哈希文件，而 CDN 或发布过程已删除它。
发布顺序应先上传新子 Sitemap，验证后再原子替换 index，最后延迟清理旧子文件。如果先发布 index，Google 在窗口期读取时会获得 404。
十、检查CDN缓存与生成竞态
Sitemap 通常会被 CDN 长时间缓存。源站修复后，边缘节点仍可能返回旧 404、错误 HTML 或不完整 XML。对比源站与公网响应的 Age、ETag、Last-Modified、字节数和 SHA-256，再定向清理准确 URL。
生成器不应直接在公网路径逐行覆盖文件，否则抓取可能在写入中途获得截断 XML。先写入同文件系统的临时文件，完成格式与数量验证后原子替换，再刷新缓存。
十一、不要重复提交掩盖根因
重复点击提交不会修正 DNS、TLS、WAF、XML 或发布竞态。先在公网完成可重复验收，并保留证据时间。修复后可使用 Search Console 的适当流程重新提交，然后等待报告下次处理。
报告并非实时监控器。在状态尚未更新时，以公网 HTTP、XML 验证、服务器日志和下次 Google 读取记录作为证据，不要因 UI 暂时保留旧文案而频繁改 URL。
十二、分步修复流程
复制 Search Console 中的完整 Sitemap URL 和最后读取时间。
从无登录公网环境采集 DNS、TLS、HTTP、重定向和响应哈希。
检查 robots.txt、WAF、CDN、速率限制和人机挑战。
使用 XML 解析器验证 UTF-8、根元素、命名空间、实体转义和 URL。
统计 URL 数和未压缩字节数，解压验证 gzip。
如为 Sitemap index，逐个拉取和验证子文件。
先修复并公网验收，再重新提交，记录下次读取结果。
十三、常见错误
管理员浏览器能打开，就判定 Google 一定能读取。
只看 200 状态，不检查返回的是 XML、HTML 还是 WAF 挑战页。
修复源站却不验证 CDN 缓存，公网仍返回旧错误。
只验证 Sitemap index，不检查任何子 Sitemap。
将 gzip 后大小当成协议的未压缩大小。
生成器直接覆盖公网文件，让抓取读到半份 XML。
不断删除、改名和重新提交，失去原错误的可观测记录。
十四、验收清单
提交 URL 从多个公网网络直接返回稳定成功响应。
无认证、无 cookie、无 JavaScript 即可获得同一 XML 字节。
XML、UTF-8、命名空间、URL 转义和 gzip 验证通过。
URL 数与未压缩大小低于当前协议限制。
Sitemap index 的所有子文件均可访问、可解析且属于正确范围。
CDN 与源站的响应哈希一致，没有发布竞态。
Search Console 在后续处理中成功读取，服务器日志与时间相符。
总结
Sitemap “无法读取”要按资源生命周期排查：Search Console 提交了哪个 URL，Google 从公网获得什么 HTTP 响应，CDN/WAF 是否改写，XML 是否完整合规，索引文件的子资源是否都可用。先用公网证据修复根因，再重新提交并等待报告更新，不要用反复提交替代诊断。
参考资料
Google Search Central: Build and submit a sitemap
https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
Google Search Central: Manage your sitemaps using the Sitemaps report
https://support.google.com/webmasters/answer/7451001
Google Search Central: Sitemap file size limits and splitting
https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps
Sitemaps XML format specification
https://www.sitemaps.org/protocol.html
常见问题
1. Sitemap在浏览器能打开，为什么仍显示无法读取？
浏览器可能携带 cookie、使用不同 DNS/网络，或获得不同 CDN 缓存。还可能是 Search Console 显示的上次失败状态尚未更新。
2. Sitemap URL可以301重定向吗？
搜索抓取可能跟随合法重定向，但稳定的直接 200 资源更容易验证。避免多跳、循环、跨认证边界或最终落到 HTML 页面。
3. Sitemap需要设为`application/xml`吗？
应返回与 XML 内容一致的合理媒体类型，不要返回 `text/html`。最终仍要以实际字节可解析和 Google 当前文档为准。
4. 需要每次更新都重新提交吗？
通常不需要为同一稳定 URL 的每次内容更新重复提交。保持 URL 稳定、可访问，并确保 Sitemap 更新正确。
5. Sitemap成功就会索引全部URL吗？
不会。Sitemap 是发现和元数据信号，索引仍受抓取、canonical、`noindex`、重复和搜索系统判断影响。