很多人一听「结构化数据」，脑子里就两句话：加了 schema，搜索结果会更好看；加了就能涨排名。前半句有机会，后半句不对。
我这几年给外贸 B2B 站和跨境 B2C 站改模板，几乎每次都会先打开源码，搜一遍 application/ld+json。有的站一个字段没有；有的站塞了假评分、假库存；还有的站把访客看不见的内容写进 JSON-LD——这些都会踩到 Google 的质量红线。
下面按「是什么 → 怎么设与政策 → B2B 分页面 → B2C 分页面 → seogeo.cc 现场拆解 → 坑与建议」写清楚。官方依据我会直接挂上 Google 搜索中心文档链接，方便你对照。
1. 结构化数据是什么：JSON-LD 给机器读，不是给访客看
按 Google 的定义，结构化数据是一种标准化格式，用来提供网页信息，并对页面内容进行分类；搜索引擎可以据此理解页面，并在合适时触发更丰富的结果呈现。入门说明见：结构化数据标记简介。
实操里最常见的写法是 JSON-LD：一段放在页面里的 <script type="application/ld+json">…</script>。它不替代标题、正文、价格表，而是用 schema.org 词汇把「这是谁、这是什么、和谁相关」说清楚。
你可以把它理解成两层：
- 访客可见层：标题、段落、参数表、FAQ、联系方式。
- 机器可读层：同一事实的 JSON 表述——作者是谁、发布时间、面包屑路径、商品价格是否与页面一致。
Google 还区分过「富媒体搜索结果」和更进一步的「丰富搜索」（可按属性筛选的那类体验）。两者都依赖结构化数据，但都不等于排名保证。官方对丰富搜索的说明见：丰富搜索结果。
具体「哪种类型可能对应哪种搜索呈现」，以 Google 的功能清单为准，而不是凭感觉堆 schema：见 搜索结果图库（Search Gallery）。图库里能直接对上文章、面包屑、商品摘要、组织、本地商家、常见问题、课程列表、个人资料页面、评价摘要等——B2B/B2C 选型时先查这里有没有对应功能，再决定标不标。
对我这种做独立站的人来说，结构化数据还有一层现实价值：实体更稳。Person、Organization、Product、Article 标清楚，搜索引擎和不少 AI 检索链路更容易把「品牌 / 作者 / 产品」对齐到同一条实体，而不是把你和同名公司搅在一起。这和「保证出现富摘要」是两件事。
2. 怎么设置：推荐 JSON-LD，再对齐政策与验证
2.1 格式选择
Google 支持的三种格式里，官方推荐 JSON-LD（另外还有微数据、RDFa）。原因很实际：JSON-LD 不和 HTML 标签缠在一起，模板维护成本低，嵌套关系（比如 Event → Place → Address）也好写。CMS、主题、自定义 SeoHead 组件里注入一段 @graph，通常比在每个 <div> 上打 itemprop 更稳。
常见落地方式：
- 主题 / 插件生成（Shopify、部分 WordPress SEO 插件）。
- 建站框架统一组件注入（我站 Astro 的
SeoHead就是这条路）。 - 关键页手工或 CMS 字段输出（产品页、FAQ 页）。
无论哪条路，原则都是：页面上已有、用户能看到的事实，再映射进 JSON-LD。
2.2 政策红线（比「会不会出星级」更重要）
请直接对照 结构化数据常规指南 / 政策。我平时反复强调的几条：
- 内容要准确、与页面可见信息一致；不要用结构化数据描述用户看不到的东西。
- 不要误导：假评价、假库存、假价格、把非产品页硬标成 Product。
- 不要用 robots / noindex 挡住又指望富结果；Googlebot 读不到，谈不上展现。
- Review / AggregateRating 只在合法、真实、符合类型要求时使用；外贸站为了「好看」硬塞 4.9 星，是高风险动作。
违反质量指南，轻则无法获得富结果，重则影响该功能甚至站点相关资格——别拿结构化数据当黑帽装饰层。
2.3 验证思路
- 浏览器查看源码，确认有
application/ld+json，JSON 能 parse。 - 用 Google 的富媒体搜索结果测试（Rich Results Test）看类型是否被识别、有无错误。
- 上线后在 Search Console 看增强功能 / 相关报告（随功能名可能调整），盯错误与有效项。
- 改模板后抽检首页、关于页、一篇文章、一个商品/服务页，不要只测首页。
3. B2B 网站按页面类型该有什么
外贸询盘站、工厂站、服务商站，目标通常不是「加购」，而是「被理解成可信供应商 + 拿到询盘」。结构化数据要服务这个目标。
3.0 先对照搜索结果图库再选型
写 B2B / B2C 清单前，我习惯先打开 搜索结果图库：里面按功能列出 Google 搜索支持的结构化数据（文章、面包屑导航、组织、商品摘要、本地商家、FAQ、课程列表、个人资料页面、评价摘要等）。图库有对应功能，才值得按该类型的字段要求去标；图库没有的类型，仍可按 schema.org 描述实体（利于理解与 GEO），但不要期待特定富结果。
3.1 首页
- Organization（或你确实是本地实体时的 LocalBusiness）：品牌名、url、logo、地址（真实）、联系方式、
sameAs外链画像。 - WebSite：站点名、url、
publisher指回组织或人；若有站内搜索，可按文档加SearchAction（没有就别硬造）。 - WebPage：当前首页自身。
B2B 首页少见 Product；硬标一堆商品反而乱。
3.2 关于我们 / 团队页
- Person（实名操盘手、创始人）+ Organization。
jobTitle、knowsAbout、sameAs（LinkedIn、行业媒体作者页等）对 E-E-A-T 很有用。- 若页面本质是人物主页，也可见 ProfilePage（需与页面内容一致）。
我自己的关于页就是「全站 Person 图 + ProfilePage」双块，后面拆解会写到。
3.3 产品 / 服务页（询盘场景）
B2B 经常纠结：标 Product 还是 Service？
- 有明确 SKU、型号、可报价参数的工业品页：可用 Product，必要时加 Offer；注意 B2B 价格常「询价」——没有对用户可见的明确价格，就不要伪造
price。 - 纯服务（SEO 陪跑、定制方案）：更贴 Service，用
provider指回 Organization。 - 询盘 CTA 本身不是 schema 类型；ContactPoint 更适合放在 Organization / LocalBusiness 上。
3.4 文章 / 博客 / 知识页
- Article 或 BlogPosting：headline、datePublished、dateModified、author、image。
- 作者用
@id指回全站稳定的 Person，比每篇文章重写一长段 Person 更干净。 - 有真实 FAQ 区块再加 FAQPage；没问没答就别空壳。
3.5 联系页、案例、面包屑
- 联系页：页面可用 WebPage；组织级 ContactPoint（电话、邮箱、联系类型）挂在 Organization。
- 案例列表：CollectionPage / ItemList（条目对应真实案例 URL）。
- 几乎所有内页建议有 BreadcrumbList，与可见面包屑一致。
4. B2C 完整按页面类型该有什么
跨境独立站、品牌 DTC、本地零售，结构化数据更「交易向」。
4.1 首页
同样是 Organization + WebSite + WebPage。有品牌故事可 about 指回组织。SearchAction 仅在真有站内搜索时加。
4.2 类目 / 集合页
- CollectionPage 或带 ItemList 的列表页：列出该页真实展示的商品 URL。
- 不要把整站几千 SKU 塞进一个类目页的 ItemList「假装完整」。
4.3 商品详情页
这是 B2C 的核心（图库里对应「商品摘要 / 购物」一类功能，见 搜索结果图库）：
- Product：name、image、description、sku/gtin（有则写）、brand。
- Offer：price、priceCurrency、availability，必须与页面展示一致。
- AggregateRating / Review：仅当站点确有合规评价系统、评价可见且符合 Google 对该类型的要求；不要为了星级而造数据。
购物车、结账、账户页通常少标或不标交易型富结果；它们不是给搜索引流的主实体页，乱标收益低、风险不低。
4.4 本地门店与内容页
- 有线下店：LocalBusiness（或更具体的子类型），地址、营业时间、geo、电话要真实。
- 博客 / 指南：与 B2B 一样用 BlogPosting / Article + BreadcrumbList；导购文不要冒充 Product。
B2C 与 B2B 最大差别，不是「B2C 一定要更多类型」，而是：商品 Offers 与评价政策的合规压力更大。
5. seogeo.cc 现场拆解：我站真实 JSON-LD 长什么样
我打开线上源码（带常见爬虫 UA）抽了首页、关于页、知识库、课程准备页，以及一篇博客。结论先说：全站共用 SeoHead 注入的 @graph 骨架（Person + WebSite + WebPage，内页再叠加 BreadcrumbList / BlogPosting / FAQPage）；关于页与知识库还有页面级补充块。
5.1 首页 https://seogeo.cc/
一个 @graph，核心类型：
- Person
@id:https://seogeo.cc/seo-xiaoping-person
name: SEO小平；alternateName: 王小平；含jobTitle、knowsAbout、knowsLanguage、affiliation、一长串sameAs（X、知乎、雨果、YouTube、B 站、Medium 等）。 - WebSite
@id:https://seogeo.cc/#website，publisher指回上述 Person。 - WebPage
@id:https://seogeo.cc/#webpage，isPartOf指回 WebSite，about指回 Person。
首页没有 BreadcrumbList（合理），也没有硬塞 Product。
5.2 关于页 https://seogeo.cc/about
两块脚本：
- 与全站相同的
@graph：Person + WebSite + WebPage（url 换成 about）+ BreadcrumbList（首页 → 关于SEO小平）。 - 额外一块 ProfilePage，
about/mainEntity再指向同一 Person@id，并补充worksFor、hasCredential、alumniOf等字段。
要点是：Person 用稳定 @id 贯穿全站，关于页是加厚，不是另起一个互不相认的「新作者」。你也可以在 关于页 对照可见文案是否一致。
5.3 博客文章（抽检一篇）
以 https://seogeo.cc/website-geo-traffic-fast-but-bing-step-missed 为例，@graph 里除了 Person / WebSite / WebPage，还有：
- BlogPosting
@id:…#blogposting，含 headline、dates、image、author/publisher均@id指回 Person。 - FAQPage（该文确有 FAQ 区块时才会注入）。
- BreadcrumbList：首页 → 分类「随笔见闻」→ 文章。
模板逻辑在 SeoHead.astro：schemaType 含 BlogPosting 时 push 文章节点；有 FAQ 再 push FAQPage。实体 @id 用 #fragment，避免造出可被误收录的假路径。
5.4 知识库与课程准备页
- AI 知识库：除 SeoHead 骨架外，另有页面级
@graph，出现 Organization（https://seogeo.cc/#organization）、另一套 Person（#person）、Course、以及 FAQ 引用。这里能看到「全站 Person id」与「知识库自建 #person / #organization」并存——类型丰富，但也提醒你做站点时尽量统一@id，减少实体分裂。 https://seogeo.cc/course-prep：典型内页骨架 Person + WebSite + WebPage + BreadcrumbList。
一句话总结我站： 个人知识站以 Person 为中心实体，用 WebSite/WebPage/BlogPosting/BreadcrumbList（必要时 FAQPage、ProfilePage、Course）描述页面角色；不是电商站，所以没有满站 Product+Offer。
6. 实操建议与常见坑
- 先统一实体 id：公司用一个 Organization
@id，作者用一个 Person@id，全站引用，不要每页新造名字拼写不同的「分身」。 - B2B 先 Organization / Person / WebSite / 服务或产品真相，再谈评分；没真实评价就别标 AggregateRating。
- B2C 商品页把 Offer 与可见价格锁死；促销变价时结构化数据要同步，否则等于主动报错。
- FAQ / HowTo 必须页面可见；只存在于 JSON 里的问答，属于政策雷区。
- 富结果是资格，不是开关：类型对、字段对、政策对，仍可能因查询、地区、竞争而不展示。
- 改模板要回归测试：首页、关于、一篇博客、一个钱货相关页（商品或服务）四席抽检。
- 别指望结构化数据单独救命：标题意图、内容证据、内链、抓取与页面体验仍是基本功；schema 是「说清楚」，不是「刷排名」。
如果你正在搭外贸站或改主题，可以把本文当检查表：先问「这一页的主实体是谁」，再问「访客能不能在页面上看到同样事实」，最后才写进 JSON-LD。官方文档（简介、政策、丰富搜索、搜索结果图库）建议收藏，改站前翻一遍，比追插件「一键 schema」靠谱得多。