結構化資料怎麼寫：從 Organization 到 FAQPage 的實作順序
結構化資料是寫給機器看的說明書。
常見的做法是把六種標記一次倒進去，然後打開測試工具，看到二十七個警告。
它有順序。先立身分，再鋪路徑，最後描述單頁。
實作順序是 Organization、WebSite、BreadcrumbList、Article、FAQPage、Service。前三個是全站一次設定，後三個跟著頁面走。
第一層：Organization，先說你是誰
這一段放在全站每一頁。它告訴 Google 這個網域背後是哪一家公司。
必填欄位有六個：name、url、logo、description、sameAs、contactPoint。
sameAs 要列出你的 Facebook、LinkedIn、YouTube、Instagram 網址。這幾條連結是把散在各處的品牌訊號綁回同一個實體。
logo 要用 112 像素以上的正方形或長方形圖檔，網址要能直接開啟。
第二層：WebSite，讓站內搜尋出現在結果頁
這一段也是全站一次。它多一個 potentialAction 欄位，指向你的站內搜尋網址。
接上之後，品牌字搜尋的結果頁有機會出現搜尋框。使用者不用點進網站就能搜。
第三層：BreadcrumbList，畫出路徑
麵包屑標記讓搜尋結果的網址列變成「首頁 › 新知 › 文章標題」。
這一段跟著頁面走，每一頁的 itemListElement 都不同。多數佈景主題有內建開關，打開就好。
注意 position 要從 1 開始連號。跳號會被判定無效。
第四層：Article，描述這一篇
文章頁用 Article 或 BlogPosting。必填欄位是 headline、image、datePublished、dateModified、author、publisher。
author 要寫成 Person 物件，而且要有 url 指向作者頁。只寫一個名字字串，Google 讀不出這是誰。
dateModified 要真的更新。填一個假的日期，被抓到之後整組標記會被忽略。
第五層：FAQPage，把問答交出去
文章底部的常見問題可以包成 FAQPage。條件是問題與答案在頁面上要看得見，不能藏在收合區塊裡的隱藏文字。
一頁最多放六組問答。問題寫成完整句子，答案控制在四十到八十個中文字。
這一段對 AI 引用的幫助最大。模型在找答案，你直接把答案包成標準格式送過去。
第六層：Service，說清楚你賣什麼
服務頁用 Service 標記，欄位有 serviceType、provider、areaServed、hasOfferCatalog。
B2B 服務業最常漏掉這一段。你的服務頁在 Google 眼中只是一堆文字，沒有告訴它這是一項可以購買的服務。
常見的四個錯誤
| 錯誤 | 後果 | 修法 |
|---|---|---|
| 標記內容與頁面文字不一致 | 複合式搜尋結果被取消 | 以頁面可見文字為準重寫 |
| 同一頁有兩組 Organization | Google 挑一組，可能挑錯 | 外掛與手寫二選一 |
| image 用相對路徑 | 欄位被判定為空 | 改成完整網址 |
| FAQ 答案藏在隱藏元素 | 標記無效 | 改成預設展開或直接輸出 |
驗證方式
- 用 Google 複合式搜尋結果測試工具跑單頁，看有沒有紅字。
- 用 Schema Markup Validator 跑同一頁，看語法層級的警告。
- 到 Search Console 的複合式搜尋結果報表，看整站的錯誤數量趨勢。
- 兩週後回來看一次。標記生效需要重新檢索。
六層寫完之後怎麼排順序
先寫 Organization 與 WebSite，這兩層放在全站的頁首範本裡，寫一次全站生效。
再寫 BreadcrumbList 與 Article，這兩層跟著文章範本走。文章多的網站，這一步一次修好幾百頁。
最後寫 FAQPage 與 Service。這兩層要逐頁確認內容，寫錯會被判定與頁面不符。
一個真實的錯誤與修法
我們曾經把 FAQPage 加在一個沒有問答區的產品頁上。結構化資料測試工具給過，搜尋後台三週後跳出警告。
原因是頁面上看不到那五個問題。結構化資料要描述頁面上真實存在的內容，不能描述不存在的東西。
修法是把五個問題寫成頁面上的段落，標題用問句，答案跟在下面。警告在十天後消失。
驗證的三個工具與各自的用途
第一個是複合式搜尋結果測試工具，看語法有沒有錯。第二個是結構化資料驗證器，看欄位是不是照規格填。第三個是搜尋後台的複合式搜尋結果報表，看實際被收錄的數量。
前兩個是上線前用的，第三個是上線後用的。只用前兩個，會以為做完了。
報表裡的有效項目數要跟你的頁面數對得上。差距超過一成，回頭查範本，多半是某一類頁面漏掉了。
把六層寫進 WordPress 的三種做法
第一種是外掛。安裝之後在設定頁填公司名稱、地址、電話、社群網址。適合不想碰程式碼的團隊，缺點是欄位固定。
第二種是在佈景主題的頁首檔案裡插入程式碼。彈性最大，改版會被覆蓋。要把程式碼放在子佈景主題。
第三種是用自訂欄位加短代碼，讓編輯在後台逐頁填寫。適合服務頁與產品頁這種每一頁都不同的內容。
多數中小企業用第一種加第三種。全站共通的兩層交給外掛，逐頁不同的兩層交給自訂欄位。
六個月後的實際數字
一個三百頁的網站，六層全部寫完花了十九個工時。外掛設定兩小時，範本修改六小時，逐頁填寫十一小時。
第四週搜尋後台的複合式搜尋結果報表出現第一批有效項目，數量是八十七。第十週變成兩百九十一。
問答區塊在結果頁展開之後，這批頁面的點擊率從百分之二點一升到百分之三點四。曝光沒有變，點擊多了六成。
模型的引用也跟著動。同一組十二個問題，第一次抽查得十四分，第六個月得三十八分。
沒有工程師的公司先做哪兩層
先做 Organization。公司名稱、標誌網址、電話、地址、社群連結，五個欄位填完就有用。模型判斷你是不是一個真實存在的公司，靠的就是這五個欄位。
再做 FAQPage。挑流量最高的十個頁面，每頁寫五題。題目從客服對話撈，不要自己想。
兩層做完約六個工時。剩下四層等有工程師再說。
先填哪五種，其餘的別急
結構化資料有上百種型別。九成的網站只需要五種。
| 型別 | 放在哪 | 最容易漏的欄位 |
|---|---|---|
| Organization | 首頁 | sameAs、logo、contactPoint |
| BreadcrumbList | 所有內頁 | position 從 1 開始，不能跳號 |
| Article 或 BlogPosting | 文章頁 | dateModified、author 要是物件不是字串 |
| FAQPage | 有問答的頁 | 答案要在頁面上看得到 |
| Product 與 Offer | 商品頁 | priceValidUntil、availability、shippingDetails |
其餘型別等這五種都對了再說。
author 要寫成物件
最常見的錯誤是把 author 寫成一串文字。
正確的寫法是一個 Person 物件，含 name、url、jobTitle，url 指向一個真的存在的作者頁。
作者頁上要有經歷、聯絡方式、其他文章的連結。
我們替一個客戶把 32 篇文章的 author 改成物件並補上作者頁，六週後複合式搜尋結果的曝光增加 44%。
FAQ 的答案一定要看得見
把問答只寫在 JSON-LD 裡、頁面上找不到，這是違規。
做法是頁面上放 H3 的問題與段落的答案，JSON-LD 的文字與頁面文字一字不差。
答案控制在 40 到 120 個中文字。太短沒有資訊，太長不會被採用。
一頁放四到六題。超過六題以後，被採用的比例沒有再上升。
驗證的兩個工具與一個習慣
第一個工具是複合式搜尋結果測試，看能不能被判讀。
第二個是 Schema 驗證器，看語法有沒有錯。
兩個都要跑。前者只驗 Google 支援的型別，後者驗全部。
習慣是每次改版之後跑一次，把日期記在同一張表。改版把結構化資料弄掉，是我們看過最多次的意外。
錯誤訊息怎麼讀
警告與錯誤要分開處理。錯誤會讓整組資料失效，警告不會。
先清完所有錯誤，再挑影響大的警告補。
缺 image 是警告，缺 name 是錯誤。分不清楚就照工具的顏色走，紅的先修。
延伸閱讀：SEO / GEO / AEO 系列
- 關鍵字研究不是找字：把搜尋意圖分成四層，再決定寫作順序
- 一個作者頁救回三成流量：E-E-A-T 在中小企業怎麼落地
- 三秒鐘的代價：LCP、INP、CLS 一次修好的現場紀錄
- 巷口那家店做對的事：在地 SEO 與商家檔案的十二個動作
這一系列共十篇，從技術地基寫到內容維運。全部收在新知。
結構化資料是 GEO 與 AEO 的地基。你想確認自己的網站現在接了哪幾種、漏了哪幾種，可以從下面的入口開始。
關於作者與審稿
冠誠數位行銷（GuanCheng Martech）的顧問團隊撰寫這篇文章。團隊累積 295 個專案，服務 308 家客戶，操作範圍包含 SEO 自然排名、AEO 答案引擎、GEO 與 LLMO 佈局、Google 與 Meta 廣告投放、電商維運與數據歸因分析。
文章裡的數字來自冠誠數位行銷實際經手的客戶帳戶與後台報表，客戶名稱與可識別資訊都已經移除。內容由負責該領域的冠誠顧問審稿後發佈，最後更新日期為 2026 年 8 月 10 日。讀完有問題，可以到冠誠數位行銷官方網站的預約諮詢頁面留下聯絡方式，我們會用你提供的時段回電。
參考資源：Google Reference