Cookie 扫描：识别服务与 Cookie

横幅要能拿出选择项，前提是先弄清网站上到底加载了什么。为此扫描器会抓取自家页面并加以分析。结果构成服务列表、拦截规则以及 Cookie 声明的基础。

1. 打开“Kakapo Consent”，在“规则”分组中选择“Cookies”。
2. 点击右上角的“立即扫描”——这次运行会抓取首页和最新的四篇文章，也就是最多五个地址。
3. 在表格中逐行检查服务、主机、分类和“启用”开关；分类和开关会立即保存。
4. 如果有遗漏，用“添加服务”手动填入名称、主机和分类。
5. 想要更完整的结果，就在“深度扫描”卡片中点击“开始深度扫描”。

一次运行会分析什么

• HTML 的 src 和 href 标记中所有指向第三方主机的地址
• 响应中的 Set-Cookie 响应头——只有这样，服务器端设置的 Cookie 才会显现出来，并附上实测的有效期
• 依据已知模式识别页面的内联脚本，其中包括 Google Analytics、Google Tag Manager、Google Ads、Meta Pixel、Matomo、Hotjar、Microsoft Clarity、LinkedIn、TikTok、Plausible、HubSpot 和 Intercom
• 脚本通过 document.cookie 自行设置的 Cookie 名称
• 插件自身的代码会被跳过；某个响应正在删除的 Cookie 也不会被报告为发现项

深度扫描

深度扫描有自己的页面预算（默认 8，最多 60），可按需跟随内部链接，并能通过路径模式加以限制（“不抓取”，每行一个模式）。每个第三方主机都会被记录下来，附命中次数、发现位置和引入方式——script、link、iframe、img、source、video、audio、embed、object 和 form，也包括来自 data-src 或 data-lazy-src 的延迟加载地址。纯链接不在其列。已知的跟踪器会自动进入服务列表，其余的可以逐条“应用”或永久“忽略”。

三张结果卡片

• “已发现的 Cookie”：名称、有效期、供应商、目的，以及该名称来自 Set-Cookie 响应头还是来自脚本；“应用”会把它写入 Cookie 声明
• “页面源码中的跟踪器”：不带独立脚本文件、直接写在页面里的服务，附命中次数以及——只要代码中存在——容器 ID 或衡量 ID
• “来自已启用插件的 Cookie”：随附的知识库对已启用插件的了解；若该名称在上次扫描中确实出现过，则带有“已发现”标记

让扫描定期运行

1. 打开“Kakapo Consent”并选择“概述”（德语：„Allgemein“）。
2. 在“日志记录 & 自动化”卡片中把“自动 Cookie 扫描”设置为每天、每周或每月。
3. 需要时填写一个“通知电子邮件”；留空则表示使用站点管理员的地址。
4. 打开“报告新服务”，这样每次自动运行之后，只要出现此前未知的主机就会收到一封电子邮件。
5. 用“立即执行”马上启动一次运行；下方显示下一次和上一次运行的时间。