GitHub 上大約有 2,000 個儲存庫 符合「google maps scraper」。但其中大多數都已經失效了。
這聽起來很誇張，不過如果你曾經 clone 過 repo、跟 Playwright 依賴項纏鬥過，還在凌晨 2 點看著爬蟲吐出空白 CSV，你大概就懂那種感覺。Google Maps 全球有 超過 2 億筆商家列表——它是地球上最完整的在地商家資料庫之一。難怪從業務開發到代理商老闆，大家都想把這些資料抓下來。問題在於，Google 會以數週到數月的頻率調整 Maps 介面，而每一次改動都可能悄悄弄壞你才花一小時設好的爬蟲。就像一位 GitHub 使用者在 2026 年 3 月的 issue 裡說的，這個工具 「could not find search box on google maps.」 這不是冷門邊緣案例，而是核心流程直接壞掉。我今年一直密切追蹤這些 repo，發現「GitHub 上看起來很活躍」和「今天真的能抓到資料」之間的落差，比多數人想像得還大。這篇指南是我誠實整理訊號與雜訊的嘗試——會說明哪些 repo 能用、哪些會壞、什麼時候該直接跳過 GitHub，以及抓完資料後接下來該怎麼做。
GitHub 上的 Google Maps 爬蟲是什麼？為什麼大家會用？
GitHub 上的 Google Maps 爬蟲通常是 Python 或 Go 腳本（有時包在 Docker 裡），會在無頭瀏覽器中開啟 Google Maps，輸入像「芝加哥的牙醫」這類搜尋詞，然後擷取畫面上顯示的商家列表資料——名稱、地址、電話、網站、評分、評論數、分類、營業時間，有時還包括經緯度。
GitHub 會成為這類工具的預設據點，原因很簡單：程式碼免費、開源，而且理論上還能自行客製。你可以 fork 一個 repo、調整搜尋參數、加上自己的 proxy 邏輯，並匯出成你需要的任何格式。
大家通常想抓的資料欄位大致如下：
| 欄位 | 在各 repo 中的常見程度 |
|---|---|
| 商家名稱 | 幾乎必備 |
| 地址 | 幾乎必備 |
| 電話號碼 | 幾乎必備 |
| 網站 URL | 幾乎必備 |
| 星等評分 | 幾乎必備 |
| 評論數 | 非常常見 |
| 分類／類型 | 常見 |
| 營業時間 | 常見 |
| 緯度／經度 | 在較強的 repo 中常見 |
| Email／社群連結 | 只有爬蟲也會去造訪商家網站時才有 |
| 完整評論內容 | 在專門評論爬蟲中常見，但大規模爬取時較不穩定 |
誰會用這些工具？做外撥名單的業務團隊、分析在地市場的房地產專業人士、做競品分析的電商團隊、執行在地 SEO 稽核的行銷人員。共同點很簡單：他們都需要結構化的在地商家資料，而且不想一筆一筆從瀏覽器手動複製貼上。
為什麼業務與營運團隊會搜尋 Google Maps 爬蟲 GitHub repo
Google Maps 之所以有吸引力，原因很單純：在地商家資訊真的就在那裡。不是某個冷門目錄，不是在付費牆後面，而是直接放在搜尋結果裡。
這個商業價值主要可分成三大類。
名單開發與潛在客戶挖掘
這是最主要的用途。一位為自由工作者和代理商打造 Google Maps 爬蟲的創辦人，曾直白描述這個流程：在特定城市與利基市場找名單、蒐集冷開發聯絡資訊，並產出包含名稱、地址、電話、網站、評分、評論數、分類、營業時間、Email 與社群帳號的 CSV。 其中一個最活躍的 repo（gosom/google-maps-scraper）甚至直接告訴使用者，可以請它的 agent 「Find me all dentists in Berlin with their emails.」 這不是興趣型用途，而是銷售管道。
市場研究與競品分析
營運與策略團隊會用抓回來的 Maps 資料，按社區統計競爭者、分析評論情緒、找出市場缺口。一位在地 SEO 從業者曾 回報自己透過擷取 Google Maps 公開資料，審核了 76,228 家在地商家 。這種分析如果要靠人工大規模完成，幾乎不可能。
在地 SEO 稽核與名錄網站建置
行銷人員會抓 Google Maps 來稽核在地搜尋曝光、檢查 NAP（名稱、地址、電話）一致性，並建立目錄網站。有位使用者曾 描述將抓下來的 Google Maps 資料試算表匯入 WordPress，搭配 WP All Import 使用 。
為什麼抓取會讓人心動的勞動成本算術
就算是用瀏覽器視窗人工蒐集，也不是免費。Upwork 把行政資料輸入的虛擬助理報價放在 每小時 12–20 美元以上。如果一個人每家花 1 分鐘抓基本資訊，1,000 家就要約 16.7 小時——還沒做 QA 前，人工成本大約就是 200–334 美元。若每家花 2 分鐘，同樣名單的成本就變成 400–668 美元。這才是每一個「免費 GitHub 爬蟲」真正要對比的基準。
用 AI 抓取 Google Maps 資料 Get Started Free
Google Maps API、GitHub 爬蟲 repo、無程式碼工具：2026 年決策樹
在你 clone 任何東西之前，先選好路線。資料量、預算、技術能力，以及你能接受多少維護成本，都很關鍵。
| 評估標準 | Google Places API | GitHub 爬蟲 | 無程式碼工具（例如 Thunderbit） |
|---|---|---|---|
| 每 1,000 次查詢成本 | 7–32 美元（常見 Pro 呼叫） | 軟體免費 + proxy 成本 + 時間成本 | 有免費方案，之後按點數計費 |
| 資料欄位 | 結構化，但受 API schema 限制 | 彈性高，取決於 repo | 由 AI 針對各站點配置 |
| 取得評論 | 每個地點最多 5 則評論 | 可抓完整內容（若爬蟲支援） | 依工具而定 |
| 速率限制 | 每個 SKU 有免費上限，之後付費 | 自行管理（取決於 proxy） | 由供應商代管 |
| 法律清晰度 | 授權明確 | 灰色地帶（有 ToS 風險） | 供應商在營運上處理合規 |
| 維護 | Google 維護 | 你自己維護 | 供應商維護 |
| 設定複雜度 | API key + 程式碼 | Python + 依賴項 + proxies | 安裝擴充功能，點一下就抓 |
什麼時候適合用 Google Places API
如果你的查詢量是小到中等，而且你需要官方授權與可預測的帳單，那 API 很明顯是首選。Google 2025 年 3 月的價格調整 把原本通用的每月額度改成各 SKU 的免費上限：許多 Essentials SKU 有 10,000 次免費呼叫，Pro 有 5,000 次，Enterprise 有 1,000 次。之後，Text Search Pro 每 1,000 次收 32 美元，而 Place Details Enterprise + Atmosphere 則是每 1,000 次 5 美元。
最大的限制是評論。API 每個地點最多只會回傳 5 則評論。如果你需要完整評論內容，API 就不夠用了。
什麼時候適合用 GitHub 爬蟲
如果你要的是大量關鍵字加地理位置的探索、API 欄位之外的瀏覽器可見資料、完整評論文字，或自訂解析邏輯——而且你有能力用 Python/Docker 維護爬蟲，那 GitHub repo 會是正確選擇。代價是，所謂的「免費」只是把費用轉移成時間、proxy、重試和故障處理。光是 proxy 成本就可能累積：Decodo residential proxy 從每 GB 1 美元起，Bright Data datacenter 按量付費每 GB 0.6 美元，Oxylabs residential 則是每 GB 6 美元。
什麼時候適合用像 Thunderbit 這樣的無程式碼工具
如果你的團隊不懂技術？如果優先目標是盡快把資料送進 Sheets、Airtable、Notion 或 CSV？那無程式碼工具可以跳過整個 Python/Docker/proxy 設定流程。使用 Thunderbit，你只要安裝 Chrome 擴充功能、打開 Google Maps、點一下「AI Suggest Fields」，再點「Scrape」——然後就能 匯出到 Google Sheets、Excel、Airtable 或 Notion。雲端爬取模式會自動處理反機器人防護，且可 同時抓取最多 50 個頁面，不需要設定 proxy。
簡單決策流程： 如果你只需要少於 500 家商家，而且有預算 → 用 API。若你需要數千筆，而且會 Python → 用 GitHub repo。若你需要快速拿到資料、又不想做技術設定 → 用無程式碼工具。
2026 年新鮮度稽核：哪些 Google Maps 爬蟲 GitHub repo 今天真的能用？
這是我希望自己一開始做研究時就已經存在的章節。大多數「最佳 Google Maps 爬蟲」文章只會列 repo 名稱、簡短描述和星數，卻不會告訴你這東西這個月到底還能不能吐資料。
怎麼判斷一個 Google Maps 爬蟲 GitHub repo 還活著
在 clone 任何東西之前，先跑這份檢查清單：
- 最近是否有程式碼提交： 看最近 3–6 個月內是否有真正的 commit，不是只有 issue 留言。
- Issue 健康狀態： 看最近更新的 3 個 issue，內容是核心故障（空欄位、selector 錯誤、瀏覽器當機）還是功能需求。
- README 品質： 是否有完整文件說明目前的瀏覽器堆疊、Docker 設定與 proxy 配置。
- Issue 裡的警訊詞： 搜尋「search box」、「reviews_count = 0」、「driver」、「Target page」、「selector」、「empty」。
- Fork 與 PR 活動： 有活躍 fork 與已合併 PR，通常代表社群還在維護。
如果沒有近期程式碼活動、核心爬取 bug 也沒修，還沒有 proxy 或瀏覽器維護指引，那這個 repo 多半不夠活躍，不適合商業用途——即使星數看起來很漂亮。
評估過的熱門 Google Maps 爬蟲 GitHub repo
我依照上面的方法，評估了星數最高的一批 repo。以下是總表，後面會有個別說明。
| Repo | 星數 | 最近提交 | 2026 年還能用嗎？ | 能應對 UI 變動嗎？ | Proxy 支援 | 技術堆疊 |
|---|---|---|---|---|---|---|
| gosom/google-maps-scraper | 3.7k | 2026-04-19 | ⚠️ 核心擷取還活著；評論欄位不太穩 | 持續維護中 | 有，且明確 | Go + Playwright |
| omkarcloud/google-maps-scraper | 2.6k | 2026-04-10 | ⚠️ 應用活躍，但有當機／支援問題 | 由供應商維護 | 文件不夠清楚 | 桌面應用程式 / binary |
| gaspa93/googlemaps-scraper | 498 | 2026-03-26 | ⚠️ 只適合狹窄的評論爬取場景 | 證據有限 | 沒有明顯的 proxy 故事 | Python |
| conor-is-my-name/google-maps-scraper | 284 | 2026-04-14 | ⚠️ Docker 流程有潛力，但 3 月曾 selector 失效 | 有一些修復跡象 | 已 Docker 化，proxy 不明 | Python + Docker |
| Zubdata/Google-Maps-Scraper | 120 | 2025-01-19 | ❌ stale／空值欄位問題太多 | 幾乎沒證據 | 不太強調 | Python GUI |
| patxijuaristi/google_maps_scraper | 113 | 2025-02-24 | ❌ 訊號偏弱，舊的 Chrome driver 問題 | 幾乎沒證據 | 沒有強證據 | Python |
gosom/google-maps-scraper
目前是最強的開源通用型選擇。README 的成熟度異常高：CLI、web UI、REST API、Docker 指令、proxy 配置、grid／bounding-box 模式、Email 擷取，以及多種匯出目標。它聲稱可抓 33+ 種資料點，也明確寫了 proxy，因為「對於較大規模的爬取工作，proxy 有助於避免速率限制。」
缺點不是沒人維護，而是邊緣欄位的正確性漂移。2026 年的新 issue 顯示 "reviews_count" = 0、user_reviews 回傳空陣列，以及 open_hours 只寫出星期三。所以它在商家列表擷取上仍可信，但如果你要豐富的評論與營業時間資料，就還得等修復。
omkarcloud/google-maps-scraper
因為星數高、存在時間長，所以很顯眼，但它看起來比較像封裝好的 extractor 產品，而不是透明的 OSS——有支援管道、桌面安裝檔、加值服務。2026 年 4 月有位使用者說，應用程式啟動後終端機一直噴出 "Target page, context or browser has been closed" errors，最後卡住不動。另一個未解 issue 則抱怨工具 "Very slow and inefficient." 它不是死了，但對想要可檢視、可自行修補的 OSS 讀者來說，不算最乾淨的答案。
gaspa93/googlemaps-scraper
它不是那種通用的大規模搜尋名單爬蟲，而是一個專門的 評論爬蟲，從特定 Google Maps POI 評論 URL 出發，抓取近期評論，並支援 metadata 擷取與評論排序。這種較窄的定位其實對某些工作流程很有價值——但它沒有解決大多數商業使用者真正關心的「搜尋發現」問題。
conor-is-my-name/google-maps-scraper
很符合現代營運團隊的直覺：Docker 優先安裝、JSON API、商務友善欄位，還在 r/n8n 裡有社群曝光。不過 2026 年 3 月的 issue 正好示範了這類工具有多脆弱：某位使用者更新容器後，輸出顯示爬蟲 "could not find search box on google maps." 這是核心流程失敗，不是外觀層級的小問題。
Zubdata/Google-Maps-Scraper
紙面上它的欄位很廣：email、評論、評分、地址、網站、電話、分類、營業時間。實際上，公開 issue 區卻說了不同的故事：使用者回報 應用套件缺少資源檔、電話／地址／網站欄位為空值，以及 爬取限制。再加上較舊的提交歷史，很難推薦它作為 2026 年的選擇。
patxijuaristi/google_maps_scraper
在 GitHub 搜尋裡很容易找到，但最強的公開訊號是一個 舊的 Chrome driver 錯誤 issue，而不是活躍維護。它出現在這篇文章裡，主要是作為「搜尋上看起來還活著，但實務上很風險」的例子。
逐步教學：如何從 GitHub 設定一個 Google Maps 爬蟲
你已經決定 GitHub repo 是正確路線了嗎？那實際的設定流程大概會長這樣。我這裡會講通用流程，不綁定特定 repo——因為目前活躍選項的步驟其實驚人地相似。
步驟 1：克隆儲存庫並安裝相依套件
常見流程如下：
git clone該 repo- 建立 Python 虛擬環境（或拉取 Docker 映像）
- 透過
pip install -r requirements.txt或docker-compose up安裝相依套件 - 有時還要安裝瀏覽器執行環境（Playwright 用 Chromium、Selenium 用 ChromeDriver）
像 gosom/google-maps-scraper 和 conor-is-my-name/google-maps-scraper 這種 Docker 優先的 repo，可以減少相依套件地獄，但不會完全消失——你還是需要 Docker 正常運作，並且有足夠磁碟空間放瀏覽器映像。
步驟 2：設定搜尋參數
多數通用型爬蟲都會想要：
- 關鍵字 + 地點（例如「Austin TX 的水電工」）
- 結果上限（要抓多少筆）
- 輸出格式（CSV、JSON、資料庫）
- 有時還會支援 地理邊界框 或網格式探索的半徑設定
較好的 repo 會把這些做成 CLI 參數或 JSON request body。較舊的 repo 可能得直接修改 Python 檔案。
步驟 3：設定 proxies（如果需要）
只要不是很小的測試量，就會想用 proxies。gosom/google-maps-scraper 有文件說明 HTTP/HTTPS/SOCKS5 proxy 輪換，並明確把 proxies 視為大規模任務的標準解法。沒有它們的話，跑幾十次請求後就很可能遇到 CAPTCHA 或 IP 封鎖。
步驟 4：執行爬蟲並匯出資料
執行腳本，看瀏覽器走過結果卡片，然後等待 CSV 或 JSON 輸出。順利路徑只要幾分鐘；但不順的路徑——比任何人承認的都更常見——通常會出現：
- 瀏覽器意外關閉
- Chrome driver 版本不匹配
- selector／搜尋框失敗
- 評論數或營業時間回傳空白
步驟 5：處理錯誤與故障
當爬蟲回傳空結果或錯誤時：
- 查看該 repo 的 GitHub Issues，找有沒有類似回報
- 檢查是否是 Google Maps UI 變動（新的 selector、不同頁面結構）
- 更新到 repo 的最新 commit
- 如果維護者還沒修，看看 forks 有沒有社群補丁
- 想一想：與其除錯，是否改用其他工具更划算
實際的首次設定時間： 如果你熟悉終端機，但還沒有現成可用的 Playwright/Docker/proxy 環境，第一次成功抓取的現實範圍通常是 30–90 分鐘。不是 5 分鐘。
如何避免在抓 Google Maps 時被封鎖與速率限制
Google 沒有公開一個明確門檻說「你在 X 次請求後就會被封鎖」。Google 故意讓它不透明。有人回報在伺服器型 Playwright 設定下，大約 50 次自動化請求 後就遇到 CAPTCHA；也有人聲稱某個公司自建的 Maps 爬蟲在單一 IP 下每天可跑到 10,000 筆查詢。所以門檻不是高或低，而是不穩定、而且依情境而變。
下面是一張實用策略表：
| 策略 | 難度 | 效果 | 成本 |
|---|---|---|---|
| 隨機延遲（每次請求間隔 2–5 秒） | 容易 | 中等 | 免費 |
| 降低並行數（更少平行 session） | 容易 | 中等 | 免費 |
| residential proxy 輪換 | 中等 | 高 | 每 GB 1–6 美元 |
| datacenter proxy（用於較容易的目標） | 中等 | 中等 | 每 GB 0.02–0.6 美元 |
| 無頭瀏覽器指紋隨機化 | 困難 | 高 | 免費 |
| 瀏覽器持久化／暖機 session | 中等 | 中等 | 免費 |
| 雲端爬取（把問題外包） | 容易 | 高 | 視方案而定 |
在請求間加入隨機延遲
固定 1 秒間隔很可疑。要用隨機抖動——動作之間隔 2 到 5 秒，偶爾再加長暫停。這是你最容易做的一件事，而且完全不用花錢。
旋轉 proxies（residential vs. datacenter）
residential proxies 效果更好，因為它們看起來像真實使用者，但成本也更高。最新價格： Decodo residential 每 GB 1 美元起、Oxylabs residential 每 GB 6 美元、Oxylabs datacenter 每 GB 0.59 美元。datacenter proxies 可以應付輕量爬取，但在 Google 旗下產品上更容易被標記。
隨機化瀏覽器指紋
對無頭瀏覽器爬蟲來說：輪換 user agent、視窗大小和其他指紋訊號。預設的 Playwright／Puppeteer 設定很容易被偵測。這做起來較難，但免費，而且效果很好。
用雲端爬取把問題外包出去
像 Thunderbit 這類工具，會透過雲端爬取基礎設施，自動處理反機器人防護、IP 輪換與速率限制。Thunderbit 在雲端模式下可 同時抓取最多 50 個頁面——不需要設定 proxy 或延遲。對不想變成兼職反機器人工程師的團隊來說，這是最實際的路線。
Google 的速率限制實際上會長什麼樣子
你被限流的跡象包括：
- 爬取中途出現 CAPTCHA
- 之前成功的查詢突然變成空結果
- 暫時性 IP 封鎖（通常 1–24 小時）
- 頁面載入品質下降（變慢、內容不完整）
恢復方式：停止爬取、輪換 IP、等 15–60 分鐘，再用更低的並行數繼續。如果你經常碰到限制，表示你的設定需要 proxies，或者根本該換方法。
無程式碼退路：什麼時候 GitHub 的 Google Maps 爬蟲不值得你花時間
大約 90% 談 Google Maps 抓取的文章，都假設你會 Python。但很多讀者——代理商老闆、業務、在地 SEO 團隊、研究人員——其實只需要試算表中的一排排資料，不是瀏覽器自動化專案。如果你是這類人，這一節會誠實談清楚取捨。
「免費」GitHub 爬蟲的真實成本
| 因素 | GitHub repo 做法 | 無程式碼替代方案（例如 Thunderbit） |
|---|---|---|
| 設定時間 | 30–90 分鐘（Python/Docker/proxies） | 約 2 分鐘（瀏覽器擴充功能） |
| 維護 | 手動（你修故障） | 自動（供應商維護） |
| 客製化 | 高（完整程式碼存取） | 中等（AI 設定欄位） |
| 成本 | 軟體免費，但要付時間 + proxies | 有免費方案，之後 按點數計費 |
| 規模 | 取決於你的基礎設施 | 雲端擴展 |
「免費」GitHub 爬蟲其實是把帳單轉移到時間上。如果你把自己的時間估成每小時 50 美元，花 2 小時在設定、1 小時除錯、30 分鐘設定 proxy，那你在抓到任何一筆列表前，就已經花了 175 美元。再加上 proxy 成本和 Google 介面變動後的持續維護，「免費」選項立刻就不便宜了。
Thunderbit 如何簡化 Google Maps 抓取
實際上用 Thunderbit 的流程是這樣：
- 安裝 Thunderbit Chrome Extension
- 前往 Google Maps 並執行搜尋
- 點選 「AI Suggest Fields」 —— Thunderbit 的 AI 會讀取頁面並建議欄位（商家名稱、地址、電話、評分、網站等）
- 點選 「Scrape」，資料就會自動結構化
- 使用 子頁面爬取，從抓下來的 URL 進入每家商家網站，擷取更多聯絡資訊（Email、電話號碼）——把 GitHub repo 使用者得手動做的事自動化
- 匯出到 Google Sheets、Excel、Airtable 或 Notion —— 匯出沒有付費牆
不需要 Python。不需要 Docker。不需要 proxies。不需要維護。對做名單開發的業務與行銷團隊來說，這直接移除了 GitHub repo 原本需要的整個設定負擔。
價格背景： Thunderbit 採點數制，1 點 = 1 筆輸出列。免費方案每月涵蓋 6 個頁面，免費試用涵蓋 10 個頁面，入門方案為 每月 15 美元，或每年 9 美元可得每月 500 點。
抓完之後：整理與擴充你的 Google Maps 資料
大多數指南都停在原始擷取。原始資料不是名單。論壇使用者經常回報 「many formatting issues which required significant data cleanup」 ，還會問「這種設定下你怎麼處理重複資料？」抓完之後，接下來才是真正的工作。
去除重複資料
重複資料會從分頁重疊、對重疊區域重複搜尋、涵蓋同一批商家的網格／bounding-box 策略，以及一家商家有多個列表而混入。
最佳實務的去重順序：
- 若爬蟲有暴露 place_id，就先用它比對（最可靠）
- 以正規化後的 商家名稱 + 地址 做精確比對
- 以名稱 + 地址做模糊比對，再用電話或網站確認
簡單的 Excel／Sheets 公式（COUNTIF、移除重複項）就能處理大部分情況。若資料量更大，用 pandas 寫個快速 Python 去重腳本會很有效。
正規化電話號碼與地址
抓回來的電話格式千奇百怪：(555) 123-4567、555-123-4567、+15551234567、5551234567。若要匯入 CRM，請統一成 E.164 格式——也就是 + 國碼 + 國內號碼，例如 +15551234567。
Thunderbit 在抓取時會自動將電話號碼正規化為 E.164 —— 少做一道清理步驟。
地址則建議統一格式：街道、城市、州／省、郵遞區號。移除多餘空白、修正縮寫不一致（St vs Street），若準確度很重要，可用地理編碼服務驗證。
用 Email、網站與社群資料做擴充
Google Maps 列表幾乎一定會有網站 URL，但幾乎不會直接附上 Email。最有效的流程是：
- 先抓 Maps 做商家發現（名稱、地址、電話、網站 URL）
- 再造訪每家商家網站，擷取 Email、社群連結與其他聯絡資訊
這正是最好的 GitHub repo 與無程式碼工具會在這裡交會的地方：
- gosom/google-maps-scraper 提供可選的 Email 擷取，方式是造訪商家網站
- Thunderbit 的子頁面爬取功能 可以從抓下來的 URL 前往每家商家網站，擷取 Email 與電話號碼——而且全部會附加回原始表格
對沒有內建擴充功能的 GitHub repo 使用者來說，這代表你得寫第二個爬蟲，或手動逐站造訪。Thunderbit 把這兩步濃縮成一個流程。
匯出到你的 CRM 或工作流程工具
最實用的匯出目的地有：
- Google Sheets：方便協作清理與分享
- Airtable：適合有篩選與檢視的結構化資料庫
- Notion：輕量級營運資料庫
- CSV/JSON：適合匯入 CRM 或後續自動化
Thunderbit 支援 直接匯出到這些格式。大多數 GitHub repo 只匯出 CSV 或 JSON——CRM 整合得你自己處理。如果你想了解更多把抓取資料送進試算表的方法，也可以看我們的 如何抓取到 Google Sheets 指南。
Google Maps 爬蟲 GitHub repo：完整對照表
這裡是適合收藏的總結表，涵蓋所有做法：
| 工具／Repo | 類型 | 成本模式 | 設定時間 | Proxy 管理 | 維護 | 匯出選項 | 2026 年還能用嗎？ |
|---|---|---|---|---|---|---|---|
| Google Places API | 官方 API | 每 1K 次呼叫 7–32 美元（Pro） | 低 | 不需要 | 低 | JSON / 應用整合 | ✅ |
| gosom/google-maps-scraper | GitHub OSS | 免費 + proxies + 時間 | 中 | 有，且有文件 | 高 | CSV、JSON、DB、API | ⚠️ |
| omkarcloud/google-maps-scraper | GitHub 封裝版 | 幾乎免費、產品化 | 中 | 不清楚 | 中高 | 應用輸出 | ⚠️ |
| gaspa93/googlemaps-scraper | GitHub 評論爬蟲 | 免費 + 時間 | 中 | 有限 | 中高 | CSV | ⚠️（利基） |
| conor-is-my-name/google-maps-scraper | GitHub Docker API | 免費 + 時間 | 中 | 可能需要 | 高 | JSON / Docker service | ⚠️ |
| Zubdata/Google-Maps-Scraper | GitHub GUI app | 免費 + 時間 | 中 | 有限 | 高 | 應用輸出 | ❌ |
| Thunderbit | 無程式碼擴充功能 | 點數／列 | 低 | 已抽象化（雲端） | 低中 | Sheets、Excel、Airtable、Notion、CSV、JSON | ✅ |
如果你想更了解不同抓取方法的選擇，也可以看看我們整理的 最佳自動化網頁爬取工具 懶人包，或是 網頁抓取 vs. 資料探勘 的比較。
法律與服務條款考量
篇幅不長，但很重要。
Google 目前的 Maps Platform 條款寫得很明確：客戶不得為了服務外用途而 「export, extract, or otherwise scrape Google Maps Content for use outside the Services,」 ，其中包括在允許的服務使用範圍之外，複製和儲存商家名稱、地址或使用者評論。Google 的服務特定條款也只允許某些 API 有限快取，通常 最多連續 30 個曆日。
法律層級很清楚：
- 使用 API 的合約基礎最明確
- GitHub 爬蟲 運作在更灰色的地帶
- 無程式碼工具 能降低營運負擔，但不會免除你自己的合規責任
請針對你的具體情境諮詢法律顧問。若想更深入了解法律面，我們另外整理了 網頁抓取的法律影響 。
重點整理：2026 年該怎麼選 Google Maps 爬蟲方案
在研究了 repo、issue、論壇與價格頁之後，現況大致如下：
-
在投入設定時間之前，一定要先檢查 repo 新鮮度。 星數不是「今天還能用」的保證。看最近 3 個 issue，再看最近 3–6 個月內是否有程式碼提交。
-
目前最好的開源方案是 gosom/google-maps-scraper——但即使它也有 2026 年新的欄位退化問題。把它當作需要監控的活系統，而不是設定好就能放著不管的工具。
-
Google Places API 是穩定性與法律清晰度最好的答案——但它有上限（最多 5 則評論、按次計價），而且不太適合大量探索。
-
對非技術團隊來說，像 Thunderbit 這樣的無程式碼工具是更務實的替代方案。 從設定到拿到第一批資料的時間差是幾分鐘，不是幾小時，而且你也不用變成兼職爬蟲維護者。
-
原始資料只完成一半。 請預留時間做去重、電話正規化、Email 擴充，以及 CRM 匯出。能自動處理這些步驟的工具（例如 Thunderbit 的子頁面爬取與 E.164 正規化）通常能省下比你想像更多的時間。
-
「免費爬蟲」最好理解為：附帶未付費維護的軟體。 如果你有技能，而且喜歡這類工作，那很合理。但如果你只是個業務，想在週五前拿到 500 筆鳳凰城牙醫名單，那就是很差的交易。
如果你想探索更多商家資料擷取方式，可以看看我們的 用 Python 抓 Google Maps、最佳 Google 地圖評論爬蟲，以及 最佳資料擷取工具 指南。你也可以在 Thunderbit YouTube 頻道 看教學影片。
常見問題
從 GitHub 使用 Google Maps 爬蟲是免費的嗎？
軟體本身免費，工作不是。你會花 30–90 分鐘設定、之後持續花時間排除故障，而且若有實際量體，proxy 成本常常每月還要 10–100 美元以上。如果你的時間有價值，「免費」其實名不副實。
使用 GitHub 的 Google Maps 爬蟲需要 Python 技能嗎？
大多數熱門 repo 都需要基本的 Python 與命令列知識。Docker 優先的 repo 雖然降低負擔，但並不代表完全不用技術——你仍然要除錯容器問題、設定搜尋參數，並處理 proxy 配置。對非技術使用者來說，像 Thunderbit 這類無程式碼工具提供了 2 步驟替代方案，不需要寫程式。
Google Maps 爬蟲 GitHub repo 多久會壞一次？
沒有固定排程，但目前 GitHub issue 歷史顯示，核心故障與欄位退化會以數週到數月的週期出現。Google 會定期更新 Maps 介面，讓 selector 和解析邏輯在一夜之間失效。活躍 repo 會快速修復；停止維護的 repo 就會一直壞下去。
我可以用 GitHub 爬蟲抓 Google Maps 評論嗎？
有些 repo 支援完整評論擷取（gaspa93/googlemaps-scraper 就是專門做這件事），但有些只會抓摘要資料，例如評分和評論數。評論也是 Google 改變頁面行為時最先出現漂移的欄位之一——所以即使是支援評論的 repo，在 UI 更新後也可能回傳不完整資料。
如果我不想用 GitHub 爬蟲，最好的替代方案是什麼？
主要有兩條路：使用 Google Places API，獲得官方、結構化的存取方式（但有成本與欄位限制）；或用 像 Thunderbit 這樣的無程式碼工具，快速、由 AI 驅動地擷取資料，不需要寫程式。API 最適合需要合規確定性的開發者。Thunderbit 最適合想快速把資料放進試算表的商務使用者。
進一步閱讀
