部落格文章該加 Article Schema 嗎？AI 搜尋時代的內容護身符

TL;DR

• Article Schema 是部落格、新聞、品牌專欄文章的標準結構化資料——標記作者、發布時間、章節分類、出版單位等元資料，讓搜尋引擎與 AI 能正確識別文章身分。
• 它直接影響「被 AI 引用時是否標註來源」。一篇沒有 Article Schema 的文章被 ChatGPT 引用後，可能完全留不下出處；有 Schema 的文章，AI 引用時更可能附上連結。
• dateModified 是被低估的欄位——它影響搜尋引擎對「內容新鮮度」的判斷，與 datePublished 同樣重要，但很多網站只設定後者就忽略了。
• Article 是父類型，BlogPosting / NewsArticle / TechArticle 是子類型——選最精確的子類型，比泛泛用 Article 更好。

一、Article Schema 是什麼？跟 BlogPosting、NewsArticle 是什麼關係？

核心觀點： Article Schema 是 Schema.org 中用來標記「文章類內容」的類型，下面細分出 BlogPosting、NewsArticle、TechArticle 等子類型。父類型 Article 適用所有文章內容，子類型則對應特定的內容性質——選用最精確的子類型，搜尋引擎與 AI 的判斷會更準確。

Article 在 Schema.org 階層中位於 CreativeWork 之下，作為所有「以文字為主、有作者、有發布時間」的內容的通用標記。它的下面細分出三個常見子類型：

• BlogPosting：個人或品牌部落格文章，最常用的類型。如果是品牌經營的內容行銷文章、產業觀察、教學文，多半適用這個類型。
• NewsArticle：新聞稿、媒體報導、時事評論。要進 Google News 索引、要顯示在 Google Discover 的「頭條新聞」區，必須用這個類型。
• TechArticle：技術文件、API reference、開發者教學。Google 對這個類型的解析會偏向「使用手冊」邏輯，與一般部落格文章不同。

選類型時的原則是「盡量選最精確的子類型」。一篇咖啡廳的開店心得寫在品牌部落格上，用 BlogPosting 比用通用的 Article 更好——前者繼承了部落格特有的欄位（如評論支援、社群分享 metadata），搜尋引擎能做更細緻的判斷。

如果你還不熟 Schema.org 整體生態，可以先讀 Schema.org 是什麼？商家網站最該做的 5 種結構化資料——Article 是其中 5 種優先實作類型之一。

二、為什麼 AI 搜尋時代 Article Schema 反而比 SEO 時代更重要？

核心觀點： 在傳統 SEO 時代，Article Schema 影響的是「能不能進 Google Discover、能不能在搜尋結果頁顯示作者頭像」這類視覺增強。到了 AI 搜尋時代，它的角色升級為「AI 引用內容時的身分證」——直接決定品牌在生成式 AI 答案中的能見度。

純 SEO 時代的 Article Schema 主要影響三件事：Google Discover 的曝光、Google News 的索引、搜尋結果頁的 metadata 顯示（作者、發布時間）。這些都是「視覺增強」級別的影響，不會直接動到排名，但能提升點擊率。

進入 AI 搜尋時代，這個角色被大幅放大。ChatGPT、Perplexity、Gemini 在引用網頁內容時，會用 Article Schema 中的 author、datePublished、publisher 判斷三件事：

第一，這篇文章是誰寫的、屬於哪個媒體。如果 Schema 中清楚標註 author 與 publisher，AI 引用時較可能標註「根據 XX 媒體的報導」、「OO 撰寫的文章指出」這類有來源的句式。沒有 Schema 的文章 AI 也會引用，但可能完全不標來源，等於免費供給內容卻拿不到品牌曝光。

第二，這篇文章何時發布、是否還新鮮。AI 在面對「最新動態」類查詢時會優先引用近期內容；標好 datePublished 與 dateModified 的文章在新鮮度判斷上佔優勢。

第三，這篇文章的章節分類與專業領域。articleSection 欄位告訴 AI 這篇文章屬於哪個主題類別（「SEO 教學」「行業案例」「產品評測」），AI 在做主題式檢索時會優先考慮 articleSection 對應的內容。

這三項加總，就是「為什麼 Article Schema 在生成式 AI 時代的重要性反而上升」的答案。

三、Article Schema 的必填與建議欄位有哪些？

核心觀點： Article Schema 的必填欄位是 headline、author、datePublished、image 四項，建議補上 dateModified、publisher、articleSection、mainEntityOfPage。整份結構大約 15–25 行 JSON-LD，多數內容管理系統可以從文章 metadata 自動產生。

一份完整的 Article Schema JSON-LD 結構大約是這樣：

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "文章標題（不超過 110 字元）",
  "image": ["https://example.com/cover.jpg"],
  "datePublished": "2026-05-14T10:00:00+08:00",
  "dateModified": "2026-05-14T15:30:00+08:00",
  "author": {
    "@type": "Person",
    "name": "作者姓名",
    "url": "https://example.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "品牌或媒體名稱",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "articleSection": "SEO 教學",
  "mainEntityOfPage": "https://example.com/blog/article-slug"
}

逐項說明關鍵點：

headline 是文章標題，Google 建議不超過 110 字元，否則可能被截斷。image 是封面圖，建議放高解析（至少 1200×675）、長寬比接近 16:9 的圖檔，這是 Google Discover 與社群分享的視覺主軸。datePublished 與 dateModified 必須是 ISO 8601 格式並帶時區。

author 與 publisher 是兩種不同的角色：author 是「個人創作者」，publisher 是「出版方」。即使是個人部落格，也建議同時放兩者——author 寫作者本人、publisher 寫部落格品牌名稱。

articleSection 是文章分類，對應網站的部落格分類體系（例如「SEO 教學」「行業案例」「產品評測」）。mainEntityOfPage 是文章的 canonical URL，這個欄位告訴搜尋引擎「這個 Schema 物件代表的就是這個 URL 的主要內容」。

實作上可以用 AHHA Article Schema 產生器 直接生成，同時支援 Article、BlogPosting、NewsArticle 三種類型。

四、dateModified 為什麼比 datePublished 重要？

核心觀點： datePublished 只代表「文章何時發布」，dateModified 代表「文章何時最後一次更新」。在搜尋引擎與 AI 的內容新鮮度判斷中，dateModified 的權重往往更高——一篇 2024 年發布、2026 年更新過的文章，在搜尋結果中的競爭力可能勝過 2026 年新發布但內容單薄的同主題文章。

很多網站把 datePublished 設好就以為大功告成，但 dateModified 才是真正影響「內容新鮮度訊號」的欄位。Google 在搜尋演算法中明確使用 dateModified 判斷文章的「相對新鮮度」，AI 引擎在做「最新動態」類查詢時也會優先看 dateModified。

實務上 dateModified 的維護有幾個要點：

第一，dateModified 必須真實對應內容更新時間。 不能為了「假裝文章很新」而每天偷偷更新 dateModified——Google 會比對頁面 HTML 是否真的有變動，純改 metadata 而內容沒改的「假更新」會被識別為操弄訊號。

第二，重大內容更新後一定要更新 dateModified。 部落格文章的觀點修正、新資料補充、章節重組，都應該觸發 dateModified 重新寫入。多數內容管理系統會在每次儲存時自動更新這個欄位，但有些靜態網站需要手動處理。

第三，dateModified 早於 datePublished 是非法的。 這聽起來理所當然，但因為時區處理不當常出錯——datePublished 用 UTC 寫、dateModified 用本地時間寫，兩者一比較就可能出現「修改時間早於發布時間」的邏輯錯誤。建議統一用同一時區（含時區標記的 ISO 8601 格式）。

對於想精準掌握網站每篇文章的 Schema 狀態的使用者，AHHA SEO + GEO + AI 爬蟲三合一檢測 能掃描網站所有文章的 Article Schema 完整度，回報哪些文章缺漏 dateModified、哪些文章的時間格式有問題。

五、Article Schema 怎麼驗證？常見實作錯誤有哪些？

核心觀點： 驗證 Article Schema 用 Google Rich Result Test + Schema.org Validator 兩個官方工具搭配。常見實作錯誤集中在「時間格式錯誤」「image 欄位用了縮圖」「author/publisher 結構不完整」三類，這些都會讓 Schema 被部分搜尋引擎忽略。

驗證流程兩步：用 Google Rich Result Test 確認 Schema 能被 Google 解析、用 Schema.org Validator 檢查整份語法合規。

實作上的常見錯誤集中在三類：

第一類：時間格式錯誤。 ISO 8601 要求格式 YYYY-MM-DDTHH:MM:SS+TZ，常見錯誤包含：用 2026/05/14 這種非 ISO 格式、漏寫時區（2026-05-14T10:00:00 沒有 +08:00 結尾）、用本地中文格式（「2026年5月14日」）。這些都會被 Schema 解析器拒絕。

第二類：image 欄位用了縮圖。 Google Discover 要求 Article 的 image 解析度至少 1200 像素寬、長寬比接近 16:9。如果直接放縮圖（300×200 那種），Schema 雖然有效但無法觸發 Discover 曝光。建議放原圖 URL，不要放縮圖路徑。

第三類：author 或 publisher 結構不完整。 author 不能只是字串，必須是 {"@type": "Person", "name": "..."} 物件結構；publisher 同樣必須是 {"@type": "Organization", ...} 並含 logo。多數產生器會自動處理，但如果是從舊系統手寫的 Schema，常常會看到 "author": "John Doe" 這種字串寫法——這在 Schema.org 規範上是過時的，新版搜尋引擎已不接受。

對於想完整盤點網站所有文章 Schema 狀態的使用者，AI 爬蟲檢測工具能一次掃描整站、產出 Schema 完整度報告。

六、結語：Article Schema 是長期內容投資的最小成本配備

對任何想以部落格、專欄、媒體內容做長期 SEO / GEO 經營的網站來說，Article Schema 是「成本最低、回報最持久」的標記類型之一。每篇文章上線時花 2–3 分鐘確認 Schema 完整、dateModified 隨內容更新同步寫入，長期累積下來就是品牌在 AI 搜尋時代的能見度資產。

寫作端搭配 Markdown 流程能進一步降低長期維護成本——Article Schema 從 metadata 自動產生、內容用純文字保存可跨平台遷移、與 AI 工具協作零摩擦。Markdown 的核心語法與適用場景可參考 Markdown 是什麼？內容創作者該掌握的純文字寫作格式。

完整的 SEO + GEO 策略可參考 SEO 與 GEO 完整指南；Schema.org 整體實作可參考 商家網站最該做的 5 種結構化資料。

實作 Article Schema 可以用 AHHA Article Schema 產生器 快速產出；如果想直接使用一個內建 Article Schema 從部落格 metadata 自動生成、dateModified 隨編輯自動更新的網站平台，可以 立即試用 AHHA 30 天 →。