Article Schema 怎麼做？文章結構化資料欄位與驗證流程

Article Schema 是什麼？它在文章頁扮演什麼角色？

Article Schema 是用來描述文章本體的結構化資料，重點是讓搜尋引擎讀懂文章標題、作者、發布時間、更新時間、代表圖片、出版者與頁面關係。它適合放在真正的文章頁，不適合硬套在首頁、分類頁或純商業頁。

在實作上，Article Schema 不應該只是外掛自動吐出的程式碼，而是文章頁 metadata 的機器可讀版本。我的判斷是：只要網站有長期經營內容，Article Schema 就應該被當成文章模板的一部分，而不是單篇文章上線後才補的裝飾。

Article Schema 可以幫 Google 理解哪些文章資訊？

Article Schema 可以把文章的核心資訊整理成搜尋引擎容易解析的格式，常見欄位包含 headline、image、datePublished、dateModified、author、publisher 與 mainEntityOfPage。讀者下一步要做的是先盤點文章頁目前是否有這些資訊，缺少作者頁、代表圖片或更新日期時，先補頁面內容，再補 Schema。

• 文章主題：用 headline 表示文章標題。
• 作者來源：用 author 指向 Person 或 Organization。
• 發布與更新時間：用 datePublished、dateModified 提供日期訊號。
• 文章圖片：用 image 指向可抓取、與文章相關的圖片。
• 出版者：用 publisher 說明文章由哪個品牌或組織發布。
• 頁面關係：用 mainEntityOfPage 連回文章所在網址。

Article Schema 不等於排名保證

Article Schema 的價值是幫搜尋引擎理解內容，不是保證排名或保證出現 Rich Result。Google 的結構化資料規範也明確提醒，即使標記通過測試，也不代表一定會在搜尋結果中以特殊樣式呈現。下一步要做的是把它當成「降低機器理解成本」的基礎建設，而不是排名捷徑。

Article Schema 對 AI 搜尋與語音助理的意義

AI 搜尋與語音助理在理解網頁時，會更重視實體、作者、日期與內容可信度。Article Schema 無法保證內容被引用，但能讓文章的作者、出版者與更新時間更清楚。對 2026 年的內容網站來說，我會把它視為 entity clarity 的基本配備，尤其是有作者專業度、專題內容與定期更新的站台。

Article、BlogPosting、NewsArticle、WebPage 該怎麼選？

一般部落格文章多數情況可用 BlogPosting，新聞內容可用 NewsArticle，較泛用的文章可用 Article；WebPage 則是描述頁面容器，可以和 Article 類型同時存在，但兩者要描述不同層次。

一般部落格文章建議用 BlogPosting 還是 Article？

如果文章發佈在部落格、知識庫、內容專欄，多數情況建議用 BlogPosting。它比 Article 更具體，也符合 Google 建議使用最貼近頁面主體的類型。若網站是企業知識中心，且文章不以部落格形式呈現，用 Article 也可以。

新聞稿與即時新聞何時用 NewsArticle？

NewsArticle 適合新聞媒體、採訪報導、即時消息、新聞稿與具時效性的報導內容。若文章只是品牌教學、SEO 知識、工具比較或 evergreen guide，通常不需要用 NewsArticle。我的實務判斷是：只要內容不是以新聞標準製作，就不要為了看起來更正式而套 NewsArticle。

Article Schema 與 WebPage Schema 可以同時存在嗎？

可以。WebPage 描述的是網頁容器，Article、BlogPosting 或 NewsArticle 描述的是文章本體。實作時可用 mainEntityOfPage 把文章連回該頁網址，例如 https://9iseo.com.tw/articles/article-schema。下一步要檢查的是：兩組 Schema 的 URL、canonical 與文章標題不能互相打架。

Article Schema 欄位優先級：哪些必填、哪些建議、哪些不要亂用？

Article Schema 欄位應先補齊文章可識別性，再補強可信度與維護資訊。實作順序建議從 headline、datePublished、author 開始，再加入 image、dateModified、publisher 與 mainEntityOfPage。

必要欄位：文章最少要讓機器讀懂什麼？

最少要讓機器知道三件事：這篇文章叫什麼、何時發布、誰寫的。headline 建議貼近 H1 或文章主標題；datePublished 要是首次發布時間；author 不要只寫一個沒有背景的名字，最好能連到作者頁。

建議欄位：提升可信度與搜尋呈現的資訊

image、publisher、dateModified、mainEntityOfPage 通常值得加入。Google 對 Article 圖片建議使用可抓取、可索引、與文章內容相關的圖片，並可提供 16:9、4:3、1:1 等比例。下一步是請工程確認圖片 URL 不被 robots.txt、權限或防盜連阻擋。

情境欄位：keywords、articleSection、wordCount 何時有用？

keywords 適合填少量真實主題詞，例如 Article Schema、文章結構化資料；articleSection 可填文章分類，例如「技術 SEO」；wordCount 則適合內容團隊有自動統計時使用。不要把這些欄位當成排名加速器，它們的主要用途是清楚描述文章。

作者與出版者欄位怎麼寫才有可信度？

作者欄位建議用 Person，並加上 url 指向作者頁；出版者欄位建議用 Organization，並維持品牌名稱、首頁 URL 與 logo 一致。以 9iseo.com.tw 為例，作者可寫 Kevin Lin，出版者可寫 9iSEO。我的建議是把作者與出版者資料集中管理，避免不同文章輸出不同拼法。

Article Schema JSON-LD 範例：部落格文章可以直接參考的寫法

Article Schema 建議用 JSON-LD 實作，放在文章頁 HTML 中的 <script type="application/ld+json">。範例中的網址、標題、日期、作者、圖片與出版者，都要替換成該文章的真實資料。

基本版 JSON-LD 範例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Article Schema 實作教學：文章結構化資料怎麼寫才正確？",
  "description": "給台灣站長與 SEO 實作負責人的 Article Schema JSON-LD 欄位、驗證與維護流程。",
  "image": "https://9iseo.com.tw/assets/articles/article-schema-cover.jpg",
  "datePublished": "2026-03-10T09:00:00+08:00",
  "dateModified": "2026-05-16T10:30:00+08:00",
  "author": {
    "@type": "Person",
    "name": "Kevin Lin",
    "url": "https://9iseo.com.tw/authors/kevin-lin"
  }
}
</script>

基本版適合先確認文章頁可以被 Google 讀到。下一步是把 headline 對齊頁面標題，把日期改成真實發布與更新時間，再用 Rich Results Test 測試。

加上作者頁、publisher logo、mainEntityOfPage 的完整版本

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://9iseo.com.tw/articles/article-schema#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://9iseo.com.tw/articles/article-schema"
  },
  "headline": "Article Schema 實作教學：文章結構化資料怎麼寫才正確？",
  "description": "給台灣站長、SEO 與工程維護者使用的 Article Schema 實作藍圖。",
  "image": [
    "https://9iseo.com.tw/assets/articles/article-schema-1x1.jpg",
    "https://9iseo.com.tw/assets/articles/article-schema-4x3.jpg",
    "https://9iseo.com.tw/assets/articles/article-schema-16x9.jpg"
  ],
  "datePublished": "2026-03-10T09:00:00+08:00",
  "dateModified": "2026-05-16T10:30:00+08:00",
  "author": {
    "@type": "Person",
    "name": "Kevin Lin",
    "url": "https://9iseo.com.tw/authors/kevin-lin"
  },
  "publisher": {
    "@type": "Organization",
    "name": "9iSEO",
    "url": "https://9iseo.com.tw",
    "logo": {
      "@type": "ImageObject",
      "url": "https://9iseo.com.tw/assets/brand/9iseo-logo.png"
    }
  }
}
</script>

日期格式、URL、圖片路徑要注意什麼？

如何實作 Article Schema：手動、外掛、CMS 與框架做法比較

Article Schema 的實作方式要看網站系統而定。WordPress 可從 SEO 外掛開始，自架站與 Headless CMS 應在模板層輸出 JSON-LD，少量頁面可用產生器輔助，但任何方式上線前都要驗證。

WordPress 網站：SEO 外掛與主題內建怎麼選？

WordPress 先檢查 SEO 外掛是否已輸出 Article 或 BlogPosting，再看主題是否也輸出一份。重複輸出不一定必然錯，但最怕兩份資料的作者、日期、圖片不同。下一步是用頁面原始碼搜尋 application/ld+json，確認只有一套主資料負責文章本體。

Headless CMS 或自架站：模板層輸出 JSON-LD

Headless CMS 最穩定的做法是在文章模板層輸出 JSON-LD，欄位從 CMS 讀取，不要讓編輯手貼整段 JSON。建議欄位包含 title、slug、excerpt、cover image、publishedAt、updatedAt、author、category。這樣改標題、換圖、更新日期時，Schema 才會同步。

Article Schema 產生器怎麼用：欄位填寫到上線檢查

Schema generator 可用來建立初稿，但不能取代人工檢查。操作順序是：填文章網址、標題、作者、日期與圖片，產出 JSON-LD，貼到測試頁，跑 Rich Results Test，再檢查頁面可見內容是否一致。產生器最常見的問題是日期格式與作者型別太簡略。

Nuxt / Unhead 類框架的實作概念

Nuxt、Unhead 或類似 head 管理工具可把 Article Schema 放進頁面 head 管理流程中。重點不是使用哪個函式，而是確保最終 HTML 或可被 Google 渲染後的頁面含有正確 JSON-LD。下一步是用實際上線網址測試，不只測本機開發環境。

上線前怎麼驗證 Article Schema？

Article Schema 上線前要先用 Rich Results Test 檢查 Google 是否能讀取，再用 Schema Markup Validator 檢查 schema.org 結構，發布後用 Search Console 觀察抓取與結構化資料問題。

使用 Rich Results Test 檢查 Google 是否能讀取

Rich Results Test 適合檢查 Google 是否能解析頁面中的結構化資料。測試時優先貼正式網址，其次才是程式碼片段。下一步要看三件事：是否偵測到 Article 類型、是否有錯誤或警告、Google 是否能取得頁面與圖片。

使用 Schema Markup Validator 檢查語法與 schema.org 結構

Schema Markup Validator 適合檢查 JSON-LD 語法、類型與屬性是否符合 schema.org 結構。它不等於 Google 搜尋呈現保證，但很適合抓括號錯誤、型別錯誤、URL 格式錯誤。工程交付前，這個工具應該和 Rich Results Test 一起跑。

上線後用 Search Console 觀察哪些問題？

上線後要看 Search Console 是否能抓取頁面、是否出現結構化資料相關錯誤、索引 URL 是否與 canonical 一致。若文章更新後搜尋結果日期沒有變，先不要急著改 Schema，應先確認頁面可見日期、dateModified、sitemap lastmod 與實際內容更新是否一致。

Article Schema 常見錯誤案例：哪些寫法會讓標記失效或降低可信度？

Article Schema 最常見的失誤不是語法壞掉，而是 Schema 與頁面內容不一致。作者、標題、圖片、日期、publisher logo、canonical 只要有一項對不上，搜尋引擎就可能降低信任或忽略標記。

author 只寫純文字，沒有 Person 或作者頁

只寫作者名字能被解析，但不足以建立清楚的作者實體。建議改成 Person，並用 url 指向作者頁。若網站有作者專業背景、社群或作品集，作者頁的價值會比單一 Schema 欄位更大。

headline、圖片、日期與頁面內容不一致

Schema 裡的 headline、image、datePublished、dateModified 必須反映頁面可見內容。若頁面顯示 2026 年 5 月更新，Schema 卻停在 2025 年，這不是小瑕疵，而是維護流程斷掉的訊號。

image URL 無法被 Google 抓取

圖片 URL 要能公開存取，且圖片要代表文章內容。不要用後台暫存圖、登入後才看得到的圖、被 CDN 規則擋住的圖。下一步請用正式網址測試圖片，不要只在 CMS 後台預覽。

dateModified 沒有跟文章更新同步

dateModified 只應在文章有實質更新時調整，例如補充段落、修正資訊、更新範例或替換關鍵圖片。若只是修錯字，不一定要改。這個欄位最怕被自動更新成每次建置時間，因為它會把維護訊號變得不可信。

Article Schema 的維護 SOP：文章更新後要同步哪些資訊？

Article Schema 不是上線一次就結束。文章每次改標題、換圖片、調整作者、更新內容或更改 canonical，都要同步檢查 Schema，確保頁面可見內容、結構化資料與索引訊號一致。

1. 確認文章是否有實質更新。
2. 更新頁面標題、H1、摘要與代表圖片。
3. 同步 dateModified，保留原始 datePublished。
4. 檢查作者、作者頁、publisher 與 logo 是否仍正確。
5. 確認 canonical、mainEntityOfPage 與文章網址一致。
6. 重新跑 Rich Results Test 與 Schema Markup Validator。
7. 必要時更新 sitemap lastmod，並在 Search Console 檢查索引狀態。

文章改標題、改圖片、改作者時要同步什麼？

改標題時同步 headline；改代表圖時同步 image；改作者時同步 author 與頁面可見署名。若文章更新幅度較大，也要同步 dateModified。這點可搭配 文章更新 SEO 流程一起處理。

作者頁與 publisher logo 的固定資料要集中管理

作者頁、publisher 名稱、logo URL 不應該分散寫在每篇文章裡。建議在 CMS 或程式設定中集中管理，文章模板只讀取固定資料。這樣品牌改版、作者頁換 URL、logo 更新時，不會留下大量舊 Schema。

每次改版後的 Schema 回歸檢查

網站改版、換主題、換 CMS、調整前端框架後，都要抽查 Article Schema。實務上最常見的是新版模板少輸出 author、圖片變成相對路徑、日期格式被改壞。下一步是建立回歸檢查清單，讓工程部署前固定跑一次。

Article Schema 對 SEO、CTR 與 AI 搜尋到底有什麼幫助？

Article Schema 能幫搜尋引擎理解文章、作者、日期與出版者，可能改善搜尋結果呈現與內容辨識，但不能取代內容品質，也不保證排名、點擊率或 AI 搜尋引用。

它可能改善搜尋結果呈現，但不保證排名

Article Schema 可以讓 Google 更容易理解文章資訊，也可能影響搜尋結果呈現，但排名仍取決於內容品質、搜尋意圖匹配、網站可信度與競爭環境。把 Schema 當成排名保證，是很多網站做結構化資料時最容易走偏的地方。

它能強化作者與出版者的 entity clarity

清楚的 author、publisher、作者頁與品牌頁，有助於搜尋引擎把內容與實體連起來。對長期經營專題內容的網站，這比單篇文章塞更多關鍵字更有意義。內容策略可搭配 內容行銷指南建立一致的作者與主題脈絡。

它不能補救薄內容或沒有可信度的文章

如果文章本身沒有清楚觀點、缺少實際經驗、資料過期或只是拼湊段落，Article Schema 只能把問題標得更清楚。我的判斷是：Schema 做得越完整，內容本身越需要站得住腳，否則只是把低品質內容用更標準的格式送出去。

不適合放進本文主軸的內容

Article Schema 實作教學應聚焦文章頁，不應延伸成全站 Schema 策略或其他結構化資料類型。下一步是先把文章頁做正確，再處理其他頁型。

Product、FAQPage、LocalBusiness 不在本文深入範圍

商品、常見問答、在地商家等 Schema 類型有各自的適用頁面、欄位與 Google 規範，不適合混在 Article Schema 實作主軸中。若文章頁同時有 FAQ 區塊，也應先確認 Article 本體正確，再評估其他標記是否真的符合頁面內容。

不討論圖片 SEO、Core Web Vitals、全站架構 SEO

圖片 SEO、Core Web Vitals、全站架構 SEO 都會影響內容表現，但不是 Article Schema 的主題。實作時只需確認圖片可抓取、頁面可索引、canonical 一致，其餘議題應拆到獨立流程處理。