事情本身不复杂，线索都在日志里。前端页面靠 fetch 拉 /wp-json/wp/v2/posts 渲染列表，浏览器里好好的，GSC 实时测试里页面主体是空的，渲染截图整片灰。
第一反应是「预检 OPTIONS 请求返回 405，Nginx 没放行这个方法」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。接口响应缺少 Access-Control-Allow-Origin，跨域请求被浏览器直接拦。另一种情况是头写成了 Access-Control-Allow-Origin: * 但同时带了 credentials，浏览器判为非法组合。
另外，JSON 只在登录态下返回数据，未登录访客拿到的是空数组。
第一件事是看接口响应头里有没有放行字段
curl -sI -H 'Origin: https://www.example.com' https://www.example.com/wp-json/wp/v2/posts | grep -i access-control随后确认 OPTIONS 预检是不是 405
curl -s -o /dev/null -w '%{http_code}\n' -X OPTIONS https://www.example.com/wp-json/wp/v2/posts以访客身份直接请求接口看返回体
curl -s https://www.example.com/wp-json/wp/v2/posts | jq 'length'恢复的判定其实很直接。接口返回头里出现与站点同源的 Allow-Origin，OPTIONS 返回 204，访客直接请求能拿到文章数组，实时测试截图能看到正文。
补一句。页面靠接口渲染时，蜘蛛和访客走的是同一条路径，接口只要对未登录用户关闭，正文就等于不存在。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。