报错是这么冒出来的。十二万条地址生成一个未压缩的 sitemap.xml，文件六十二兆，提交后服务器返回 413，GSC 报无法读取。
真正麻烦的地方在于，几个原因的现象几乎一样。单文件上限五十兆且按未压缩体积计算。少数情况下是每条地址带了很长的参数和时间字段，体积膨胀。
还有一种情况，前置代理另有请求体限制，比规范更严。
先看实际文件大小
curl -sI https://www.example.com/sitemap.xml | grep -i content-length压成 gzip 并保留原名
gzip -k sitemap.xml && ls -lh sitemap.xml.gz提交压缩后的地址
curl -sI https://www.example.com/sitemap.xml.gz末了确认解压后条数不变
zcat sitemap.xml.gz | grep -c '<loc>'这类问题以前遇到过，但这次的触发条件和上次不一样。
这类改动我都写进变更记录，过两周再出问题时能对上号。
怎么算真的好了，看的是同一批现象。文件体积降到十兆以内，GSC 读取成功且地址数不变，服务器日志返回 200。
容易忽略的是，压缩只让文件变小，条数上限仍是五万，超了还得继续拆。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。