先看现象。多语言站的 PDF 手册只能用响应头输出 hreflang，运维在 Nginx 里加了一组 Link，HTML 页面又由插件输出另一组，两边 en 地址不一致，GSC 报备用网页语言标记冲突。
这类报错背后常见的原因有几处，逐个排除就行。响应头里的 hreflang 与 head 里的地址不同，蜘蛛取并集后互相矛盾。也可能是add_header 只对 200 生效，301 响应上没有这组头。
另外，头字段里多个 Link 用逗号分隔但漏了引号，解析被截断。
少数情况下是插件对同一语言输出了两个地区代码。
先读响应头里的 Link 字段
curl -sI https://www.example.com/en/manual.pdf | grep -i '^link'然后对照页面里的 hreflang
curl -s https://www.example.com/en/ | grep -o 'hreflang="[^"]*"'修正头字段写法
add_header Link '<https://www.example.com/zh/>; rel="alternate"; hreflang="zh"';复查 301 响应是否也带标记
curl -sI https://www.example.com/en/old | grep -i link改之前我把相关日志按时间截了一段存着，事后对时间线用得上。
恢复的判定其实很直接。头字段与页面内的 hreflang 完全一致，GSC 语言标记冲突消失，PDF 也能被正确归组。
这里还有个坑。HTTP 头适合 PDF、视频这类没有 head 的文件，HTML 页面两处都写就要保证逐字一致。报错文案容易误导，真正的原因往往在相邻那一层的日志里。