结构化数据(Schema)是给机器看的「内容说明书」。这份指南讲清楚 B2B 外贸站该加哪几种、怎么写、放哪里、怎么验证。
发布于 2026-10-17 · 约 9 分钟阅读
一句话定义:结构化数据是给页面内容加的「机器可读标签」,告诉搜索引擎和 AI「这段话是问题、那段话是答案、这个数字是价格」。没有它,机器只能靠猜;有了它,机器能准确理解页面结构与语义。
SEO 时代它的作用是富媒体摘要(搜索结果里显示评分、FAQ 折叠、面包屑,提升点击率)。到了 GEO 时代,它的价值更进一层:AI 生成答案时需要引用「确定性高」的信息源,结构化数据就是确定性的来源之一。当你的 FAQ 被标记为 FAQPage、术语被标记为 DefinedTermSet,AI 抓取和理解这些内容的效率远高于普通段落。
| 类型 | 用在哪些页面 | 解决什么问题 |
|---|---|---|
| Organization | 全站(首页或关于页) | 声明公司实体:名称、logo、联系方式、成立时间。是 AI 认识「你是谁」的第一来源。 |
| BreadcrumbList | 所有子页面 | 声明面包屑导航路径,搜索结果里显示层级而非裸 URL。 |
| Article | 博客与新闻页 | 声明标题、作者、发布时间,帮助进入新闻类富媒体结果。 |
| Service | 服务页 | 声明服务名称、描述、提供方,强化「公司-服务」的实体关联。 |
| FAQPage | 有问答内容的页面 | 声明问答对,搜索结果可折叠展示;同时是 AI 抓取问答内容的高效格式。 |
多语言站点再加 hreflang 标注语言版本;术语表类页面可以加 DefinedTermSet;有详细步骤的教程可以加 HowTo(注意:谷歌已大幅收缩 HowTo 的富媒体展示,但结构化声明本身仍有语义价值)。
谷歌目前只推荐一种格式:JSON-LD——一段放在页面里的 JavaScript 对象,不影响渲染,改起来也最安全。下面是一个 FAQPage 的最小可用示例:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "外贸独立站多久能被谷歌收录?",
"acceptedAnswer": {
"@type": "Answer",
"text": "提交 sitemap 后通常 3-7 天开始收录首页,内页陆续跟上。"
}
}]
}
三个字段注意点:name 必须是页面上真实存在的问题(不能虚构);text 是完整答案(不是摘要);一个页面可以放多个 JSON-LD 块,用 separate script 标签或 @graph 数组均可。
我们的做法是第一种 + 第二种结合:模板管全局实体,页面数据驱动管具体内容——纯静态输出,无插件依赖,抓取端拿到的是完整 HTML。
Schema Markup Validator(validator.schema.org)验证语法与字段完整性;GSC「增强功能」报告看谷歌实际识别了哪些、报了哪些错。后者才是裁判——语法对了但谷歌不认,通常是因为页面内容与标记不符。
最后更新:2026-10-17