Schema Markup 完全指南：什麼是 Schema 標記以及如何用於 SEO（2026 版）

1. 什麼是 Schema Markup？30 秒快速入門

想象一个食谱网页，页面某处写着"30 分钟"。你知道这是烹饪时间，但搜索引擎只看到字符 "3-0"。

Schema 标记将這個数字标注为 cookTime，这样 Google 就知道这代表 30 分钟——而不是 30 卡路里、30 条评论或食谱第 30 页。

从技术上讲，Schema 标记是一种结构化資料，使用 Schema.org 提供的共享词汇表——该项目于 2011 年由 Google、Microsoft、Yahoo 和 Yandex 联合发起。它有几种格式，但你需要知道的只有 JSON-LD（JavaScript Object Notation for Linked Data）。Google 推荐使用它，它最易上手，也是本文全程使用的格式。

实际代码如下：

就这么简单。一个 <script> 程式碼區塊添加到页面 HTML 中即可。页面上没有任何视觉变化——只是向机器传递了一个关于内容含义的信号。

2. 為什麼 Schema Markup 在 2026 年仍然重要

你可能会想：AI 搜索已经接管了一切，老式的 Schema 标记还有用吗？

有用——但原因与 2020 年不同。

複合式搜尋結果（经典原因）

当 Google 更准确地理解你的内容时，它可以展示複合式搜尋結果：星级评分、价格、導覽標記导航、活动日期等。這些使你的搜索条目在成片的蓝色連結中脱颖而出。尽管 Google 从未确认 Schema 是直接排名因素，但複合式搜尋結果确实能显著提高點閱率。

AI 搜索可见性（2026 年的新原因）

以下是 2026 年关于 Schema 与 AI 搜索的資料：

• 约 65% 的搜索不再产生點擊（零點擊趋势，Similarweb 2024），这意味着你的内容需要被 引用 到 AI 答案中，而不仅仅是获得排名。
• AI 引荐流量在 2025 年初同比增长了 527%（Adobe 数字经济指数），Gartner 预测到 2026 年商业网站的传统自然搜索流量将下降 25%。
• 包含结构化資料的页面出现在 AI Overviews 中的概率显著更高——BrightEdge 研究发现大多数被 AI 引用的页面都包含 Schema 标记，结构化页面的出现概率高出 3 倍以上。
• Google AI Overviews 引用的来源中只有 16.7% 同时出现在自然排名前十（Yotpo, 2026）。传统排名和 AI 引用正在分化。

实体信号（被低估的原因）

Schema 标记为 Google 的 Knowledge Graph（知识图谱）提供資料——这是 Google 内部关于人物、地点、品牌和事物的資料库。当你使用带有稳定 @id 的 Organization Schema 时，实际上在告诉 Google"這個品牌是一个独立实体"。这对品牌搜索、本地搜索结果以及 AI 系统区分同名品牌至关重要。

客观评价

Schema 标记在 2026 年对于複合式搜尋結果和 AI 可见性来说，是一个必要但不充分的条件。它不能让糟糕的内容获得排名，也不能保证 AI 引用。但如果没有它，你最好的内容就更难被机器解析、分类和呈现——在任何渠道中都是如此。

3. Schema 类型：初学者真正需要知道的

Schema.org 定义了 800+ 种类型，Google 支援其中的一部分。作为初学者，你只需要了解其中 7 到 8 种。

2026 年必备 Schema 类型

应该从哪三个开始？

如果只做三件事，请實作以下三种：

1. 在首页添加 Organization
2. 每篇博客文章添加 Article（或 BlogPosting）
3. 每个页面添加 BreadcrumbList

这三者覆盖了实体身份、内容理解和导航——是所有其他 Schema 的构建基础。

4. 如何添加 Schema Markup：三种方法对比

目前有三种实用的 Schema 添加方式，对比如下：

AI Agent 方案是 2026 年的新方法，值得特别关注——特别是当你想要经过验证的自定义 Schema 但又不想学 JSON 语法时。

5. 方法一：CMS 插件（最简单）

如果你使用 WordPress、Webflow 或 Wix，插件或内置功能是获得基础 Schema 覆盖的最快路径。

WordPress

Yoast SEO 和 Rank Math 都能自动添加 Schema：

• Yoast 預設为页面設定 WebPage，为文章設定 Article
• 它还会根据你的設定生成 Organization（或 Person）Schema
• 在插件設定中一次性录入你的组织名称、Logo 和社交媒体资料即可

局限性：插件只能提供通用 Schema。你无法获得自定义的 Product 属性、详细的 Event 标记或 FAQPage——這些需要方法二或方法三。

Webflow、Wix、Shopify

這些平台的 Schema 支援程度各不相同。Webflow 和 Wix 允许在 SEO 面板中调整一些 Schema 設定。Shopify 自动为产品页面生成 Product Schema（价格、库存、变体）——但你可能需要补充 AggregateRating 或 Brand 属性，这需要自定义代码或方法三。

6. 方法二：手动 JSON-LD（複製即用）

有时你需要插件无法提供的 Schema。以下是三套完整、已验证的 JSON-LD 模板，可直接修改使用。

模板一：Organization（用于首页）

需要修改的内容： 将 yoursite.com 和 Your Brand Name 替换为你的真实資訊。@id 创建了一个稳定标识符——设定后永远不要更改。sameAs 数组应列出你真实的社交媒体资料（2–5 个即可）。

模板二：BlogPosting（用于博客文章）

需要修改的内容： 文章标题、描述、作者名称/URL、日期、图片 URL 和 publisher @id（应与 Organization 的 @id 一致）。注意：dateModified 应反映内容最后一次实质性更新的时间——搜索引擎会注意到过时的日期。

模板三：Product（用于电商页面）

需要修改的内容： 产品详情、价格、货币、库存状态和 priceValidUntil 日期。确保 price 和 availability 与页面上实际展示的一致——Schema 中的过时定价会导致 Google 取消你的複合式搜尋結果。

7. 方法三：AI Agent 實作（2026 年新方法）

这是自最早的 Schema 标记指南问世以来最大的变化。你现在可以使用 AI 程式開發代理——如 Claude Code 或 OpenAI Codex——来分析页面、确定正确的 Schema 类型、生成经过验证的 JSON-LD，并将其正确插入 HTML。

為什麼这对初学者很重要： 你不需要记住 Schema.org 的属性名称，不需要担心 JSON 语法错误，也不需要手动查阅 Google 的文档来确认必填字段。你只需用自然语言描述需求，AI 代理会完成剩下的工作。

AI Agent 能为 Schema 做什么

• 分析 URL 并推荐适用的 Schema 类型
• 生成 完整的、经过验证的 JSON-LD，包含所有必填+推荐属性
• 提取 页面中的真实資料（标题、作者、日期、价格、FAQ）并填入 Schema
• 验证 是否符合 Google 结构化資料要求并标记问题
• 将 Schema 插入 HTML 的正确位置
• 审计 多页面上的现有 Schema，查找错误、缺失属性或已弃用类型
• 警告 已退役类型（FAQPage 複合式搜尋結果于 2026 年 5 月停用、HowTo 仅桌面端等）

选项 A：使用現成的 Claude Code Skill

如果你使用 Claude Code（Anthropic 的 CLI 程式開發代理），最简单的方式是安装一个 Schema 标记 Skill。Skill 是一组指令，告诉 Claude 如何处理特定类型的任务——這裡就是 Schema 标记。

以下是一个完整的、開箱即用的 Skill 檔案。将其保存为 SKILL.md，放在项目的 .claude/skills/schema-markup/ 檔案夹中，或透過 Claude Code Skills 注册表安装。

---
name: schema-markup
description: Generate, validate, and insert Schema.org JSON-LD structured data for web pages. Use when asked to add schema markup, structured data, rich results, or JSON-LD to a page.
metadata:
  type: task
  version: "1.0"
  updated: "2026-07-30"
---

# Schema Markup Skill

You are a schema markup expert. When a user asks you to add, generate, check, or fix structured data, follow this workflow.

## Core Rules

1. **Always use JSON-LD format** wrapped in `<script type="application/ld+json">`. Never use microdata or RDFa.
2. **Mark up only what is visible on the page.** Content in the schema MUST have a visible counterpart in the page body. Hidden or misleading schema can trigger manual actions from Google.
3. **Use the most specific Schema.org type available.** Prefer `BlogPosting` over `Article` for blog posts. Prefer `Restaurant` over `LocalBusiness` for restaurants. Specificity helps search engines and AI systems classify content correctly.
4. **Always include `@context`: "https://schema.org"`** in every schema block.
5. **Use stable `@id` properties** for Organization and Person entities so different schema blocks can reference each other.
6. **Validate every required property.** Check Schema.org and Google's documentation for the type you're using. Missing required properties can prevent rich results.
7. **Never invent data.** Dates, prices, ratings, author names, and all other values must come from the actual page content or user-provided information.

## Deprecated & Limited Types (2026)

Flag these clearly when encountered or requested:
- **FAQPage** — Rich results retired by Google on May 7, 2026. Schema is still valid for general structured data and AI parsing, but it will NOT produce FAQ rich snippets in Google Search. Tell the user this explicitly.
- **HowTo** — Rich results are desktop-only since September 2023. Schema is still valid for AI/LLM parsing.
- **SpecialAnnouncement** — COVID-era type. Limited current use.
- **Dataset** — Limited support. Only use if the page genuinely hosts a dataset.

## Workflow

### Step 1: Analyze the Page
- If given a URL, fetch and read the page content. If given a file path, read the file.
- Identify: page type, visible content elements, existing schema (if any).
- Determine which schema types apply. Ask the user for confirmation if multiple types could fit.

### Step 2: Extract Real Data
From the visible page content, extract:
- Headline/title
- Author name and URL (if visible)
- Publication date and last-modified date
- Description or summary
- Main image URL
- Organization name, logo, and social links (from homepage or user input)
- Any prices, availability, ratings (from product pages)
- Any FAQ questions and answers (from FAQ sections)
- Any event dates, times, and locations

If any critical information is missing from the page, ASK the user. Do not invent.

### Step 3: Generate the JSON-LD
- Use the most specific type.
- Include ALL required properties per Schema.org.
- Include recommended properties when data is available.
- For multi-type pages (e.g., a product page with reviews and breadcrumbs), use the `@graph` pattern to include multiple types in one script block.
- Add a stable `@id` for entities that appear across multiple pages (Organization, Person).

### Step 4: Validate Before Output
- Check for valid JSON syntax (no trailing commas, proper quoting, no unescaped characters in strings).
- Verify all required properties are present.
- Confirm no properties reference data that isn't visible on the page.
- Flag any deprecated types being used.

### Step 5: Output with Clear Instructions
Provide the schema as a complete, copy-paste-ready code block. Include:
1. Where to place it (in `<head>` or at the end of `<body>` — either works)
2. Which properties the user should customize (brand name, URLs, prices, dates)
3. How to validate after insertion (link to Rich Results Test and Schema Validator)
4. A warning if any deprecated types are used

## @graph Pattern (Multiple Types on One Page)

When a page needs multiple schema types, combine them under `@graph`:

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "...",
      "author": { "@type": "Person", "name": "..." }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [...]
    },
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "..."
    }
  ]
}

Edge Cases

• No author visible on page: Use the Organization as the publisher; skip Person author schema.
• Product with variable pricing (min/max): Use AggregateOffer with lowPrice and highPrice, not a single Offer.
• Multiple FAQ sections: Combine all questions into one FAQPage block with a single mainEntity array.
• Job posting with salary range: Use QuantitativeValue with minValue and maxValue inside the baseSalary property.
• Event with multiple dates/times (recurring): Use multiple Event objects, one per occurrence. Do not try to cram all dates into one event.
• Page in a non-English language: Set inLanguage to the appropriate BCP 47 language code (e.g., "it", "de", "ja").

Post-Implementation

After the user adds the schema:

1. Remind them to validate with https://validator.schema.org/ and https://search.google.com/test/rich-results
2. Suggest submitting the updated page for reindexing in Google Search Console
3. Recommend monitoring the "Enhancements" section in GSC for schema-related errors over the following weeks

### 选项 B：独立 Prompt（适用于 Claude、Codex、ChatGPT 或任何 AI 工具）

如果你不使用 Claude Code 或更偏好一次性 Prompt，以下是可复制的指令，适用于任何 AI 程式開發工具。只需替换占位符并粘贴即可。

#### Prompt 1：为单篇博客文章添加 Schema

```text
I need you to generate JSON-LD schema markup for this blog post. Here's the information:

- Page URL: [YOUR_URL]
- Headline: [YOUR_HEADLINE]
- Author name: [AUTHOR_NAME]
- Author URL: [AUTHOR_PAGE_URL]
- Date published: [YYYY-MM-DD]
- Date last modified: [YYYY-MM-DD]
- Post summary (1-2 sentences): [YOUR_SUMMARY]
- Main image URL: [IMAGE_URL]
- Publisher name: [YOUR_BRAND_NAME]
- Publisher website: [YOUR_HOMEPAGE_URL]

Please:
1. Use @type BlogPosting (not Article)
2. Include headline, description, author (as Person), datePublished, dateModified, image, and publisher (as Organization with @id)
3. Output as a complete <script type="application/ld+json"> block
4. Only include data I've provided — don't invent anything
5. Tell me where to place the code and how to validate it

Prompt 2：为产品页面添加 Schema

Generate JSON-LD Product schema for this product page:

- Product name: [PRODUCT_NAME]
- Description (visible on page): [DESCRIPTION]
- Image URL: [IMAGE_URL]
- SKU: [SKU]
- Brand name: [BRAND]
- Price: [PRICE]
- Currency: [USD/EUR/etc.]
- Availability: [InStock / OutOfStock / PreOrder]
- Price valid until: [YYYY-MM-DD]
- Product page URL: [URL]
- Aggregate rating (if visible on page): [RATING_VALUE] from [REVIEW_COUNT] reviews

Please:
1. Use @type Product with Offer and optional AggregateRating
2. Include all provided properties, skip any I left blank
3. Output as a complete <script type="application/ld+json"> block
4. Remind me that price and availability must match what's visible on the page

Prompt 3：审计页面上的现有 Schema

I'm going to paste the HTML of a web page. Please find all existing schema markup (JSON-LD, microdata, or RDFa) and audit it:

1. List every schema block found, by type
2. Flag any missing required properties
3. Flag any deprecated types (FAQPage rich results retired May 2026, HowTo desktop-only)
4. Flag any data that doesn't seem to have a visible counterpart on the page
5. Flag any JSON syntax errors
6. Suggest improvements (more specific types, additional recommended properties)

Here's the HTML:
[PASTE_HTML_HERE]

Prompt 4：为整个网站批量生成 Schema

I need schema markup for a typical small business website with these pages:

Homepage: [URL]
About page: [URL]
Blog index: [URL]
Individual blog post template: [URL]
Contact page: [URL]
Product or service page: [URL] (if applicable)

Business details:
- Brand name: [NAME]
- Logo URL: [LOGO_URL]
- Social profiles: [LIST_URLS]
- Contact email: [EMAIL]
- Physical address (if local biz): [ADDRESS]

Please generate the appropriate schema for EACH page type:
1. Homepage → Organization (with @id, logo, sameAs, contactPoint)
2. Blog posts → BlogPosting (with publisher reference to Organization @id)
3. Blog index → CollectionPage (or Blog type)
4. Contact → WebPage with Organization reference
5. All pages → BreadcrumbList
6. Product/service → Product (if applicable)

Use the @graph pattern where a page needs multiple types. Output each page's schema as a separate, labeled code block.

8. 如何验证你的 Schema

添加 Schema 是第一步。确保它正常工作才是第二步。

两个必备验证工具（建议收藏）

1. [Schema.org Validator](https://validator.schema.org/) — 检查你的 JSON-LD 语法和 Schema.org 合规性。先用這個工具捕获结构性错误（缺少逗号、无效类型、缺少必填属性）。
2. [Google Rich Results Test](https://search.google.com/test/rich-results) — 专门检查你的页面是否符合 Google 複合式搜尋結果的展示条件。比 Schema.org 验证器更严格——它只检查 Google 支援複合式搜尋結果的类型。第二步使用。

工作流程： 先用 Schema.org Validator 验证（修复结构性问题）→ 再用 Rich Results Test（修复 Google 特定问题）→ 然后提交索引。

持续監控：Google Search Console

页面被索引后，Google Search Console 的 "Enhancements"（增强功能） 部分显示全站所有 Schema 驱动的複合式搜尋結果状态。每隔几周检查一次：

• 新增错误（网站更新后 Schema 失效）
• 警告（Schema 有效但可以改进）
• 趋势（更多页面获得了複合式搜尋結果吗？）

快速检查：浏览器扩展

Ahrefs SEO Toolbar（免费）在你访问任何页面时显示"Structured data"选项卡，可一键跳转到两个验证器。Detailed SEO Extension 和 SEO Pro 也有类似功能。

9. Schema Markup 与 AI 搜索：2026 年的已知事实

这是每个人都在问的问题："Schema 标记对 AI 搜索有帮助吗？"答案是微妙的。

研究结论

大多数 AI 系统不将 Schema 作为结构化資料来读取。 在 Mark Williams-Cook 的一个著名实验中，一个关于 "DUCKYEA t-shirts" 的页面仅在 Schema 标记中包含了一个虚构地址（页面上不可见）。ChatGPT 和 Perplexity 都返回了這個虚假地址——但结论是模型将其作为 HTML 中的纯文本 来读取，而非结构化資料。换句话说，Schema 恰好出现在它們解析的原始 HTML 中。

Marketing1on1 在 2026 年的一项实验证实了这一点：仅在 LocalBusiness Schema 中放置的营业时间（页面上不可见）没有被任何主要 AI 模型引用。所有 AI 都表示该网站没有公布其营业时间。

Gemini 是显著的例外。 Dan Petrovic 的研究发现证据表明 Google 的 Gemini 模型在其 grounding（資訊溯源）过程中使用结构化資料——该机制是 Gemini 查询 Google 搜索索引以验证回复的方式。因此，至少对于 Google 的生态系统而言，Schema 可能更重要。

AI 爬虫不执行 JavaScript。 GPTBot（OpenAI）、ClaudeBot（Anthropic）和 PerplexityBot 都只处理原始 HTML。如果你的 Schema 是透過 Google Tag Manager 添加的，或者是透過客户端 JavaScript 注入的，AI 爬虫将无法看到。Schema 必须出现在静态 HTML 中，作为服务端渲染的 <script type="application/ld+json"> 程式碼區塊。

间接路径：实体才是关键

Schema 在 2026 年最强的 AI 关联是透過实体信号——而非直接的 Schema 读取。

当你實作带有稳定 @id 和准确 sameAs 連結的 Organization Schema 时，你正在向 Google 的 Knowledge Graph 提供資料。而 Knowledge Graph 正是 Google 的 AI 系统（Gemini、AI Overviews）用来溯源其回答的基础。一个定义明确的实体更有可能被正确引用，也更不容易与其他品牌混淆。

Wordlift 研究（2026 年 3 月） 发现，将页面重新设计为结构化的"增强实体页面"（Enhanced Entity Pages）——实体关系在页面上可见且可导航，而非隐藏在 JSON-LD 中——将 AI 答案准确度提升了 29.8%。关键洞察：当 Schema 反映了页面上也能看到的实体关系时，它才最有帮助。

实操要点

2026 年面向 AI 搜索：

• ✅ 应该做： 實作清晰的 Organization、Article 和 Product Schema，使用 @id 相互引用
• ✅ 应该做： 服务端渲染所有 Schema（而非透過 JavaScript）
• ✅ 应该做： 确保每个 Schema 字段在页面上都有对应的可见内容
• ✅ 应该做： 关注实体清晰度（稳定的 @id、准确的 sameAs、一致的名称/地址/电话）
• ❌ 不要： 指望仅靠 Schema 就让 ChatGPT 或 Claude 引用你
• ❌ 不要： 在 Schema 中隐藏页面上不存在的内容
• ❌ 不要： 使用已弃用类型并期待複合式搜尋結果（FAQPage、HowTo）

10. 常见 Schema 错误（以及 AI 如何帮助你避免）

在审计数千个页面后，某些错误反复出现。以下是六大常见错误——以及 AI Agent 如何在你发布之前就捕获它們。

1. 无效的 JSON 语法

对象最后一个属性后面的尾随逗号是头号错误。它会破坏整个 Schema 程式碼區塊。

// 错误 — "name" 后面多了逗号
{
  "@type": "Organization",
  "name": "My Brand",
}

AI Agent 不会犯這個错误——它每次生成的 JSON 语法都是正确的。

2. Schema 与页面内容不匹配

你的 Schema 写的是 "price": "19.99"，但页面上显示的是 $29.99。Google 视之为误导資訊，可能直接取消你的複合式搜尋結果。AI Agent 在获得页面内容进行分析后，会从页面中提取实际值而非凭空编造。

3. 使用了过于泛化的类型

用 Article 而不是 BlogPosting。用 LocalBusiness 而不是 Restaurant 或 Dentist。泛化类型虽然能用，但会错失类型特定的複合式搜尋結果功能。优秀的 AI Agent 会建议使用最具体的适用类型。

4. Schema 程式碼區塊重复

你的 CMS 插件添加了 Organization Schema，你手动又添加了另一个 Organization 程式碼區塊。现在 Google 看到了关于同一个实体的两份矛盾描述。AI Agent 可以检测到已有的 Schema，然后选择替换或补充——而非重复。

5. 缺少必填属性

每种 Schema 类型都有 Google 文档规定的必填属性。例如，Product 需要 name，Event 需要 startDate。缺少一个就可能导致整个类型的複合式搜尋結果资格被取消。AI Agent 会对照当前文档检查它生成的每种类型。

6. 日期过时或错误

dateModified 写的是 2023 年，但文章上周刚更新过。priceValidUntil 是过去的日期。过时的日期向搜索引擎传递了"内容不再维护"的信号。AI Agent 使用页面内容中实际日期，并在日期需要更新时发出提醒。

11. Schema 實作檢查清單

以下是执行清单。每个网站完整执行一次——或每种页面类型执行一次。

基础层（每个网站执行一次）

• [ ] 首页添加 Organization Schema：@id、name、url、logo、2–5 个 sameAs 社交連結
• [ ] Website Schema（可选但推荐）：基础站点级别标记
• [ ] 所有有導覽標記导航的页面添加 BreadcrumbList

内容页面（每篇文章/页面执行）

• [ ] 每篇博客文章添加 BlogPosting（或 Article）：headline、author（Person）、datePublished、dateModified、image、publisher（引用 Organization 的 @id）
• [ ] 作者名称和 URL 准确且在页面上可见

产品/服务页面（如适用）

• [ ] Product Schema：name、description、image、offers（含 price、priceCurrency、availability、priceValidUntil）
• [ ] 价格和库存状态与页面展示一致
• [ ] AggregateRating 仅在页面上可见的真实评论存在时使用（不能是第三方网站上的评论）

验证

• [ ] 每个 Schema 程式碼區塊透過 Schema.org Validator 验证
• [ ] 每个 Schema 程式碼區塊透過 Google Rich Results Test 验证
• [ ] 任何页面上都没有重复或冲突的 Schema 程式碼區塊
• [ ] 所有 Schema 均在静态 HTML 中服务端渲染（非透過 JavaScript 注入）
• [ ] 每个 Schema 字段在页面上都有对应的可见内容

持续维护

• [ ] 每月检查 Google Search Console "Enhancements" 是否出现新错误
• [ ] 页面内容变更时同步更新 Schema（新价格、日期、作者）
• [ ] 定期检查已弃用类型（FAQPage、HowTo）并考虑替代方案

常见问题

Schema 标记能直接提升 Google 排名吗？

不能——Google 从未确认 Schema 是直接的排名信号。但它能启用複合式搜尋結果，从而提升點閱率。而點閱率作为一种用户行为信号，可以间接影响排名。可以这样理解：Schema 改善的是可见性，而非排名位置。

ChatGPT 或 Claude 能读取我的 Schema 标记吗？

不是作为结构化資料来读取。研究一致表明，大多数 AI 模型将 Schema 当作 HTML 中的纯文本处理——就像阅读任何其他代码一样。它們不会将其解析为结构化含义。唯一的例外是 Google 的 Gemini，有证据表明它在資訊溯源过程中使用了结构化資料。

小型个人博客需要 Schema 标记吗？

需要——但保持简单即可。在首页添加 Organization（或 Person），在每篇文章添加 BlogPosting。这只需要 15 分钟，覆盖了最基本的要素。你不需要像电商网站那样實作全套 Schema 类型。

Schema 上线后多久能在搜索结果中显示？

添加 Schema 后，在 Google Search Console 中提交索引请求。複合式搜尋結果可能在几天到几周后出现——Google 需要重新抓取和处理页面。并非所有页面都能获得複合式搜尋結果；资格取决于页面质量、权威性以及 Google 是否认为 Schema 資料准确。

JSON-LD、Microdata 和 RDFa 有什么区别？

• JSON-LD： 独立的 <script> 程式碼區塊，与 HTML 分离。Google 推荐的格式。最容易编写和维护。
• Microdata： Schema 属性散布在 HTML 标签内部。维护难度更高，因为 HTML 变更可能破坏 Schema。
• RDFa： 与 Microdata 类似但更古老。2026 年很少用于 SEO。

使用 JSON-LD。在 2026 年，没有充分理由去使用其他两种格式做 SEO。

我真的可以用 AI 来生成 Schema 标记吗？

是的——而且它正迅速成为非开发人员最实用的方法。参见上文第 7 节中的 Claude Code Skill 和独立 Prompt。AI 处理 JSON 语法、知道哪些属性是必填的、能识别已弃用类型。你只需要提供实际的页面資料。

现在就开始

Schema 标记是技术 SEO 中投资回报率最高的任务之一。它不费时、文档完善，而现在——借助 AI Agent 工具——如果你不想写，连一行 JSON 都不用自己写。

从本文中选择一件事立即执行：

• 如果你使用 WordPress，安装 Yoast SEO 并配置 Organization 設定（5 分钟）
• 如果你想要完全可控，复制第 6 节的 BlogPosting 模板并适配到你最新的文章（10 分钟）
• 如果你想要最简单的路径，使用第 7 节的 Claude Code Skill 或 Prompt 1 来生成你的第一个 Schema 程式碼區塊（2–5 分钟）

然后用 Rich Results Test 验证它，在 Search Console 中提交索引，一周后回来查看。SERP 中那个第一个複合式搜尋結果值得你付出的这点努力。

Author: Julian Mercer，Auspia 14 年技术 SEO 从业者。Julian 撰写关于 Schema 标记、可抓取性、渲染、网站架构以及面向 AI 可读内容的技术基础等主题的文章。