Article 結構化資料：文章、部落格與新聞的標記

Q: Article、BlogPosting、NewsArticle 該選哪一個？

不確定就選 Article，它最通用而且涵蓋另外兩者的用途。部落格文章可以用 BlogPosting 更精確一些，但收益很小。NewsArticle 只有真正的新聞媒體該用，一般網站用它反而不恰當。

Q: author 用 Person 還是 Organization？

個人署名的文章用 Person，並盡量附上作者頁面的網址；由團隊或公司名義發佈的用 Organization。要避免的是把作者填成網站名稱卻標成 Person，那會讓實體類型與實際內容不符。

Article 是內容型網站最通用的結構化資料型別。它告訴搜尋引擎「這一頁是一篇文章」，並提供標題、作者、發佈時間與圖片等資訊。

json

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "文章標題",
  "description": "文章摘要",
  "image": ["https://example.com/og.png"],
  "author": {
    "@type": "Person",
    "name": "Away",
    "url": "https://example.com/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "F2E 前端工程文件",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/site-logo.png"
    }
  },
  "datePublished": "2026-09-07",
  "dateModified": "2026-09-07",
  "inLanguage": "zh-Hant-TW",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/article"
  }
}

三種型別怎麼選

型別	適用	建議
`Article`	任何文章	不確定就用這個
`BlogPosting`	部落格文章	可用，但收益很小
`NewsArticle`	新聞報導	只有新聞媒體該用

選 Article 就好

BlogPosting 與 NewsArticle 都是 Article 的子型別，欄位幾乎相同。選更精確的型別在多數情況下沒有額外收益。

NewsArticle 值得特別提醒：它對應的是新聞出版標準，一般網站用它不但沒好處，還可能因為不符合新聞內容政策而被忽略。

欄位一覽

欄位	必要性	說明
`headline`	必填	文章標題，110 字元內
`image`	建議	圖片網址，建議多種比例
`author`	建議	作者，`Person` 或 `Organization`
`publisher`	建議	發佈者，通常是 `Organization`
`datePublished`	建議	發佈時間，ISO 8601
`dateModified`	建議	最後修改時間
`description`	選填	摘要
`inLanguage`	選填	語言代碼
`mainEntityOfPage`	選填	這篇文章的正式網址
`articleSection`	選填	所屬分類

headline 的限制

110 字元上限，而且必須與頁面標題一致

超過 110 個字元的部分可能被截斷。更重要的是 不要為了塞關鍵字寫成與頁面不同的版本，那屬於標記與內容不符，是結構化資料的政策紅線。

json

// 錯誤：與頁面上的 h1 完全不同
"headline": "文章標記 Article schema BlogPosting NewsArticle 結構化資料教學"

// 正確：與 h1 一致
"headline": "Article 結構化資料：文章、部落格與新聞的標記"

實務上最好的做法是 直接取用頁面標題的同一份資料：

{
  headline: page.title,   // 和 <title>、<h1> 同一個來源
}

author 與 publisher

author

情況	用哪個
個人署名的文章	`Person`
團隊或公司名義發佈	`Organization`

json

// 個人署名，附上作者頁面
"author": {
  "@type": "Person",
  "name": "Away",
  "url": "https://example.com/about"
}

不要把網站名稱填成 Person

json

// 錯誤：實體類型與內容不符
"author": { "@type": "Person", "name": "某某科技有限公司" }

公司名義發佈就用 Organization。

url 建議填，指向一個 真實存在的作者頁面，這對內容可信度有幫助。

publisher

通常是網站或組織本身：

json

"publisher": {
  "@type": "Organization",
  "name": "F2E 前端工程文件",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/site-logo.png"
  }
}

用 @id 避免每頁重複

整站的組織資訊在首頁完整描述並給它一個 @id，文章頁用識別碼參照就好：

json

"publisher": { "@id": "https://example.com/#organization" }

做法見組織與網站 Organization 標記。

日期欄位

json

"datePublished": "2026-09-07",
"dateModified": "2026-09-07"

格式用 ISO 8601，可以只寫日期或帶時間與時區：

json

"datePublished": "2026-09-07T14:30:00+08:00"

dateModified 不要每次部署都改

// 錯誤：每次建置都變成當天
dateModified: new Date().toISOString().slice(0, 10);

這會讓欄位失去意義，一篇兩年沒動的文章顯示為「今天更新」。長期下來搜尋引擎會整體忽略它。

正確做法是從版本控制取值：

bash

# 檔案的最後提交時間
git log -1 --format=%cI -- docs/src/seo/schema-article.md

import { execSync } from 'node:child_process';

function getLastModified(filePath) {
  const iso = execSync(`git log -1 --format=%cI -- "${filePath}"`)
    .toString()
    .trim();
  return iso.slice(0, 10);
}

image 欄位

不是必填，但有圖片的文章在搜尋結果中 比較可能取得帶縮圖的呈現。

json

"image": [
  "https://example.com/16x9.png",
  "https://example.com/4x3.png",
  "https://example.com/1x1.png"
]

建議	說明
提供多種比例	16:9、4:3、1:1，讓搜尋引擎依版位挑
寬度至少 1200 像素	太小的圖不會被採用
用絕對網址	相對路徑無效
圖片必須可被爬取	不能被 `robots.txt` 擋住

可以和 og 圖共用

1200 × 630 的 Open Graph 圖同時當 Article 的 image 是常見做法。這個站就是這樣做的，一張圖同時服務搜尋結果與社群卡片。

一個完整的範例

內容型網站通常把 Article 交給頁面資料自動產生，每篇文章的檔頭都會有這麼一段：

html

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article 結構化資料：文章、部落格與新聞的標記",
  "image": ["%SITE%/images/seo/schema-article-og.png"],
  "author": { "@type": "Person", "name": "作者名稱", "url": "%SITE%/about" },
  "datePublished": "2026-09-07",
  "dateModified": "%MODIFIED%",
  "inLanguage": "zh-Hant-TW",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "%SITE%/seo/schema-article"
  }
}
</script>

%SITE% 是網域 token，建置時依環境替換，這樣測試機不會產出指向正式網域的標記。細節見 JSON-LD 語法與驗證。

常見錯誤

這四個都會讓標記無效或被忽略

錯誤	後果
`headline` 與頁面 `<h1>` 不同	標記與內容不符
`dateModified` 早於 `datePublished`	邏輯矛盾，欄位被忽略
`image` 用相對路徑	抓不到圖
列表頁也標成 `Article`	型別不符，列表頁不是一篇文章

最後一項值得說明：分類頁、標籤頁、搜尋結果頁 不是文章。它們如果要標記，適合的是 CollectionPage 或 ItemList，不是 Article。

檢查清單

項目	標準
`headline` 與頁面標題一致	必備
`headline` 在 110 字元內	建議
`author` 的型別符合實際情況	必備
`datePublished` 為 ISO 8601	必備
`dateModified` 反映真實修改時間	必備
`dateModified` 不早於 `datePublished`	必備
`image` 為絕對網址且寬度至少 1200	建議
只用在真正的文章頁	必備
通過複合式搜尋結果測試	建議

常見問題

Article、BlogPosting、NewsArticle 該選哪一個？

不確定就選 Article，它最通用而且涵蓋另外兩者的用途。部落格文章可以用 BlogPosting 更精確一些，但收益很小。NewsArticle 只有真正的新聞媒體該用，一般網站用它反而不恰當。

headline 有長度限制嗎？

建議 110 個字元以內，超過的部分可能被截斷。更重要的是它必須與頁面上實際的標題一致，不要為了塞關鍵字寫成不同的版本，那屬於標記與內容不符。

dateModified 每次部署都要更新嗎？

不要。它應該反映內容真正被修改的時間。每次部署都改成當天會讓這個欄位失去意義，長期下來搜尋引擎會整體忽略它。建議從版本控制的最後提交時間取值。

author 用 Person 還是 Organization？

個人署名的文章用 Person，並盡量附上作者頁面的網址；由團隊或公司名義發佈的用 Organization。要避免的是把作者填成網站名稱卻標成 Person，那會讓實體類型與實際內容不符。

image 欄位一定要填嗎？

不是必填，但強烈建議填。有圖片的文章在搜尋結果中比較可能取得帶縮圖的呈現。建議提供多種比例的版本，讓搜尋引擎依版位挑選，圖片寬度至少 1200 像素。

延伸閱讀

JSON-LD 語法與驗證

麵包屑 BreadcrumbList 標記

網頁標題的寫法

結構化資料是什麼？

參考資料：Google 搜尋中心：Article 結構化資料

Article 結構化資料：文章、部落格與新聞的標記 ​

三種型別怎麼選 ​

欄位一覽 ​

headline 的限制 ​

author 與 publisher ​

author ​

publisher ​

日期欄位 ​

image 欄位 ​

一個完整的範例 ​

常見錯誤 ​

檢查清單 ​

常見問題 ​

延伸閱讀 ​

Article 結構化資料：文章、部落格與新聞的標記

三種型別怎麼選

欄位一覽

headline 的限制

author 與 publisher

author

publisher

日期欄位

image 欄位

一個完整的範例

常見錯誤

檢查清單

常見問題

延伸閱讀