rws是浏览器级机制，html无法实现它，仅能配合展示关联关系、提供跳转链接和呈现rationale文案；其核心依赖服务器部署的/.well-known/related-website-set.json文件及跨域双向验证。
Related Website Sets（RWS）本身是浏览器级的声明机制，**HTML 无法直接“实现”RWS**——它不靠前端代码生效，而依赖服务器可访问的 .well-known/related-website-set.json 文件和跨域所有权验证。但 HTML 是展示关联关系、引导用户、配合 RWS 行为的关键一环。
为什么不能用 <link rel="related"> 或自定义 meta 实现 RWS
RWS 不是 HTML 标准的一部分，也不是靠页面内标签声明的。Chrome、Edge（v144 前）等浏览器只读取每个域名根路径下的 /.well-known/related-website-set.json，且该文件必须满足：
• 包含有效的 primary 和完整站点列表
• 所有域名均通过 HTTPS 提供
• 每个成员站点都需在自身域名下提供完全一致的 JSON 内容（双向验证）
• <link>、<meta>、JavaScript 动态注入等前端手段对 RWS 无任何作用，浏览器完全忽略。
HTML 能做的三件实际事情
虽然不能“实现”RWS，但 HTML 是用户侧体验闭环中不可替代的一环：
- 在页面上显式展示关联关系（满足 W3C 对 Associated Sites 的“用户可见性”要求）：比如页脚统一导航、品牌栏标注“同属 XXX 集团”，或使用
<div class="rws-indicator"> 这类语义化容器 <li>为每个关联站点提供可点击的跳转链接，并确保链接 URL 与 <code>related-website-set.json中声明的完全一致（协议、大小写、末尾斜杠） - 在
rationaleBySite字段中引用的文案（如“官方博客站点”），应在对应页面的<meta name="description">或 About 页面中自然呈现，作为人工审核依据 - 可通过
https://example-news.com/.well-known/related-website-set.json直接 GET 访问，返回200 OK和Content-Type: application/json - 内容与你在 RWS 配置中心（如 GitHub PR）提交的 JSON 完全一致，包括字段顺序、空格、引号风格（推荐双引号）
- 所有关联站点（如
https://sports.example-news.com）也必须各自部署相同结构的文件，且primary字段统一指向同一个主站 - 若使用 CDN，需确认其未缓存 404 或重定向响应——首次请求必须真实返回 JSON，否则 Chrome 会直接判定验证失败
-
serviceSites域名（如https://cdn.example-news.com）**不能出现在任何用户的导航路径中**：它不能有独立首页、不能被列在主导航栏、不能在 sitemap.xml 中暴露；否则会被视为违反“非入口点”原则 -
ccTLDs映射中的变体（如"https://example-news.co.uk": ["https://example-news.de"]）必须共享同一 eSLD（有效二级域名），即example-news部分必须完全相同，且不能是通配符或子域名 - Microsoft Edge 自 v144 起已弃用 RWS（2026 年 4 月确认），目前仅 Chrome 稳定支持；Safari、Firefox 无计划支持 —— 所有 HTML 层面的“兼容性适配”都是徒劳的
.well-known 文件必须由 Web 服务器提供，不是前端构建产物
你不能把 related-website-set.json 放进前端打包流程、用 fetch() 加载、或通过 CDN 缓存规则“模拟”它。它必须：
容易被忽略的硬性限制点
很多团队卡在最后一步，不是因为 JSON 写错，而是撞上了这些隐性规则：
