Shopify Theme 內容該用 Blog、Product、Collection 還是 Metafield？

前言

上一篇 把一頁式畫面拆成 sections、settings 與 blocks。這解決了「商家怎麼編輯」，卻還沒回答更重要的問題：內容究竟存在哪裡？

同一張首頁卡片可以來自 block，也可以指向 Article、Product 或 Collection；分類與補充欄位又可能放在 tag 或 metafield。選錯資料模型，畫面仍能完成，但同一份內容很快會在首頁、列表頁與詳情頁各存一份。

原本的做法與問題症狀

Static source 裡，新聞、政策、活動與支持商品都只是 HTML：

• 標題、日期、圖片與連結直接寫在卡片。
• 分類 tab 是固定字串。
• 商品名稱與呈現文字沒有庫存、variant 或商品狀態。
• 首頁精選與列表頁之間沒有共同 identity。

轉進 Theme Editor 後，最直接的做法是全部改成 blocks。這比硬編碼好，卻會製造新的重複：

• 發布一篇文章後，還要手動改首頁卡片。
• 商品下架時，手動卡片仍可能留著。
• Collection 已經管理一組商品，Theme 又保存另一份商品清單。
• Metafield 只是為了「可以自訂」而建立，卻沒有 owner、型別或 fallback。

另一個極端是所有內容都做 metafield。Metafield 適合擴充既有 resource，不適合取代 Article、Product 或 Collection 本身。

問題是怎麼推敲出來的？

案例先看內容的生命週期，而不是卡片長相：

內容問題	優先模型
有標題、內文、作者、發布時間與獨立 URL 的編輯內容	Blog / Article
有價格、variant、庫存、購買流程與商品頁	Product
商家要維護一組商品，並讓多個 surface 重用	Collection
在既有 Article、Product、Collection 上補結構化欄位	Metafield
只屬於單一 section、沒有獨立生命週期的小型策展內容	Block

來源 conversion plan 因此把新聞與政策規劃成 Blogs／Articles，把支持商品規劃成 Products／Collection，把 category、group、card label 與 featured 等補充資訊規劃為 tags 或 metafields。

但 source 也揭露了「計畫」與「已實作」的差距：Theme 內已有基礎 Blog、Article、Product 與 Collection sections，卻沒有足夠證據證明首頁客製卡片已讀取這些 resources；目前首頁活動與商品卡仍主要來自手動 blocks，也沒有客製 section 讀取 metafield 的證據。

最後採用的架構

適合正式演進的資料流是：

Shopify admin
  ├─ Blog / Article
  │    └─ tags / article metafields
  ├─ Product
  │    └─ product metafields
  └─ Collection
       └─ selected products / rules

JSON template
  → 選擇要顯示的 section

Section settings
  → 選 Blog、Collection 或 featured resource

Liquid
  → 讀 resource
  → 讀 typed metafield 補充欄位
  → render card snippet

Manual blocks
  → 僅在 resource 尚未建立或內容只屬於這個 section 時 fallback

關鍵不是完全禁止 manual block，而是定義 single source of truth。若卡片代表可購買商品，Product 是真實來源；block 最多保存策展標籤或 override，不應再保存一份價格與庫存狀態。

關鍵實作

新聞列表直接迭代 blog articles：

{% paginate blog.articles by 12 %}
  {% for article in blog.articles %}
    {% render 'article-card',
      title: article.title,
      url: article.url,
      image: article.image,
      published_at: article.published_at
    %}
  {% endfor %}
{% endpaginate %}

支持商品則讓 merchant 在 section setting 選 Collection：

{% assign featured_collection = section.settings.collection %}

{% for product in featured_collection.products limit: section.settings.limit %}
  {% render 'product-card', product: product %}
{% endfor %}

Metafield 應擴充既有 resource，例如讓 Article 帶一個 typed category：

{% assign category = article.metafields.editorial.category.value %}

{% if category != blank %}
  <span class="article-card__category">{{ category }}</span>
{% endif %}

這段只有在 merchant admin 已建立對應 metafield definition、內容也已搬移後才成立。案例來源目前沒有足夠實作證據，因此公開文章把它列為最終模型，而不宣稱已在正式 theme 使用。

實際驗證

來源 theme 可證明的能力有：

• blog.liquid 會 paginate blog.articles，使用 Article 的 title、URL、image、published time 與 excerpt。
• article.liquid 會輸出 Article image、title、metadata 與 content。
• collection.liquid 會 paginate collection.products，並讀取 Product image、title、URL 與 price。
• product.liquid 使用 Product variants 與 product form。
• Header 透過 Shopify menu setting 取得導覽。
• Theme Check 對這些 Liquid／JSON files 沒有回報 error。

目前不能證明：

• 首頁活動卡已自動同步 Blog／Article。
• 首頁支持卡已由 selected Collection 驅動。
• 計畫中的 article metafields 已建立 definition、搬移資料並被客製 section 讀取。
• Production merchant 已完成 Blog、Product、Collection 或 Metafield 內容建置。

這個差距很重要：source code 裡有通用 resource surface，不等於客製首頁已完成資料接線。

仍然存在的限制

第一，Blog 與 Article 適合發布型內容，但若需要複雜關聯、跨 Blog 聚合或非文章型實體，tags 與 metafields 可能不足，應評估 metaobjects。

第二，Collection 有 manual 與 automated rules 等不同維護方式。Theme 只應消費結果，不應假設每個 Collection 都是人工排序。

第三，Product 的價格、可售狀態與 variant 必須從 Product object 取得。把顯示價格存進 block 會繞過 Shopify 的真實 commerce state。

第四，Metafield definition、namespace、key、type 與 owner 都是 API contract。刪除或改型別前要先找出所有 Liquid consumers，不能只把它當自由欄位。

第五，manual fallback 很適合讓轉換先有畫面，但要有退場條件。若 resource 已可用卻仍保留 fallback，商家不知道該改哪一份內容。

最後，這篇的最終模型仍需要 live store 內容與 Theme Editor 驗收，才算完成 migration。Repository 只能證明 Liquid consumer，不能證明 admin data 已正確建立。

可以延伸到哪些情境？

若專案加入活動場次、人物介紹、據點或 FAQ，可沿用同一個判斷：

有 Shopify 原生 commerce/editorial resource？
  → 先用原生 resource

只是在原生 resource 上補一個 typed field？
  → metafield

是一種可重用、可關聯、非原生的內容實體？
  → metaobject

只屬於單一頁面的一小段策展內容？
  → section setting / block

下一篇把模型落到發布前的驗收：Shopify Theme 轉版如何驗收？從 Theme Check 到三種響應式尺寸

參考資料

• Shopify：Blog templates
• Shopify：Article templates
• Shopify：Product templates
• Shopify：Collection templates
• Shopify：Metafields
• Shopify：Access metafields in Liquid

以上平台文件查核日期：2026-07-29。