报错是这么冒出来的。图片服务支持按 w 参数实时裁剪，前端在列表、详情、推荐位用了十几种宽度组合，半年后搜索里出现四万个带 w 参数的图片地址，原图反而找不到。
中间走过弯路，把「图片 sitemap 只写了原图，蜘蛛从页面发现了参数地址」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。同一张图按宽度生成了大量可访问 URL。还有一种是裁剪地址没有 canonical 也没有 noindex。
少数情况下是CDN 对每种参数都缓存一份，成本一起涨。
动手时先统计参数组合的数量
grep -o 'w=[0-9]*' access.log | sort | uniq -c | sort -rn | head给裁剪地址加 canonical 指回原图
curl -sI 'https://img.example.com/a.jpg?w=300' | grep -i link接着在 robots 里挡掉图片处理参数
Disallow: /*?w=等前面都确认过，再核对图片 sitemap 输出
curl -s https://www.example.com/image-sitemap.xml | grep -c 'w='恢复的判定其实很直接。裁剪地址返回带 canonical 的响应头，参数 URL 抓取量下降，图片 sitemap 只剩原图地址且全部 200。
实时裁剪很方便，但每个组合都是独立 URL，上线前就要想好哪些宽度允许被抓。报错文案容易误导，真正的原因往往在相邻那一层的日志里。