事情本身不复杂，线索都在日志里。站点拆成 8 个分片共 32 万条 URL，为了让蜘蛛下载快一点，生成脚本里先 gzip 压一遍，Nginx 又对 .xml.gz 开了 gzip_static。提交到百度站长平台后状态一个月都停在「文件解析失败」，浏览器打开 sitemap.xml.gz 直接弹下载，解压出来还是乱码。删掉重提三次结果一样。
第一反应是「索引文件里子地图地址指向未压缩的 .xml，目录里只有 .gz」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。文件本身已是压缩体，响应头又加了一层 Content-Encoding: gzip，客户端解一次拿到的仍是二进制。还有一种是Content-Type 声明成 text/xml 但内容是压缩体，解析器按 XML 直接读。
少数情况下是应用层压缩和 Nginx 的 gzip_static 同时开着，两层叠在一起。
先看响应头里编码和类型各写了什么
curl -sI https://www.example.com/sitemap.xml.gz | grep -i -E 'content-(type|encoding)'然后关掉应用层压缩，压缩只交给 Nginx 一处完成
gzip_static on; gzip_types application/xml;接着确认索引文件里的子地图地址与实际文件同名
curl -s https://www.example.com/sitemap_index.xml | grep -o '<loc>[^<]*' | head等前面都确认过，再在站长平台删掉旧记录后重新提交索引文件
https://ziyuan.baidu.com/sitemap/index改完先别撤，确认这几项。状态从解析失败变成已抓取，索引文件展开后子地图数量与 8 个分片对得上，抓取统计里开始出现 sitemap 请求。
百度对 .xml.gz 的支持一直不稳，分片接近五万条时优先拆文件，比压缩更省事。报错文案容易误导，真正的原因往往在相邻那一层的日志里。