結構化資料 Schema 實作順序教學封面圖,冠誠數位行銷製作

結構化資料怎麼寫:從 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 眼中只是一堆文字,沒有告訴它這是一項可以購買的服務。

常見的四個錯誤

錯誤後果修法
標記內容與頁面文字不一致複合式搜尋結果被取消以頁面可見文字為準重寫
同一頁有兩組 OrganizationGoogle 挑一組,可能挑錯外掛與手寫二選一
image 用相對路徑欄位被判定為空改成完整網址
FAQ 答案藏在隱藏元素標記無效改成預設展開或直接輸出
結構化資料的四個常見錯誤與修法。

驗證方式

  1. 用 Google 複合式搜尋結果測試工具跑單頁,看有沒有紅字。
  2. 用 Schema Markup Validator 跑同一頁,看語法層級的警告。
  3. 到 Search Console 的複合式搜尋結果報表,看整站的錯誤數量趨勢。
  4. 兩週後回來看一次。標記生效需要重新檢索。

六層寫完之後怎麼排順序

先寫 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 系列

這一系列共十篇,從技術地基寫到內容維運。全部收在新知


結構化資料是 GEO 與 AEO 的地基。你想確認自己的網站現在接了哪幾種、漏了哪幾種,可以從下面的入口開始。

常見問題

結構化資料會直接提升排名嗎?

不會直接提升。它讓 Google 更容易理解頁面,也讓頁面有機會拿到複合式搜尋結果。點擊率上去,排名才跟著動。

用外掛產生就夠了嗎?

Organization、Article、BreadcrumbList 用外掛就夠。Product、Service、HowTo、FAQPage 通常要手動補欄位,外掛猜不到你的內容。

標記寫錯會被懲罰嗎?

標記的內容跟頁面上看得到的內容不一致,會被判定為垃圾結構化資料,複合式搜尋結果會被取消。寫在標記裡的每一句話,頁面上都要看得到。

JSON-LD 要放在 head 還是 body?

兩個位置都可以。Google 兩邊都讀。放在 head 比較好管理,放在 body 比較好隨內容一起輸出。

結構化資料要先做哪幾種?

五種。Organization、BreadcrumbList、Article 或 BlogPosting、FAQPage、Product 與 Offer。其餘型別等這五種都正確了再說。

FAQ 的答案可以只寫在 JSON-LD 裡嗎?

不行,這是違規。頁面上要有 H3 的問題與段落的答案,JSON-LD 的文字要與頁面文字一字不差。答案控制在 40 到 120 個中文字,一頁四到六題。