Article schema 對 AI Search 有什麼用？欄位、限制與驗收

Article schema 的用法，是替文章補上標題、圖片、日期和作者這幾個機器讀得懂的線索，讓 Google 更容易理解頁面在講什麼。這適用於已經把正文、來源、作者和日期寫清楚的頁面；正文沒有的資訊，別靠 JSON-LD 補進去——那會讓 schema 和可見內容互相矛盾。本文提供的是可以照著做的東西：Google 官方支持哪五件事、七個常見欄位各自的證據要求、JSON-LD 範例與逐欄對照、部署前後的六步驗收，以及 schema 和 AI Search 之間的界線。

先把定位講清楚：Article schema 像書本封底的那一段資訊——書名、作者、出版日期、簡介。它幫圖書館員把書歸到對的架上，但書架位置決定不了有沒有人借。它不是 AI Search 的排名開關，AI citation、AI Overviews 或一般排名都不在它的能力範圍。

schema 驗證不保證 AI citation 或排名。

先回答 Article schema 的角色

Article schema 提供的是機器可解析的頁面描述。它和文章正文是兩個表達層：正文服務讀者，結構化資料提供額外線索。兩者衝突的時候，以正文為準——JSON-LD 裡寫一個頁面上看不到的作者或日期，那個資訊不會因為被標記過就變成事實。

Google 的 Article structured data 文件 說明，Article markup 可以協助 Google 理解文章的標題、圖片和日期，並可能支援更豐富的搜尋結果。Google 的 structured data 介紹 與一般結構化資料指南提醒，結構化資料提供線索或讓特定 rich result 有資格，不構成排名或顯示保證。

對 AI Search 的關係可以濃縮成三句：schema 可能幫助頁面理解；schema 不是引用命令；AI 產品會不會選用，要按產品和查詢觀測。Google AI features 文件也說沒有額外的 AI 專用 schema——這反而讓 Article schema 的責任更清楚：它服務頁面理解和搜尋資格，不承擔「AI 曝光開關」這個角色。

Google 官方支援什麼

依 Google 文件，實作 Article structured data 時至少要注意：

Google AI features 文件要求結構化資料與頁面可見內容一致，也說沒有額外技術要求。要處理 Article schema 和 AI citation 的關係時，canonical、內部連結、可抓取文字、索引和實際引用 URL 都要一起查——JSON-LD 驗證通過，證明的是那段 JSON 語法正確。

Article schema 常見欄位

常見欄位可按「頁面本身能證明什麼」來整理：

1. @type：可使用 Article、NewsArticle 或 BlogPosting 等適用類型，選擇要符合文章性質。
2. headline：對應頁面可見標題，不要放超出頁面主題的行銷承諾。
3. image：使用文章相關且 crawler 可取得的圖片 URL，並確認尺寸和格式符合實際部署。
4. datePublished：文章首次公開日期，需有內容紀錄或頁面呈現支持。
5. dateModified：最近一次實質更新日期，不要每次抓取就任意刷新。
6. author：對應可識別的作者或作者頁，名稱與頁面呈現一致。
7. mainEntityOfPage：這是 schema.org 的可選欄位示意，可指向該文章正式 URL；是否採用仍要與 canonical、內部連結和頁面實際資料一致，不把它寫成 Google Article 必填欄位。

不是每一頁都要把欄位填滿。缺少可靠證據的欄位就留空，先確保填了的那幾欄是對的——一個猜出來的 dateModified，比空著更麻煩。欄位數量和顯示方式之間沒有換算關係；品質來自可回溯和一致。

JSON-LD 示意與可見內容對照

以下是概念示意，部署時要替換成頁面真實、可存取且已核對的值：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "文章頁面上的可見標題",
  "image": ["https://example.com/images/article.webp"],
  "datePublished": "2026-09-21",
  "dateModified": "2026-09-21",
  "author": {
    "@type": "Person",
    "name": "頁面上顯示的作者"
  },
  "mainEntityOfPage": "https://example.com/blog/article"
}
</script>

發布前逐欄對照一次：headline 等不等於可見 H1 或文章主標題、image 直接請求得到嗎、日期有沒有內容紀錄支持、作者在頁面上看不看得到、mainEntityOfPage 是不是正式 canonical。圖片還沒生出來、正式 URL 還沒確認的話，示意值就留在示意的位置——把它當已部署結果，上線那天會有一個 404 的圖片 URL 躺在 JSON-LD 裡。

部署前後的 6 步驗收

1. 內容對照：讀正文、H1、作者區塊、日期和圖片，建立 schema 欄位清單。
2. 程式檢查：確認 JSON-LD 是有效 JSON，沒有重複屬性、截斷字串或環境 placeholder。
3. 可存取檢查：用不需登入的請求確認頁面、圖片和作者頁的 HTTP response。
4. Google 驗證：使用 Google 支援的 rich result 或結構化資料工具檢查適用錯誤與警告。
5. 正式 URL 檢查：部署後確認 canonical、sitemap 和內部連結指向同一版本，再按授權使用 URL Inspection。
6. AI 觀測分開：用固定查詢、日期、產品記錄是否出現來源。沒有答案證據時保留未觀測，不從 schema 驗證推導引用。

頁面圖片由後續工作補上時，先在圖片紀錄寫用途、alt 和狀態，等檔案真的存在再更新頁面資料。schema 裡放一個還沒生成或還沒驗收的圖片 URL，是內容與工程之間最常見的一種漏接——這是交接界線，不是 Google 的額外排名規則。

Article schema 與 AI Search 的限制

Article schema 改善的是機器對頁面實體的理解線索。可見文字、作者責任、來源引用、canonical 和內部連結這五件事，它一件都替代不了。Google AI features 仍以既有 Search 基礎處理，頁面要可抓取、可索引、具備摘要資格；顯示和引用依產品狀態決定。

其他 AI 產品是否讀取 schema、讀取哪些欄位，以及是否在答案中提供 citation，不能從 Google 文件直接推廣。若要跨平台整理，先按各產品官方文件和固定 query 觀測；沒有證據時寫未知或無資料。提及率也要定義樣本、分母、日期和有效回答，不能把少量答案稱為所有平台的 SOV。

若要把 schema 放回整體 AI 搜尋治理，可先看 EthorX GEO 服務；產品觀測入口可參考 Otlex。這些頁面不是本文的 Google rich result 或 AI citation 正式確認資料。

常見問題

查證邊界

本文依 Google Article、結構化資料與 AI features 文件整理欄位與驗收界線；文中的書本封底比喻與 example.com 值都是說明用的示例。Article schema 的欄位說明不是 AI citation 或排名保證。沒有指定 URL 的正式 HTML、JSON-LD、圖片存取、Search 工具結果或產品答案樣本時，本文只能提供檢查方法，不能推出頁面已符合資格或已被引用。

參考來源

• Google Article structured data
• Google structured data 介紹
• Google AI features
• Google canonical 文件
• Schema.org：mainEntityOfPage