FAQs
{% for faq in faqs %}
{{ faq.question }}
{{ faq.answer }} {# 若是富文本会自动渲染 #}
{% endfor %}
{% endif %}
## 自定义FAQ的JSON格式的元字段
如果你不想建 Metaobject，也可以在 Blog posts 上新建一个多行文本元字段，手动填 JSON 数组，再用 Liquid 解析：
### 新建元字段
- 名称：FAQ JSON
- 命名空间与键：custom.faq_json
- 类型：多行文本（Multi-line text）
在每篇文章里填入Json数组：
[
{"question": "Question 1", "answer": "Answer 1"},
{"question": "Question 2", "answer": "Answer 2"}
]
### 模板中解析并输出 JSON-LD
{% if article.metafields.custom.faq_json %}
{% assign faq_raw = article.metafields.custom.faq_json.value %}
{% assign faq_list = faq_raw | parse_json %}
{% if faq_list.size > 0 %}
{% endif %}
{% endif %}
## Metaobject方案与JSON字段方案对比
对比维度 | Metaobject方案 | JSON字段方案 |
后台填写体验 | ✅ 表单式输入，每个问题/回答分开填写；支持无限添加 FAQ 条目；运营可视化维护，无需懂代码。 | ⚠️ 需要以 JSON 格式手动输入（如 [{"question":...}]）；对非技术运营不友好，容易格式出错。 |
可维护性 | ✅ 高。FAQ 内容存储在结构化的 Metaobject 中，可复用、可独立管理；适合团队长期维护。 | ❌ 较低。JSON 文本难以查找与编辑，修改容易出错。 |
数据结构化程度 | ✅ 完全结构化（每个问题和回答都是字段），Shopify API 读取方便。 | ⚠️ 半结构化（需要解析 JSON），不便于做二次开发。 |
复用性 | ✅ 同一个 FAQ 条目可以被多篇文章共用；更新后全站同步。 | ❌ 不可复用，每篇文章独立维护。 |
SEO 结构化数据正确性 | ✅ 非常高；Liquid 直接循环输出，无解析风险。 | ⚠️ 稍低；若 JSON 拼写错误会导致结构化数据无法被解析。 |
实现复杂度 | ⚠️ 略高，需要创建 Metaobject、再建立列表引用字段。 | ✅ 简单，创建一个文本字段即可。 |
主题模板编写难度 | ✅ 中等；循环 metaobject 引用，逻辑清晰。 | ✅ 简单；只需解析 JSON 后循环输出。 |
性能影响 | ⚪ 正常；调用 metaobject 数据略微增加 API 调用。 | ⚪ 正常；JSON 解析对性能影响极小。 |
Shopify 2.0 可视化支持 | ✅ 可在 Online Store Editor 中显示 FAQ 内容区块。 | ❌ 不可直接可视化显示，只是数据层。 |
适合场景 | 📘 官方博客、SEO 优化文章、有多人维护内容团队。 | 🧩 技术性博客或实验用途，内容少、单人维护。 |
额外建议
目标 | 推荐方案 |
你想让非技术运营像填写表单一样添加 FAQ | 方案A |
你是唯一维护者，内容少，只想快速上线结构化数据 | 方案B |
想将 FAQ 在页面上同步展示 | 方案A更容易（直接循环 metaobject） |
想导出或通过 API 调用 FAQ 数据 | 方案A完全支持 GraphQL 调用 |
想节约后台配置时间，先测试效果 | 方案B更快上手，随时可升级到A |
- A 方案 = 长期方案，团队友好、标准化、可视化维护、可复用。
- B 方案 = 临时方案，部署快但维护麻烦，不建议长期使用。
## 如果Shopify博客文章中没有明显的FAQ问答汇总段落，如何生成FAQ结构化数据？
发送以下指示词给ChatGPT (https://zhangwenbao.com/bing-ranking-chatgpt-brand-visibility.html)等AI工具快速分析提取博客文章中的FAQ：
> Please analyze the following article and extract all questions and answers suitable for a FAQ, ultimately generating the following JSON array:
[ {"question": "Question (https://schema.org/Question) 1", "answer": "Answer 1"}, {"question": "Question 2", "answer": "Answer 2"} ]
Use a "one question, one answer" format, using the article content directly. Minor modifications to the original text are permitted to maintain semantic consistency with the original Q&A. Answers should be read within 30 seconds. The article content is as follows:
[Article Content]
注意将[Article Content]替换为你的博客文章全文。
最后将生成的JSON数组复制到Shopify文章的自定义字段值中。
## FAQPage结构化数据和文章中的文案不完全一致，对SEO会有负面影响吗？
不会有明显的负面影响，只要你掌握以下几个SEO关键原则：
1. 保持语义一致性
FAQ结构化数据里的问题和回答可以是概括或提炼后的版本，不需要与正文一字不差。Google的算法重视的是语义相关性，即FAQ的问答要真实反映正文内容，而不是机械复制。
2. 避免“自创内容”
如果FAQ中出现了正文中完全没有提及的观点或信息，就可能被算法判断为“误导性结构化数据”，这会影响FAQ片段在搜索结果中的展示（例如不再显示FAQ富摘要）。
3. 建议做法
- 确保FAQ问答与正文在逻辑上完全一致（即使表达略简化）。
- 可以在FAQ回答中使用与正文相同的关键词或短语，保持自然。
- 控制FAQ数量（一般建议3–8条最优），避免重复或过度优化。
- 确保这些问答确实出现在页面上（Google要求FAQ内容在用户可见范围中）。
4. 实践经验
在实际SEO项目中（包括Shopify、WordPress、独立站），轻度改写FAQ文本以提炼重点是非常常见的做法，并不会导致负面效果。相反，它能帮助搜索引擎更好地理解内容结构，提高FAQ片段展示率。
结论：
只要FAQ内容保持语义一致、真实来源于正文，就算文字略有差异，也不会造成SEO负面影响；合理提炼反而有助于FAQ的点击率与收录效果。
## Google砍了FAQ富媒体之后，这套FAQPage还值得做吗
讲完两套实操方案，保哥得先回答一个很多人心里的疑问——既然Google早就大幅收窄了FAQ富媒体，那费劲埋这套FAQPage结构化数据，还有意义吗？这个问题不讲清楚，前面的代码你做起来都没底气。
先把背景交代准。2023年4月起，Google宣布大幅缩减FAQ rich result的展示，到当年9月，SERP上的FAQ折叠问答基本只留给权威的政府和医疗健康类网站，绝大多数普通站点、电商博客的FAQ富摘要，在搜索结果里看不到了。这是实打实的政策收缩，不是错觉。
但保哥的结论很明确：FAQPage依然值得做，只是它的价值重心彻底搬了家。从过去“抢SERP上那块富媒体展示位”，转向了三个新支柱。
第一个，也是最重要的，是GEO和AI引用。AI Overview、ChatGPT、Perplexity，包括国内的豆包、DeepSeek，在生成答案时都偏爱结构清晰的问答对。FAQPage本质就是喂给AI的“预处理过的高品质食物”，它让AI极其容易地理解并抽取你的Q&A，把你的页面纳入可信来源。富媒体没了，但这个价值不降反升——SERP上的展示位收窄了，AI答案里的引用位却在迅速膨胀。
第二个，是PAA（People Also Ask，他人还问）的入选率。把内容清晰组织成问答并打上标记，Google更容易发现你的页面是回答相关问题的好来源，进PAA框的概率明显提升。这块流量并没有随FAQ富媒体一起消失。
第三个，是语义理解和长尾匹配。结构化标记帮搜索引擎搞清楚你这页在讲什么、能回答哪些具体的长尾问句，匹配查询变体的能力更强。
还有一层别忘了：可见的FAQ段落本身，对用户体验、停留时长、转化就有价值——用户快速找到关心的零散答案，跳出率自然降。这份收益跟上不上富媒体半点关系都没有。
所以实操上要调整心态。既然不再为那块SERP富媒体优化，FAQ的写法就要从“为折叠展示讨巧”转向“为AI提取和PAA友好”——答案开头直接给结论、句法完整主谓宾齐全、多用事实性陈述少用营销话术。做国内市场的还要单独看百度，百度的FAQ摘要逻辑和Google不一样，豆包、DeepSeek引用问答的偏好也各有脾气。保哥另有一篇专门拆“Google优化FAQ生效后FAQ Schema还该不该写”，想深究的可以对照着看。
一句话收尾：别因为SERP上看不见FAQ富摘要了，就把这套Schema扔进废纸篓。它的战场已经从蓝链上方，悄悄搬进了AI答案里和PAA框里，而这两个地方的价值，在2026年只会越来越重。看不见，不等于没用。
## Shopify上FAQPage翻车的几个真实坑
方案给得再清楚，真上手做也容易翻车。保哥把这些年在Shopify和独立站上FAQPage踩过的坑归归类，几乎全集中在“数据一致性”和“格式合法性”两件事上，每一个都能让你的结构化数据整篇报废。
第一个坑，JSON字段方案的格式错误。有个客户图省事用了方案B，手填JSON数组，结果某条答案里有个英文半角双引号没转义，整段JSON-LD直接解析失败。拿到Google的Rich Results Test里一测，红字报错，那篇文章的结构化数据全废了，自己还浑然不知。这恰恰是保哥更推荐方案A（Metaobject）的原因——表单式录入，从根上避免了手写JSON的转义灾难。真要用方案B，答案里每一个双引号都得老老实实转义。
第二个坑，可见FAQ和Schema不一致到“误导性”的程度。有团队为了多塞关键词，在JSON-LD里写了一堆页面上压根不存在的问答。Google的判定很干脆：misleading structured data（误导性结构化数据），不光FAQ彻底不展示，还可能吃一个人工处罚警告。Google的硬性要求白纸黑字——Schema里的每一个问答，都必须在页面上对用户可见。想靠结构化数据偷偷塞内容，是死路。
第三个坑，答案字段里塞复杂HTML。有人在acceptedAnswer的text里塞了img图片、iframe视频，想让答案更丰富，结果校验直接通不过。Google明确规定，答案字段只支持纯文本和少量基础HTML标签（加粗、斜体、列表、换行那几个），图片视频一概不认。要展示媒体，放到页面可见内容里，结构化数据里只留文字。
第四个坑，Liquid输出未做清洗。如果answer用的是富文本字段，直接把它怼进JSON-LD，里面的HTML标签和换行会把JSON结构撑破。前面代码里其实给了解法——加strip_html和json过滤器，但实操中十有八九会忘，一忘就出错。
第五个坑，全站文章共用同一组FAQ。方案A的“可复用”本是优点，但常被滥用成“每篇文章底部都挂同一组通用问答”。Google会把这种判成重复、低质内容，不但拿不到好处，还反过来拖累页面。FAQ必须和每篇文章的主题真实相关，复用要克制。
这五个坑串起来看，教训只有一条：FAQPage的成败全在细节。上线前务必过两道校验——Google Rich Results Test和Schema Markup Validator，方案B尤其要逐字检查JSON转义。技术SEO就是这么残酷，差一个引号、多一段不一致的问答，满盘皆输。埋之前多花十分钟校验，比上线后排查白忙一周划算得多。
## 常见问题解答
1. FAQPage 结构化数据和 HowTo 结构化数据有何区别？
答： 它们服务于不同的目的和内容类型。FAQPage 用于回答一系列常见问题（Q\&A 格式），通常是短小的问答。而 HowTo 结构化数据则用于展示步骤或指导性内容，如“如何制作蛋糕”，它强调的是一个有具体步骤（steps）的完整流程。两者不可混用，必须根据内容类型选择正确的 Schema 标记。
2. 我的文章中包含很多图片和视频，可以在 FAQ 的答案中添加图片或视频链接吗？
答： 在 FAQPage 的结构化数据中，答案 (acceptedAnswer 的 text 字段) 只能包含纯文本和基础 HTML 标签（如