报错是这么冒出来的。文章结构化数据里 author 用了 @id 指向 /author/zhang/，实际这个作者页返回 404，富媒体报告提示作者实体无法解析，Article 的署名信息一直为空。
中间走过弯路，把「@id 用了相对路径，解析器拼出的地址多了目录层级」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。作者页被删除但文章里的 @id 没有跟着更新。另一种情况是作者 archive 链接被伪静态规则改成了另一套路径。
还有一种情况，主题把作者页 noindex 了，实体仍能被读到但无法验证。
动手时先确认作者页的真实状态
curl -s -o NUL -w "%{http_code} %{redirect_url}\n" https://www.example.com/author/zhang/再往下核对页面里的 author 字段
curl -s https://www.example.com/post-1024/ | findstr /i "\"author\""接着改成指向存在的作者页或直接内嵌 Person
echo json_encode(['@type'=>'Person','name'=>'张三','url'=>'https://www.example.com/about/']);复验富媒体报告
curl -s https://www.example.com/post-1024/ | findstr /c:"Person"恢复的判定其实很直接。作者实体改成内嵌 Person 后，报告里的解析错误消失，署名信息正常展示。
结构化数据里的引用要指向稳定存在的地址，作者页改版时记得同步 @id。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。