結構化資料（Schema）實作：6 種中小企最該加嘅類型

好多中小企第一次聽到 Schema，第一反應是：「加咗係咪會即刻排名升？」答案通常是：不會。結構化資料不是排名捷徑，它的真正作用，是用搜尋引擎看得懂的格式，清楚說明頁面講的是一間公司、一件產品、一篇文章、一個活動，還是一條導航路徑。

這篇不會重複技術 SEO 檢查清單入面「要加 Schema」那一層概念，而是幫你決定：哪些頁面值得加、加哪一種、需要準備甚麼資料、甚麼情況不要加。做對這些，才談得上 rich result、Search Console enhancement report 或之後的 CTR 優化。

先明白：Schema 不是排名捷徑，而是內容說明書

Google Search Central 對結構化資料的說明很直接：它可以幫搜尋引擎理解頁面內容，也可能讓頁面符合某些 rich result 資格。重點是「可能」，不是保證。Google 亦在結構化資料政策要求標記內容必須和頁面可見內容一致；頁面看不到的營業時間、評價、價格，不應該只寫在 JSON-LD 裡。

另外，不是每一種 Schema 都仍然有明顯搜尋外觀。FAQPage 就是常見誤區：Google 早在 2023 年已限制 FAQ rich results主要顯示於權威政府與健康網站，2025 年又宣布逐步移除幾種較少用的結構化資料搜尋展示。結論很簡單：不要為了舊教學裡的截圖而加 Schema。先問頁面本身有沒有資料、用戶是否需要這些資料、Google 目前是否仍支持這類搜尋功能。

先選頁面類型，再選 Schema 類型

中小企網站最常見錯誤，是把同一段 Organization 或 LocalBusiness JSON-LD 貼到全站，然後以為已完成 Schema。其實每種頁面要解釋的東西不同。服務頁要講公司與服務範圍；產品頁要講價格、庫存、評價；文章頁要講作者、發布日期與主圖；活動頁要講時間與地點。

6 種 Schema 選型矩陣：LocalBusiness、Product、Article、Breadcrumb、Review、Event

頁面類型	優先 Schema	適合誰	上線前要確認
首頁、關於頁、分店頁	Organization / LocalBusiness	本地服務、診所、餐飲、顧問公司	公司名、地址、電話、營業時間、sameAs 與頁面一致
產品頁、電商 collection 內的重點商品	Product + Offer	Shopify、WooCommerce、獨立電商	價格、幣種、庫存、圖片、SKU 不要過期
博客、指南、新聞稿	Article / BlogPosting	內容行銷、專業服務、B2B 網站	發布日期、更新日期、作者與主圖清楚可見
全站內頁	BreadcrumbList	有多層分類、服務群、博客分類的網站	麵包屑路徑和頁面實際導航一致
評價頁、產品頁、服務證明區	Review / AggregateRating	有真實評價來源的商家	評價必須可見、可追溯，不要自己作星級
活動、課程、講座、預約型頁面	Event / Course	教育中心、工作坊、展覽、線下活動	日期、地點、票價、狀態和延期資訊要同步更新

6 種 Schema 實作重點

1. LocalBusiness / Organization：先把 NAP 做乾淨

本地商家最常漏的是 NAP 一致性：Name、Address、Phone。你的 Google Business Profile、網站 footer、聯絡頁、分店頁、社交平台名稱最好一致。多分店不要只在首頁塞一段總公司 Schema；每間分店應該有獨立分店頁，並在該頁標明地址、電話、營業時間、地圖和服務範圍。這部分可以和Local SEO 香港攻略一起處理。

2. Product / Offer：電商頁不要只交給 theme 自動生成

Shopify 和很多電商 theme 會自動輸出 Product Schema，但不代表一定完整。你要檢查價格、幣種、availability、品牌、SKU、圖片、評價是否跟頁面一致。香港跨境電商常見問題是：頁面顯示 HKD，Schema 寫 USD；商品缺貨，但 structured data 還寫 InStock；不同 variant 的價格沒有更新。這類錯誤會令 Product rich result 失效，也會影響用戶信任。

3. Article / BlogPosting：日期和作者要可被驗證

文章 Schema 最重要不是把所有欄位填滿，而是日期和作者可信。頁面可見日期應與 datePublished、dateModified 對得上；如果只是改一兩個字，不要為了「新鮮」硬改更新日期。作者也不要用不存在的人名。中小企網站用 Organization 作為作者可以接受，但最好在文章底部或 About 頁交代內容由誰負責。

4. BreadcrumbList：細小但高回報

BreadcrumbList 通常不難做，但對大型服務頁、博客分類、產品分類很有用。它讓搜尋引擎理解頁面在網站內的位置，也幫用戶看到更清楚的路徑。重點是不要讓頁面上的麵包屑和 JSON-LD 不一致；如果頁面顯示「首頁 > 部落格 > 技術 SEO」，Schema 就不應該寫成「首頁 > 服務 > SEO」。

5. Review / AggregateRating：只標記真實、可見、合規的評價

Review Schema 很容易被濫用。不要把自己寫的 testimonial 包裝成第三方評價，也不要在所有服務頁硬塞五星。比較穩陣的做法，是只在產品頁、可公開評價頁或有清楚評價來源的頁面標記；評價文字、評分、作者、日期都要能在頁面上看到。專業服務網站若只有匿名簡短推薦，通常更適合先補案例與信任材料，而不是急著加 Review Schema。

6. Event / Course：日期狀態要有人維護

教育中心、工作坊、講座、展覽、體驗活動可以考慮 Event 或 Course。這類 Schema 的價值在於時間、地點、報名狀態清楚；風險也在這裡。如果活動延期、取消、售罄，頁面和 JSON-LD 要同步更新。若公司沒有固定維護流程，寧願先不要加，避免搜尋結果顯示過期資訊。

JSON-LD 實作流程：不要先寫 code，先審內容

大部分網站用 JSON-LD 最方便。你可以把它放在頁面的 <head>，也可以由 CMS template 自動輸出。不過實作順序不應該是「找一段範本貼上」。先看頁面是否有足夠資料，再決定欄位。

Schema 上線 4 步：對照頁面內容、補欄位、發佈 JSON-LD、測試與監控

對照頁面可見內容：先圈出頁面已有的公司名、地址、電話、價格、作者、日期、活動時間等資料。
補齊必要欄位：缺價格就不要做 Product；缺活動日期就不要做 Event；缺可見評價就不要做 Review。
發佈 JSON-LD：WordPress 可用 SEO plugin 或自訂欄位；Shopify 可放在 theme section；自建站可由 template 生成。
測試與監控：用 Rich Results Test 驗證，再看 GSC enhancement report 是否有 error 或 warning。

一段基本 LocalBusiness JSON-LD 可以長這樣。正式上線前要把範例值換成真實、頁面可見的資料：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "你的公司名稱",
  "url": "https://example.com/",
  "telephone": "+852-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "頁面可見地址",
    "addressLocality": "Hong Kong",
    "addressCountry": "HK"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }]
}
</script>

不同平台應該點做？

WordPress：先檢查 SEO plugin 是否已經輸出 Organization、Article、Breadcrumb。不要同時開幾個 plugin 生成同類 Schema，否則一頁可能有兩三段互相矛盾的 JSON-LD。商品或活動頁若靠自訂 post type，最好由模板統一管理欄位。

Shopify：先 View Source 搜 "@type":"Product"，再用 Rich Results Test 看 Product 是否合格。很多 theme 已有基本 Product Schema，但 FAQ、Review、Breadcrumb 和多語資料可能需要自訂。更完整的 Shopify 基礎設定可看Shopify SEO 香港電商攻略。

自建網站：最安全是用資料庫或 frontmatter 生成 JSON-LD，不要每頁手動貼。這樣改地址、圖片、日期時可以集中更新，也比較不會出現頁面內容已改、Schema 還是舊資料的問題。

上線前檢查清單

每段 Schema 都只描述當前頁面，不描述另一頁或整個網站不存在的內容。
頁面可見內容與 JSON-LD 內容一致，尤其是價格、庫存、日期、地址、電話、評價。
同一頁不要有多段互相衝突的 Product、Organization 或 Breadcrumb。
所有圖片 URL 可正常打開，尺寸足夠，並使用可被 Google 抓取的 HTTPS URL。
Rich Results Test 沒有 error；warning 逐項判斷是否真的要補。
上線後 7 至 14 日看 GSC 是否出現 enhancement report 或錯誤提示。

香港中小企最常見的 Schema 錯誤

第一，為了星星亂加 Review。 服務頁沒有真實評價，卻寫 aggregateRating。這不只是無效，還可能觸及 structured data policy 問題。

第二，FAQ 還當成必做 rich result。 FAQ 內容仍然值得寫，因為它幫用戶判斷；但不要把 FAQPage Schema 當成搜尋結果必出摺疊問答的技巧。現在更重要是 FAQ 本身是否回答了購買前疑慮。

第三，改版時忘記同步模板。 很多網站重做首頁、換 theme、搬 Shopify app 後，舊 Schema 還在輸出。改版後要把 Schema 放入收錄與技術排查流程，避免 canonical、breadcrumb、Product 資料同時出錯。

第四，只測首頁。 Schema 最大問題通常不在首頁，而在產品頁、文章頁、分店頁這類大量模板頁。抽樣至少要測 5 至 10 個不同模板 URL。

如何量度 Schema 是否有用？

不要只問「有冇出 rich result」。比較完整的量度應該分三層：

觀察層級	看甚麼	下一步
技術合格	Rich Results Test error、GSC enhancement error	先修 error，再處理有商業價值的 warning
搜尋外觀	GSC Search appearance、CTR、曝光查詢	比較上線前後同類頁面的 CTR 變化
商業承接	產品頁點擊、WhatsApp、表單、電話點擊	配合 GA4 事件追蹤看是否有更多合格互動

如果 Schema 上線後沒有 rich result，不代表完全沒價值；它仍可能幫搜尋引擎更清楚理解頁面。但如果三十日後 GSC 沒有任何改善訊號，也沒有 CTR 或轉換變化，就要回到頁面內容本身，而不是繼續加更多標記。

下一步：先做一張 Schema 優先級表

不要一次全站硬加。先列出 20 個最重要 URL：首頁、服務頁、最高流量博客、最有成交價值的產品頁、分店頁、活動頁。對每個 URL 填三欄：頁面類型、應加 Schema、缺少資料。缺資料的先補內容，已齊資料的再做 JSON-LD。

Redstone SEO 做技術審計時，會把 Schema 和索引、canonical、內容承接一起看。因為結構化資料只是頁面的說明書；如果頁面本身內容薄、內鏈弱、價格過期或 CTA 不清楚，加再多標記也不會變成好 SEO。

下一步可以點做

如果你正在處理這個問題，建議不要只看單一頁面。先把相關服務、案例和相近主題一併看完，會更容易判斷優先次序。

結構化資料與網站技術優化把 Schema、速度和模板維護放進網站底層。 看 SEO 實戰打法用不同情境理解我們如何排序技術、內容和轉化工作。 預約免費 SEO 診斷把目前網站問題先分級，決定下一步是否值得投入。 回到 SEO 主題集群按索引、內容、廣告、技術和收費問題繼續延伸閱讀。 頁面未被收錄排查Schema 之前先確認頁面可被抓取和索引。 技術 SEO 檢查清單用上線檢查避免模板和標記衝突。

Redstone SEO 編輯部

由資深 SEO 從業者撰寫。專注香港與大灣區中小企 SEO、技術審計、內容策略與數據追蹤。了解更多 →

想知道你網站 Schema 有冇加錯？

把網站 URL 傳給我們。Redstone SEO 可以先幫你抽查首頁、服務頁、產品頁和博客模板，分辨哪些 Schema 要修、哪些其實不必加。

WhatsApp 檢查 Schema