Search Console 抓取预算被图片拖垮，我改了三处

土耳其区一个本地生活站的 Search Console 后台，过去三周「抓取统计信息」里图片请求占了 68%，HTML 只占 21%。站点规模不大：约 1.2 万个 URL，图片约 4.5 万张，托管在 Cloud Storage 后面挂 Cloud CDN。现象是 HTML 的抓取频次从每天 9000 次掉到 5200 次，新发的商户页要 4 到 6 天才被收录，而图片几乎当天就进索引。

第一处我改了 sitemap 的拆分方式。原来一个 sitemap 同时塞 HTML 和图片扩展，Google 按 URL 条目算配额，图片扩展不占条目但会放大单个文件的解析和抓取请求。拆成 sitemap-pages.xml 和 sitemap-images.xml，后者只保留商户详情页的主图，列表页缩略图全部剔除：

<url>
  <loc>https://example.com/tr/merchant/1234</loc>
  <image:image>
    <image:loc>https://cdn.example.com/merchant/1234/main.webp</image:loc>
  </image:image>
</url>

第二处在 CDN 上给图片响应加 Cache-Control: public, max-age=604800, immutable，之前是 no-cache，Googlebot 每次来都重新拉原图，Cloud Storage 的出口流量也随之上涨。第三处把列表页的懒加载图从 <img data-src> 改成原生 loading="lazy"，避免爬虫把 data-src 当真实地址反复探测 404。

为什么这样有效：抓取预算按主机名分配，图片和 HTML 同域时会互相挤占。把图片请求的边际成本压到最低（强缓存 + 稳定 URL），爬虫在图片上的往返就减少了，省下来的配额自然流向 HTML。代价是缓存失效变慢，商户换主图后最长要等七天，我们接受这个延迟，因为主图本来就很少改。

失效的地方也很明确：如果图片和页面不同域，预算分开计算，这套做法收益就小很多；immutable 一旦用错在会变的 URL 上，用户会看到旧图，我们只在带内容哈希的路径上加。我自己踩过的坑是把 sitemap 拆得太碎，单个文件只有几十条，反而增加了抓取 sitemap 本身的请求数，最后合并回两个文件才稳。

你们在 Search Console 里看到图片请求占比偏高时，是先去压图片数量，还是先看 HTML 这边有没有被无效参数拖住？