企业官网建设流程全解析

本指南基于 Front-End-Checklist 项目skills/privacy-policy技能条目及其规则源文件，系统讲解隐私政策的法律必要性、GDPR 第 13 条必备要素、页脚链接的放置规范、URL 约定与代码实现，并结合仓库中规则的定义方式与审查提示（prompts）体系，给出可直接落地执行的自查与验证方案。读完本文，你将掌握一套"何时需要、如何编写、放哪、怎么实现、怎么验证"的完整隐私政策落地流程。

为什么隐私政策必须"公开可见"而不只是"存在"

Front-End-Checklist 将"在页脚放置隐私政策链接"列为高优先级（priority: high）、入门难度（difficulty: beginner）、预计耗时 15 分钟的检查项，其核心判断标准非常明确：即便政策文件技术上已经发布，但如果站点没有从页面链接到它，依然属于违规。

这条规则的法规依据横跨多个司法辖区：GDPR（欧盟）、CCPA（加利福尼亚）、PIPEDA（加拿大），以及实践中同样会涉及的其他隐私法规。隐私政策的存在价值有两层：

1. 法律层面：向用户披露站点收集了哪些个人数据、为何收集、如何使用、与谁共享、保存多久，以及用户享有哪些权利，是法定的透明度义务；
2. 信任层面：一份清晰、可达、可读的隐私政策是站点可信度的重要信号，直接影响用户对表单填写、账号注册等行为的意愿。

从仓库结构看，这条规则在项目中存在三重体现：技能入口 skills/privacy-policy/SKILL.md、完整实现细节 skills/privacy-policy/references/rule.md，以及内容包的规则源文件 packages/content/rules/en/privacy/privacy-policy.mdx。三份文件共同定义了该规则从"一句话摘要"到"可执行审查提示"的完整链条。

何时必须提供隐私政策

规则明确指出：只要收集了以下任何一类数据，隐私政策就是必需的：

• 电子邮件地址（联系表单、新闻通讯注册）
• 姓名或其他可识别身份的信息
• IP 地址（即便仅用于服务器日志）
• Cookie（尤其是分析类或广告类 Cookie）
• 支付信息
• 通过分析工具收集的使用数据

一个容易被忽视的现实是：如果你的站点服务对象包含欧盟、加利福尼亚、加拿大或英国的用户，那么隐私政策"几乎必然"是必需的——即便你的站点没有显式的用户注册功能，仅凭服务器日志记录 IP 地址或部署了任意一款分析脚本，就已经落入触发范围。

GDPR 第 13 条：合规隐私政策的十项必备要素

规则文件以表格形式给出了 GDPR 合规隐私政策必须包含的内容，这也是审查时逐项对照的清单：

在此基础上，规则特别强调：如果你使用了分析工具、会话回放（session replay）、前端监控或 CDN 日志，必须在政策中说明这些系统是否接收个人数据或伪匿名标识符，并写明每一类数据的保留时长。这一条在实际审查中是最常被忽略的——政策写清了表单数据，却对埋点、日志和监控数据含糊其辞，会直接被判定为不合规。

仓库中与之配套的规则还包括 packages/content/rules/en/privacy/right-to-erasure.mdx（删除权/被遗忘权）与 packages/content/rules/en/privacy/data-minimisation.mdx（数据最小化），它们共同构成"数据权利"（data-rights）子类目，审查时通常一起评估。

隐私政策链接的放置位置

规则对链接的放置提出四项硬性要求：

• 每个页面可见——通常放在页脚；
• 标签清晰——使用 "Privacy Policy" 或 "Privacy Notice"，不要埋在 "Legal" 下拉菜单深处；
• 机器可读——能够被爬虫和无障碍技术访问到；
• 保持更新——必须反映当前真实的数据实践。

附加的必需触点

这里的关键洞察是：隐私政策的可达性要求是触达所有收集数据的场景，而不仅仅是主页。审查清单（Check）中明确要求"检查链接存在于所有页面，而非仅主页"。

URL 约定与可抓取性

搜索引擎和隐私扫描工具会按固定路径模式查找隐私政策，规则给出了推荐约定：

https://example.com/privacy https://example.com/privacy-policy https://example.com/legal/privacy

规则同时明确要求避免在其他页面使用#锚点跳转或模态对话框承载隐私政策——隐私政策必须拥有独立、稳定、可被爬取的 URL。

代码实现：从静态 HTML 到 React/Next.js

标准 HTML 页脚

规则文件给出了可直接复用的标准页脚结构，使用语义化的nav元素与列表，便于无障碍与 SEO 理解：

<!-- Standard footer with privacy link --> <footer> <nav aria-label="Legal"> <ul> <li><a href="/privacy">Privacy Policy</a></li> <li><a href="/terms">Terms of Service</a></li> <li><a href="/cookies">Cookie Policy</a></li> </ul> </nav> </footer>

React/Next.js 组件

对于使用 React/Next.js 的站点，规则提供了组件化实现：

// components/footer.tsx export function Footer() { return ( <footer> <nav aria-label="Legal links"> <a href="/privacy">Privacy Policy</a> <a href="/terms">Terms of Service</a> <a href="/cookies">Cookie Settings</a> </nav> </footer> ) }

在实际工程中，可以从这个最小示例延伸出两个增强点：一是通过 Next.js 的Link组件实现客户端路由跳转（保留同源 SPA 体验的同时，仍应确保/privacy是一个真实可抓取的独立路由页面而非弹窗）；二是结合国际化（i18n）机制将链接文本替换为对应语言环境下的等价表述——规则要求链接文本使用 "Privacy Policy" 或语言环境等价物，以兼顾 SEO 与无障碍识别。

Cookie 横幅不是隐私政策

规则以警告（Warning）形式明确划清了两者的边界：GDPR 合规的 Cookie 同意横幅 ≠ 隐私政策。两者必须同时具备：

• 横幅负责为 Cookie 获取用户同意；
• 隐私政策负责说明全部数据处理活动；
• 两者通常相互链接。

仓库中对应的配套技能 skills/cookie-consent/SKILL.md 与规则 packages/content/rules/en/privacy/cookie-consent.mdx 详细规定了同意的前置性要求——非必要 Cookie（分析、广告、个性化）必须等用户主动接受后才允许加载，预勾选复选框不构成有效同意。两条规则在规则文件中被显式声明为"通常一起审查"（relatedRules），因为实践中它们强耦合：横幅要链到政策，政策要如实描述横幅所允许的各类 Cookie。

在 Front-End-Checklist 中该规则如何被定义与审查

这条规则在项目内容层被结构化为 packages/content/rules/en/privacy/privacy-policy.mdx，其 frontmatter 元数据本身就是一套可被 AI 代理执行的审查指令，值得开发者借鉴其组织方式：

• tldr（快速参考）：六条要点，覆盖"页脚链接、平实语言、触发条件、GDPR 可达性、链接文本、保留期限披露"；
• whyItMatters：一句话的法律后果陈述；
• prompts：按四种审查场景拆分的提示词——
  • check：检查页脚是否含隐私政策链接、目标页是否真实包含联系方式/数据收集说明/用户权利、是否所有页面都有链接、是否披露保留期限与第三方接收方；
  • fix：在每页页脚添加链接，确保目标页写清收集什么、为何收集、如何使用、与谁共享、保留多久、如何行使权利；
  • explain：向用户解释 GDPR/CCPA 的法律要求、必备内容与真正的可达性；
  • codeReview：审查服务端配置、响应头、表单与集成点，标记违规的响应、Cookie 或浏览器行为，并与生产环境的实际响应逐一核对；
• sources：将 GDPR 第 13 条、CCPA 等法规以spec类型、primary权威级别登记为标准依据；
• relatedRules：关联到 cookie-consent、terms-of-service、right-to-erasure、third-party-cookies 四条相邻规则。

技能入口 skills/privacy-policy/SKILL.md 则浓缩了这套元数据，并指向完整实现细节 skills/privacy-policy/references/rule.md，形成"技能摘要 → 深度参考"的两级阅读路径，方便人工与 Agent 快速接入。

验证：自动化检查与人工核对

自动化检查

规则推荐的自动化工具包括 iubenda Privacy Policy Generator（生成合规政策）与 PrivacyPolicies.com（免费生成器）。它们的价值在于从模板层面兜住 GDPR 第 13 条的必备要素，但生成后的内容仍需人工校准以匹配站点真实的数据实践。

人工检查清单

规则给出两项必做的人工核对：

1. 确认已发布政策对表单、分析、日志和账户数据分别给出了具体的保留期限声明；
2. 确认政策与生产环境中 Cookie 横幅、分析配置、监控工具的实际行为一致。

支持说明与浏览器差异

规则在 Support Notes 中特别提示：隐私相关行为可能因浏览器的存储、Cookie 与嵌入行为差异而不同，因此应以支持环境中的用户可见结果为准来验证，而非只依赖服务端逻辑；当同一隐私控制在不同浏览器中表现不一致时，应记录回退方案或平台特定限制。

常见误区与落地建议

综合规则全文，可将最常见的落地误区归纳为四点：

1. 只发布不链接——政策页面存在但没有从任何页面可达，等同于未发布；
2. 政策与实现脱节——政策宣称不收集分析数据，生产环境却加载了分析脚本，人工核对环节专门针对此场景；
3. 用 Cookie 横幅替代政策——横幅与政策职责不同，必须并存且互相链接；
4. 用模态框或#锚点承载政策——破坏可爬取性与可访问性，应使用独立稳定 URL。

落地时建议遵循规则给出的 15 分钟快速路径：先审计触发条件（是否收集上述六类数据）→ 对照 GDPR 第 13 条清单补齐政策要素 → 按 URL 约定创建独立页面 → 在全局页脚组件添加链接（覆盖所有页面）→ 在表单、横幅、邮件等附加触点补链 → 最后按人工检查清单逐项核对政策与生产行为的真实一致性。整个流程在 Front-End-Checklist 中被结构化为一套可复用的检查-修复-解释-代码审查（check / fix / explain / codeReview）闭环，同样适用于将其接入团队自己的合规审查流水线。