报错是这么冒出来的。日志里 /wp-json/wp/v2/types 和 /wp-json/ 这类地址每天被抓三千多次，返回的都是 JSON，GSC 里出现一批内容为 JSON 的已编入索引页面。
这类报错背后常见的原因有几处，逐个排除就行。主题在 head 里输出了 REST 的 link 标签，蜘蛛顺着就抓。另一种情况是接口没有 X-Robots-Tag，返回 200 且可索引。
还有一种情况，robots 里只挡了 /wp-admin，没管 /wp-json。
先确认接口返回与索引状态
curl -sI https://www.example.com/wp-json/ | grep -iE "HTTP/|content-type|x-robots"给 REST 响应加不索引头
add_filter('rest_post_dispatch', function($r){ $r->header('X-Robots-Tag', 'noindex, nofollow'); return $r; });剩下的就是在 robots 里显式挡掉接口前缀
Disallow: /wp-json/报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
当时还开着另一个排查窗口，两边日志对照着看才定位到。
别只看报错消失，验证要多做一步。接口响应头出现 X-Robots-Tag: noindex，日志里该前缀请求降到个位数，GSC 里 JSON 页面逐步退出索引。
容易忽略的是，直接 Disallow 会让 REST 在部分场景报错，先加响应头再考虑 robots，顺序别反。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。