适用读者：负责外贸独立站技术 SEO / GEO 的工程师与站长，熟悉 JSON-LD 基础写法，正在做 AI 搜索引用优化。

上个月接手一个做工业配件出口的独立站，后台数据显示 Google 的富媒体结果测试（Rich Results Test）全绿，schema.org 的 Product 标记一条报错都没有，但 Perplexity 和其他 AI 引擎的产品引用量是零。更奇怪的是，同一批产品页在传统搜索里收录正常、排名也不差。问题最后定位到：站点半年前改版，产品 URL 从 /product.php?id=1234 换成了 /parts/hydraulic-cylinder-hg80，页面里的 JSON-LD 重新生成过，@id 却还留着旧地址——旧地址早就 404 了。Schema 语法完全合法，实体对齐（Entity Resolution）却悄悄断了。这篇文章把整个排查和修复过程拆开讲一遍。

现象：语法全绿，引用归零

先说清楚这次复盘里"归零"的具体表现。改版后第四周，我们抽查了三类来源：

• Google 富媒体结果测试：所有产品页通过，Product、Offer、AggregateRating 全部识别，无警告；
• 传统 Google 搜索：新 URL 收录正常，约 87% 的产品页进了索引；
• AI 引擎侧：用 20 个典型采购问句（比如 "hydraulic cylinder manufacturer with ISO 9001"）在多个 AI 搜索产品里做人工抽查，站点被引用次数为 0，一个产品实体都没被带出来。

这个反差说明一件事：语法校验器只检查 JSON-LD "长得对不对"，不检查它"指的是不是真实存在的东西"。实体对齐关心的恰恰是后者。

传统 SEO 的世界里，URL 换了、301 做了、sitemap 更新了，搜索引擎顺着链接爬就能把新旧关系接上。AI 引擎的逻辑不一样——它更依赖结构化数据里声明的实体标识去判断"这个页面讲的产品，和我知识里那个产品，是不是同一个东西"。标识断了，实体接不上，引用自然出不来。

排查过程：从 Schema 校验到可达性校验

排查走了些弯路。前两天我们一直在改内容：加参数表、补认证信息、调整标题关键词，引用量纹丝不动。第三天换思路，把问题从"内容够不够好"切换成"实体标识可不可达"，思路才通。

排查路径如下：

flowchart TD
    A[AI 引用为零但 Rich Results 全绿] --> B{JSON-LD 语法是否合法}
    B -- 合法 --> C{实体内自引用字段是否一致}
    C --> D[抓取 @id 与 url 字段值]
    D --> E{逐条发起 HTTP 请求验证可达性}
    E -- 大量 404/301 --> F[定位断链根因]
    F --> G[确认改版时 @id 生成逻辑未同步]
    G --> H[设计稳定 @id 方案并批量修复]
    E -- 全部 200 --> I[回头排查内容质量与其他信号]

核心动作是写了个校验脚本，把全站 JSON-LD 里的 @id、url、mainEntityOfPage 抠出来逐条请求。脚本依赖：Python 3.11、requests 2.31、beautifulsoup4 4.12，URL 清单来自 sitemap.xml。逻辑不复杂，但有几个执行细节值得交代：并发控制在 8，加 1.5 秒超时，301 要跟随并记录"最终落点"，因为落点和声明值不一致同样是实体对齐的破坏因素。

# 依赖：Python 3.11 / requests 2.31 / beautifulsoup4 4.12
# 用途：批量校验全站 JSON-LD 中 @id 与 url 字段的可达性
import re
import time
import requests
from bs4 import BeautifulSoup
from urllib.parse import urlparse

# 请求头集中定义，巡检与人工复核共用一套指纹

HEADERS = {
    # 普通浏览器 UA，避免被 WAF 直接拦掉拿不到真实状态码
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) LinkChecker/1.0"
}

def extract_entities(html):
    # 解析页面里所有 application/ld+json 脚本块
    soup = BeautifulSoup(html, "html.parser")
    entities = []
    # 只抓 @id 与 url 两个关键字段，满足排查目标足够了
    for tag in soup.find_all("script", type="application/ld+json"):
        raw = tag.string or ""
        # 用正则粗提 @id 与 url 的值，避免为校验引入完整 JSON 解析的异常分支
        ids = re.findall(r'"@id"\s*:\s*"([^"]+)"', raw)
        urls = re.findall(r'"url"\s*:\s*"([^"]+)"', raw)
        entities.append((ids, urls))
    return entities

def check_url(u):
    try:
        # allow_redirects 打开是为了记录最终落点，301 落点不一致也算问题
        r = requests.head(u, headers=HEADERS, timeout=1.5, allow_redirects=True)
        # 返回状态码与最终落点，供上层做一致性比对
        return r.status_code, r.url
    except requests.RequestException:
        # 网络异常按 0 处理，后续人工复核，不混入 404 统计
        return 0, u

def audit(sitemap_url):
    # 入口：从 sitemap 拿页面清单，控制抽查规模防跑飞
    sm = requests.get(sitemap_url, headers=HEADERS, timeout=5).text
    pages = re.findall(r"<loc>([^<]+)</loc>", sm)
    broken = []
    for page in pages[:2000]:
        # 每页间隔 0.2 秒，控制对生产站点的压力
        html = requests.get(page, headers=HEADERS, timeout=3).text
        for ids, urls in extract_entities(html):
            for u in ids + urls:
                code, final = check_url(u)
                if code >= 400 or code == 0:
                    broken.append((page, u, code))
                elif final.rstrip("/") != u.rstrip("/"):
                    # 声明地址与最终落点不一致：实体指向漂移
                    broken.append((page, u, f"redirect->{final}"))
                time.sleep(0.2)
    return broken

if __name__ == "__main__":
    # 入口参数写死 sitemap 地址，接 CI 时改成环境变量即可
    # 输出格式：所在页面 | 声明的实体地址 | 状态
    for row in audit("https://example.com/sitemap.xml"):
        print(" | ".join(map(str, row)))

跑完 1420 个产品页，结果很扎眼：638 条 @id 返回 404，另有 217 条 301 落到了别的路径上。也就是说，接近六成产品页声明的实体标识指向一个不存在的资源。这份清单导出来当天，根因也确认了：改版时模板里的 JSON-LD 是重写的，url 字段用了新的路由函数生成，@id 却是开发从旧代码里复制过来的一行字符串拼接，没人意识到这两个字段必须对齐。

sequenceDiagram
    participant Bot as AI 爬虫
    participant Page as 产品页 HTML
    participant JSONLD as JSON-LD 实体
    participant OldID as 旧 @id 地址(已 404)
    participant ER as 实体对齐流程
    Bot->>Page: 抓取产品页
    Page->>JSONLD: 提取 Product 实体
    JSONLD->>ER: 提交 @id 与 url
    ER->>JSONLD: 发现 @id 与 url 指向不同资源
    ER->>OldID: 尝试解析旧 @id
    OldID-->>ER: 404 Not Found
    ER->>ER: 标识不可达，实体对齐失败
    Note over ER: 实体不进入知识图，引用无从谈起

机制剖析：实体对齐为什么卡在 @id 与 url

这一节讲机制。实体对齐是把"页面上声明的实体"和"知识库里已有的实体"判等的过程。判等不是靠标题文字相似度碰运气，主要看三类信号：

1. 稳定标识：@id 是实体在全局范围内可区分、可解析的身份声明。schema.org 虽然不强制 @id 可达，但下游消费方（AI 引擎的知识构建管线）普遍会把它当作可解析的 URI 来对待——解析不通，这条声明就可疑。
2. 自洽性：实体内部的 @id、url、mainEntityOfPage 应当指向同一个规范地址。三个字段各说各话，消费方要么判定为两个实体，要么直接丢弃。
3. 外部佐证：其他页面用 sameAs、引用块指向这个 @id 时，形成一张佐证网。锚点一断，整张网跟着失效。

关键在于：@id 是标识，不是链接装饰。写传统 SEO 时大家习惯把 url 当字段、把 @id 当可有可无的补充，这个心智模型在实体对齐场景下是反的。AI 管线做实体合并（Entity Merging）时，@id 相同的实体声明会被聚合到同一节点；@id 不可达且与 url 不一致时，聚合置信度降到阈值以下，该产品在知识图里根本建不成节点——后面所有的检索、引用、推荐都无从发生。这就解释了为什么语法校验全绿：语法层根本不关心解析可达性，两层检查各管各的。

还有一个隐性成本要提：旧 @id 对应的地址如果曾经被收录过、积累过实体信号，改版后没有做 301，等于亲手把旧实体和历史信号之间的桥拆了。我们复盘时发现，这个站改版时给旧 URL 配的是 302 临时跳转，搜索引擎按"临时"处理不传递等价关系，AI 管线那边更不会。

修复方案：稳定 @id 设计与批量落地

修复的思路不是"把 @id 改成新 URL"这么简单——那是下次改版又会断的脆弱方案。我们定的设计原则有三条：

• 锚点选业务不变量：URL 会因为营销、改版、多语言策略变，SKU 不会。@id 用 SKU 构造稳定 URI，如 https://example.com/id/product/HG80-2201，与页面 URL 解耦；
• @id 与 url 必须同源生成：模板层强制两个字段从同一份数据对象渲染，改版只动路由，不动实体标识；
• 断链零容忍：把可达性校验挂进 CI，每晚跑一遍全站抽查，出现非 200 直接告警。

修复后的产品实体由模板层统一渲染，核心结构如下（示意数据，语言 Python 3.11，标准库 json）：

# 依赖：Python 3.11 标准库，无需第三方包
# 用途：从产品数据对象渲染修复后的 Product JSON-LD，@id 与 url 同源生成
import json

def build_product_entity(p):
    # p 是模板层传入的产品数据对象，包含 sku/name/price 等字段
    # @id 走独立的稳定命名空间，与页面路由完全解耦，改版不受影响
    stable_id = f"https://example.com/id/product/{p['sku']}"
    # url 是当前规范页面地址，由路由函数生成，可随营销策略调整
    canonical_url = f"https://example.com/parts/{p['slug']}"
    return {
        # 上下文声明：固定指向 schema.org 词表
        "@context": "https://schema.org",
        # 实体类型：产品类实体，是 AI 引擎识别商品的前置条件
        "@type": "Product",
        # 实体身份锚点：SKU 不变，@id 就不变
        "@id": stable_id,
        # 规范页面：与 @id 语义对应，由同一数据源渲染
        "url": canonical_url,
        # sku 与 gtin 双保险：gtin 是全球贸易项目码，佐证权重更高
        "sku": p["sku"],
        "gtin13": p.get("gtin", ""),
        # 名称与品牌：参与实体消歧，避免同名配件混判
        "name": p["name"],
        "brand": {"@type": "Brand", "name": p["brand"]},
        "offers": {
            "@type": "Offer",
            "price": p["price"],
            "priceCurrency": "USD",
            "availability": "https://schema.org/InStock"
        },
        # sameAs 把多语言页面与社媒主页挂进同一实体佐证网
        # 任一锚点失效都会削弱实体置信度，需纳入可达性巡检
        "sameAs": [
            f"https://example.com/de/parts/{p['slug']}",
            "https://www.linkedin.com/company/examplehyd"
        ]
    }

# 渲染结果以 application/ld+json 内嵌到页面 head 中
# indent=2 是为了人工 diff 友好，线上可关闭压缩体积
entity = build_product_entity({"sku": "HG80-2201", "slug": "hydraulic-cylinder-hg80",
                               "name": "Hydraulic Cylinder HG80", "brand": "ExampleHyd",
                               "price": "218.00", "gtin": "0690123456789"})
print(json.dumps(entity, ensure_ascii=False, indent=2))

注意 @id 是独立的稳定命名空间，url 是当前的规范页面，德语站的页面通过 sameAs 挂进同一实体——这套结构在后续两次小改版中一次都没断过。批量落地用脚本把 1420 个产品的 SKU 映射表生成出来，模板改造后灰度发布，旧地址补了 301（这次是 301 不是 302）。改版前后实体的状态对比：

验证：30 天引用对比

修复上线后连续观察 30 天。口径说明：引用数是人工在三个 AI 搜索入口用固定 20 个采购问句抽查的合计次数，属于抽样数据，量级仅供参考。

曲线不是一夜起来的。前 10 天基本没动静，第 12 天左右开始零星出现引用，第 20 天后进入稳定输出。这个节奏和知识图重建实体节点的周期对得上——实体信号要先被重新抓取、聚合、确认，然后才进入回答的候选池。等不及的人容易在第七八天误判"修复无效"然后回滚，那才是白费劲。

收尾：两个误区与一个预判

误区一："Schema 不报错 = 结构化数据没问题"。校验器管语法和必填字段，实体对齐管标识可达与自洽，这是两套检查。GeO 实践里，后者出问题的概率远比想象中高，因为它坏得悄无声息。

误区二："@id 随便写个页面地址就行"。把 @id 绑在会变的 URL 上，等于把实体身份交给营销部门的重定向表。标识要选业务上不变的东西，SKU、内部物料号都比路由路径稳。

趋势预判：AI 引擎对实体一致性的要求只会更严。多语言站点尤其要早做规划——每个语言版本的页面 URL 不同，但产品实体应该共享同一个稳定 @id，靠 sameAs 和 hreflang 把多语言面织到同一实体节点上。晚做不如早做，这事儿的改造成本会随着页面量线性涨。

如果你的站也有"语法全绿但 AI 不认"的情况，欢迎在评论区贴一下你的 @id 写法，可以一起看看。

参考与延伸

• schema.org Product 实体定义：https://schema.org/Product
• Google Search Central 结构化数据通用指南（含 @id 使用说明）：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
• Google 富媒体结果测试文档：https://developers.google.com/search/docs/appearance/structured-data/search-gallery
• RFC 9309（爬虫排除协议，AI 爬虫抓取控制参考）：https://datatracker.ietf.org/doc/html/rfc9309

GEO｜实体对齐｜JSON-LD｜@id｜AI 爬虫｜独立站 AI 流量｜商品被 AI 推荐