SEO GUIDE
網站專欄 Q & A
站內優化

多分店 SEO 完整教學|連鎖店與多據點策略

從一家店擴張到 3 家、10 家、甚至 50 家分店,本地 SEO 不只是「把同樣的事情做 10 次」,而是本質上不同的問題。每多一家分店,您要面對的是獨立 GBP 管理、分店頁面內容如何不重複、URL 結構怎麼設計、Schema 怎麼標、評論怎麼分流、避免關鍵字蠶食——這些單店根本不會遇到的議題。本篇拆解多分店 SEO 的完整策略,從每家分店是否要有獨立網頁、URL 結構選擇、分店頁面 11 項必備元素、Google Business Profile 批量管理、LocalBusiness Schema 多分店實作,到避免關鍵字蠶食的 3 個原則,協助台灣的連鎖店、區域型品牌、多分院診所建立可長期運作的多據點 SEO 系統。

一、多分店 SEO 為什麼比單店難 10 倍?

單店 SEO 的核心邏輯很單純:把 GBP 做完整、累積評論、官網設計好就行。多分店 SEO 多了三個維度的複雜性:

資料管理的規模問題

10 家分店等於 10 個 GBP、10 組 NAP、10 份營業時間、10 個評論流。光是每天回覆評論、處理特殊節日,人工作業量就是單店的 10 倍。

內容差異化的難題

每家分店要有獨立頁面,但內容服務又大致相同——怎麼寫得不重複?如果是模板套換城市名,Google 會視為「薄內容」反而影響整體網域評分。

關鍵字蠶食的風險

同一品牌的服務頁、分店頁、城市頁可能瞄準同一個「服務 + 城市」關鍵字,反而互相壓制。沒有清楚的內容分工,擴張越多反而排名越差。

三類型多分店業者的不同挑戰

業者類型 典型情境 核心 SEO 挑戰
區域型小型連鎖 3-5 家分店,集中在大台中或大台北 避免分店之間互相蠶食關鍵字、各分店評論流分開累積
跨縣市中型連鎖 10-30 家分店,跨多個縣市 批量管理 GBP、統一品牌但允許在地差異、Schema 母子結構建立
全國 / 跨國品牌 50+ 分店,連鎖加盟體系 GBP API 自動化、加盟主權限管理、不同分店主視覺一致性

關於 Google 商家檔案的單店完整設定,請參考Google 商家檔案完整設定教學;NAP 一致性的跨平台處理請看NAP 一致性教學;本地 SEO 整體架構回到SEO 基礎教學

二、每家分店都需要獨立網頁嗎?

答案是肯定的:每一家實體分店都必須有自己的獨立網頁(也稱為 location page 或分店頁)。這不是建議,而是多分店 SEO 的基本門檻。Google 近年的多次更新中持續強化這個訊號——沒有獨立頁面的分店,等於告訴 Google 您「沒有正式在那個位置經營」。

為什麼一定要獨立頁面?

  1. 作為 GBP 的目標連結頁 每個 GBP 都需要填寫「網站連結」,這個連結應該指向該分店的專屬頁面,不能全部指向首頁。Google 把 GBP 與該頁面的相關性視為信任訊號,首頁分散性太高、信任度被稀釋。
  2. 每家分店都能單獨被搜尋到 獨立頁面才能在搜尋結果中以該分店為主體出現。沒有獨立頁面,使用者搜尋「OO 拉麵 七期店」時,Google 沒有對應的頁面可以排名,只能呈現首頁(可能完全沒提到七期店),點擊率與轉換率都會大幅下滑。
  3. 承載分店專屬的 Schema 標記 每個分店需要自己的 LocalBusiness Schema(含該分店的地址、電話、營業時間、評論等)。Schema 必須掛在對應內容的頁面上,不能全部塞到首頁。
  4. 建立內部連結網絡 分店頁與服務頁、總部頁、其他相關內容之間的連結,構成一個讓 Google 理解「品牌結構」的網絡圖。獨立頁面是這個網絡的節點(node),缺少節點等於缺少網絡。

三種常見的錯誤做法

  • 把所有分店資訊塞進首頁 首頁列出 10 家分店的地址、電話、營業時間——對使用者勉強可用,但對 Google 來說一個頁面同時要為 10 個城市排名,主題模糊,結果是每個城市都排不上。改善方式:首頁保留「分店導引」連結,每家分店建立獨立頁。
  • 把分店資訊藏在下拉選單中,沒有獨立 URL 「點選分店看詳情」用 JavaScript 切換顯示,但 URL 不變——這樣的「分店資料」對 Google 來說等於不存在。Google 爬蟲只看到一個 URL,後面的切換內容不會被識別為獨立頁面。改善方式:每個分店用獨立 URL,可以保留下拉選單作為入口,但目的地必須是真實的獨立頁面。
  • 用樣板套換城市名生成幾十頁「假分店頁」 為了 SEO 在沒有真實營業的城市開頁面(例如台中有 1 家,但開了「台北店」「高雄店」「台南店」頁面引導加 LINE),這是 Google 明確抓的「薄內容」與「欺騙性內容」,會降低整個網域評分。改善方式:只為真實存在的實體分店建立頁面;若是服務區域型業務,改用「服務地區頁」並明確說明「我們從 OO 區出發到 XX 區服務」,而非偽裝成分店。

三、URL 結構建議:扁平 vs 巢狀

分店頁的 URL 結構是長期影響網站架構的決策。改一次成本很高(要做 301 redirect、可能短期掉排名),建議在分店還少時就規劃好。業界主流的兩種結構:

扁平結構(by city):適合多數情境

扁平 URL 結構 /locations/[城市]/

每個分店一個目錄,直接以城市名稱(或品牌統一識別碼)命名。適合各分店在不同城市、且每個城市只有 1 家的連鎖。台灣中小企業中最常見的結構。

/locations/taipei/、/locations/taichung/、/locations/kaohsiung/、/locations/tainan/

巢狀結構(by city + district):適合同城多店

巢狀 URL 結構 /locations/[城市]/[區域]/

城市層為一個「城市總覽頁」(列出該城市所有分店),下層才是個別分店頁。適合同一城市有多家分店的連鎖。

/locations/taipei/(台北分店總覽)、/locations/taipei/xinyi/(信義店)、/locations/taipei/dazhi/(大直店)、/locations/taichung/(台中分店總覽)、/locations/taichung/qiqi/(七期店)

常被誤用的 URL 模式

URL 結構 建議度 適用 / 不適用
/locations/taipei/ ★★★ 強烈推薦 扁平,語意清楚,適合多數連鎖
/locations/taipei/xinyi/ ★★★ 強烈推薦 巢狀,適合同城多店
/store/taipei/ ★★ 可用 store 而非 locations,語意稍弱但可接受
/taipei/ ★ 不建議 「taipei」直接在根目錄,容易與其他內容混淆,無法擴展
/taipei/store/ ★ 不建議 把城市放最前面,網站架構難以擴展(以後其他內容如何分類?)
/?store=taipei ✕ 避免 用查詢字串,Google 索引困難,且不利於 GBP 連結
/store-taipei.html ✕ 避免 所有分店擠在根目錄,擴展性差
實務建議:(1) 用 /locations//branches//stores/ 當父層目錄,語意明確且容易擴展;(2) 城市名用英文(taipei、taichung、kaohsiung)而非中文 URL encoded,可讀性與分享性都更好;(3) 區域名同樣用英文(xinyi、qiqi、bayi);(4) 同時準備「總覽頁」(/locations/)列出所有分店,方便使用者瀏覽選擇。

URL 確定後的注意事項

  • 不要再大改:URL 變動成本極高,要做 301 redirect、暫時掉排名、外部連結失效。在分店還少時就規劃好。
  • 結尾斜線統一:選擇「都用 / 結尾」或「都不用 / 結尾」,並用 301 redirect 統一(避免 Google 視為兩個不同頁面)。
  • 大小寫統一:都用小寫,避免 /Taipei//taipei/ 並存。

四、分店頁面 11 項必備內容元素

每個分店頁的內容如果只是「換個城市名 + 換個地址」,Google 會視為薄內容。實務上的目標:每頁 60-70% 內容是該分店獨特的。以下 11 項必備元素,前 8 項是基本門檻,後 3 項是進階差異化。

必備 8 項(每個分店頁都要有)

  1. 分店名稱(含 H1 標題) 「OO 拉麵 七期店」這種格式。H1 不能寫成「分店頁」「Location」這類無意義詞,要明確包含「品牌 + 分店識別」。
  2. 該分店的完整 NAP 地址(精準到號到樓)、電話、Email——這三項要與 GBP 一字不差。建議在頁面顯眼位置(如頁首或側欄)固定顯示。
  3. 營業時間(含特殊時段) 常規時間 + 國定假日 + 該分店特殊時段(例如「七期店週一公休」)。寫法上要清楚分清楚,避免與其他分店混淆。
  4. 嵌入式 Google 地圖 從 Google 地圖取得 embed code 嵌入。每個分店嵌入該分店自己的地圖,而不是所有分店都嵌入總公司地圖。這直接強化 Schema 的 hasMap 屬性。
  5. 交通與停車資訊 「捷運 XX 站 2 號出口走路 5 分鐘」「店門口提供 3 個停車位、附近捷運停車場步行 3 分鐘」這類內容是真實在地價值,非常難以複製貼上,且使用者高度需要。
  6. 該分店提供的服務 / 商品 如果不同分店提供的服務範圍不同(例如七期店有「外送」、信義店有「包場」),要明確標示。即使服務相同,文字描述要稍有變化避免完全複製。
  7. 該分店的「行動鈕」 「立即電話」「導航前往」「LINE 加好友」「線上預約」——每個按鈕都連到該分店的對應資源(不是總公司客服)。
  8. 該分店的 LocalBusiness Schema JSON-LD 格式,包含該分店的所有 NAP 與營業時間。詳細實作請看第 6 章。

進階差異化 3 項(讓分店頁脫離薄內容)

  1. 該分店的員工 / 主廚 / 醫師照片 放分店實際團隊照,不要用 stock photo,也不要全分店用同一張集團照。每個分店有自己的人,顧客也想知道「會服務我的人是誰」。這是 Google 認為的「在地真實性訊號」。
  2. 該分店的精選評論 從 Google 評論中挑 3-5 則最具該分店特色的評論引用顯示。注意:必須在頁面標示「來自 Google 評論」,並連結到原評論;不可虛構或修改。AI 搜尋會引用這些評論的具體內容。
  3. 該分店的在地特色內容 這是最關鍵也最被忽略的元素:寫該分店真正獨有的故事——什麼時候開幕、為什麼選這個地點、附近的地標、季節活動、與在地的連結。例如「七期店開在 2018 年,是大台中首家全素拉麵專門店,附近有國家歌劇院、新光三越,週末常見家庭聚餐」。這類內容無法複製、Google 喜歡、AI 摘要也會引用。

分店頁的差異化不是寫作技巧,而是「您的分店真的有差異嗎?」每家分店真實的故事、團隊、地理位置、顧客樣貌,都是內容資產。把這些挖出來寫,自然不會重複。

五、Google Business Profile 多分店管理

Google 對多分店管理有完整的層級設計,但很多老闆只用「個人帳號逐一登入」的最笨方法。以下是 Google 官方提供的三層架構,以及不同規模適用的工具。

三層帳號架構

個人帳號(Personal Account)

員工個人的 Google 帳號。可以被授權加入位置群組,但不應該直接擁有店家檔案(員工離職就失去管理權)。

使用者群組(User Group)

把多個個人帳號組成群組,統一管理權限。例如「七期店所有員工」「全國行銷團隊」。一次調整群組權限等於同步調整所有成員。

位置群組(Location Group)

把多個分店組成群組,可批量管理。可以按連鎖品牌、區域、業態分群。一個分店可以同時屬於多個位置群組。

不同規模適用的管理方式

分店數量 推薦管理方式 關鍵注意
1-9 家 business.google.com 手動管理 用「公司專用 Gmail」當所有店的擁有者,加入店長個人帳號為「管理員」權限
10-49 家 啟用 Bulk Management(批量管理)+ 試算表上傳 需符合 Google 品質指南,可一次上傳所有分店資料、批量驗證
50+ 家 Google Business Profile API(程式化管理) 需技術人員開發,可自動同步 CRM、推送節日特殊時間、批量回覆評論
連鎖加盟 位置群組 + 加盟主授權階層 總部保留「策略決策」(類別、品牌名稱),分店保留「即時更新」(營業時間、評論回覆)
注意:服務區域型業務(到府維修、家教等沒有實體店面的業者)無法使用 Bulk Verification,每個分點要個別驗證。此外,目前 Google 越來越常要求影片驗證作為 Bulk 流程的一部分——由授權代表親自到其中一個分店現場視訊或上傳影片。提交批量請求前,要先安排好這個流程。

多分店 GBP 命名規則

連鎖品牌的 GBP 名稱命名,Google 政策允許「品牌名 + 分店識別」格式,但禁止加描述詞。建議規則:

  • ✓ 推薦:「品牌名 + 空格 + 分店識別」,例如「新視野 七期店」「新視野 信義店」
  • ✓ 推薦:用真實在地地名而非自編識別碼(七期店、士林店,而非「A-001 店」「Z-1 號店」)
  • ✕ 禁止:加描述詞「新視野 七期店 - 台中最大」
  • ✕ 禁止:加優惠促銷「新視野 七期店 開幕 8 折」
  • ✕ 禁止:加業種描述「新視野 七期 牙醫植牙專家」

各分店電話策略

每家分店建議使用該分店專屬的電話號碼,不要全部使用總公司客服。原因:

  • NAP 一致性訊號:每分店有獨立電話,Google 才能正確判斷它們是「不同實體」。
  • 使用者體驗:顧客打電話想找「七期店問訂位」,直接接通該分店比較好。
  • 排名訊號分流:每個電話累積的通話量,是該分店的 Behavioral Signal,有助於各分店各自的排名。

若預算不允許每個分店有獨立市話,可以申請「主號 + 分機」格式,但每個 GBP 仍要分別填入,讓 Google 識別為獨立號碼。

六、LocalBusiness Schema 多分店實作

多分店的 Schema 結構比單店複雜,要建立母組織 + 子分店的層級關係。Google 從這個結構理解「這是同一品牌的不同實體」,而不會誤判為「重複內容」或「不相關的店家」。

多分店 Schema 結構原則

  1. 首頁:Organization + subOrganization 首頁用 Organization 作為主類型,在 subOrganization 屬性中列出所有分店。如果首頁本身沒有實體地址(例如純品牌官網),用 Organization 而非 LocalBusiness。
  2. 每個分店頁:LocalBusiness + parentOrganization 每個分店頁用 LocalBusiness(或更精確的子類型,如 Restaurant、Dentist、AutoRepair),在 parentOrganizationbranchOf 屬性中回連到首頁的 Organization。
  3. @id 屬性必須唯一 每個分店要有獨立的 @id(通常用該分店的 URL + Schema 類型),這是讓 Google 區分不同實體的關鍵。
  4. hasMap 屬性用 Google Maps URL 指向該分店的 Google Maps 連結,而非 GeoCoordinates(後者可被使用者改動,穩定性低)。

首頁 Schema 範例

假設「新視野咖啡」有 3 家分店(七期店、信義店、博愛店),首頁(newscan-coffee.com.tw)的 Schema 結構:

JSON-LD | 首頁(Organization)
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://newscan-coffee.com.tw/#organization",
  "name": "新視野咖啡",
  "url": "https://newscan-coffee.com.tw/",
  "logo": "https://newscan-coffee.com.tw/logo.png",
  "sameAs": [
    "https://www.facebook.com/newscancoffee",
    "https://www.instagram.com/newscancoffee/"
  ],
  "subOrganization": [
    { "@id": "https://newscan-coffee.com.tw/locations/taichung/qiqi/#localbusiness" },
    { "@id": "https://newscan-coffee.com.tw/locations/taipei/xinyi/#localbusiness" },
    { "@id": "https://newscan-coffee.com.tw/locations/taipei/boai/#localbusiness" }
  ]
}

分店頁 Schema 範例

七期店頁面(newscan-coffee.com.tw/locations/taichung/qiqi/)的 Schema:

JSON-LD | 分店頁(LocalBusiness)
{
  "@context": "https://schema.org",
  "@type": "CafeOrCoffeeShop",
  "@id": "https://newscan-coffee.com.tw/locations/taichung/qiqi/#localbusiness",
  "name": "新視野咖啡 七期店",
  "parentOrganization": {
    "@id": "https://newscan-coffee.com.tw/#organization"
  },
  "url": "https://newscan-coffee.com.tw/locations/taichung/qiqi/",
  "telephone": "+886-4-2301-XXXX",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "公益路 168 號 3 樓",
    "addressLocality": "西屯區",
    "addressRegion": "台中市",
    "postalCode": "407",
    "addressCountry": "TW"
  },
  "hasMap": "https://maps.google.com/?cid=XXXXXXXXXXXXX",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "10:00",
      "closes": "21:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday", "Sunday"],
      "opens": "09:00",
      "closes": "22:00"
    }
  ],
  "image": "https://newscan-coffee.com.tw/img/qiqi-store.jpg",
  "priceRange": "$$"
}

關鍵屬性說明

屬性 用途 注意事項
@type 定義店家類型 盡量用具體子類型(RestaurantDentistCafeOrCoffeeShop),而非僅用 LocalBusiness
@id 唯一識別碼 建議用該頁 URL + Schema 類型,例如 /locations/qiqi/#localbusiness
parentOrganization 連結回母品牌 用首頁 Organization 的 @id,讓 Google 理解品牌結構
hasMap 該分店地圖連結 使用 Google Maps URL(含 CID 號碼),比 GeoCoordinates 穩定
address 該分店地址 用 PostalAddress 結構,addressLocality 為「區」、addressRegion 為「縣市」
openingHoursSpecification 該分店營業時間 不同時段用陣列分開寫,週日週六若不同要分開
sameAs 連到品牌社群 放在 Organization 即可,各分店通常共用品牌社群
提示:(1) Schema 寫好後,用 Google Rich Results Test 驗證沒有錯誤;(2) 一個頁面可以掛多個 Schema(LocalBusiness + BreadcrumbList + FAQPage 等),不衝突;(3) Schema 改動後,Google 重新爬取與套用通常需要 1-2 週;(4) 若使用 WordPress,Yoast SEO、Rank Math 等外掛都支援 LocalBusiness Schema 自動生成。

取得 hasMap 用的 CID 號碼

CID(Customer ID)是 Google 給每家店的唯一識別碼。取得方式:

  1. 在 Google 地圖搜尋您的分店 搜尋「您的品牌 + 分店名」,點開該店的知識面板。
  2. 複製分享連結 點「分享」→ 複製連結。連結中包含一段長英數字組合(類似 !1s0x...:0x...)。
  3. 用線上工具轉換 把該連結貼入 Pleper(pleper.com/index.php?do=tools_google_cid_converter)或類似工具,轉出 CID 號碼。
  4. 組合 hasMap URL 格式:https://maps.google.com/?cid=您的CID號碼(數字格式,不是英數字)。把這個 URL 填入 Schema 的 hasMap 屬性。

七、避免關鍵字蠶食的 3 個原則

關鍵字蠶食(Keyword Cannibalization)是多分店 SEO 最常見的隱形殺手——同一個品牌的不同頁面互相搶同一個關鍵字,結果每頁都拿不到好排名。Google 不知道該推薦哪個給使用者,只好都壓下去。

蠶食的典型場景

假設「新視野咖啡」有三個頁面都涉及「台中咖啡廳」:

  • 首頁:標題「新視野咖啡 - 台中咖啡廳推薦」
  • 服務頁 /services/coffee/:標題「我們的精選咖啡 - 台中咖啡廳」
  • 分店頁 /locations/taichung/:標題「新視野咖啡 台中分店」

三個頁面都瞄準「台中咖啡廳」這個關鍵字,Google 看到一個品牌、三個頁面、同一個目標——只能挑一個排前面,其他兩個壓下去。最差的情況是每個頁面都只能勉強到第 4-6 名,看起來像「都做了 SEO 但都沒效果」。

避免蠶食的 3 個原則

  1. 服務頁聚焦業種,分店頁聚焦該分店 服務頁瞄準「精品咖啡」「手沖咖啡」這類業種關鍵字(不含城市);分店頁瞄準「新視野咖啡 七期店」「七期咖啡廳」這類分店關鍵字(含具體分店識別)。各自有清楚的目標,不互搶。
    服務頁 H1:「精品手沖咖啡的職人堅持」;分店頁 H1:「新視野咖啡 七期店 - 西屯區的咖啡選擇」。兩者完全不搶。
  2. 建立「總覽頁」吸收城市層流量 如果城市內有多家分店,設立「城市總覽頁」(/locations/taipei/)瞄準「台北分店」「台北咖啡廳」這類關鍵字,從這頁分流到信義店、大直店、士林店等子頁。城市層只有一個頁面在戰場上,內部結構清楚。
  3. 用 Title 與 H1 明確差異化 每個頁面的 <title><h1> 是 Google 判斷頁面焦點的主要依據。寫的時候強制要求每個頁面的 title 不重複。實務做法:用試算表列出所有頁面的 title,看哪些有重複,修正到全部唯一。

蠶食自我檢查表

  • site:yourdomain.com.tw 關鍵字 在 Google 搜尋,看哪些頁面出現。若 3 個以上頁面都出現,有蠶食風險。
  • 檢查 Google Search Console 的「成效報告 → 頁面」,同一個關鍵字若有多個頁面有曝光,代表蠶食。
  • 每季用試算表盤點所有頁面的 title 與 H1,確認沒有兩頁瞄準同關鍵字。
  • 新增分店頁時,先確認 title 與 H1 沒有與既有頁面衝突。

八、多分店 SEO 常見地雷

以下整理多分店業者最常踩的地雷,以及對應的改善方式。

  • 所有分店頁套同一個模板,只換城市名 這是 Google 演算法明確抓的「薄內容」。內容相似度超過 80% 的多個頁面,會被視為複製。改善方式:每個分店至少 60-70% 內容是該分店獨特的——員工、停車、評論、在地特色、歷史故事都是好素材。
  • 所有分店共用一個 GBP 把 3 家店的資訊塞進一個 GBP,Google 不知道每家店在哪。改善方式:每個實體分店都要有獨立的 GBP,各有各的評論、地址、電話、營業時間。
  • 分店頁面 URL 設計不一致 台北用 /store-taipei/、台中用 /locations/taichung/、高雄用 /?city=kaohsiung——結構不一致讓 Google 難理解網站架構。改善方式:在分店少時就統一規劃 URL 結構,用 301 redirect 把舊格式轉到新格式。
  • 總公司客服電話寫在每個分店頁 每個分店頁都印「客服:0800-XXX-XXX」,沒有該分店的直撥電話。改善方式:每個分店頁顯眼位置放該分店電話,客服電話可放在頁尾或聯絡頁。
  • 在沒有真實營業的城市開「假分店頁」 為了搶搜尋曝光,在沒有實際分店的城市建立頁面引導加 LINE。Google 已明確將其列為「欺騙性內容」,被偵測會大幅降低整個網域評分。改善方式:服務區域型業務改用「服務地區頁」明確標示「我們從 OO 區出發到 XX 區服務」,而非偽裝成分店。
  • 每家分店都連回首頁,但分店之間沒互連 分店頁全部只連回首頁,沒有「相關分店」連結結構。Google 因此無法判斷「同品牌的不同分店」的關係。改善方式:在每個分店頁底部加「品牌其他分店」區塊,列出 3-5 家鄰近分店連結。
  • 擴張到新城市時忘了同步建立新分店頁 開了實體店,但官網沒新增對應頁面、GBP 也沒建立——等於開了店卻沒告訴 Google。改善方式:把「新分店上線」納入標準作業流程:GBP 建立 → 官網分店頁 → Schema 補上 → 評論流啟動 → 同步首頁的 subOrganization 列表。
參考來源:Google Business Profile API 開發者文件(developers.google.com/my-business)、Google 商家檔案說明中心(support.google.com/business)、Schema.org LocalBusiness 規範、Whitespark 與 BrightLocal 多分店 SEO 研究、Entrepreneur 雜誌多分店 SEO 報導、Search Engine Journal 與 Schema App 多位置結構化資料指南。

常見問答 FAQ

我只有 2-3 家分店,需要做完整的多分店 SEO 嗎?還是簡單做就好?
需要完整做,但不必過度複雜化。2-3 家分店的規模,核心原則與大型連鎖完全一樣,只是執行的工具與規模不同。實務建議:(1) 每家分店要有獨立 GBP + 獨立網頁 + 獨立 Schema——這三項是基本門檻,不能省;(2) URL 結構選擇扁平結構(/locations/[城市]/)即可,簡單明確;(3) GBP 管理可以從 business.google.com 手動操作,3 家還不需要 API 或進階工具;(4) 評論回覆指定 1 位主管統籌即可,不必設置複雜的權限階層;(5) 重點放在「分店頁的差異化內容」——3 家分店各自寫好獨特的在地故事、員工、停車、評論,比 30 家分店都套模板效果好得多。台灣實務上很多 2-3 家分店的中小企業,常見錯誤是「以為小所以可以省」結果反而沒做好基礎,擴張到第 4、5 家時整個結構需要重做。趁分店還少時把基礎建好,擴張時只要套用既有架構即可,長期省下大量工。
分店頁的內容差異化很難做,服務都一樣怎麼寫得不重複?
差異化不在「服務本身」,而在「該分店的真實情境」。當您試圖用「換個城市名」做差異化會失敗,但用以下角度切入,自然就會有獨特內容:(1) 地理與交通:該分店附近的捷運站、地標、停車狀況、周邊商家——這些每個分店都不同;(2) 該分店的員工:店長介紹、主廚經歷、設計師專長,真實照片配真實故事;(3) 該分店的歷史:何時開幕、為什麼選這個位置、開幕時的故事、最受歡迎的客群;(4) 該分店的精選評論:挑 3-5 則該分店的 Google 評論放在頁面,並引用,評論本身就是差異化內容;(5) 該分店的營業特色:可能該分店週末開到比較晚、有提供包場、有提供素食選項——找出與其他分店不同的細節;(6) 季節活動:該分店參與在地活動、附近商圈活動、節日特殊安排。把這 6 個維度填進去,每分店頁自然就有 60-70% 獨特內容。差異化不是「想」出來的,是「寫出真實情況」自然得到的
如果我是區域加盟連鎖,加盟主可以自己管理他的分店 GBP 嗎?
可以,而且強烈建議。但需要設計好「總部 vs 加盟主」的權限分工。實務建議的分層:(1) 總部保留決策權的欄位:商家名稱(品牌一致性)、主類別、品牌 logo、品牌官網連結——這些統一由總部管理,加盟主只能讀不能改;(2) 加盟主管理的日常欄位:該分店的營業時間、特殊時段、照片、貼文、評論回覆、Q&A——這些必須讓加盟主能即時更新,等總部反而會延誤;(3) 共同管理的欄位:商家描述(框架由總部訂,具體文字由加盟主填)、服務項目(目錄由總部定,實際提供由加盟主勾選)。Google 提供的「位置群組 + 使用者群組」架構正是為此設計:總部建立位置群組(包含所有分店),加盟主以個人帳號加入該分店的權限,可以管理但不能刪除。連鎖總部建議建立「加盟主 GBP 操作手冊」,明確列出哪些可以改、哪些不能改、改了會發生什麼,避免好心做錯事。每季由總部抽查,確保品牌一致性沒被破壞。
LocalBusiness Schema 與 Organization Schema 有什麼差別?多分店要用哪個?
兩者是 Schema.org 中的不同類型,在多分店情境中有明確的搭配規則:(1) Organization 表示「一個組織、品牌或公司」,可以是純品牌(沒有實體地點)或多分點的母公司。多分店情境中,Organization 用在首頁,代表整個品牌;(2) LocalBusiness 是 Organization 的子類型,表示「一個具體的實體營業點」。多分店情境中,LocalBusiness 用在每個分店頁。兩者用 subOrganization(從母指向子)與 parentOrganizationbranchOf(從子指回母)互相連結,構成完整的層級。如果您的首頁本身也是實體店面(例如總店就是首頁地址),首頁可以用 LocalBusiness 而非 Organization。另外,LocalBusiness 有許多更精確的子類型(如 RestaurantDentistAutoRepairCafeOrCoffeeShop),用最精確的子類型訊號最強。實務上建議:Schema 寫好後用 Google Rich Results Test 驗證,確認 Google 能正確識別您的結構。
同一個城市有 2 家以上分店,要建立「城市總覽頁」嗎?
強烈建議建立,而且這是台灣中小企業最常漏的一步。城市總覽頁(例如 /locations/taipei/)的功能與價值:(1) 吸收城市層流量:使用者搜尋「台北 OO」「OO 台北分店」這類關鍵字時,Google 需要一個對應的頁面排名。沒有總覽頁,就會是 4-5 個分店頁互相蠶食(誰都排不好);有了總覽頁,流量集中到一頁,排名穩定。(2) 給使用者選擇導引:顧客知道您在台北有分店但不確定哪一家近——總覽頁讓他們在一個頁面看到所有選項(附地圖、地址、特色),選好後再點進子頁。(3) 強化內部連結結構:總覽頁是「首頁 → 城市 → 分店」階層中的中間節點,Google 從這層結構理解您的網站架構。實作建議:總覽頁包含「該城市分店列表 + 互動式地圖 + 各分店簡介 + 該城市特色內容」,目標 800-1500 字。重要:總覽頁的 Title 寫「台北分店」「台北據點」,不要寫「台北咖啡廳」(會與分店頁蠶食)。
多分店的評論該如何分流?顧客留評沒指定哪家分店怎麼辦?
每家分店都有獨立的 GBP,所以評論自動分流:顧客在 Google 地圖搜尋「OO 拉麵 七期店」,點進去留評,該評論就只會出現在七期店的 GBP。前提是每家分店有獨立 GBP,如果您把所有分店塞進一個 GBP,評論就全混在一起。實務上常見的問題:(1) 顧客在「品牌名」搜尋而非「分店名」,留評到錯誤分店:這是無法完全避免的,但可以引導——在桌牌、收據、結帳區放該分店的 QR Code(從該分店 GBP 取得專屬短連結),讓顧客掃這個 QR Code 留評,自動進到正確分店。(2) 明顯留錯分店的評論:可以申請檢舉「off-topic」(內容與該分店無關),但成功率不高,實務上更建議的做法是「在回覆中溫和釐清」(「謝謝您的評論,您描述的應該是我們大直店的體驗,我們會把回饋轉給該店長」)。(3) 負責人分流:每家分店指定一位主管負責回覆評論,48 小時內回。建議用 Google 商家檔案 App 開啟通知,有新評論即時收到推播。
分店搬遷或關店,網頁與 GBP 該怎麼處理?
兩種情境處理方式不同,要分開看:(1) 分店搬遷(地址改變):GBP 的處理請參考NAP 一致性教學的「搬遷 SOP」段落——直接從原 GBP 改地址,不要刪除重建(會失去評論)。網頁部分,如果新地址在同城市,可保留原 URL 直接更新內容;如果跨縣市,建議建立新分店頁(新 URL),原頁面用 301 redirect 到新頁,並在新頁顯眼標示「本店原位於 OO,於 X 月 X 日搬遷至此」幫助老顧客找到新店。(2) 分店永久關店:GBP 設定為「永久歇業」(在 GBP 後台的「設定」中操作),不要刪除 GBP——保留它讓 Google 知道這家店「曾經存在但已歇業」,而不是「消失」。網頁處理有三個選項:(a) 保留頁面但顯眼標示「已歇業」+ 引導到最近的其他分店;(b) 用 301 redirect 到城市總覽頁;(c) 刪除頁面但用 410 狀態碼回應。最不建議的是「直接刪掉頁面但不處理 301」,會留下 404 錯誤,長期影響網站健康度。
我經營到府服務(沒有實體店),但服務範圍涵蓋全台北,要算多分店嗎?
不是多分店,是「服務區域型業務 + 多區內容布局」,完全不同的策略。多分店需要實體據點,而到府服務沒有實體分店,如果為了 SEO 在每個區「假裝」開分店,會被 Google 判定為欺騙性內容大幅扣分。正確的策略:(1) GBP 設定為服務區域型:選擇「服務區域(Service Area)」,指定您願意到府的最多 20 個區域(信義、大安、中山、士林、北投等),GBP 上不公開實體地址;(2) 官網建立「服務地區頁」:可以用類似 /areas/xinyi//areas/daan/ 的 URL 結構,但必須明確標示「我們從 OO 區出發到 XX 區服務」,而非偽裝成有實體據點。內容要寫該區的真實案例、該區的服務時間(交通考量)、該區的常見需求等;(3) 跨區累積評論:每完成一個案件,結案後請該區顧客留 Google 評論,半年後評論者地址分布於各區,Google 會推斷您真的服務這些區域。這個做法與多分店的差別在於:多分店是「真的有 5 個實體店」,服務區域是「一個營運基地服務 5 個區」。Google 對這兩者有明確的政策分流,千萬不要混用,被偵測會直接停權。

歡迎推廣本文,請務必連結(LINK)本文出處:新視野網頁設計公司