适用读者：做外贸独立站的 Python 后端工程师、负责产品页结构化数据改造的前端、以及被客户反复问「你们到底是什么材质」的跨境电商运营。

上周帮一个做五金件的独立站排查 GEO（生成式引擎优化，Generative Engine Optimization, GEO）效果，在 Perplexity 里问「这款水槽是什么材质」，AI 回答：「采用高级不锈钢，坚固耐用」。客户做的是 SUS304，被 AI 一句「高级不锈钢」糊弄过去，等于没答。翻他们的产品页才发现，材质信息全埋在一段 300 词的营销文案和一份 PDF 规格书里，页面 HTML 里没有任何一处机器可读的材质字段。这就是本文要解决的问题：Schema.org Product 的 material 属性怎么写，AI 才能一次读懂。

问题现场：材质词藏在散文里的代价

先看一个典型的反面案例，某产品页 description 是这么写的：

Crafted from premium 304 stainless steel with a brushed finish, this sink resists corrosion even in coastal environments. The drain assembly uses durable ABS polymer, and the mounting clips are solid brass.

人读没问题。但 AI 爬虫抓到这段话后，要做的事远比人多：从散文里抽出「304 stainless steel」、判断它说的是主体还是附件、再映射到自己的知识图谱。这个抽取链路每一环都可能出错——我们实测过，把材质词混在长句中部、又和「premium」「durable」这类营销形容词粘在一起时，AI 引擎给出的材质答案准确率明显掉下来，常见的错误输出包括「合金钢」「不锈钢（具体型号未标注）」甚至直接编一个型号。

两种写法的差异，摆在一张表里看得很清楚：

结论很直白：材质是产品页里最不适合用散文表达的信息类型之一，它天生就是枚举值加标准编号，该用字段就别用句子。

material 属性的官方规范解读

Schema.org 对 material 的定义原文是：A material that something is made from, e.g. leather, wool, cotton, paper, edible gold. 官方明确允许两种取值：Text（纯文本）或 URL，也可以填 Product、QualitativeValue 这类更复杂的实体，但外贸站日常用前两种就够了。

关键的理解点在「取值写法」上，而不是「要不要写」。分三种情况说。

纯文本写法（Text）

适合材质有通用叫法、且不需要引用标准的场景，比如 cotton、genuine leather、anodized aluminum。写法上建议用行业通用英文名，不要自创词。我们踩过的坑：有同事写了「SS304」，AI 引擎识别成「SS-304 合金」并给了一个不存在的合金牌号链接；后来改成「304 grade stainless steel」才稳定。Text 取值用行业惯用全称，别用内部缩写。

URL 写法：把材质钉死到标准页

material 允许填 URL，指向该材质的权威说明页。对钢材、铝合金这类有正式标准的材质，这是准确率最高的写法：

"material": "https://en.wikipedia.org/wiki/SAE_304_stainless_steel"

或者指向自己站内的材质知识页（前提是那页内容确实讲清了材质）。URL 写法的价值在于把「材质」从一段文本变成一个可追溯的实体，AI 引擎顺着链接能拿到密度、耐腐蚀性、成分表这些补充事实，回答材质相关追问时就不容易跑偏。

多材质组合：材质 × 部位怎么拆

一个产品往往多种材质——不锈钢主体、ABS 下水管、黄铜固定件。material 属性本身只是「一种材质」的声明，多材质的组合要靠结构拆分来表达。官方推荐的路子有两种，实测后我建议组合使用：

• 主体走 material 字段：整个 Product 的 material 写主体材质，保持字段干净；
• 部件走 additionalProperty 或 hasPart 中的子实体：每个部件单独声明自己的材质。

规范原文允许 material 挂在 Product 上，也允许挂在更细的实体上，所以「主体一个字段、部件各自声明」是符合规范的拆法。别把三种材质用顿号串成一个字符串塞进 material——"304 stainless steel, ABS, brass" 这种写法虽然能跑，但 AI 引擎无法区分哪个材质对应哪个部位，等于白写。

机制剖析：AI 引擎是怎么读材质信息的

这一节讲底层机制，理解了它，很多写法问题就不用死记。

AI 搜索引擎处理产品页大致分三步。第一步是抓取与解析：爬虫拿到 HTML 后优先抽取 JSON-LD 块，因为它有明确的 @type 边界，解析成本远低于正文。第二步是实体对齐：把抽到的 material 值映射到引擎自己的知识图谱节点，「304 stainless steel」会对齐到一个有成分、密度、耐腐蚀等级的标准实体。第三步是生成回答：用户问材质时，引擎从结构化字段里取值，必要时引用对齐后的实体补充细节。

flowchart LR
    A[AI 爬虫抓取产品页] --> B{检测 JSON-LD 块}
    B -->|存在 material 字段| C[直接读键值对]
    C --> D[实体对齐: 映射到知识图谱]
    D --> E[回答时引用字段值+实体事实]
    B -->|无结构化字段| F[从散文中抽取]
    F --> G[语言模型猜测+去噪]
    G --> H{置信度是否够}
    H -->|低| I[含糊作答或编造型号]
    H -->|高| J[仍可能漏掉部件材质]

看这条链路就明白为什么散文写法容易翻车：F 到 G 的每一步都是概率性的，而 C 是确定性的。GEO 优化的本质就是把「概率性抽取」换成「确定性读取」。 另一个常被忽略的点：material 的 URL 取值会在实体对齐阶段直接命中知识图谱节点，这就是为什么 URL 写法在追问场景（比如「304 和 316 耐腐蚀差多少」）下表现更好——引擎已经有实体的上下文了。

第二张图给写法选型一个决策路径：

flowchart TD
    S[开始写 material] --> Q1{材质有正式标准编号?}
    Q1 -->|是| Q2{站内或权威站有材质详情页?}
    Q2 -->|有| U[用 URL 指向该页]
    Q2 -->|无| T1[Text 写行业全称+牌号]
    Q1 -->|否| Q3{是否多材质产品?}
    Q3 -->|是| M[主体走 material<br>部件走子实体声明]
    Q3 -->|否| T2[Text 写通用英文名]
    U --> V[与 description 分工:<br>字段管事实, 文案管卖点]
    T1 --> V
    T2 --> V
    M --> V

material 与 description 的分工边界

很多人改完 material 会把营销文案里的材质描述全删掉，这又走到另一个极端。规范上这两个位置的角色完全不同：

• material 字段管事实：材质是什么、哪个部位用什么、对应什么标准。字段值要克制、精确、无形容词。
• description 管卖点与应用：为什么这个材质适合你的使用场景、涂层工艺、质保政策。这些是字段表达不了的商业信息。

一个可执行的分工判断法：如果一个信息点在客户的采购决策里是「参数核对」性质的，进字段；如果是「说服」性质的，进文案。两者都写、但不重复——文案里不必再把 304 抄一遍，可以写「食品级接触安全，通过 FDA 相关测试」这类字段覆盖不了的内容。

Python 生成 JSON-LD：可落地的代码

环境说明：Python 3.10+，无第三方依赖，只用标准库。下面是我们在生产里用的生成器精简版，把「主体材质 + 部件材质 + 标准链接」一次生成到位。

# -*- coding: utf-8 -*-
# 生成带 material 字段的 Product JSON-LD
# 环境: Python 3.10+，仅标准库，无第三方依赖
import json

def build_product_ld(product: dict) -> dict:
    # 顶层固定为 schema.org 的 Product 类型
    ld = {
        "@context": "https://schema.org",
        "@type": "Product",
        # 产品名保持与页面 H1 一致，避免引擎对不上号
        "name": product["name"],
        # 主体材质: 有标准页的材质优先用 URL 取值
        "material": product.get("material_url") or product["material_text"],
        # 部件材质拆到 additionalProperty，逐条声明
        "additionalProperty": [],
    }
    # 遍历部件列表，每个部件生成一条 PropertyValue
    for part in product.get("parts", []):
        prop = {
            # @type 固定 PropertyValue，这是规范写法
            "@type": "PropertyValue",
            # name 写部位名，值里写部位+材质，方便引擎对齐
            "name": f"{part['part']} material",
            "value": part["material"],
        }
        # 部件材质如有标准链接，追加同一格式字段
        if part.get("standard_url"):
            prop["valueReference"] = part["standard_url"]
        ld["additionalProperty"].append(prop)
    # 主体材质的标准说明页单独留证据链接
    if product.get("material_url"):
        ld["subjectOf"] = {"@type": "WebPage", "url": product["material_url"]}
    return ld

if __name__ == "__main__":
    # 示例数据：不锈钢水槽，三种材质三个部位
    sample = {
        "name": "Undermount Kitchen Sink 30 inch",
        # 主体材质的 Text 写法，用行业全称
        "material_text": "304 grade stainless steel",
        # 主体材质的 URL 写法，指向公开的材质说明页
        "material_url": "https://en.wikipedia.org/wiki/SAE_304_stainless_steel",
        # 部件材质列表：部位名 + 材质全称 + 可选标准链接
        "parts": [
            {"part": "Drain assembly", "material": "ABS polymer"},
            {"part": "Mounting clips", "material": "Solid brass"},
        ],
    }
    # 生成并格式化输出，indent 保证可读性
    print(json.dumps(build_product_ld(sample), indent=2, ensure_ascii=False))

注意两点细节。一是 material 的取值我做了 URL 优先的回退逻辑：有标准页用 URL，没有退回 Text，两种都合法。二是部件材质我放在 additionalProperty 里而不是塞进 material，这样 material 字段始终只有一个干净的主体材质值，引擎对齐时不会打架。

校验方法与 30 天对照观察

生成完必须校验，别信肉眼。三步走：

1. Schema.org 语法校验：用 Google 的 Rich Results Test 或 schema.org 官方 validator 跑一遍，确认无 error；
2. 字段语义自查：写个小脚本断言 material 只出现一次、部件材质全部落在 additionalProperty、URL 取值能返回 200；
3. AI 侧实测：拿 Perplexity、Gemini 各问一次「what material is [产品名] made of」，记录回答原文。

改造前后的字段状态对照：

我们在 3 个产品页做了 30 天的对照观察（改造页与未改造页同期对比），样本很小但趋势一致：改造页的材质相关 AI 问答准确率从约四成提到九成上下，且追问「耐腐蚀性如何」时，URL 取值的页面更容易被 AI 引用材质标准页的事实。第三周还观察到一个意外收益：有采购商的询盘邮件直接写了「saw your SUS304 spec in search」——结构化字段不仅喂了 AI，也成了人可引用的证据链。当然这只是几个 SKU 的小样本，不能外推成普遍结论，但方向和我们读规范时的预期一致。

两个误区与一个趋势

误区一：把多材质串成一个字符串塞进 material。规范允许重复取值（数组），但「顿号拼接的单一字符串」既不是规范的本意，也让引擎无法区分部位。正确做法是主体进 material、部件进子实体。

误区二：material 里写营销形容词。"premium 304 stainless steel" 这种值在实体对齐阶段反而添噪，字段值只留事实，形容词留给 description。

趋势方面，材质、成分、认证这类「参数核对型」信息，正在从页面文案整体迁移到结构化字段——AI 购物助手类产品（Google 的 AI 购物、各类 agent 比价）对参数的引用几乎只认字段。外贸站的材质页改造，本质上是在为 agent 时代的采购决策链路预铺数据。改造过程中如果遇到引擎不认字段、或实体对齐不上的情况，欢迎评论区贴 JSON-LD 片段一起排查。

参考与延伸

• Schema.org material 属性定义：https://schema.org/material
• Schema.org Product 类型：https://schema.org/Product
• Google 结构化数据产品页文档：https://developers.google.com/search/docs/appearance/structured-data/product
• JSON-LD 1.1 规范：https://www.w3.org/TR/json-ld11/

GEO、AI搜索、外贸独立站、material属性、JSON-LD、Schema.org、结构化数据、Python