摘要：别乱加Schema，先讲清页面对象
系列：AI建站与SEO/GEO营销完整教程｜第 10/20 篇
关键词：Schema教程、结构化数据、JSON-LD
很多卖家做独立站和内容站，会把 Schema 当成一个“SEO 插件开关”。
插件里勾一下 Article、FAQ、Product、Organization，好像页面马上就更容易排名。
这就是第一个误区。
Schema 不是排名捷径，也不是给页面贴越多标签越好。它真正的作用，是用机器能读懂的格式说明：这个页面讲的对象是什么、对象有哪些属性、对象之间是什么关系。
对跨境卖家来说，这件事很实际。
你的页面到底是一篇选购文章、一个产品详情页、一个尺寸计算工具、一个品牌介绍页，还是一个专题页？如果页面自己讲不清，搜索系统和 AI 搜索系统就只能从正文里猜。
结构化数据做得好，相当于给网页补了一张“标准资料卡”。
一个真实场景：宠物笼卖家，页面很多但对象混乱
假设你是一个做宠物用品的跨境卖家，准备做一个英文站，主推可折叠 dog crate。
网站上有这些页面：
Dog Crate Size Chart：一篇尺寸选购文章；Dog Crate Size Calculator：一个尺寸计算工具；Foldable Dog Crate 36 inch：一个产品详情页；Dog Crate Training Guide：一个专题页；About PawHome：品牌介绍页。
用户能看懂这些页面，但搜索系统不一定能立刻判断清楚：
- 这是一篇 Article，还是一个 Product？
- 这个计算器算不算 SoftwareApplication？
- 这个品牌页是不是 Organization？
- 面包屑路径是什么？
- 产品价格、库存、评分是不是页面上真实可见？
- FAQ 是否还能带来 Google 富结果？
这时候 Schema 的价值就出来了。
它不是替代正文，而是把正文里已经可见、已经真实的信息，用标准 JSON-LD 再说一遍。
先把事实边界说清楚
资料事实一：Google 官方结构化数据文档说明，结构化数据是一种标准格式，可以提供页面信息并分类页面内容。Google 可用这些信息理解页面，也可能让页面获得更丰富的搜索展示。
资料事实二：Google 支持 JSON-LD、Microdata 和 RDFa，其中在可行时推荐使用 JSON-LD。
资料事实三：Google 的结构化数据通用指南要求，标记内容必须准确、代表页面主要内容，并且结构化数据描述的内容应当对用户可见。不能为了富结果标记页面上没有的评分、评论、价格或问答。
资料事实四：不是 Schema.org 上存在的每一个类型，Google Search 都会给富结果。Google 支持一部分结构化数据功能，每种功能还有自己的必填和推荐字段。
资料事实五：截至 2026 年 7 月 7 日，Google 官方更新记录显示，FAQ rich result 功能已经不再在 Google Search 结果中展示，相关文档也已移除。这意味着普通网站不要再把 FAQPage 当成“抢富结果”的主策略。FAQ 内容仍然可以写在页面里，但 Schema 策略要更谨慎。
合理推断：结构化数据对 AI 搜索和生成式搜索的价值，不应被理解成“提交后必定被引用”。更现实的作用是：让网页对象、作者、产品、组织、路径和工具属性更清楚，减少系统理解成本。
实操建议：先把页面内容做扎实，再给真实可见的信息补 JSON-LD。不要让 Schema 走在内容前面。
Schema到底解决什么问题
你可以把 Schema 理解成产品包装上的标准标签。
页面正文是产品本身。
标题、段落、图片、价格、FAQ、工具说明，是用户看到的内容。
Schema 则是给机器看的资料卡：
- 这是文章；
- 作者是谁；
- 发布时间和更新时间是什么；
- 这篇文章属于哪个路径；
- 这是产品；
- 品牌、SKU、价格、库存是什么；
- 这是软件或工具；
- 工具名称、用途、应用类别是什么；
- 这是组织；
- 官网、Logo、社媒资料是什么。
没有 Schema，搜索系统也可能理解页面。
有正确 Schema，相当于你主动把关键对象说清楚。
但如果 Schema 写错，就像产品包装上乱贴标签：页面明明没有评价，你写 4.9 星；页面明明没有价格，你写 $39.99；页面明明是文章，你硬标 Product。短期看像优化，长期看是风险。
页面类型和Schema怎么匹配
先别急着写代码。先做页面类型判断。
下面这张表，是内容站、工具站、产品站最常用的匹配方式。
| 页面类型 | 推荐优先考虑 | 什么时候用 | 不要这样用 |
|---|---|---|---|
| 文章页 | Article + BreadcrumbList | 教程、选购指南、测评、排障文章 | 不要把普通文章标成 Product |
| 专题页 | WebPage 或 CollectionPage + BreadcrumbList | 某个主题入口、系列页、分类页 | 不要为了凑字段乱标 FAQ |
| 工具页 | SoftwareApplication 或 WebApplication + BreadcrumbList | 计算器、生成器、检测工具 | 页面只是文章时不要硬标工具 |
| 产品页 | Product + Offer | 独立站产品详情页，有真实价格库存 | 不要伪造评分、评论、库存 |
| 品牌页 | Organization | 公司/品牌介绍、官网主体 | sameAs 不要填无关账号 |
| 导航路径 | BreadcrumbList | 多数重要页面都可以用 | 路径要和页面真实层级一致 |
这里的重点不是“加得多”，而是“加得准”。
对一个 Dog Crate Size Calculator 页面，更合理的是：
- 页面本体：SoftwareApplication 或 WebApplication；
- 路径：BreadcrumbList；
- 如果页面有相关说明文章，文章页面再用 Article；
- 不要在工具页上硬写 Product，除非页面真的主卖一个产品。
对一个 Foldable Dog Crate 36 inch 产品页，更合理的是：
- 页面本体：Product；
- 出售条件：Offer；
- 品牌：brand；
- 图片：image；
- SKU 或 GTIN：如果真实存在就写；
- 评分评论：只有页面真实展示并符合 Google 指南时才写；
- 路径：BreadcrumbList。
文章页示例：Article + BreadcrumbList
假设页面是：
/guides/dog-crate-size-chart
页面标题是：Dog Crate Size Chart: How to Choose the Right Crate
页面可见内容包括作者、发布日期、更新时间、文章图片、正文和路径。
JSON-LD 可以这样写：
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Dog Crate Size Chart: How to Choose the Right Crate",
"description": "A practical guide for choosing a dog crate size based on dog length, height, weight, and use scenario.",
"image": "https://www.example.com/images/dog-crate-size-chart.jpg",
"author": {
"@type": "Organization",
"name": "PawHome"
},
"publisher": {
"@type": "Organization",
"name": "PawHome",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/logo.png"
}
},
"datePublished": "2026-07-01",
"dateModified": "2026-07-07",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.example.com/guides/dog-crate-size-chart"
}
}
再加 BreadcrumbList：
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Guides",
"item": "https://www.example.com/guides"
},
{
"@type": "ListItem",
"position": 3,
"name": "Dog Crate Size Chart",
"item": "https://www.example.com/guides/dog-crate-size-chart"
}
]
}
注意：日期、作者、图片、标题，最好和页面可见内容保持一致。不要为了显得更新，把 dateModified 每天自动改成今天。
产品页示例：Product + Offer
假设你有一个产品页：
/products/foldable-dog-crate-36-inch
页面真实展示：
- 产品名；
- 品牌；
- 主图；
- SKU；
- 价格；
- 库存状态；
- 产品描述；
- 评分和评论。
可以用 Product：
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Foldable Dog Crate 36 inch",
"image": [
"https://www.example.com/images/foldable-dog-crate-36.jpg"
],
"description": "A foldable 36-inch dog crate for medium dogs, designed for home and travel use.",
"sku": "PH-CRATE-36",
"brand": {
"@type": "Brand",
"name": "PawHome"
},
"offers": {
"@type": "Offer",
"url": "https://www.example.com/products/foldable-dog-crate-36-inch",
"priceCurrency": "USD",
"price": "79.99",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}
如果页面没有真实用户评分，不要写：
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.9",
"reviewCount": "238"
}
这是很多卖家最容易踩的坑。
Google 对产品结构化数据有专门指南，产品页要区分 Product snippets、Merchant listings、变体、退货政策、配送政策等不同功能。刚开始不用一次做全，但价格、库存、币种、图片、产品名必须和页面真实内容一致。
工具页示例：SoftwareApplication
如果你做的是工具页，例如：
/tools/dog-crate-size-calculator
这个页面不是普通文章，而是一个在线计算器。你可以考虑 SoftwareApplication 或 WebApplication。
示例：
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Dog Crate Size Calculator",
"applicationCategory": "LifestyleApplication",
"operatingSystem": "Web",
"url": "https://www.example.com/tools/dog-crate-size-calculator",
"description": "A free web calculator that helps dog owners estimate a suitable crate size based on dog measurements and use scenarios.",
"publisher": {
"@type": "Organization",
"name": "PawHome"
},
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
}
}
这里要注意两点。
第一，工具页要真的有可用工具，不能只是一篇文章。
第二，Schema 只是说明“这是一个软件应用/网页工具”。真正让页面有价值的，仍然是可见正文：使用场景、输入字段、计算逻辑、示例结果、风险边界和相关内容。
品牌页示例：Organization
品牌页、关于我们、首页，可以考虑 Organization。
示例：
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "PawHome",
"url": "https://www.example.com",
"logo": "https://www.example.com/logo.png",
"sameAs": [
"https://www.instagram.com/pawhome",
"https://www.youtube.com/@pawhome"
]
}
sameAs 只放真实官方账号。不要把经销商账号、平台搜索页、无关论坛主页都塞进去。
Organization 的价值，是帮助系统理解“这个站背后的实体是谁”。对品牌独立站、内容站、工具站都很重要。
FAQ要不要加Schema
这部分要单独讲，因为很多旧教程会建议所有页面都加 FAQPage。
截至 2026 年 7 月 7 日，Google 官方更新记录显示，FAQ rich result 功能已经不再在 Google Search 结果中展示，并且相关文档已移除。
这并不意味着页面里不能有 FAQ。
FAQ 对用户仍然很有用，也可能帮助页面覆盖更完整的问题意图。但不要再把“加 FAQPage 就能拿 FAQ 富结果”当成策略。
实操建议：
- 文章页可以保留 FAQ 模块；
- 产品页可以保留购买前常见问题；
- 工具页可以保留输入和结果解释；
- 是否继续写 FAQPage，需要看具体项目，不要作为优先级最高的 Schema；
- 不要把页面没有展示的问题写进 JSON-LD。
换句话说：FAQ 先为用户写，Schema 不要为富结果幻想写。
Next.js里怎么落地JSON-LD
如果你用 Next.js App Router，可以在页面组件里输出 JSON-LD。
官方 Next.js JSON-LD 指南给出的方向，是用 <script type="application/ld+json"> 注入结构化数据，并注意避免把不可信数据直接注入。
一个简化示例：
export default async function ArticlePage() {
const article = {
title: 'Dog Crate Size Chart: How to Choose the Right Crate',
description: 'A practical guide for choosing a dog crate size.',
url: 'https://www.example.com/guides/dog-crate-size-chart',
image: 'https://www.example.com/images/dog-crate-size-chart.jpg',
datePublished: '2026-07-01',
dateModified: '2026-07-07',
}
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: article.title,
description: article.description,
image: article.image,
datePublished: article.datePublished,
dateModified: article.dateModified,
mainEntityOfPage: {
'@type': 'WebPage',
'@id': article.url,
},
author: {
'@type': 'Organization',
name: 'PawHome',
},
}
return (
<main>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(jsonLd).replace(/</g, '\\u003c'),
}}
/>
<h1>{article.title}</h1>
<p>{article.description}</p>
</main>
)
}
这个例子里有三个关键点。
第一，JSON-LD 的字段来自页面真实数据，不是手写幻想值。
第二，页面上也能看到标题和描述，不是只写在 JSON-LD 里。
第三，对 < 做替换，是为了降低脚本注入风险。真实项目里要统一封装组件，不要每个页面都复制一段。
一套Schema上线SOP
你可以按下面流程执行。
第一步，列页面类型。
把网站页面分为：
- 首页；
- 专题页；
- 文章页；
- 工具页；
- 产品页；
- 品牌页；
- 资源页。
第二步，给每类页面确定主 Schema。
每页先只选一个主对象。例如 Article、Product、SoftwareApplication、Organization、WebPage。
第三步，补 BreadcrumbList。
重要页面尽量有真实面包屑路径。路径要和页面导航层级一致。
第四步，整理字段来源。
每个字段都要能回答：它来自哪里？
name来自 H1；description来自摘要或产品描述；image来自主图；datePublished来自发布日期；price来自产品页可见价格；availability来自库存状态；author来自作者或品牌；sameAs来自官方社媒账号。
第五步，生成 JSON-LD。
可以让 AI 生成初稿，但必须人工核对字段来源。
第六步，用工具验证。
至少使用：
- Google Rich Results Test：看是否符合 Google 支持的富结果功能；
- Schema Markup Validator：看 Schema.org 语法和类型是否合理；
- Search Console：上线后看结构化数据增强报告和问题。
第七步，抽样看页面源码。
确认 JSON-LD 出现在最终页面里，不是只在本地代码里。
第八步，建立字段同步机制。
产品价格、库存、评分、发布日期、更新时间，不要人工复制到 Schema 后就忘了。字段最好来自同一套数据源。
可以直接复制的提示词
下面这段可以直接给 Cursor、Codex、Claude Code 或内容 SEO 同事。
你是一个熟悉 Google 结构化数据、Schema.org、JSON-LD、Next.js 和跨境电商 SEO 的技术 SEO 顾问。
我要为一个网站设计结构化数据方案：
- 网站类型：[内容站 / 工具站 / 品牌站 / 产品站 / 多语言站]
- 目标市场：[美国 / 欧洲 / 日本 / 其他]
- 技术栈：[Next.js App Router / WordPress / Webflow / Shopify / 其他]
- 页面类型：[首页、专题页、文章页、工具页、产品页、品牌页、资源页]
- 示例页面内容：[粘贴页面主要内容或字段]
请你输出结构化数据方案，必须包含：
1. 每类页面推荐的主 Schema 类型，以及为什么适合。
2. 每类页面是否需要 BreadcrumbList。
3. 每个 Schema 字段的数据来源，必须区分“页面可见内容”“后台字段”“不能填写”。
4. Article、Product、SoftwareApplication、Organization 的 JSON-LD 示例。
5. 哪些字段不能编造，例如评分、评论、价格、库存、作者、发布时间。
6. FAQPage 当前在 Google Search 中的展示边界，不要把 FAQ 富结果当作核心收益。
7. Next.js App Router 的落地方式，包括如何注入 JSON-LD 和如何避免脚本注入风险。
8. 验证流程：Rich Results Test、Schema Markup Validator、Search Console。
9. 上线前检查清单和常见错误。
要求：
- 不要为了富结果乱加 Schema。
- 只允许标记页面真实可见或后台真实存在且页面一致的信息。
- 如果某个字段无法确认，请标记“需要人工确认”，不要编造。
如果你要让 AI 检查现有页面，可以追加：
请检查当前页面的结构化数据风险：
1. JSON-LD 是否能解析；
2. Schema 类型是否和页面主要内容一致；
3. 字段是否和页面可见内容一致；
4. 是否伪造评分、评论、价格、库存；
5. 是否使用过时或不再适合的 FAQ 策略；
6. 是否缺少 BreadcrumbList；
7. Product、Article、SoftwareApplication、Organization 是否各用在正确页面；
8. 请输出 P0/P1/P2 修复清单。
上线前检查清单
按这张清单检查。
| 检查项 | 通过标准 | 不通过的风险 |
|---|---|---|
| Schema类型 | 和页面主对象一致 | 页面语义混乱 |
| 可见内容一致 | JSON-LD 描述的信息页面能看到 | 违反结构化数据指南 |
| 字段来源 | 每个字段有真实来源 | AI 编造数据 |
| 产品价格库存 | 与页面和后台一致 | 产品富结果风险 |
| 评分评论 | 真实展示且符合指南 | 虚假标记风险 |
| BreadcrumbList | 路径和导航一致 | 层级关系不清 |
| JSON格式 | 能通过解析和验证 | Google 无法读取 |
| 富结果资格 | 只期待 Google 支持的功能 | 错把 Schema.org 当 Google 支持列表 |
| FAQ策略 | 不把 FAQ 富结果当主收益 | 使用过时策略 |
| 上线监控 | Search Console 能看到报告 | 问题发现太晚 |
这张表的本质是防止“看起来加了很多 Schema，实际上字段全错”。
常见错误和边界
第一，Schema 不是排名保证。
Google 官方一直把结构化数据描述为理解页面和可能产生富结果的方式，不是排名承诺。不要把“加了 Schema”当成排名策略的核心。
第二，不要标记页面上没有的内容。
页面没有价格，不要写价格；没有库存，不要写 InStock；没有评论，不要写 Review；没有评分，不要写 AggregateRating。
第三，不要把所有页面都标成 Product。
很多内容站为了商业化，把文章页、专题页、工具页都标 Product。这会让页面对象变得混乱。
第四，不要迷信 FAQPage。
FAQ 内容可以保留，但 Google Search 的 FAQ rich result 已经不再展示。旧教程如果还把 FAQPage 当核心增长技巧，需要更新。
第五，不要让 AI 自动生成最终 Schema。
AI 可以生成草稿，但字段必须人工核对。特别是日期、作者、价格、库存、评分、公司信息、社媒账号，不能让 AI 猜。
第六，不要只验证语法。
Schema Markup Validator 能帮你看语法和类型，Rich Results Test 能看 Google 支持的富结果资格，但两者都不等于 Google 一定展示富结果。上线后还要看 Search Console。
最小可行版本
如果你的网站刚开始，不要第一天做一大堆复杂 Schema。
先做这四类：
- 全站：Organization。
- 所有重要页面：BreadcrumbList。
- 文章页：Article。
- 产品页：Product + Offer。
如果有明确在线工具，再做：
- 工具页：SoftwareApplication 或 WebApplication。
先把这几类做准，比全站乱加十几种类型更有价值。
Schema 的目标，不是让页面伪装得更厉害，而是让真实内容表达得更清楚。
对 AI 建站和 AI 搜索时代来说，这个思路更重要：网页不只给人看，也要给搜索系统、AI 搜索系统和未来的 Agent 看。结构化数据就是其中一层清晰、克制、可验证的机器说明书。
官方参考资料
- Google Search Central: Intro to structured data：用于核对结构化数据定义、Google 理解页面和富结果边界、JSON-LD 推荐使用方式。
- Google Search Central: General structured data guidelines：用于核对结构化数据内容必须准确、可见、代表页面主要内容等通用要求。
- Google Search Central: Article structured data：用于核对 Article 类型和文章页字段。
- Google Search Central: Product structured data：用于核对 Product、Offer、产品结果和购物相关结构化数据边界。
- Google Search Central: Breadcrumb structured data：用于核对 BreadcrumbList 标记方式。
- Google Search Central: Organization structured data：用于核对 Organization、logo、sameAs 等品牌实体信息。
- Google Search Central: Software App structured data：用于核对 SoftwareApplication 类型。
- Google Search documentation updates: Removing FAQ rich result feature：用于核对 FAQ rich result 在 Google Search 中不再展示及文档移除的当前状态。
- Schema.org: Product：用于核对 Schema.org Product 类型本身的词汇定义。
- Schema.org: SoftwareApplication：用于核对 Schema.org SoftwareApplication 类型本身的词汇定义。
- Schema Markup Validator：用于核对 Schema.org 语法和类型。
- Next.js Docs: JSON-LD：用于核对 Next.js App Router 中注入 JSON-LD 的官方做法。