企业官网的 Cookie 同意与隐私政策怎么做

本文面向正在新建或改版官网的制造业、化工、外贸与 B2B 企业市场负责人，说清企业官网的 Cookie 同意与隐私政策该怎么做：三份文件怎么分工、同意弹窗的合规边界在哪、政策正文必须写清哪些条款、询盘表单和统计脚本的采集范围怎么划、上线前按什么清单验收。适用对象是在中国境内运营、同时面向国内与海外访客的企业站点，全文约三千五百字，读完需要十分钟，可以直接当作交付验收的依据。

为什么这件事在 2026 年绕不过去

三股力量同时压过来。第一是法规。中国境内的《网络安全法》《数据安全法》《个人信息保护法》已经把告知同意、最小必要、保存期限、个人权利响应这几件事写成了硬要求；面向欧盟访客的站点还要叠加 GDPR 与 ePrivacy 指令对 cookie 的同意规则；做美国市场的，加州 CCPA 与 CPRA 也要求披露信息的共享与出售。三条线不完全一样，但底线一致：你得说清收什么、为什么收、给谁、留多久。

第二是商业。B2B 采购的尽调流程这几年明显变长，大客户的合规部门在签合同前会翻供应商官网，看有没有像样的隐私政策、有没有 Cookie 清单、表单有没有告知。这一步在化工、医药、汽车零部件这些行业已经变成准入项。官网的合规页写得含糊，等于在第一轮筛选里自己扣分。

第三是技术。同意弹窗做过头会挡住首屏、挡住搜索引擎和 AI 爬虫，直接影响自然流量。不少企业为了合规加了一个全屏遮罩，结果正文在遮罩下面，抓取程序拿到的页面和用户看到的完全不是一回事。合规和获客在这里是同一件事的两面，只顾一头都会出问题。

现实情况是，多数企业官网的隐私政策是从同行那里复制改的，条款里写着从未启用的第三方、并不存在的境外服务器、点不进去的注销入口。这种文本不但没有保护作用，反而是风险：一旦真出事，纸面承诺与实际行为不一致，会被认定为未尽告知义务。

三份文件别混为一谈：隐私政策、Cookie 政策、用户协议

最常见的问题是三份文件被塞进一个页面，标题叫法律声明，内容混在一起，访客看不懂，监管也看不出你到底做了什么。正确做法是拆开，各司其职。

隐私政策管的是个人信息处理活动的总账：你是谁、收哪些信息、为什么收、依据是什么、保存多久、给谁、用户怎么行使权利、政策怎么更新。它覆盖的不只是网站，还包括线下收集、展会名片、客服通话，只要进入同一套系统就该一并说明。

Cookie 政策管的是浏览器端的小数据：站上用了哪些 cookie 与同类技术（localStorage、像素标签、SDK），每一个的名字、来源域名、用途归类、有效期、是否第三方、能不能关。这份文件必须是清单式的，逐条列，不能只写一句本站使用 cookie 以改善体验。

用户协议管的是使用规则：账号能不能转让、内容版权归谁、禁止行为、免责范围、争议解决。它和隐私政策是两件事，很多站点把免责条款写进隐私政策，逻辑上就是错的。

还有一份常被漏掉的文件：第三方处理者清单。统计工具、在线客服、邮件营销平台、CDN、表单收集服务、CRM，这些都会接触访客数据。清单里要写清服务商名称、所在国家或地区、接触的数据类型、处理目的，以及是否涉及跨境传输。这份清单在客户尽调时经常被直接索要。

Cookie 同意弹窗：合规底线与不挡生意的做法

先把 cookie 分类，这是所有后续动作的基础。必要 cookie 是维持登录态、安全校验这类离开就无法提供服务的，可以不经同意；统计类、营销类、功能偏好类原则上都要先取得同意再写入。分类错了，弹窗做得再漂亮也是白做。

几条硬底线：访客同意之前不能写入非必要 cookie；同意与拒绝的入口要同样显眼，不能用大色块放接受、灰色小字放拒绝；不能预勾选；不能因为访客拒绝就阻断访问；同意要留证，记录时间、政策版本号、访客的选择项。留证的意义在于日后能证明你确实取得过同意。

中国境内目前没有专门针对 cookie 的单行法，实务上参照《个人信息保护法》的告知同意规则，以及《个人信息安全规范》对明示同意、撤回同意、去标识化的要求。真正严格的是面向欧盟访客的场景，ePrivacy 指令要求非必要 cookie 必须先取得事先同意，GDPR 则对同意本身提出自由给出、具体、知情、明确四项条件。做法上，按欧盟口径实现基本能覆盖其他市场。

技术选型上，第三方 CMP（同意管理平台）适合多站点、多语言、需要留证审计的集团；自研弹窗成本低，但要自己实现分类开关、按类别拦截脚本、记录同意状态、支持撤回。自研最容易漏的是脚本拦截：光弹一个框而不真正拦住第三方脚本，等于什么都没做。

还有一点常被忽略：撤回同意的入口要和给出同意一样方便。放一个常驻的 Cookie 设置链接在页脚，比任何事后说明都实用。

隐私政策正文的六项必备内容

一份能通过尽调的隐私政策，至少要回答六个问题。

第一，你是谁。写明公司全称、注册地址、联系方式，以及个人信息保护负责人的邮箱。只留客服电话是不够的，用户行使权利需要一个可留痕的书面入口。

第二，收什么。按场景列：注册收什么、询盘收什么、订阅收什么、浏览行为收什么。分开写比笼统列一长串字段有用，因为用户和监管关心的都是具体场景。

第三，为什么收、依据是什么。每个场景对应一个明确目的，以及对应的合法性基础：取得同意、履行合同所必需、履行法定义务所必需，这几类要分清。写成提升服务体验这种空话，等于没有告知。

第四，留多久。每一类数据给出保存期限或期限的确定方法。没有期限的政策是不合格的。

第五，给谁。列出共享、转让、公开披露的对象类型与具体服务商，说明是否跨境，以及跨境的目的地与传输方式。

第六，用户怎么行使权利。查询、复制、更正、删除、撤回同意、注销账号、解释说明，逐项给出路径与响应时限。常见错误是只留一个邮箱却不写多久回复。

另外三块视情况补充：未成年人信息的处理规则、政策更新机制与版本记录、敏感个人信息的单独说明。B2B 站点确实很少涉及未成年人，但一旦有校园招聘、开放日报名这类场景，就得写进去。

询盘表单与统计脚本的采集边界

询盘表单是最容易越界的地方。最小必要原则落地成具体字段：姓名、公司名称、职位、邮箱或电话、需求描述、所属行业，这些与业务直接相关；身份证号、家庭住址、银行账号、与采购无关的健康或家庭信息，一律不收。表单字段每多一个，转化率就掉一点，合规风险就升一点，两头都不划算。

告知要放在提交按钮旁边，一行话说明用途并链接到隐私政策，配合一个不预勾选的同意框。同意框的文案不要写成我已阅读并同意所有条款这种捆绑式表述，收集与营销用途要分开授权，邮件订阅尤其要单独勾选。

统计脚本要先想清数据去向。GA4 的数据会传输到境外服务器，涉及个人信息出境的合规路径；百度统计、Umami、Matomo 这类可以本地部署的方案，在数据留在境内这一点上有优势。选型时把这一条纳入考虑，比事后补协议省事得多。

询盘数据进了 CRM 之后，保存期限与访问权限要一起定。销售离职、账号回收、导出权限、脱敏查看，这些属于内部管理，却恰恰是泄露事故的高发环节。建议按季度清理一次超过保存期限且已无跟进价值的记录。

与 SEO 和 GEO 的关系：别让同意管理挡住生意

这一节值得单独讲，因为合规做过头会直接伤流量，而且伤口在数据报表上表现为流量下滑，很难归因到弹窗头上。

第一个坑是全屏遮罩遮挡正文。爬虫抓取时读到的是一个近乎空壳的文档，正文被隐藏或根本没有渲染，收录和 AI 摘要都会出问题。正确做法是正文始终由服务端渲染进 HTML，弹窗用固定定位的浮层覆盖视觉，但不隐藏正文节点。

第二个坑是同意前不加载任何内容。有些实现把整个页面主体放在脚本里，等访客点了接受才注入。这种站点在带 AI 摘要的搜索里几乎不可能被引用，因为摘要生成依赖可抓取的静态正文。合规上也没有必要这么做，必要 cookie 与正文渲染本来就是两件事。

第三个坑是弹窗反复出现、拒绝之后每次刷新都弹。体验上会推高跳出率，行为数据变差又会反过来影响排名。把访客的选择记住，再给一个明确的撤回入口，就够了。

延伸阅读可以看站内这两篇：讲抓取与引用机制的AI 搜索时代企业网站如何被AI优先引用，以及讲上线前合规前置动作的网站备案全流程指南。前者的判断标准同样适用于同意管理的实现方式，后者说明了备案信息与站内公示信息的一致性要求。

上线前验收清单

复审机制：一年一次不够

政策不是写完就结束的文件。三种情况必须触发更新：新增了第三方工具或统计脚本、业务场景发生变化（比如新开了海外站、上线了会员系统）、法规或监管口径有调整。除此之外，至少每年做一次全面复审。

复审时不要只看文本，要对照实际行为核一遍：站上到底写了哪些 cookie、表单到底收了哪些字段、数据到底存在哪台服务器、第三方到底有哪几家。文本与事实的偏差是最常见的隐患，也是最容易在尽调中被发现的。

每次更新保留版本号、生效日期与变更摘要，旧版本存档。有客户要求提供历史版本时能立刻给出，这本身就是专业度的体现。

回到最初的问题：这件事该谁做。市场部定场景与文案，技术部实现同意管理与脚本拦截，法务审条款，三方缺一不可。把它当成上线前的一个验收项排进项目计划，比事后补救便宜得多。