前端工程文件

Appearance

LocalBusiness 與 Event 標記：在地商家與活動資訊 ​

LocalBusiness 與 Event 標記：在地商家與活動

這兩個型別都在描述 現實世界的東西：LocalBusiness 是一個有地址的商家，Event 是一場有時間地點的活動。

本頁的範例只寫在程式碼區塊裡

這一頁不是門市頁也不是活動頁，所以 檔頭沒有真的注入這兩種標記。標記不存在的商家或活動是 結構化資料的政策紅線 。

LocalBusiness ​

json
{
  "@context": "https://schema.org",
  "@type": "CafeOrCoffeeShop",
  "name": "某某咖啡 信義店",
  "image": ["https://example.com/store-1200.jpg"],
  "url": "https://example.com/stores/xinyi",
  "telephone": "+886-2-1234-5678",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "信義路五段 7 號",
    "addressLocality": "信義區",
    "addressRegion": "台北市",
    "postalCode": "110",
    "addressCountry": "TW"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 25.033976,
    "longitude": 121.564472
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday", "Sunday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}

用更精確的子型別 ​

LocalBusiness 有大量子型別，用具體的那一個比用通用的好：

子型別適用
Restaurant餐廳
CafeOrCoffeeShop咖啡店
Store零售店
ClothingStore服飾店
Dentist、MedicalClinic診所
HairSalon美髮
AutoRepair汽車維修
RealEstateAgent房仲
ProfessionalService專業服務（找不到更精確的時）

找不到完全對應的就用 LocalBusiness

Schema.org 的子型別清單很長但不可能涵蓋所有行業。找不到貼切的就用 LocalBusiness 本身，那完全合法。

address 的欄位 ​

json
"address": {
  "@type": "PostalAddress",
  "streetAddress": "信義路五段 7 號",
  "addressLocality": "信義區",
  "addressRegion": "台北市",
  "postalCode": "110",
  "addressCountry": "TW"
}
欄位台灣的對應
streetAddress路名與門牌號
addressLocality鄉鎮市區
addressRegion縣市
postalCode郵遞區號
addressCountry國家代碼，台灣是 TW

不要把整串地址塞進 streetAddress

json
// 錯誤：無法解析成結構化的地址
"streetAddress": "台北市信義區信義路五段 7 號"

// 正確：分欄填寫
"streetAddress": "信義路五段 7 號",
"addressLocality": "信義區",
"addressRegion": "台北市"

分欄的意義在於搜尋引擎能把它對應到地圖上的行政區。

addressCountry 用 兩個字母的 ISO 國碼，不是國名：

json
// 錯誤
"addressCountry": "Taiwan"
"addressCountry": "台灣"

// 正確
"addressCountry": "TW"

營業時間 ​

openingHoursSpecification 用陣列，每一筆是一組時段：

json
"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "08:00",
    "closes": "20:00"
  }
]

星期用 英文全名（也接受 Schema.org 的網址形式）：

Monday、Tuesday、Wednesday、Thursday、Friday、Saturday、Sunday

跨夜營業必須拆成兩段

json
// 錯誤：結束時間早於開始時間
{
  "dayOfWeek": ["Friday"],
  "opens": "22:00",
  "closes": "02:00"
}

// 正確：拆成兩筆
[
  { "dayOfWeek": ["Friday"], "opens": "22:00", "closes": "23:59" },
  { "dayOfWeek": ["Saturday"], "opens": "00:00", "closes": "02:00" }
]

午休時間也是同樣的處理，拆成上午與下午兩筆：

json
[
  { "dayOfWeek": ["Monday"], "opens": "09:00", "closes": "12:00" },
  { "dayOfWeek": ["Monday"], "opens": "13:30", "closes": "18:00" }
]

特殊營業時間 ​

國定假日或臨時調整用 validFrom 與 validThrough：

json
{
  "@type": "OpeningHoursSpecification",
  "opens": "00:00",
  "closes": "00:00",
  "validFrom": "2027-02-06",
  "validThrough": "2027-02-12"
}

opens 與 closes 都填 00:00 表示 當天休息。

geo 座標 ​

json
"geo": {
  "@type": "GeoCoordinates",
  "latitude": 25.033976,
  "longitude": 121.564472
}

不是必填，但能避免地址解析錯誤

地址本身就足以定位。填上經緯度的價值在於 巷弄內、新開發區、同名路段 這些地址容易解析錯的地方。

要注意數值必須準確，填錯會把使用者導到錯誤的位置，那比不填更糟。

priceRange ​

用貨幣符號的數量表示價位帶：

值意義
$平價
$$中價
$$$高價
$$$$高檔

也可以寫具體區間如 "NT$200-500"，但符號形式比較通用。

多家分店 ​

一家分店一個頁面，各自標記

每家分店有自己的網址、自己的 LocalBusiness 標記。這是最清楚的做法。

總公司的頁面用 Organization 並列出分支：

json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "某某咖啡",
  "url": "https://example.com",
  "department": [
    {
      "@type": "CafeOrCoffeeShop",
      "name": "某某咖啡 信義店",
      "url": "https://example.com/stores/xinyi"
    },
    {
      "@type": "CafeOrCoffeeShop",
      "name": "某某咖啡 中山店",
      "url": "https://example.com/stores/zhongshan"
    }
  ]
}

不要把所有分店塞在同一頁

那會讓搜尋引擎無法判斷「這一頁對應哪個地點」，也無法在使用者搜尋附近店家時給出正確結果。

分店頁面的網址設計見 SEO 友善的網址結構 。

與 Google 商家檔案的分工 ​

Google 商家檔案LocalBusiness 標記
維護位置Google 的平台自己的網站
對地圖與在地搜尋影響大影響較小
對官網的識別較弱確認官網與商家是同一實體
需要驗證是（明信片或電話）否

兩邊的資訊必須一致

商家檔案寫營業到 20:00、網站標記寫 18:00，這種不一致是負面訊號，也會讓使用者白跑一趟。

兩邊都做，並保持同步。 有分店的話，商家檔案的每個地點都要對應到網站上的分店頁。

Event ​

json
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "前端工程研討會 2027",
  "description": "一日的前端技術分享活動。",
  "image": ["https://example.com/event-1200.jpg"],
  "startDate": "2027-03-15T09:00:00+08:00",
  "endDate": "2027-03-15T17:00:00+08:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "某某會議中心",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "信義路五段 7 號",
      "addressLocality": "信義區",
      "addressRegion": "台北市",
      "postalCode": "110",
      "addressCountry": "TW"
    }
  },
  "organizer": {
    "@type": "Organization",
    "name": "某某科技",
    "url": "https://example.com"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/events/2027/tickets",
    "price": "1500",
    "priceCurrency": "TWD",
    "availability": "https://schema.org/InStock",
    "validFrom": "2027-01-01T00:00:00+08:00"
  }
}

必填與建議欄位 ​

欄位必要性說明
name必填活動名稱
startDate必填開始時間，建議帶時區
location必填地點
endDate建議結束時間
eventStatus建議活動狀態
eventAttendanceMode建議實體、線上或混合
image建議活動圖片
offers建議票務資訊
organizer建議主辦單位
performer選填表演者或講者

startDate 要帶時區

json
// 不夠明確：搜尋引擎可能用錯時區
"startDate": "2027-03-15T09:00:00"

// 明確
"startDate": "2027-03-15T09:00:00+08:00"

eventStatus ​

活動改期或取消時務必更新這個欄位：

值意義
https://schema.org/EventScheduled照原定計畫舉行
https://schema.org/EventPostponed延期（新日期未定）
https://schema.org/EventRescheduled改期（有新日期）
https://schema.org/EventCancelled取消
https://schema.org/EventMovedOnline改為線上舉行

改期時同時填 previousStartDate：

json
{
  "eventStatus": "https://schema.org/EventRescheduled",
  "previousStartDate": "2027-03-15T09:00:00+08:00",
  "startDate": "2027-04-20T09:00:00+08:00"
}

線上活動 ​

地點改成 VirtualLocation，並把出席模式標為線上：

json
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "線上技術分享會",
  "startDate": "2027-03-15T19:00:00+08:00",
  "eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
  "location": {
    "@type": "VirtualLocation",
    "url": "https://example.com/live/2027-03-15"
  }
}

實體與線上並行的活動同時提供兩種地點：

json
{
  "eventAttendanceMode": "https://schema.org/MixedEventAttendanceMode",
  "location": [
    {
      "@type": "Place",
      "name": "某某會議中心",
      "address": { "@type": "PostalAddress", "addressCountry": "TW" }
    },
    {
      "@type": "VirtualLocation",
      "url": "https://example.com/live/2027-03-15"
    }
  ]
}

活動結束後怎麼處理 ​

不要直接刪頁面

過期的活動頁面通常還有搜尋流量與外部連結。做法：

  1. 保留頁面，在上面明確標示「本活動已結束」。
  2. 加上前往最新活動的連結。
  3. 標記保留，但確認 endDate 已過。
  4. 系列活動可以把舊場次的 canonical 保持指向自己，用 內部連結 導向新場次。

直接回傳 404 會浪費那些累積的訊號，做法比較見 轉址與 HTTP 狀態碼 。

檢查清單 ​

LocalBusiness ​

項目標準
用最精確的子型別建議
address 分欄填寫必備
addressCountry 用兩字母國碼必備
營業時間跨夜已拆成兩段必備
geo 座標準確（若填寫）必備
一家分店一個頁面建議
與 Google 商家檔案的資訊一致必備

Event ​

項目標準
name、startDate、location 齊全必備
startDate 帶時區建議
改期或取消時更新 eventStatus必備
線上活動用 VirtualLocation必備
票價的 price 為純數字字串必備
過期活動不直接刪頁建議
通過 複合式搜尋結果測試建議

常見問題 ​

有了 Google 商家檔案還需要 LocalBusiness 標記嗎？

兩者互補。商家檔案是在 Google 的平台上直接維護資料，對地圖與在地搜尋的影響更大；網站上的標記則讓搜尋引擎確認您的官網與那個商家是同一個實體。兩邊的資訊必須一致，不一致反而是負面訊號。

營業時間要怎麼寫？

用英文星期名稱加上開始與結束時間，時間用 24 小時制。跨夜營業要拆成兩段，例如：晚上十點到凌晨兩點必須寫成兩筆規格，不能用結束時間小於開始時間的寫法。

多家分店要怎麼標？

每家分店各有自己的頁面與各自的標記，這是最清楚的做法。總公司的頁面用 組織型別 ，並可用 department 欄位列出各分店。把所有分店塞在同一頁會讓搜尋引擎無法對應到正確的地點。

地理座標一定要填嗎？

不是必填，地址就足以定位。但填上經緯度可以避免地址解析錯誤，對巷弄內或新開發區的地點特別有幫助。要注意經緯度必須準確，填錯會把使用者導到錯誤的位置。

線上活動要用什麼標記？

同樣用 Event 型別，但地點改成 VirtualLocation 並填上參加的網址，同時把 eventAttendanceMode 標為線上。實體與線上並行的活動可以同時提供兩種地點，並把模式標為混合。

延伸閱讀 ​

組織與網站 Organization 標記 代表圖組織與網站 Organization 標記JSON-LD 語法與驗證 代表圖JSON-LD 語法與驗證複合式搜尋結果測試 代表圖複合式搜尋結果測試結構化資料是什麼？ 代表圖結構化資料是什麼？

參考資料：Google 搜尋中心：本地商家結構化資料

Copyright © 2025-Present