網站負責人必讀：按順序實作結構化資料的六層流程與優先次序

網站負責人必讀：按順序實作結構化資料的六層流程與優先次序

要把結構化資料做好，先照順序寫六層標記：先 Organization、WebSite，再 BreadcrumbList、Article，最後 FAQPage 與 Service。

本文觀點短論式整理，直接回到可操作的步驟與注意事項，方便工程與編輯在有限資源下先做哪些、怎麼做。

為什麼要有實作順序？

結構化資料（structured data）本質是給機器看的「說明書」。按順序實作可以把品牌實體、站內搜尋與內容路徑先建立好，讓後續的頁面型別（文章、問答、服務）能被正確判讀。我的觀點是：先立身分，再鋪路徑，最後描述單頁；這樣能把風險與驗證工作流程化，減少重工。

實務關鍵：先做全站一次設定（Organization、WebSite），再做跟頁面綁定的標記（BreadcrumbList、Article），最後補上可能導致錯誤的逐頁型別（FAQPage、Service）。

六層標記的實作順序與目的（步驟總覽）

  1. Organization（全站）—先說你是誰
  2. WebSite（全站）—讓站內搜尋可能出現在 SERP
  3. BreadcrumbList（逐頁）—畫出內容路徑
  4. Article / BlogPosting（文章頁）—描述文章元資料
  5. FAQPage（逐頁，有問答時）—把問答以標準格式輸出
  6. Service（服務頁）—把服務描述成可以購買的項目

簡要步驟（實作順序）：

  • 步驟 A：把 Organization 與 WebSite 放到全站 header 模板。
  • 步驟 B：在文章範本加入 BreadcrumbList 與 Article 欄位。
  • 步驟 C：逐頁填寫 FAQPage 與 Service，並驗證與可見內容一致。

這樣排列，能把大多數錯誤與被忽略的欄位先行補上，後續只需對逐頁內容做微調。

每一層的必要欄位與注意事項（詳解）

Organization（第一層）——先說你是誰（放在每一頁）

必要欄位（常見必填七項）：

  • name
  • url
  • logo（112px 以上，完整可直接開啟的 URL）
  • description
  • sameAs（列出 Facebook、LinkedIn、YouTube、Instagram 等社群 URL）
  • contactPoint（客服或聯絡方式）

注意事項：logo 與 sameAs 能把分散的品牌訊號綁回同一實體；logo 記得使用完整網址（避免相對路徑）。

觀點：Organization 是搜索引擎判斷「這個網域背後有沒有真實實體」的第一把鑰匙，先做價值最高。

WebSite（第二層）——讓站內搜尋有機會出現在結果頁

必要欄位：基本站點資料加上 potentialAction（指向站內搜尋 URL）。

注意事項：填好 potentialAction 後，品牌字搜尋有機會在 SERP 顯示搜尋框，使用者可直接在結果頁搜尋站內內容。

BreadcrumbList（第三層）——畫出路徑（逐頁）

用途：讓搜尋結果顯示麵包屑（例如「首頁 › 新知 › 文章標題」）。

重要提醒：itemListElement 的 position 必須從 1 開始連號，不能跳號或重覆，否則會被判定無效。

Article / BlogPosting（第四層）——描述文章本體

必要欄位：headline、image、datePublished、dateModified、author（Person 物件）、publisher。

關鍵注意：author 必須是 Person 物件（含 name、url），而非單純字串；dateModified 必須真實反映更新時間，填假的會讓整組標記失效。

觀點：很多網站把 author 寫成純文字，這會讓搜尋引擎無法把文章與作者頁建立連結；建立作者頁並連回去，對 E-E-A-T 有實用價值（本文觀點）。

FAQPage（第五層）——把頁面問答以標準格式輸出

條件：問題與答案必須在頁面上可見，不能只寫在 JSON-LD 中的隱藏文字。

建議：一頁 4–6 組問答；問題用完整句子，答案控制在 40–120 個中文字之間（原文建議 40–80，但本文範圍略放寬上限至 120，以保留必要說明）。

注意：一頁最多放六組問答；超過後被採用的比例沒有顯著上升（原實務觀察）。

Service（第六層）——把你賣的東西寫清楚

常用欄位：serviceType、provider、areaServed、hasOfferCatalog。

提醒：B2B 服務頁常被忽略，結果在 Google 看起來只是一堆文字；加上 Service 標記能讓搜尋引擎把頁面理解為可提供的服務。

常見錯誤、後果與修法（表格與要點）

錯誤情境 後果 建議修法
標記內容與頁面可見文字不一致 複合式搜尋結果被取消或標記無效 以頁面可見文字為準重寫標記
同一頁有兩組 Organization Google 可能選錯一組 外掛與手寫選一種做法（不要重複）
image 使用相對路徑 欄位被判定為空 改成完整網址
FAQ 答案放在隱藏元素 標記無效 改為預設展開或直接把問答輸出在頁面上

實作要點（快速檢查清單）：

  • author 是否為 Person 物件且有作者頁 URL？
  • logo 是否為完整 URL，且尺寸符合建議？
  • BreadcrumbList 的 position 是否從 1 開始連號？
  • FAQPage 的問答是否在頁面上可見且不超過每頁上限？
  • 是否存在重複的 Organization 標記？

限制/例外：某些型別（如 Product、Offer）的欄位（priceValidUntil、availability）需要與電商後台資料同步，若站點無電商系統，暫時不要填寫誤導資訊。

驗證工具與標準化流程（何時用哪個工具）

  • 上線前：
  • 用 Google 複合式搜尋結果測試工具（Rich Results Test）檢查能否被 Google 讀取與辨識（特定型別）。
  • 用 Schema Markup Validator（或通用 Schema 驗證器）檢查語法與欄位規格。
  • 上線後：
  • 在 Google Search Console 的「複合式搜尋結果報表」查看整站錯誤與有效項目數的趨勢。

操作習慣建議：每次改版後（尤其是範本變更）都跑一次驗證工具，並把結果記錄在變更清單。錯誤先修（紅色），再處理重要的警告（黃色）。

驗證頻率建議：上線後兩週內回來看一次，之後視站頻率每月或每次範本改版檢查。

在 WordPress 的三種實作做法（適用情境與風險）

  1. 外掛（最簡單，欄位固定）
    – 適合：沒有工程師、想快速上線的團隊。
    – 優點：介面友善、設定一次即可全站生效。
    – 風險：欄位固定、較難支援客製化欄位。
  2. 把程式碼放在佈景主題的 header（彈性大）
    – 適合：有前端工程師、需要完全客製的團隊。
    – 優點：彈性最大，可以精確控制輸出內容。
    – 風險：主題更新會覆蓋，建議放在子佈景主題。
  3. 自訂欄位 + 短代碼（逐頁由編輯填寫）
    – 適合：服務或產品頁每頁內容都不同，需要編輯介面輸入的情況。
    – 優點：後台可逐頁管理，適合多變內容。
    – 風險：工作量較大，需要編輯訓練。

實務建議：多數中小企業採外掛 + 自訂欄位的混合做法，把全站共通的兩層（Organization、WebSite）交給外掛，逐頁不同的層交給自訂欄位處理。

實務案例與數字（原文觀察與限制）

以下為原文提供的實務觀察，保留原始數字，並在下方說明資料邊界與可驗證性：

  • 範例：一個三百頁的網站，六層全部寫完花了 19 個工時（外掛設定 2 小時、範本修改 6 小時、逐頁填寫 11 小時）。在第 4 週，Search Console 出現 87 個有效項目；第 10 週變成 291。問答區塊在結果頁展開後，這批頁面的點擊率從 2.1% 上升到 3.4%，點擊增加約 60%。
  • 另一觀察：為某客戶把 32 篇文章的 author 改成物件並補上作者頁，6 週後複合式搜尋結果的曝光增加 44%。
  • 模型引用（原文內部抽查數據）：同一組 12 個問題，第一次抽查得 14 分，第六個月得 38 分（原始分數定義為作者內部衡量）。

本文資料邊界：以上數據為原文作者（冠誠數位行銷）提供的實務彙整與觀察，來源為該團隊在其客戶帳戶與後台報表的匿名彙整；若讀者要在自己站上驗證相同效果，需以自身流量基礎與範本規模為準。

觀點與取捨：這些數字可作為估算與規劃參考，但不保證在不同網站環境、產業與流量結構下會重現相同結果。

沒有工程師時先做哪兩層？（快速可執行的 6 小時策略）

優先順序（無工程師時）：

  1. Organization（填公司名稱、標誌 URL、電話、地址、社群連結）—填完五個欄位就能產生基礎品牌信號。
  2. FAQPage（挑流量最高的十個頁面，每頁寫 4–6 題）—題目可從客服對話或搜尋關鍵字裡擷取，不要憑空想。

估時參考（原文建議）：這兩層合計約 6 個工時。

常見問題（本文真實回答）

FAQ 1：Organization 的 sameAs 要列哪些社群？

同一實體在外部平台的官方帳號（如 Facebook、LinkedIn、YouTube、Instagram）都應該列在 sameAs 裡，這有助於把分散的品牌訊號綁回同一個實體。

FAQ 2：FAQPage 的答案可以放在收合面板（accordion）裡嗎？

不建議把答案放在預設隱藏的收合區塊。條件是問答必須在頁面上可見，否則 FAQPage 標記可能被視為不符合條件而無效。可把問答預設展開或直接輸出為段落。

FAQ 3：author 可以只填一個字串嗎？

不行。author 要寫成 Person 物件（含 name 與指向作者頁的 url）。只寫一個名字字串，Google 讀不出這是誰。

FAQ 4：發現 Search Console 顯示錯誤，我應該先修警告還是錯誤？

先修錯誤（會造成整組資料失效），再針對影響較大的警告做優先級修補。工具上通常以紅色（錯誤）優先於黃色（警告）。

FAQ 5：如何知道我是否漏掉某一類頁面的標記？

把 Search Console 的有效項目數與實際頁面數比對，若差距超過約 10%，回檢該類範本是否未被套用標記。

下一步（站內資源與行動清單）

建議的最短行動路線：

  1. 在後台或範本先加入 Organization、WebSite（全站一次設定）。
  2. 於文章範本加入 BreadcrumbList、Article 欄位，並把 author 改成 Person 物件。
  3. 逐頁加入 FAQPage 或 Service（有問答或服務內容的頁面），並跑驗證工具。

如需更進一步的實作支援，可參考我們的站內資源：

（以上內連為站內入口，供讀者做下一步的聯繫或查閱。）

作者聲明與本文定位：本文以觀點短論方式整理實務流程與注意事項。文章中的數字與案例為原稿作者團隊在其客戶帳戶中的彙整結果；若需把同樣手法套到你自己的站，請先在測試環境驗證。

延伸閱讀：