让AI能读懂你的官网，不等于让AI能读走你的所有数据。改造的第一步不是加Schema标记，而是做数据分级。

让AI能读懂你的官网，不等于让AI能读走你的所有数据。改造的第一步不是加Schema标记，而是做数据分级。

本文要点：AI友好化改造（结构化标记、llms.txt、AI爬虫开放）在提升内容可读性的同时，也在放大数据的可提取性。本文给出一条可落地的工程路径：先做L1-L4数据分级，再按分级结果配置robots.txt精细化管理、llms.txt安全边界、JSON-LD敏感字段管控；配套三个可运行的扫描验证脚本（PII暴露扫描、robots拦截验证、Schema敏感字段检查）；最后是合规审计要点和一份可直接照做的检查清单。

在易科势腾给企业做AI友好化改造的项目里，数据安全分级往往是官网改造的第一步——先划边界，再谈开放。

阅读提示：安全/运维同学重点看三、四节的三个脚本；合规和业务同学可先看二、五、七节；想直接动手的，把第七节检查清单和三个脚本拉下来就能开工。

一、AI友好化改造引入了新的数据暴露面

企业在做AI友好化改造时，关注点通常在"怎么让AI更好地理解我的内容"——加结构化标记、部署llms.txt、开放AI爬虫权限。但有一个问题容易被忽略：你在让AI更容易理解内容的同时，也在让AI更容易提取内容。

这带来一个直接的安全问题：原本散在网页深处、用户需要翻几页才能找到的信息，通过结构化标记后，AI爬虫可以一抓就走。如果你的产品页面里有客户信息、技术文档里有内部架构细节、FAQ里有尚未公开的产品规划——这些内容在传统SEO时代不太容易被批量提取，但在AI友好化之后，它们的可提取性大大增强。

这不是说不要做AI友好化改造，而是说改造前必须先做一件事：数据安全分级。

举两个真实场景：

某客户在给产品FAQ页面加Schema.org标注时，把FAQPage的Schema里包含了"内部测试中的功能说明"——这些内容本来只对员工可见，但因为页面模板统一加了结构化标记，外部AI爬虫直接抓走了。

另一个客户的案例页面中包含了真实客户名称和联系方式，在加JSON-LD标注后，AI在回答"XX行业有哪些供应商"时，直接把这些客户信息作为推荐依据暴露给了所有人。

这些问题的根源不是技术实现有bug，而是改造流程缺了"数据分级"这一步。

二、适用法律法规框架

在动手做技术方案之前，先理清楚你的AI友好化改造涉及哪些法律法规的约束。这不是法务部门的事——作为技术负责人，你至少要知道红线在哪里。

2.1 《个人信息保护法》（PIPL）

PIPL对AI友好化改造最直接的影响在于：如果你的官网包含个人信息（客户姓名、联系方式、用户评价中的个人信息等），在让AI爬虫抓取这些内容前，需要确认你是否有合法的个人信息处理基础。

PIPL第十三条规定的合法事由包括：

• 取得个人同意
• 为订立、履行合同所必需
• 为履行法定职责或法定义务
• 其他法定事由

在AI友好化改造场景下，最需要注意的条款是第十四条：同意必须是明确、自愿的。如果你的客户案例中使用了客户名称和联系方式，但当初获取客户同意时并没有明确告知"这些信息会被公开展示并可能被AI系统抓取和使用"，那在AI友好化改造时就存在合规风险。

工程落地建议：

• 对外展示的案例页面，脱敏处理客户真实名称（可用"某XX行业头部企业"替代）
• 客户联系方式（电话、邮箱）不在结构化数据中暴露
• 用户评论/评价中包含个人信息的，做字段级脱敏后再加结构化标记
• 隐私政策中补充说明：网站内容可能被AI系统抓取和使用

2.2 《网络安全法》（2025年修正）

《网络安全法》于2025年10月28日完成修正，2026年1月1日起施行。这次修正的重点之一，是把不履行网络安全保护义务的处罚力度整体抬高，与《数据安全法》拉齐。

修正后的第六十一条按后果分档：

情形	罚款幅度
不履行保护义务，警告并责令改正	可处1万-5万
拒不改正，或已导致危害网络安全后果	5万-50万
关键信息基础设施运营者（对应各档）	10万-100万
造成大量数据泄露等严重危害后果	50万-200万
造成特别严重后果（如CII丧失主要功能）	200万-1000万

除单位罚款外，各档还规定了直接负责的主管人员和其他直接责任人员的个人罚款（最高100万）——数据安全合规不是"罚公司"，具体经办的技术负责人同样要担责。

对AI友好化改造的影响：

• 网站作为网络运营者，安全保护义务明确包括防止网络数据泄露
• 开放AI爬虫权限、新增内容API，都是在扩大攻击面，改造要同步规划、同步建设、同步运行
• 一旦因改造引入的漏洞导致数据泄露，罚则直接按上表执行——合规不是可选项

工程落地建议：

• AI爬虫权限开放要有白名单机制，不是所有爬虫都放行
• 新增的API接口（如给AI提供的内容API）要有认证和限流
• 网站安全扫描要在改造前后各做一次，确认没有引入新的漏洞

2.3 《网络数据安全管理条例》

2024年9月公布的《网络数据安全管理条例》第十八条特别提到了自动化工具：

“网络数据处理者使用自动化工具访问、收集网络数据，应当评估对网络服务带来的影响，不得非法侵入他人网络，不得干扰网络服务正常运行。”

这条规定有两个方向的含义：

对你自己用AI工具抓取数据时的约束：如果你在改造过程中使用AI工具分析竞品网站或行业数据，要确保不违反对方网站的robots规则，不干扰对方服务。

对你被AI爬虫抓取时的权利：你有权通过robots.txt和访问控制来管理AI爬虫对你网站数据的访问。合理使用这些工具不是"阻碍AI发展"，而是行使数据主权。

条例第十九条专门针对生成式AI服务：

“提供生成式人工智能服务的网络数据处理者应当加强对训练数据和训练数据处理活动的安全管理。”

这意味着如果你的网站内容被AI用于训练，你可以在robots.txt中明确拒绝训练用爬虫（如GPTBot、ClaudeBot），同时允许搜索索引爬虫（如OAI-SearchBot）。

2.4 《生成式人工智能服务管理暂行办法》

虽然这个办法主要约束AI服务提供者，但对企业的AI友好化改造也有间接影响。如果你的官网嵌入了AI对话功能（如智能客服），你就是生成式AI服务的提供者，需要遵守以下要求：

• 训练数据来源合法
• 生成内容标识（用户有权知道回答来自AI）
• 个人信息处理合规
• 安全评估和备案（面向公众的生成式AI服务需向网信部门备案）

三、数据分级：改造前的第一件事

在开始任何技术改造之前，先做一轮完整的数据资产盘点和分级。这是整个数据安全合规工作的基础。

3.1 数据分级标准

建议按照以下四个等级对企业官网及关联系统中的数据进行分级：

等级	名称	包含内容	AI友好化策略
L1	公开信息	产品介绍、公司简介、公开案例、行业分析	完全开放，可加结构化标记
L2	内部信息	产品路线图、内部技术文档、未公开案例	不对外暴露，不在结构化标记中出现
L3	敏感信息	客户真实信息、合同条款、定价策略	脱敏后可部分公开，关键信息不出现在公开页面
L4	机密信息	核心算法、源代码、安全架构	完全隔离，禁止出现在任何对外内容中

分级的判断标准很简单：这条信息如果被AI提取并展示给外部用户，会不会造成商业损失或合规风险？如果会，至少是L2。

3.2 盘点清单

做数据盘点时，需要覆盖以下数据源：

官网页面（HTML）
├── 产品页面（参数、功能列表、定价）
├── 案例页面（客户名称、项目详情、效果数据）
├── 关于我们（公司信息、团队信息、联系方式）
├── 博客/新闻（文章内容、评论数据）
├── 帮助中心（FAQ、使用文档）
└── API文档（接口定义、认证信息）

关联系统
├── 知识库（内部文档、技术方案）
├── CRM（客户信息、销售记录）
├── CMS后台（内容管理、用户数据）
└── 日志系统（访问日志、操作日志）

盘点的产出物是一份数据分级清单，格式不复杂，关键是覆盖全：

数据项	所在位置	分级	处理建议	负责人
客户案例中的公司名称	/cases/customer-a.html	L3	替换为"某制造业头部企业"	市场部
产品技术参数表	/products/specs.html	L1	加JSON-LD Product标记	技术部
团队成员姓名和照片	/about/team.html	L2	保留姓名，移除个人联系方式	HR
FAQ中的内部测试功能	/faq/index.html	L2	从公开FAQ中移除	产品部

这份清单不是一次性的文档，而是持续维护的。每次官网内容更新或AI友好化改造推进前，都要对照清单检查。

3.3 用脚本辅助盘点：官网PII暴露扫描

人工逐页翻找PII太慢，而且容易漏。可以写个简单的扫描脚本，把官网页面过一遍，自动标出出现手机号、邮箱、身份证号的位置——扫出来的页面直接进数据分级清单，按L3处理：

# scan_site.py —— 官网PII暴露面扫描（数据分级辅助工具）
# 用法：python3 scan_site.py <站点根URL>
import re
import sys
import urllib.request

PII_PATTERNS = {
    # (?<!\d)(?!\d)边界断言：防止身份证、订单号里的数字片段被误匹配成手机号
    "手机号": re.compile(r"(?<!\d)1[3-9]\d{9}(?!\d)"),
    "邮箱": re.compile(r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"),
    "身份证号": re.compile(
        r"[1-9]\d{5}(?:19|20)\d{2}(?:0[1-9]|1[0-2])"
        r"(?:0[1-9]|[12]\d|3[01])\d{3}[\dXx]"),
}

def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": "PII-Scanner/1.0"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        return resp.read().decode("utf-8", "ignore")

def mask(value):
    """掩码：手机号/身份证保留前3后4，邮箱保留用户名首字符和域名"""
    if "@" in value:
        local, domain = value.split("@", 1)
        return local[0] + "***@" + domain
    return value[:3] + "****" + value[-4:]

def scan_page(url):
    try:
        text = re.sub(r"<[^>]+>", " ", fetch(url))  # 去掉HTML标签
    except Exception as e:
        print(f"  [跳过] {url}（{e}）")
        return []
    hits = []
    for name, pattern in PII_PATTERNS.items():
        for m in pattern.finditer(text):
            hits.append((name, mask(m.group())))
    return hits

def main():
    base = sys.argv[1]
    pages = [base]
    try:  # 有sitemap就从sitemap补全页面清单，没有则只扫首页
        sm = fetch(base.rstrip("/") + "/sitemap.xml")
        pages = re.findall(r"<loc>(.*?)</loc>", sm)[:50]
    except Exception:
        pass
    print(f"共 {len(pages)} 个页面，开始扫描……\n")
    for page in pages:
        hits = scan_page(page)
        if hits:
            print(f"[!] {page}")
            for name, value in hits[:5]:
                print(f"    发现{name}: {value}")
    print("\n扫描完成：把命中页面加入数据分级清单，按L3处理。")

if __name__ == "__main__":
    main()

四点说明：

• 正则能稳定识别的是格式固定的PII（手机号、邮箱、身份证），人名、地址这类需要NER模型，脚本先不覆盖，人工补查
• 长数字串（身份证号、订单号）里的片段可能被手机号规则误匹配，脚本已加边界断言降低误报，命中的结果仍建议人工复核
• 脱敏后输出，扫描结果本身不落原始PII，避免扫描工具自己变成泄露源
• sitemap解析最多取前50页，适合中小站点快速盘点；大站需要分批跑或改为完整遍历，避免漏扫

四、技术层面的安全措施

数据分级做完之后，技术改造就有明确的边界了：L1数据充分开放并做结构化标记，L2数据限制AI爬虫访问，L3数据脱敏后才可公开，L4数据完全隔离。

4.1 robots.txt的精细化管理

大多数企业的robots.txt是这样的：

User-agent: *
Disallow: /admin/
Disallow: /api/

这种写法在AI时代太粗糙了。你需要对不同类型的爬虫做精细化管理：

# ===== 训练用爬虫（可控，根据你的策略决定是否放行）=====
User-agent: GPTBot
Disallow: /internal/
Disallow: /api/
Allow: /

User-agent: ClaudeBot
Disallow: /internal/
Disallow: /api/
Allow: /

# Bytespider兼具搜索索引与训练抓取双重用途，按训练类从严管理
User-agent: Bytespider
Disallow: /internal/
Disallow: /api/
Allow: /

# ===== 搜索索引爬虫（建议放行）=====
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Googlebot
Allow: /

# ===== 默认策略 =====
User-agent: *
Disallow: /admin/
Disallow: /api/
Disallow: /internal/

关键设计原则：

• 将训练用爬虫和搜索索引爬虫分开管理。训练用爬虫会拿走你的数据用于训练模型，你的内容可能出现在竞品的AI回答中；搜索索引爬虫只在用户搜索时引用你的内容，附带来源链接
• L2级别的内容路径（如/internal/）对所有AI爬虫关闭
• L2的判断标准是URL可达性，不是有没有入口链接——内容放在公开路径下、只是不在导航里露出来，sitemap、目录遍历、搜索缓存都可能把它暴露出去，L2数据要么真隔离，要么接受它可能被看到
• L3级别的内容在脱敏后可以放在公开路径下，但要注意脱敏后的页面不要再缓存原始数据

一个提醒：robots.txt是约定协议而非强制手段——主流大厂爬虫会遵守，但不在承诺范围内的爬虫可以无视它（包括伪装成普通浏览器UA的采集器），别把它当成唯一的防线。L2/L3的数据，核心靠"不出现在公开路径"来保护，而不是靠robots拦。

改完robots.txt，可以用脚本验证拦截是否真的生效——按robots的匹配规则模拟各爬虫的访问判定：

# check_robots.py —— 验证L2/L3路径是否被AI爬虫正确拦截
# 用法：python3 check_robots.py robots.txt
import sys

def parse_rules(text):
    """把robots.txt解析为 {user_agent: [(allow/disallow, path)]}"""
    rules, current = {}, None
    for line in text.splitlines():
        line = line.split("#")[0].strip()  # 去注释
        if not line:
            continue
        key, _, value = line.partition(":")
        key, value = key.strip().lower(), value.strip() or "/"
        if key == "user-agent":
            current = rules.setdefault(value.lower(), [])  # UA键统一小写，避免查询时大小写不一致
        elif key in ("allow", "disallow") and current is not None:
            current.append((key, value))
    return rules

def match_length(path, rule_path):
    """按robots标准算匹配长度：最长路径匹配优先"""
    path = path.split("?")[0]
    if rule_path.endswith("$"):
        return len(rule_path) - 1 if path == rule_path[:-1] else -1
    return len(rule_path) if path.startswith(rule_path) else -1

def is_allowed(ua, path, rules):
    ua_rules = rules.get(ua.lower(), rules.get("*", []))
    best, best_len = "allow", -1
    for directive, rule_path in ua_rules:
        ml = match_length(path, rule_path)
        if ml > best_len or (ml == best_len and directive == "allow"):
            best, best_len = directive, ml   # 同长度时allow优先（Google约定）
    return best == "allow"

def main():
    with open(sys.argv[1]) as f:
        rules = parse_rules(f.read())
    tests = [
        ("GPTBot", "/blog/rag-guide.html"),   # L1，应放行
        ("GPTBot", "/internal/arch.html"),    # L2，应拦截
        ("GPTBot", "/api/content"),           # L2，应拦截
        ("OAI-SearchBot", "/blog/rag-guide.html"),  # 搜索爬虫，应放行
        ("Googlebot", "/"),                   # 默认爬虫，应放行
    ]
    print(f"{'爬虫':<16}{'路径':<30}结果")
    for ua, path in tests:
        result = "放行" if is_allowed(ua, path, rules) else "拦截"
        print(f"{ua:<16}{path:<30}{result}")

if __name__ == "__main__":
    main()

把站点根目录的robots.txt存下来，跑一次，五分钟就能确认L2/L3路径没有被意外放行。

在易科势腾的实际改造项目中，robots.txt是官网改造里第一个动手改的文件——它的配置直接决定了整个改造的暴露面大小，值得花半天时间仔细调。

4.2 llms.txt的正确使用

llms.txt是近一两年出现的社区提案（非官方Web标准），类似于给AI爬虫的"网站地图"。主流AI爬虫在逐步支持读取，但并非全部都会读取——把它当辅助手段，别当官方协议依赖。它放在网站根目录，告诉AI爬虫"这个网站有哪些内容，分别是什么类型"。

一个规范的llms.txt示例：

# 示例科技

> 面向制造业提供工业视觉检测设备，2015年成立，产品覆盖汽车零部件、3C电子等行业。

## 产品与服务
- [视觉检测设备](/products/vision): 产线外观检测与缺陷识别
- [数据采集系统](/products/iot): 设备运行数据采集与分析
- [售后服务](/services/support): 设备安装、调试与培训

## 技术文档
- [设备选型指南](/blog/selection-guide): 按产线类型选择检测方案
- [常见故障排查](/blog/troubleshooting): 现场问题处理手册

## 常见问题
- [产品FAQ](/faq): 高频问题解答

llms.txt的安全要点：

• 只列出L1级别的公开内容，不要把L2/L3内容的URL放进去
• 公司简介中不要包含敏感信息（如内部组织架构、未公开的战略方向）
• 定期更新，确保列表中的链接都是有效的

4.3 结构化数据的安全边界

JSON-LD结构化标记是AI友好化改造的核心技术手段，但也是数据暴露的高风险点。

一个常见的安全隐患：开发者在使用CMS模板系统时，为了省事，会对所有页面统一应用同一套Schema模板。这意味着即便是L2/L3级别的页面，也会被自动加上结构化标记。

安全实践：

• 结构化标记按页面类型分别配置，不做全站统一模板
• Product Schema中只包含公开的产品参数，不包含内部定价策略
• Organization Schema中的联系方式只放公开信息（客服电话、通用邮箱），不放个人联系方式
• Article Schema中的author字段，如果作者不希望个人信息被AI抓取，用团队名替代个人名
• 上线前检查每个页面的Schema输出，确认没有多余字段

上线前检查Schema输出，人工逐页看太累，写个脚本自动扫——递归遍历页面里的JSON-LD，找出敏感字段：

# check_schema.py —— 检查页面JSON-LD输出是否包含敏感字段
# 用法：python3 check_schema.py <页面URL>
import json
import re
import sys
import urllib.request

# 结构化数据中不应出现的字段
SENSITIVE_KEYS = ["telephone", "email", "faxNumber", "streetAddress",
                  "postalCode", "price", "lowPrice", "highPrice",
                  "vatID", "taxID", "member", "employee"]

def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": "Schema-Checker/1.0"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        return resp.read().decode("utf-8", "ignore")

def walk(node, path=""):
    """递归遍历JSON，找敏感字段"""
    if isinstance(node, dict):
        for k, v in node.items():
            if k in SENSITIVE_KEYS:
                print(f"[!] 敏感字段: {path}.{k}")
            walk(v, f"{path}.{k}")
    elif isinstance(node, list):
        for i, item in enumerate(node):
            walk(item, f"{path}[{i}]")

def main():
    url = sys.argv[1]
    html = fetch(url)
    blocks = re.findall(
        r'<script type="application/ld\+json">(.*?)</script>', html, re.S)
    if not blocks:
        print("未发现JSON-LD结构化标记。")
        return
    print(f"发现 {len(blocks)} 段JSON-LD，检查敏感字段……\n")
    for i, block in enumerate(blocks, 1):
        try:
            walk(json.loads(block), f"LD[{i}]")
        except json.JSONDecodeError:
            print(f"[!] LD[{i}] JSON解析失败，请检查语法")
    print("\n检查完成：如无[!]输出，说明结构化标记中没有敏感字段。")

if __name__ == "__main__":
    main()

备注：脚本直接抓取静态HTML，拿不到JS动态渲染的JSON-LD（如前端框架运行时注入的标记）。不过多数AI爬虫同样不执行JS，脚本的视野和AI爬虫的视野基本一致——把静态标记查干净，AI能看到的基本也就查干净了。

4.4 API安全

如果你的AI友好化改造涉及对外提供内容API（如RESTful接口或MCP协议），安全要求会更高——因为API返回的是结构化数据，比网页更容易被批量提取。

API安全配置建议：

api_security:
  authentication:
    type: oauth2
    token_expiry: 3600s
  rate_limiting:
    requests_per_minute: 60
    requests_per_day: 1000
  response_filtering:
    # 根据调用方权限过滤返回字段
    public_fields: [name, description, category, public_specs]
    authenticated_fields: [pricing, internal_specs, case_details]
  logging:
    enabled: true
    retention: 180d
    fields: [timestamp, client_id, endpoint, response_summary]
  data_minimization:
    # 只返回请求的字段，不返回全量数据
    default_mode: selective

五、合规审计与日志

合规不只是"做对了"，还要能证明"做对了"。审计日志是证明合规的关键证据。

5.1 需要记录什么

在AI友好化改造的背景下，以下操作需要被记录：

日志类别	记录内容	留存要求
爬虫访问日志	爬虫类型、访问URL、访问频率、响应状态	至少6个月
结构化标记变更日志	变更时间、变更内容、操作人	至少1年
API调用日志	调用方、接口、参数摘要、返回数据量	至少6个月
数据分级变更日志	数据项、原级别、新级别、变更原因	至少1年
敏感数据访问日志	谁在何时访问了L3/L4数据	至少1年
页面内容变更日志	页面URL、变更时间、变更人	至少6个月

留存期限参考《网络数据安全管理条例》和等保2.0的要求。金融、医疗等特殊行业可能有更长的留存要求。

5.2 日志脱敏

审计日志本身也可能成为数据泄露源。如果日志中记录了用户查询内容或API返回的数据，这些数据中可能包含PII。

日志脱敏的技术方案：

• 对查询参数做正则匹配，识别手机号、身份证号、邮箱等PII
• 识别到PII后做掩码处理（如 138****1234）
• 日志存储时做字段级加密，密钥与日志存储分离
• 日志查询需要授权，敏感日志查询需要二次审批

5.3 定期合规检查

建议建立以下定期检查机制：

月度检查：

• 爬虫访问日志分析：有没有异常的爬虫行为（如某爬虫短时间大量请求L2内容）
• robots.txt有效性验证：确认L2/L3路径确实被正确拦截（直接跑4.1的脚本）
• 结构化标记审查：抽检10个页面，确认Schema中没有敏感信息（直接跑4.3的脚本）

季度检查：

• 数据分级清单更新：新增页面是否已分级，级别是否需要调整
• 跨平台内容一致性检查：公司基础信息在各平台是否一致
• API权限审查：调用方权限是否合理，有没有多余的授权

年度检查：

• 全量数据安全评估：对照最新法规要求，检查合规缺口
• 第三方安全审计：建议引入外部安全团队做渗透测试
• 合规报告生成：整理年度合规报告，作为内部审计和监管检查的依据

六、不同行业的合规差异

AI友好化改造的数据安全要求在不同行业有显著差异。以下三个行业的合规要求最严格，改造时需要特别注意。

6.1 金融行业

金融行业的官网通常包含理财产品介绍、利率信息、风险提示等。这些内容在AI友好化改造时的特殊要求：

• 产品页面结构化标记中不能包含未公开的收益率数据
• 客户案例需要彻底脱敏，不能暴露客户资产规模等敏感信息
• 智能客服的AI回答中涉及投资建议的，需要有风险提示标识
• 需要符合《个人金融信息保护技术规范》的要求

6.2 医疗行业

医疗行业的官网和自媒体内容通常涉及疾病知识、诊疗方案、医生信息等。

• 医疗信息属于敏感个人信息，PIPL对敏感信息的处理要求更严格
• 结构化标记中不能包含患者个人信息
• 医生信息标注时，执业资格信息可以公开，个人联系方式不能公开
• AI客服回答医疗咨询时，必须标注"仅供参考，不构成诊疗建议"

6.3 政企行业

政府机构和国企的官网改造需要额外关注：

• 不能在结构化数据中暴露内部组织架构和人员编制
• 涉密信息完全隔离，不能出现在任何对外页面上
• 需要通过等保2.0三级认证
• 政务数据开放遵循中办、国办《关于加快公共数据资源开发利用的意见》等文件的要求，涉及公共数据开放的，先走内部审批流程

七、一份可执行的安全检查清单

把前面的内容浓缩成一份检查清单，改造时逐项对照：

改造前：

• 完成数据资产盘点，建立分级清单（可用3.3的扫描脚本辅助）
• 确认所有L3/L4数据的存储位置和访问权限
• 检查现有隐私政策是否覆盖AI抓取场景
• 评估是否有需要补充的合规文件（如PIPL影响评估报告）

改造中：

• robots.txt按爬虫类型分级配置（配完跑一遍4.1的验证脚本）
• llms.txt只包含L1公开内容
• JSON-LD结构化标记按页面类型单独配置，不做全站统一模板（上线前跑一遍4.3的检查脚本）
• 产品参数页面标注前，确认参数数据已脱敏
• FAQ页面内容确认不含未公开信息
• API接口加认证、限流、日志
• 新增的AI对话功能标注"AI生成"标识

改造后：

• 使用结构化数据测试工具检查每类页面的Schema输出
• 用AI搜索工具测试品牌搜索结果，确认没有敏感信息泄露
• 服务器日志确认AI爬虫只访问了允许的路径
• 审计日志系统上线并配置告警
• 建立月度/季度/年度安全检查机制

八、FAQ：高频问题速答

Q1：加了JSON-LD结构化标记，是不是等于把数据直接暴露给AI？

A：取决于你在Schema里放了什么。结构化标记只暴露你写进去的字段——产品名、参数、价格放了就会被抓走，没放就不存在暴露问题。所以原则是：L1数据才进结构化标记，L2/L3数据压根别写进去。Schema本身不是漏洞，全站统一模板批量上标记才是漏洞。

Q2：robots.txt能拦住所有AI爬虫吗？

A：不能。robots.txt是君子协议，主流大厂爬虫（GPTBot、Googlebot等）会遵守，但恶意爬虫可以无视它。所以L2/L3数据的保护不能依赖robots——核心手段是让敏感内容不出现在公开路径下，robots只是第一道筛子。

Q3：llms.txt和sitemap.xml都要维护吗？有什么区别？

A：都要，但作用不同。sitemap.xml是给搜索引擎爬虫的，帮它发现页面；llms.txt是给AI爬虫的，相当于"站点简介+重点内容目录"，告诉AI哪些内容是值得引用的。安全口径一致：两者都只放L1内容，L2/L3路径不要出现在任何"地图"里。

Q4：官网改造和公众号改造的数据安全要求一样吗？

A：思路一样，手段不同。共同点是都先做数据分级、都按L1-L4管内容。区别在于：官网你有完全的控制权（robots.txt、llms.txt、Schema都归你管），公众号内容在微信生态里，你只能管内容本身——敏感信息就别往公众号发，发了平台的反爬你也拦不住抓取。

Q5：做完数据分级就安全了吗？还需要做什么？

A：分级只是划边界，安全要靠闭环：分级 → 按级别配置技术管控（robots/llms.txt/Schema）→ 审计日志留证 → 定期用脚本复查。建议把本文第七节检查清单里的"月度/季度/年度"机制建起来，改造不是一次性项目，是持续运营的流程。

九、先分级，再改造

AI友好化改造和数据安全合规不是对立的——很多企业觉得"做AI友好化就是要把数据都开放出去"，这其实是对改造的误解。

真正的AI友好化是"让AI理解你愿意让它理解的内容"，而不是"把所有内容都暴露给AI"。数据分级是边界，结构化标记是手段，合规审计是保障。三件事缺一不可。

在易科势腾的官网改造实践中，数据安全分级永远是第一步——先分级、先定边界，再做技术实现。这样做的好处是：技术团队在开发时就有明确的"哪些能做、哪些不能做"的规则，避免做完再返工。而且分级结果要跟着内容走，每次发布新页面，先过一遍清单再上线。

如果你正在规划AI友好化改造，可以先从数据分级盘点开始。哪怕只有一份简单的Excel清单，也比完全没有强。数据安全合规这件事，最容易出问题的不是技术实现，而是改造流程里漏了「数据分级」这一步。先把边界划清楚，后面怎么改都稳妥。