JSON-LD 的 @context 写成 http 整段标记被解析器跳过

站点做全站 HTTPS 改造时用批量替换把模板里的 schema.org 地址也改成了 https，同时又有一批旧模板写的是 http，两种写法混在一个页面里。测试工具对其中一段直接提示无法识别，搜索结果里的富媒体一周后消失。

一开始怀疑是「@context 写在子节点上 父级缺失导致整棵树无上下文」，查了一圈，方向不对。

真正麻烦的地方在于，几个原因的现象几乎一样。同一页面输出两个不同的 @context 解析器只取第一段。也可能是批量替换把 schema.org 改成了带 www 的错误域名。

少数情况下是模板输出时被 CDN 的 HTML 改写功能动过 属性顺序被打乱。

数一下页面里出现了几个 @context

curl -s https://www.example.com/post/123 | grep -o '"@context":"[^"]*"' | sort | uniq -c

随后统一成官方地址并只保留一段

"@context": "https://schema.org"

接着用 @graph 合并多段实体

{"@context": "https://schema.org", "@graph": [ {...}, {...} ]}

复验页面输出的 JSON 是否可解析

curl -s https://www.example.com/post/123 | python -c "import sys,re,json;print(len(json.loads(re.search(r'<script type=.application/ld\+json.>(.*?)</script>', sys.stdin.read(), re.S).group(1))))"

恢复的判定其实很直接。统一成一段 @graph 之后测试工具读到了全部实体，富媒体在两周内恢复，页面里也不再出现两种协议混用的情况。

补一句。schema.org 的地址用 http 和 https 都能被识别，真正致命的是同一页面出现多套上下文，解析器只会认第一段。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。