元字段解决的是一件很具体的事：同一套产品模板下，规格、适用场景、常见问题这些东西每个产品都要有，值各不相同。全部塞进产品描述，格式靠人工维持，模板改一次要重排全部产品；放进元字段，格式由模板固定，后台只填空。至于排名，元字段本身不带任何权重加成。
下面按存什么、怎么渲染、怎么核对来讲，末尾说哪些情况下不值得用。
哪些内容值得拆成字段
判断标准只有一条：这套信息是不是在多个产品上重复出现，而且值各不相同。符合的有四类：
结构化、可复用、可核实的内容（光算 · 示意图）
- 结构化规格：尺寸、材质、重量、功率、包装数量、认证编号。同一个字段在不同产品上填不同的值，模板里排成表格或列表。
- 使用场景：适用环境、适配机型、安装条件。写成两三个短句比长段落有用，模板可以把它放在图片旁边。
- 常见问题：售后、安装、兼容性这类问答对。同一个问题在二十个产品上都要答时，它属于可复用内容。
- 资料与下载：说明书、图纸、合规文件的文件引用。挂在页面上比让买家发邮件索取好。
不该拆的也有四类：营销长文案属于产品描述本身；每个产品只出现一次的自由文本放进字段只会让模板更复杂；按序号排进去的「SEO 关键词字段」会在页面上生成没有阅读价值的文本；品类共性的介绍应该写成集合页正文，而不是在每个产品上重复一遍。
选字段类型时按内容来定：能用一个词或一句话说清的用单行文本；需要换行、加粗、列表的用富文本；尺寸重量这类数值用数字类型，以后想排序或比对时不用再解析文本；说明书和图纸用文件引用，将来换文件只改后台那一处。类型选得随意，等模板里要做判断时才发现拿到的是一段带格式的 HTML，处理起来更麻烦。另外字段的说明文字值得花两分钟写清楚，它是唯一能告诉填表人「这里写什么、写成什么格式」的地方，尤其当填表的人不止一个。
元字段和元对象：先决定内容存在哪一层
三个产品共用同一批问答、五个产品共用同一张认证表，这种「多个产品指向同一份内容」的情况适合用元对象：内容存一份，产品字段里放引用列表，改一处全部生效。只在单个产品上出现的信息，直接建在产品上就够。官方模板文档里元对象有自己的页面类型，主题需要对应模板才能渲染这类页面（主题模板文档）；如果只做产品页展示，不必急着给元对象配独立模板。
场景说明这类内容放在页面哪一段
使用场景的价值在于替买家做判断：这件东西适合谁、不适合谁、通常和什么一起用。它不适合塞在产品描述末尾，因为买家的阅读顺序是先看图、再看规格，最后才关心场景。放在规格之后、问答之前更顺。模板可以给场景字段一个固定的小标题和简短排版，值控制在几行以内；写成一整屏的段落，买家会跳过，模板也排不出层次。一个产品需要很长的场景说明时，那已经是指南文章，适合放进博客再从产品页链过去。
示意：字段定义与模板渲染的对应关系（界面示意）
把字段接到产品模板上
帮助中心对元字段的说明停在「加自定义字段、用主题编辑器连接」这一层（产品详情文档），落到哪个文件、怎么写判断，取决于你手上的主题。可执行的顺序是这样：
- 在后台的自定义数据设置里为产品定义字段，记下命名空间与键名。这两个名字一旦被主题引用，之后改动要同时改模板。
- 复制一份主题，在副本上改，预览无误再发布。这类改动没有预览就等于没有回退点，具体目录职责见主题结构说明。
- 找到产品页对应的 section 文件。JSON 模板下产品页由 section 拼装，HTML 与 Liquid 都在 section 里，不在模板文件里（Sections 文档）。
- 在合适的位置插入渲染代码，先判断值是否存在，再决定标题和内容输出什么。
- 保存后右键「查看网页源代码」，确认规格与问答出现在初始 HTML 里，而不是等脚本执行之后才出现。
规格表用列表渲染的最小写法，先判空再循环：
{%- assign specs = product.metafields.specs.rows.value -%}
{%- if specs != blank -%}
<h2>规格</h2>
<ul>
{%- for row in specs -%}
<li>{{ row }}</li>
{%- endfor -%}
</ul>
{%- endif -%}问答如果做成了元对象列表，循环写法类似，但取字段的路径由你在元对象定义里的键名决定。写之前先在预览里打印一次数据结构，比反复猜键名快：
{%- assign faqs = product.metafields.faq.items.value -%}
{%- if faqs != blank -%}
<h2>常见问题</h2>
{%- for faq in faqs -%}
<h3>{{ faq.question }}</h3>
{{ faq.answer | metafield_tag }}
{%- endfor -%}
{%- endif -%}元字段在 Liquid 里都是先拿到定义再取值，字段类型不同，渲染方式也不同：纯文本可以直接输出，富文本用对应的过滤器，文件引用要取它的地址。拿不准时先把值打印出来看一眼，再决定用哪种输出方式，这比照着别人的主题抄一段更可靠。自己写这类展示块时，把一个 section 收成一类内容会更省事，思路和自定义 section 的写法一致。
缺失值是常态，模板要按常态写
新建字段的那一刻，所有已有产品在这个字段上都是空的。没有判断的模板会在页面上留下「重量：」后面什么都没有的小标题、空表格行、只有问题没有答案的问答框。买家看到的是半个页面，搜索侧看到的是重复出现的空壳文本，两边都吃亏。
做法是把标题和值绑在一起：有值就标题加内容一起出现，没值就整段不输出。
{%- if product.metafields.specs.material != blank -%}
<h3>材质</h3>
<p>{{ product.metafields.specs.material.value }}</p>
{%- endif -%}批量填值比逐个点开产品快得多，但一次导入会覆盖大量字段，风险也随之放大：先拿几个产品试，确认导出的表结构与字段名对得上，再全量执行。填完之后回头抽查渲染结果，比在导入前反复核对模板更省时间。
上线前逐项核对
字段定义、模板代码、数据填充由不同的人在不同时间完成，出错的环节也就分布在这三处。下面这几项按顺序走一遍，每项都用实际页面验证，而不是看后台里字段有没有值。
| 核对项 | 怎么看 |
|---|---|
| 字段命名与模板取值一致 | 对比后台字段的命名空间与键名，和模板里的取值路径逐字核对 |
| 内容在初始 HTML 里 | 查看网页源代码，搜索标题文字是否直接存在 |
| 缺值不留空壳 | 找几个没填字段的产品打开，看有没有空标题与空表格 |
| 移动端排版 | 用手机宽度看同一段内容，表格是否溢出、两列是否挤在一起 |
| 批量导入后抽样 | 从导入过的产品里随机抽几个，看值有没有错位到相邻字段 |
元字段管不到的部分
有几点提前知道，能省掉做到一半才发现方向不对的返工。展示依赖主题是否支持，主题编辑器里能不能直接连上取决于主题版本与设置项，换主题后不能假定同一套代码继续可用；字段不会自动出现在集合页的产品摘要里，也不会自动参与站内搜索，需要模板显式输出；字段值不会自动变成结构化数据；不同版本后台在自定义数据的入口和字段类型上有差别，操作前以当前后台为准。还有个容易被忽略的点：字段定义被删掉之后，引用它的模板不会报错，只会安静地什么都不输出，所以改字段定义时最好同时打开几个产品页看一眼。
SEO 上真正要看的是渲染后的 HTML
字段值只存在后台，对搜索和买家都不存在。Google 的说法是内容必须在渲染后的 HTML 里可见才能被索引（JavaScript SEO 基础），落到元字段上只有一种含义：渲染结果要出现在初始响应里。检查办法是查看网页源代码，而不是看 Elements 面板——面板显示的是脚本执行后的 DOM，源代码里没有的内容，抓取时不一定有。
如果主题先把字段值写进一段 JSON，再由脚本生成表格，抓取方看到的可能只是一个空容器。这种写法在买家浏览器里看着正常，内容却不在正文里。真正需要脚本渲染的场景存在，但规格和常见问题通常不属于其中。
顺便说清与结构化数据的关系：材质、运费、退货这类信息在 Google 的商品标注里有对应位置（Product 结构化数据文档），但标注是模板层面的输出，不会因为用了元字段就自动出现；而且是否展示增强结果由 Google 决定，官方文档也写明增强展示不保证出现。把元字段内容输出成可读的 HTML 是确定的部分，结构化数据核对是另一件需要单独做、单独验的事。
字段本身能带来的搜索收益，和我们之前写过的元字段对 SEO 的作用是同一个结论：它改善的是内容完整度和一致性，排名结果要看页面整体。
这些情况不用上元字段
产品数量少、内容不复用的店铺，规格直接写进描述更快；产品线差异大到字段定义互相冲突时，维护字段定义和模板的成本会超过它省下的排版时间；把问答当关键词容器，每个答案里堆一遍品类词，实际结果是买家不读、页面重复。
元字段也不解决内容质量问题：它只保证位置和一致性，值写得敷衍，页面上就是排版整齐的空话。内容本身的判断与本地化表达属于另一件事，那部分和站点级的搜索表现一起做才有意义，可以对照我们做谷歌 SEO 服务时的检查顺序。
最后留一个判断给做决定的人：当产品线还在频繁调整、字段定义一个月要改三次时，先把内容写进描述里，等结构稳定了再拆字段；反过来，产品型号多、参数固定、上新节奏快的店铺，越早把规格结构化成字段，后面每次改模板的代价越小。两种做法都能上线，区别在于维护成本落在谁身上。