主题的 head 里写了几条 preload 字体，路径还是上一版的 hash 文件名。浏览器控制台报 404，日志里蜘蛛对同一个地址一天请求几十次。
一开始怀疑是「preload 的 as 值和实际资源类型不符，浏览器还会二次请求」，查了一圈，方向不对。
把日志和配置对完，能解释这个现象的基本就这几处。字体文件名带了构建 hash，升级主题后路径没同步。少数情况下是404 不会立即被放弃，蜘蛛会在后续几轮抓取里重复试探。
另外，资源域名和页面域名不同，跨域还需要 crossorigin 属性。
上来先把所有 preload 的地址逐个请求一遍
curl -s https://www.example.com/a/ | grep -o 'rel="preload"[^>]*' | head随后确认字体真实文件名
ls /www/wwwroot/lu0.cn/wp-content/themes/x/assets/fonts/修正路径后清一次缓存
wp cache flush末了验证返回状态
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/assets/fonts/x.woff2别只看报错消失，验证要多做一步。字体地址返回 200，日志里该路径的 404 计数归零，GSC 的抓取错误里也不再出现这类资源。
这里还有个坑。静态资源的 404 会持续占用抓取预算，改完路径还要在 GSC 里确认旧的错误条目停止增长，而不是只看总数下降。这类问题最好一次改到位，反复小改反而容易把原因搅混。