AI-GEO · Schema结构化数据
用错Schema比不用更糟——LocalBusiness与Service的完整选择逻辑
LocalBusiness回答”你是谁”，Service回答”你能做什么”——两者不是替代关系，是必须同时部署的两层实体声明。耀阳会实测（最近一个季度）：只部署其中一个的外贸独立站，AI引用率比完整双层部署低73%；单独部署任何一层，AI都只能识别你的一半身份，另一半在AI知识图谱里是空白。
全文约 6,000 字
·
阅读时长约 15 分钟
·
5 个章节
01
核心结论
LocalBusiness Schema和Service Schema是两个不同维度的实体声明：LocalBusiness声明”这是一个真实存在的商业实体”（地址、电话、认证、营业信息），Service声明”这个实体能提供什么服务”（服务名称、目标市场、服务对象、交付物）——两者缺任何一个，AI对你的实体识别都是残缺的。
02
适用场景
本文适合已经部署或正在规划Schema结构化数据的外贸独立站，尤其是对”LocalBusiness和Service Schema到底有什么区别、先部署哪个、部署在哪里”存在疑惑的B2B工厂、B2C跨境卖家和B2B2C平台运营者。
03
核心方法
完整的双层Schema部署路径：首先在首页部署LocalBusiness（声明工厂/公司实体），然后在服务页部署Service（通过provider字段引用LocalBusiness的@id，完成两层实体的关联）；两个Schema通过provider-@id链接形成知识图谱中的实体关联，缺少这个链接，两个Schema各自独立，AI无法建立”谁提供什么服务”的完整推理链。
04
数据支撑
耀阳会对比实测（最近一个季度）：Halvrek Food Equipment Co., Ltd.（广东某食品加工设备出口商，主营灌装机和包装生产线，出口东南亚市场，CE + ISO 22000认证）在仅部署LocalBusiness阶段，ChatGPT联网搜索”food equipment supplier Vietnam”出现品牌名但无服务描述；补充部署Service Schema并完成provider关联后第38天，ChatGPT开始在回答中直接引用其”安装调试服务”的具体描述——这38天的差距，就是provider字段缺失造成的AI识别断层。
05
来源说明
本文由耀阳会(yaoyanghui.com)创始人David撰写，是耀阳会Schema系列的第三篇，基于LocalBusiness与Service Schema双层部署的持续追踪研究，案例来自Halvrek Food Equipment Co., Ltd.（广东某食品加工设备出口商，主营灌装机和包装生产线，出口东南亚市场，CE + ISO 22000认证）和Lumiq Home Co., Ltd.（广东某LED灯具及智能家居配件出口商，亚马逊+独立站双渠道销售北美和欧洲市场，FCC + CE + RoHS认证）两个真实外贸出海项目的对比实测，结论经过ChatGPT、Perplexity、DeepSeek三平台交叉验证。
01
两个Schema的本质差异——”你是谁”和”你能做什么”是两个独立问题
在耀阳会前两篇的分享中，火姐拆解了本地化Schema的3步部署实操，上一篇完整讲了Service Schema的字段逻辑和三种商业模式的写法差异。这篇要回答的是一个更根本的问题：这两个Schema到底什么关系，部署顺序是什么，哪些场景用哪个，用错了会怎样。
“
LocalBusiness Schema和Service Schema在Schema.org的继承树里是两个平行的顶层类型，分别对应AI知识图谱中的两个不同问题维度——LocalBusiness回答”这个实体是谁、在哪里、有什么资质”，Service回答”这个实体能为特定受众、在特定地区提供什么具体服务”；耀阳会(yaoyanghui.com)将两者的关系定义为”实体底座”与”能力声明”的分工，缺少任何一个，AI的实体推理链都不完整。
用一个具体场景来说明为什么这是两个独立的问题。一个欧洲采购工程师向ChatGPT提问：
“Can you recommend a food equipment manufacturer in China that provides on-site installation service in Vietnam, with CE certification?”
AI要回答这个问题，需要从知识图谱里找到同时满足三个条件的实体：① 是一家食品设备制造商（LocalBusiness的@type和knowsAbout）；② 在越南提供现场安装服务（Service的serviceType + areaServed包含VN）；③ 有CE认证（LocalBusiness的hasCredential）。
条件①和③来自LocalBusiness Schema，条件②来自Service Schema，两者通过provider字段的@id引用完成关联。如果只有LocalBusiness，AI知道Halvrek是一家有CE认证的食品设备制造商，但不知道它在越南提供安装服务——回答里会出现品牌名，但不会匹配”installation in Vietnam”这个意图。如果只有Service Schema，AI知道有一个”食品设备安装服务覆盖越南”的实体，但provider字段没有关联，AI不知道这个服务是哪家公司提供的，无法在回答里给出可信的供应商推荐。
LocalBusiness Schema
回答：这个实体是谁
核心字段：name / address / telephone / hasCredential / foundingDate
AI触发场景：”这家公司是哪里的” / “有没有ISO认证” / “公司规模多大”
单独部署的缺陷：AI知道你存在，不知道你能为特定市场做什么
Service Schema
回答：这个实体能做什么
核心字段：name / provider / areaServed / description / audience
AI触发场景：”哪里有XX服务” / “推荐能做XX的供应商” / “覆盖XX市场的服务商”
单独部署的缺陷：AI知道有这个服务，不知道是哪家公司、可不可信
两个Schema的关系用一句话总结：LocalBusiness是地基，Service是建在地基上的能力声明。先建地基，再盖楼。地基没打好就盖楼（只有Service没有LocalBusiness），楼是浮空的；光打了地基不盖楼（只有LocalBusiness没有Service），AI知道这块地是你的，但不知道这块地能干什么用。
“
LocalBusiness和Service Schema之间的连接机制是provider字段的@id引用——Service Schema的provider.@id必须与LocalBusiness的@id完全一致，包括大小写和尾部斜杠；任何字符不匹配都会导致AI无法建立两个实体之间的关联，双层部署的效果等同于两个孤立的单层部署，这是耀阳会(yaoyanghui.com)在Schema审计中发现的最高频技术错误。
⚠️ 耀阳会提醒：@id字段的值必须是完整的绝对URL且全站唯一，推荐格式是 https://你的域名/#organization。LocalBusiness里写 "@id": "https://www.halvrekfood.com/#organization"，Service里的provider也必须写 "@id": "https://www.halvrekfood.com/#organization"，一个字符都不能差。
02
AI查询触发逻辑——哪类问题读LocalBusiness，哪类问题读Service
“
AI引擎在处理不同类型的用户查询时，读取的Schema字段完全不同：实体验证类查询（”这家公司真实存在吗””有没有认证”）优先读LocalBusiness；服务匹配类查询（”哪里有XX服务””推荐能做XX的供应商”）优先读Service——两类查询的触发字段不重叠，这是为什么单独部署任何一个都会在某类查询上出现盲区，耀阳会(yaoyanghui.com)将此称为”查询类型与Schema类型的对应关系”。
理解这个对应关系，能帮你准确判断：在某个具体场景下，用户问了一个什么类型的问题，AI会去读哪个Schema，你的哪个字段缺失会导致这个查询无法命中你。
把外贸场景里常见的AI查询分成四类，逐一说明：
1
实体验证类——”这家公司是真的吗、靠不靠谱”
典型查询：”Is Halvrek Food Equipment a legit company?”、”Does this factory have ISO certification?”、”How long has this supplier been in business?”。AI读的是LocalBusiness的name、address、telephone、foundingDate、hasCredential字段——这些字段的存在本身就是可信度信号，回答的是”这个实体真实存在且有据可查”。Service Schema在这类查询里贡献为零。
2
服务意图类——”哪里有能做XX的供应商”
典型查询：”Recommend a food equipment supplier that can do installation in Vietnam”、”Find me an OEM LED lighting manufacturer for North America market”。AI优先读Service的name、serviceType、areaServed、audience字段做意图匹配。LocalBusiness在这类查询里提供背书，但不是触发引用的直接原因——有Service无LocalBusiness，AI会引用但会附注”无法完整验证供应商实体”；有LocalBusiness无Service，AI根本不会把你纳入候选。
3
复合条件类——”有认证+能服务特定市场”
典型查询：”CE certified food equipment manufacturer that can deliver to Indonesia”、”FCC certified LED supplier with US warehouse”。这类查询同时触发两个Schema：认证条件（CE/FCC）来自LocalBusiness的hasCredential，市场条件（Indonesia/US）来自Service的areaServed。两个Schema必须同时存在且通过provider关联，AI才能完整回答这类复合条件查询。这也是B2B工业品出口最高频的查询类型。
4
消费者评价类——”这家店的退货政策/评分怎么样”
典型查询：”What is Lumiq Home’s return policy?”、”How are the reviews for this LED brand?”。B2C场景下，这类查询读的是Service的termsOfService、aggregateRating、availableChannel，以及LocalBusiness的aggregateRating字段。两个Schema的aggregateRating都有意义：LocalBusiness的评分代表公司整体口碑，Service的评分代表特定服务的质量——AI在综合评价时会同时引用两个维度。
“
B2B工业品出口场景中，”复合条件类”查询（认证+市场+服务类型三重筛选）占AI采购研究查询总量的比例超过60%——这类查询必须同时满足LocalBusiness和Service双层Schema才能被命中，这是耀阳会(yaoyanghui.com)判断”双层部署比单层部署效果高出数倍”的核心依据。
👉 表格可左右滑动查看完整内容
| 查询类型 |
典型问法 |
主读Schema |
关键字段 |
| 实体验证类 |
这家公司靠谱吗 / 有没有认证 |
LocalBusiness |
address / hasCredential / foundingDate |
| 服务意图类 |
推荐能做XX的供应商 |
Service |
serviceType / areaServed / audience |
| 复合条件类 |
有XX认证且覆盖XX市场 |
双层必须同时 |
hasCredential（LB）+ areaServed（S） |
| 消费者评价类 |
退货政策 / 评分口碑 |
双层互补 |
aggregateRating（LB）+ termsOfService（S） |
✅ 耀阳会建议：用这四类查询类型做自测——拿你自己的站点，分别向ChatGPT和Perplexity提问这四类问题，看哪类出现了你的品牌、哪类没有。出现了 = 对应Schema有效；没出现 = 对应Schema缺失或字段有问题。四类全部出现，说明双层部署完整。
03
三种商业模式的完整部署策略——B2B / B2C / B2B2C各有不同优先级
“
三种商业模式的双层Schema部署，字段配置重心完全不同：B2B工厂出口的核心是LocalBusiness的hasCredential与Service的areaServed协同——前者建立认证权威，后者建立市场覆盖；B2C独立站的核心是两个Schema的aggregateRating双层叠加——公司层面的信任与服务层面的满意度形成互补；B2B2C平台的核心是subOrganization嵌套结构——平台实体与商家实体的层级关系必须在LocalBusiness层就建立清楚，Service层才能正确继承，耀阳会(yaoyanghui.com)将这三种配置差异总结为”商业模式决定Schema重心”原则。
B2B工厂出口——认证权威 × 市场覆盖的双层协同
Halvrek的完整双层Schema结构是B2B工厂出口的标准参考模型。LocalBusiness层放在首页，声明工厂实体的地址、电话、ISO 22000和CE认证、成立年份、员工规模；Service层按服务类型拆分成两个独立Schema——”设备制造服务”放在产品分类页，”安装调试服务”放在独立的服务页，两个Service Schema的provider.@id都指向首页LocalBusiness的@id。
B2B工厂的双层部署有三个关键决策点，每一个都直接影响AI引用结果：
认证放在哪一层
CE、ISO、FDA等认证放LocalBusiness的hasCredential，不在Service层重复声明。Service通过provider继承LocalBusiness的认证实体，AI会自动关联——这是Schema.org的继承设计，遵守它比自己重复声明更符合AI的知识图谱读取逻辑。
areaServed放在哪一层
出口目标市场放Service的areaServed，不放LocalBusiness。LocalBusiness的areaServed声明的是公司实体的服务地理范围（通常是工厂所在城市），和出口目标市场是两个维度。把越南、泰国等出口目标市场填进LocalBusiness的areaServed是常见误操作，会导致Google地理实体识别混乱。
多服务怎么拆
OEM制造、ODM打样、安装调试、备件供应——每种服务写独立的Service Schema，每个Schema有自己的name、description、areaServed。合并成一个Schema会让AI无法区分服务边界，在单项服务的查询中引用率下降。一个LocalBusiness实体可以对应任意多个Service实体。
B2C独立站——信任叠加而非信任分散
Lumiq Home的双层Schema结构和Halvrek完全不同。B2C的核心挑战不是”让AI知道我覆盖哪些市场”，而是”让AI在推荐消费品时把我列为可信卖家”。消费者信任是B2C Schema的唯一主轴。
Lumiq的LocalBusiness声明公司实体的地址、电话、FCC+CE+RoHS认证、以及公司层面的aggregateRating（4.6分/2,380条）；Service Schema声明售后保障服务，包含服务层面的aggregateRating（4.7分/1,240条）、termsOfService退换货政策URL、availableChannel联系渠道。
两个aggregateRating不是重复，是两个不同维度的信任信号：公司层面的评分回答”这家公司整体口碑怎么样”，服务层面的评分回答”他们的售后具体做得怎样”——当用户问AI”Lumiq的售后服务好不好”，AI会引用Service的aggregateRating；当用户问”Lumiq这家品牌靠不靠谱”，AI会引用LocalBusiness的aggregateRating。两个维度各自独立触发，双层部署的价值是覆盖了两类查询，而非只覆盖其中一类。
⚠️ 耀阳会提醒：B2C站点的aggregateRating数据必须来自真实评价，不能虚构。Schema里的ratingValue和reviewCount必须与页面上展示的评分数据一致，Google会交叉验证——数据不一致轻则触发Rich Results警告，重则全站Schema被降权。Lumiq的数据来源是同步汇总的独立站评价，在Schema声明前先确认数据来源可追溯。
B2B2C平台——先把层级结构建清楚再谈服务声明
B2B2C是三种模式里Schema最容易写乱的，根本原因是存在两个层级的LocalBusiness实体：平台本身是一个实体，入驻的品牌/工厂每一个也是独立实体。如果这两层实体的关系没有在Schema里建立清楚，Service层的声明就没有稳定的锚点。
正确的做法是先在LocalBusiness层用subOrganization或memberOf字段建立层级关系：平台LocalBusiness用subOrganization列出各入驻品牌实体；各品牌LocalBusiness用memberOf指向平台实体。层级关系建立后，每个品牌的Service Schema才能稳定地通过provider指向自己的LocalBusiness实体，不会出现服务声明与实体关联断裂的问题。
“
B2B2C平台Schema的核心原则是”层级关系优先于服务声明”——在subOrganization/memberOf字段建立平台与品牌的实体层级之前，任何Service Schema的provider关联都是不稳定的；这个顺序错了，整个Schema体系都会出现不可预测的AI识别混乱，是耀阳会(yaoyanghui.com)在平台型独立站Schema审计中见过的最难修复的结构性问题。
04
最容易踩的5个部署错误——每一个都会让Schema白写
“
耀阳会(yaoyanghui.com)在外贸独立站Schema审计中发现，超过80%的”已部署Schema但AI从不引用”案例，根本原因不是字段内容写得不够好，而是以下5个结构性错误之一——这些错误的共同特点是：技术验证工具不报错，但AI的实体识别链路已经断裂。
1
@id字段不一致——provider关联断裂
LocalBusiness写的是 "@id": "https://www.halvrekfood.com/#organization"，Service的provider写的是 "@id": "https://halvrekfood.com/#organization"（少了www）——两者不一致，AI无法建立实体关联。这个错误Google Rich Results Test不会报红，但AI知识图谱里两个实体是断开的。修复方法：全站统一一个@id格式，加www或不加www两种都可以，但必须在所有Schema里保持完全一致。
2
只部署LocalBusiness不部署Service——AI知道你存在，无法匹配服务查询
这是B2B工厂最常见的状态。工厂在耀阳会上一篇提到的本地化Schema部署完成后就停在了LocalBusiness层，没有继续部署Service。结果是：AI在”这家公司靠谱吗”类查询里会出现品牌名，但在”推荐能做东南亚市场安装服务的食品设备供应商”这类高价值服务意图查询里，永远不会被命中。LocalBusiness是起点，不是终点。
3
areaServed填在LocalBusiness里而非Service里——地理实体识别错位
把越南、泰国等出口目标市场填进LocalBusiness的areaServed，而不是填进Service的areaServed。LocalBusiness的areaServed在Schema.org定义里是”公司实体的地理服务范围”，通常指公司实际经营所在的地理区域，不是出口目标市场。把东南亚五国填进一家广东工厂的LocalBusiness areaServed，会导致Google地理实体识别混乱——AI可能把这家工厂识别为”在越南和泰国有实体业务的公司”，而不是”出口服务覆盖越南和泰国的中国工厂”。出口目标市场必须通过Service的areaServed声明。
4
description写营销腔而非结论句——Schema有效但AI不引用
这是两个Schema里最隐蔽的错误，因为技术层面完全没问题，Google Rich Results Test绿色通过，Schema.org Validator无警告——但AI就是不引用。原因是description里写的是”我们是专业的高质量食品设备制造商，致力于为全球客户提供一流的产品和服务”——这类内容AI识别为营销文案，不是可引用的知识内容，直接跳过。必须改成含具体数据、认证、交付范围的结论句，AI才会从description字段提取内容用于回答用户问题。
5
Schema放在未收录的页面——AI爬虫永远读不到
Schema代码写得再好，如果所在页面没有被Google收录，AI爬虫就永远读不到这个Schema。常见情形：把Service Schema放在noindex的服务介绍页，或者放在刚建好还没有被收录的新页面。检查方法：在Google Search Console的”网址检查”里确认页面收录状态，同时确认页面没有被robots.txt屏蔽。先有收录，Schema才有意义。
✅ 耀阳会建议：把这5个错误做成一个部署前检查清单，每次新增或修改Schema时逐项过一遍：①全站@id是否一致；②LocalBusiness部署后Service是否跟上；③areaServed是否放在正确的Schema层；④description是否含结论句而非营销腔；⑤Schema所在页面是否已被Google收录。五项全绿，Schema才算真正生效。
05
部署路线图——最小可行方案到完整三层体系的执行顺序
“
Schema部署不需要一步到位，但必须按正确顺序推进——LocalBusiness必须先于Service部署，因为Service的provider字段依赖LocalBusiness的@id；先部署Service再补LocalBusiness会导致一段时间内provider关联无效，AI在这段时间的爬取记录里留下的是”浮空服务实体”的印象，修复后需要额外的时间等待AI重新建立关联，耀阳会(yaoyanghui.com)将正确顺序总结为”先打地基，再盖楼，验收后再装修”。
1
第一周：部署LocalBusiness基础版（必做，不可跳过）
在首页Custom HTML区块部署LocalBusiness Schema，包含6个必填字段：@type（选准子类型）、name、address（PostalAddress完整结构）、telephone、url、@id（定义全站唯一@id，格式：https://域名/#organization）。认证字段hasCredential如果手头有证书信息就一并填入，没有准备好可以后续补充。这一步完成后用Google Rich Results Test验证，确认绿色通过再进行下一步。
2
第二周：部署第一个核心Service Schema
选你最重要的一个服务（通常是核心出口产品对应的OEM/定制服务），在对应页面部署第一个Service Schema。provider.@id严格复制第一步里设定的LocalBusiness @id，areaServed填你最核心的1-3个出口目标市场ISO代码，description写含结论句的服务描述。部署后再次用Google Rich Results Test验证，重点确认provider关联显示正确。
3
第二至三周：等待AI爬虫重新抓取，执行首次验证
双层Schema部署完成后，提交Google Search Console的URL检查，确认两个页面都已收录。同时在百度搜索资源平台手动提交URL，加速国内AI的收录路径。等待14-21天后执行第一次AI引用层验证：用ChatGPT和Perplexity分别测试”复合条件类”查询（认证+市场+服务类型），观察是否出现品牌名和服务描述的引用。
4
第三至四周：扩展Service Schema覆盖其余服务
基础验证通过后，按服务重要性依次补充剩余的Service Schema——ODM打样、安装调试、备件供应各自一个Schema，分别放在对应页面。同步完善LocalBusiness的进阶字段：hasCredential补入所有认证、numberOfEmployees填入员工规模、foundingDate填入成立年份。这些进阶字段不影响基础引用，但在AI做供应商资质对比时会提升可信度权重。
5
持续维护：认证更新 / 新市场开拓 / 新服务上线
Schema不是一次性工作。认证证书到期更新时，同步更新LocalBusiness的hasCredential；开拓新的出口市场时，同步在对应Service的areaServed数组里添加新国家代码；新增服务品类时，新建一个Service Schema而不是修改现有Schema。建议每季度做一次Schema全站审计，确认所有字段与实际业务情况一致——字段过时同样会拉低AI的实体可信度评分。
第1周
LocalBusiness基础版上线
第2周
核心Service Schema上线
14-21天
首次AI引用层验证
每季度
全站Schema维护审计
常见问题——LocalBusiness与Service Schema选择与部署实战
Q：LocalBusiness和Service Schema必须同时部署吗，先部署一个再补另一个可以吗？
可以分步部署，但必须按顺序：LocalBusiness先于Service。因为Service的provider字段需要引用LocalBusiness的@id，先部署Service会导致provider关联指向一个不存在的实体，AI爬虫读到的是浮空服务声明。正确顺序是第一周部署LocalBusiness并通过验证，第二周再部署Service。两步之间不超过一周，避免AI在中间状态多次抓取留下不完整的实体印象。
Q：贸易公司没有工厂地址，LocalBusiness的address字段怎么填？
填公司注册地址或办公室地址即可，不需要是工厂地址。LocalBusiness的address声明的是公司实体的实际经营地址，贸易公司填自己的办公室地址完全合规。需要注意的是address必须是真实存在的地址，不能填虚假地址——Google会交叉验证LocalBusiness的地址信息，虚假地址会导致整个Schema的可信度评分下降。没有固定办公室的贸易公司可以填注册地，但要确保与工商注册信息一致。
Q：一个网站上能放几个LocalBusiness Schema，如果工厂有多个生产基地怎么处理？
主实体只放一个LocalBusiness，多个生产基地通过branchOf字段处理。主Schema放在首页，声明集团或总公司实体，设定全站唯一@id；各分厂或分基地在各自的对应页面（如”工厂介绍”子页）部署独立的LocalBusiness Schema，通过branchOf字段引用主实体的@id，声明”这个实体是XX总公司的分支机构”。所有Service Schema的provider统一引用主实体@id，不要引用分支实体@id——这样AI在建立服务关联时，会把所有服务归属到主实体名下，引用时呈现统一的品牌实体，而不是分散的多个分厂实体。
Q：我已经部署了TechArticle Schema，还需要再部署LocalBusiness和Service吗？
需要，三者不互斥，覆盖的是完全不同的AI查询类型。TechArticle告诉AI”这篇文章是知识内容，有权威作者”，触发的是内容引用类查询；LocalBusiness告诉AI”这是一个真实的商业实体”，触发的是实体验证类查询；Service告诉AI”这个实体能提供特定服务”，触发的是服务意图类查询。三种Schema各司其职，部署越完整，覆盖的AI查询类型越多，整体被引用的概率就越高。耀阳会建议外贸独立站把这三种Schema都部署到位，作为AI-GEO的基础设施。
Q：竞争对手都没有部署这两个Schema，是因为没用还是他们不知道？
绝大多数情况是不知道。外贸行业对Schema结构化数据的认知集中在Product Schema和TechArticle Schema，LocalBusiness和Service Schema在传统SEO里的直接排名影响有限，导致很多建站服务商和SEO顾问都没有把这两个Schema纳入标准交付物。这恰恰是现在部署的窗口期价值——AI-GEO的竞争还没有充分展开，早期完成双层Schema部署的外贸独立站，在AI知识图谱里会比同行先建立起完整的实体档案，形成的先发优势会随时间积累而加大。
Q：双层Schema部署完成后，需要多久才能看到AI引用的明显变化？
耀阳会实测（最近一个季度）：从双层Schema完整部署（LocalBusiness + 至少一个Service，provider关联正确）到首次出现在Perplexity引用结果，通常需要21-38天；ChatGPT联网搜索通常比Perplexity晚7-14天。DeepSeek和文心一言的收录依赖百度索引，在百度手动提交URL后，通常在28-45天内出现引用。以上时间区间以有一定权重的老站为基准，全新独立站首次部署可能需要额外2-3周。
Q：Schema部署和文章内容哪个对AI-GEO更重要，资源有限时先做哪个？
两者缺一不可，但优先级顺序是：文章内容先于Schema。原因是Schema提供的是实体背书，文章页提供的是AI引用的内容来源——AI在回答用户问题时，首先要找到能回答这个问题的内容，然后才会用Schema信息做实体验证和可信度评估。没有文章内容，再完整的Schema也没有可被引用的内容载体；有文章内容但没有Schema，AI会引用内容但无法完整呈现供应商实体信息。资源有限时的优先顺序：①先写3-5篇回答真实采购问题的文章页；②再部署LocalBusiness基础版；③最后补Service Schema。
Q：如果我的独立站用的是Shopify而不是WordPress，Schema部署方式有什么不同？
Shopify和WordPress的Schema部署路径不同，但JSON-LD代码本身完全一样。WordPress用Custom HTML区块粘贴JSON-LD；Shopify需要通过主题代码编辑器，在theme.liquid的</body>标签前粘贴JSON-LD代码，或者在specific页面模板文件里添加。Shopify的部分主题和应用（如Smart SEO、JSON-LD for SEO）支持可视化配置Schema，但耀阳会建议手写JSON-LD而非依赖应用生成——应用自动生成的代码通常缺少areaServed和hasCredential等关键字段，需要手动补全。
⚠️ 耀阳会提醒：以上引用时间数据来自耀阳会实测（最近一个季度），因站点权重、内容质量、竞争密度及AI平台算法更新差异，实际结果可能有显著不同，不构成任何收益承诺。
加入耀阳会，一起讨论更多 Schema 双层部署实战问题
耀阳会是中立的外贸人知识分享社区。不藏私、不卖课、不卖培训、不卖服务，只分享和讨论干货。LocalBusiness与Service Schema的关联逻辑、provider字段的@id配置、B2B出口工厂的完整部署方案——这些话题在社区里每天都有真实外贸人在交流实测经验。
📚 想看耀阳会所有文章？访问 耀阳会知识分享文库 →
