AEO 的結構化資料：先標品牌和頁面，再談引用
更新 2026-10-12
結構化資料用 Schema.org 這套共用詞彙，標出一個網頁代表什麼、裡面有哪些實體、資訊從哪裡來。在 AEO（Agent Engine Optimization，代理引擎最佳化）裡，這些標籤讓系統比較容易解釋內容、把資訊歸到正確的對象。它不保證被引用。類型用錯、缺了重要欄位，或和讀者看得到的頁面不一致，會送出不清楚的訊號。
Conductor 把常用類型分成三組。基礎是 Organization、WebSite、WebPage，說明品牌是誰、網站是哪一個、單頁怎麼接回去。頁面類型是 Article 或 BlogPosting、Person、Product、Review、AggregateRating、FAQPage、HowTo、BreadcrumbList。場景類型是 LocalBusiness、Service，以及醫療、金融這類更細的類型。他們的順序是：先做三個基礎類型，再只在和可見內容相符的地方加更細的類型，網站一改就重新驗證。
目錄（11）
來源聲明 原文
完整來源聲明
來源聲明：本文根據 Conductor Academy〈Schema Markup for AEO: What Actually Helps AI Understand Your Content〉編譯整理，不是逐句翻譯。原文連結：https://conductor.com/academy/schema-for-aeo。文中「編輯解讀」為本站觀點，不屬於原文。原文的 JSON-LD 範例在本次擷取裡沒有留下程式碼，正文只寫類型和欄位，不另造範例。
標記幫系統做的三件事
結構化資料是機器可讀的說明，schema 標記是其中用 Schema.org 詞彙的一種。類型指出主體，例如 Organization、Person、Product 或 Article。屬性補上名稱、作者、價格或發布日期。
對 AEO，這些標籤做三件事。第一，說明這一頁是文章、商品、服務、作者檔案，還是別種內容。第二，把重要細節標出來，系統在解釋或歸屬資訊時多一層上下文。第三，把品牌、作者、商品、服務和頁面串起來。大型網站同一份資訊出現在多處時，一致的標記比較有用。
沒有標記，系統仍可能讀懂並使用內容，只是比較容易誤解。頁面仍要能被抓到、有用、值得信任。Google 不要求專用的 AI schema。有效標記可以讓頁面有資格出現複合式搜尋結果，但不能保證出現。
先建立品牌、網站和單頁
沒有一種型別適合每一頁。要看頁面目的、頁面上的內容，以及它代表的人、商品、服務或其他資訊。多數網站的優先順序相同：先把組織、網站和單頁的關係寫清楚，後面的類型才有東西可以接。不是每一頁都要再加專門標記。
Organization
Organization 告訴系統網站背後是哪一家公司或組織，並把品牌做成一份穩定紀錄，和名稱相近的其他組織分開。加在首頁。Google 建議把組織資料放在首頁，或放在關於我們這類專頁，不必每一頁重複整段。先寫 name、url、logo、sameAs。sameAs 用來連到同一組織的官方社群或評價檔案。視情況再加 address、telephone、email、contactPoint、description、alternateName，只加適用且仍然正確的項目。常見錯誤是 logo 過期、聯絡方式錯誤，或 sameAs 指到不是同一組織的檔案。
WebSite
WebSite 說明系統正在看的是哪一個網站、由誰發布。加在首頁，並連回 Organization，讓網站和組織是同一組。欄位用 name、url、publisher。publisher 要引用 Organization 裡同一個 @id，不要在 WebSite 裡再造一個新的發布者。
WebPage
WebPage 描述這一頁，並用 isPartOf 接回 WebSite。用在單頁上。欄位包含 name、url、description、isPartOf，而且要和頁面本身一致。名稱、描述或網址對不上可見內容或標準網址，就是常見錯誤。
再按頁面內容加類型
基礎做好之後，才用頁面類型描述主要內容。只有和讀者看得到的內容相符時才加。
Article 與 BlogPosting
這兩種告訴系統頁面是編輯內容，並標出標題、作者、發布者和日期。部落格用 BlogPosting。其他編輯頁若沒有更細的子類型，用較寬的 Article。優先寫 headline、author、publisher、datePublished、dateModified。這樣比較容易看出誰寫的、哪一家發布、何時發布或更新。作者、發布者、標題或日期若和頁面不符，或 dateModified 並沒有對應一次真實更新，就是錯誤。
Person
Person 描述一個特定的人，例如職稱、雇主、個人頁和可核對的外部檔案。用在作者頁、員工檔案，以及其他以一個人為中心的頁面。也可以嵌在 Article 或 BlogPosting 裡，標出作者。和 Organization 一樣，它用來和同名的其他人分開，並把內容接到這個人的專業背景。公開且可核對時，優先寫 name、jobTitle、worksFor、url、sameAs。資歷、專長或檔案連結若在可見的簡介裡沒有依據，不要寫進標記。
Product、Review 與 AggregateRating
Product 說明頁面在談一件特定商品，並標出品牌、價格、庫存和 SKU。最適用於電商和以單一商品為中心的頁。它把商品事實和頁面其餘文字分開，方便購物或比較。優先寫 brand、sku、offers，價格和庫存放在 Offer 裡。Review 是單則評價，AggregateRating 是多則評價的彙總。商品頁上把它們嵌在 Product 裡，而且只寫讀者看得到的資訊。價格、庫存、評價或評分在頁面上看不到，就是錯誤。Google 的評價指引也說，不要把其他網站的評價或評分彙進來。
FAQPage
FAQPage 標出一組問題和發布者提供的答案。頁面上要有真正的常見問題，而且每一則被標記的問答讀者都看得到。用 mainEntity 包住這些問答，問題用 Question，回答用 acceptedAnswer。若同一題可以有多個使用者提交的答案，改用 QAPage。Google 已經不再在搜尋裡顯示 FAQ 複合式結果。沒有那個版位，FAQPage 仍可以讓機器看清真正的問答對應。把讀者看不到的問答寫進標記，機器收到的資訊和人不一樣；若目的是操弄搜尋可見度，這可以被視為偽裝。
HowTo
HowTo 描述一套有順序的步驟，適合教學、操作文和順序有意義的指南。優先寫 name 和 step。每個 HowToStep 對應讀者看得到的一步，順序相同。頁面只是一般建議、沒有清楚的步驟序列，不要用 HowTo。
BreadcrumbList
BreadcrumbList 標出這一頁在網站裡的位置，從較寬的分類走到當前頁。電商、知識庫和導覽層級多的企業站比較有用。用 itemListElement 依頁面上的順序建立路徑。每個 ListItem 要有 position、name 和項目網址。路徑和可見導覽不一致，或指向非標準網址，就是錯誤。
地點、服務和行業類型
基礎和頁面類型蓋不住每一個細節。某些行業需要更細的類型來標地點、服務或專業範圍。這些類型不是每個網站都要。
LocalBusiness
LocalBusiness 描述綁在實體地點上的商家或分店。用在顧客可以去的門市、辦公室、餐廳、旅館、診所或其他地點頁。它把這一家分店和另一家分開，也方便回答地址、營業時間和聯絡方式。選最細的子類型，例如 Dentist、Restaurant 或 Hotel。每個地點各自一份標記。優先寫 name、address、telephone、url、openingHoursSpecification。座標經過核對才加 geo。頁面不是真實地點，或每個分店複製同一組地址、電話和營業時間，都是錯誤。Google 建議各地點分開定義，並用最細的子類型。
Service
Service 描述企業提供的工作或專業，例如顧問、託管資訊服務、居家修繕或財務規劃。對商品不是實體的 B2B 和專業服務比較有用。它標出是哪一項服務、誰提供、在哪裡提供，讓系統把服務和相關問題接上，也和相近的服務分開。加在以一項服務為中心的頁面。有用的欄位包括 name、serviceType、provider、url、areaServed。一頁涵蓋幾項不同服務時，分開定義，不要收成一個含糊的標籤。用一個很寬的 Service 代表多項無關服務，或寫上頁面沒有清楚描述的細節，都是錯誤。
行業專用類型
有些行業有更細的類型。醫療機構可以用 MedicalWebPage、MedicalOrganization、MedicalCondition。金融機構可能用到 FinancialProduct、BankAccount 或 LoanOrCredit。律師事務所和學校可以用 LegalService、EducationalOrganization。細一點有助於分出一般健康文章和某一種病況的說明。欄位依行業和類型而定。加上之前先查 Schema.org 詞彙，每一項都要正確，而且頁面上看得到。原文以醫療頁為例：MedicalWebPage 把頁面標成醫療內容，about、lastReviewed、reviewedBy、medicalAudience 再補上下文。不要只因為公司屬於那個行業就選行業類型。類型和欄位仍要描述這一頁的內容。審閱者和審閱日期必須是真的，而且讀者看得到。
各引擎怎麼用這份標記
同一份標記每個抓取程式都可能讀到，不代表每個引擎公開談過它。公開說明用來分開已確認的和仍在假設的。
- Google AI Overviews 和 AI Mode：沿用搜尋的技術要求。頁面要先被索引，並有資格帶摘要，才可能成為回答裡的支持連結。用它支援的類型，細節對上可見頁面。沒有專用的 AI schema。
- Copilot 和 Bing：電商說明比較清楚。Product 用來理解名稱、價格、庫存、品牌和識別碼，並用在搜尋、購物和 AI 體驗。商品一變就要更新。
- ChatGPT：OpenAI 主要看 OAI-SearchBot 能不能到達頁面，沒有推薦特定類型。標記正確時，到達之後有更明確的資訊可以解釋。
- Perplexity：依網域發布的資訊類型，標成 Government、Academic、Trusted 或其他類別。這些標籤沒有和 schema 連起來。
- Gemini：可透過 Google Search 找目前網頁，並把說法連到來源。沒有另寫一套 schema 建議。
- Claude：Anthropic 說明它會搜多個即時來源並直接引用，沒有談到 schema。能被抓到、頁面清楚是前提。
跨引擎一致的是：內容能被抓到，標記正確，而且和讀者看到的一樣。這不保證被引用。
用 JSON-LD，先測再放大
策略上線仍可能壞掉：語法錯誤、外掛把同一段加兩次，或頁面改了舊欄位還留著。
Schema.org 可用 JSON-LD、Microdata 或 RDFa。沒有必須用別種格式時，JSON-LD 通常最好維護，Google 在多數情況也建議它。它放在 script 裡，可放 head 或 body，不織進可見 HTML。標記盡量由和可見頁面同一組欄位產生。Article 的作者名要和署名同一來源。外掛、代碼管理或客戶端指令碼注入時，要看最終渲染頁：出現在正確網址、載入成功、沒有被另一個工具重複。
撰寫時先測，發布後再測線上網址。Schema.org Validator 查語法和抽出的資料。複合式搜尋結果測試只涵蓋 Google 支援的類型。Search Console 網址檢查確認能不能讀到頁面和標記；索引後再看複合式結果和無法剖析的報表，報表沒有列出每一筆。錯誤可能讓標記無效或失去某項功能的資格，警告多半是建議欄位沒填。通過測試只代表過了那一次技術檢查。
全站展開前先測一小群頁，含一位作者與多位作者、有庫存與沒庫存。確認類型正確、必填有值、無值欄位會消失、沒有重複、網址和 @id 指到對的實體、可見頁和標記一致。失敗就停，追到共用範本、外掛或資料來源，修好再測，然後才擴大。
選最能準確描述的類型，補上該搜尋功能要求的欄位，日期、網址、價格、庫存用預期格式。不要給抓取程式讀者看不到的細節。同一組織、網站或人物跨頁時 @id 要一致。文章接作者，商品接 Offer。記下標記來源、欄位和負責人。
價格、作者、地點、服務或標準網址一改，標記可能跟著錯。範本改版和系統更新也會一次影響很多頁。穩定的網站每季稽核；商品、庫存、地點或發布資訊常變的站要更勤。同一錯誤出現在多頁，原因多半在共用範本或欄位。
Conductor Monitoring 在做什麼
上到幾百或幾千頁後，人工檢查只是一個時間點。Conductor Monitoring 是他們自己的產品，用來盯缺類型、缺屬性和無效值。下面是產品說明，不是獨立實驗。
先為商品與分類頁、服務頁、文章和作者檔、地點頁、高流量或營收頁做區段，分辨是單頁壞了還是範本壞了。同一 Product 錯誤出現在很多網址，先查共用範本。商品頁歸電商，作者檔歸內容或網站團隊。
再看 Organization、WebSite、WebPage。產品會標缺類型、無效 @type、缺必要或建議屬性。先確認類型在預期位置，修正 @type，補必要屬性，再看建議屬性，最後對可見內容。文中要使用者用該產品的技術健康分數，先處理高價值頁。
錯誤突然變多，就把錯誤率放在發布、搬遷、系統更新和範本變更前後比較。按區段找出類型和屬性，看是否共用範本或外掛，修完確認錯誤率回到先前水準。價格、庫存、作者、地點、標準網址或範本改過之後要特別看。
長期看兩個數：有問題的受監測頁面百分比，以及優先頁裡三種基礎類型都在的百分比。用 Conductor Intelligence 看大型修復前後的提及、引用和可見度，只能標出時間重疊，不能證明是 schema 造成變化。
策略上能控制的是清楚程度
不是每一頁都要專門類型。很多頁可以用 WebPage，但不都需要 Product、Article 或 FAQPage。無關標記不會給系統更好的資訊，只會留下不清楚的訊號和更多要維護的程式。內容品質、相關性、權威、可抓取性，以及各平台怎麼檢索，都會影響誰被引用。你控制不了引擎選哪一頁。你能控制的是最重要的頁面把業務所知、所提供、所代表的東西說得多清楚。
常見問題
- 結構化資料和 schema 標記是同一件事嗎？不是。結構化資料是機器可讀說明的上位詞。schema 標記是其中用 Schema.org 詞彙標出人、組織、商品和服務的一種。
- 哪一種 schema 對 AI 可見度最重要？沒有單一最重要的類型。最有用的是最準確描述這一頁的那一個。多數網站先做 Organization、WebSite、WebPage。
- 要出現在 ChatGPT 或 AI Overviews，必須加 schema 嗎？不用。OpenAI 沒有把 schema 列為 ChatGPT 搜尋的必要條件。Google 也說 AI Overviews 和 AI Mode 不需要專用 schema。
- 多久稽核一次？相對穩定的網站以每季為起點。商品、庫存、地點或發布資訊經常變的站要更勤。範本、搬遷、系統更新，以及作者、價格、地點或庫存變更之後都要重驗。
- 正確的 schema 會保證被引用嗎？不會。它讓內容和關係比較容易被理解，不能決定引擎選哪一頁當來源。
編輯解讀
一句話重點：先讓 Organization、WebSite、WebPage 和可見頁面是同一套事實，再加更細的類型。
這對你的網站意味著什麼：
- 首頁放 Organization 和 WebSite，publisher 用同一個 @id，不要每頁複製整段組織資料。
- 商品價格、庫存、作者和日期改從頁面欄位產出，不要另維護一份 JSON-LD。
- FAQ 只標記頁面上看得到的問答。Google 已不顯示 FAQ 複合式結果，這不是加 FAQPage 的理由。
- 全站套用前先測一位作者與多位作者、有庫存與無庫存這類變體。
- 每季看一輪；價格、作者、標準網址或範本一改就重驗。
適用與不適用的情境：適合要決定先做哪些 Schema.org 類型的內容站和電商。不適合把 Conductor 的錯誤率和 AI 引用變化讀成因果。
需要注意的限制：這是 Conductor 的產品教學編譯，他們賣監測。文中沒有引用提升的對照實驗。JSON-LD 範例在本次擷取中沒有程式碼，正文沒有補造。Perplexity 的網域標籤，原文寫明和 schema 沒有對應關係。
延伸閱讀：
可沉澱規則 · 供站點自檢2 條
從本文提煉，可供人工對照或 AI 分析站點時作為依據。全部規則
AEO 用的 schema 先做 Organization、WebSite、WebPage 三角：首頁放組織與網站，publisher 用同一 @id；各頁 WebPage 的 name、url、description 須與可見內容及標準網址一致，再談更細類型。
- publisher 是否引用同一 Organization @id
- WebPage isPartOf 是否指向 WebSite
Article、Product、FAQPage、Review 等只標記讀者看得到的欄位；價格、庫存、評分、FAQ 問答在頁面不存在就不要寫進 JSON-LD。全站展開前先測單作者／多作者與有無庫存等模板變體。
- Rich Results Test 與渲染後 JSON-LD
- 欄位是否與 CMS 可見欄位同源
名詞與資料來源
- AEO 用的 schema 類型與各引擎差異 — Conductor Academy：〈Schema Markup for AEO〉 https://conductor.com/academy/schema-for-aeo（檢索日期：2026-10-12）
- Schema.org 詞彙 — Schema.org：〈Organization of Schemas〉 https://schema.org/docs/schemas.html（檢索日期：2026-10-12）
- Organization 類型 — Schema.org：〈Organization〉 https://schema.org/Organization（檢索日期：2026-10-12）
- Schema.org Validator — Schema.org：〈Schema Markup Validator〉 https://validator.schema.org/（檢索日期：2026-10-12）
- 複合式搜尋結果測試 — Google：〈Rich Results Test〉 https://search.google.com/test/rich-results（檢索日期：2026-10-12）
One Comment